[DRAFT] Add vl3ipam

[glazychev-art]

Signed-off-by: Artem Glazychev artem.glazychev@xored.com

Description

vl3-ipam has behavior:

1. If we receive a request from vl3-NSE and it hasn't IP (srcIP) - we allocate it from its CIDR (it is stored in ExtraPrefixes - link).
2. If we receive a request from NSC and it hasn't IP (srcIP) - we allocate it from our CIDR (like point2pointipam)
3. If we don't have our IP address (dstIP) - we allocate it from our CIDR and store in map[NetworkServiceName]ipAddress. In this case we have only one IP for a given NetworkService.
4. All of the allocated addresses have /32 mask

Issue link

networkservicemesh/cmd-nse-vl3-vpp#1

How Has This Been Tested?

• Added unit testing to cover
• Tested manually
• Tested by integration testing
• Have not tested

Types of changes

• Bug fix
• New functionallity
• Documentation
• Refactoring
• CI

[glazychev-art]

@denis-tingaikin @edwarnicke
Could you please take a look and provide overall review about of this chain element?

[edwarnicke]

A few comments:

1. Usually the NSE owns issuing of IPs. Why would an NSC provide ExtraPrefixes in its Request and why would we use that as the space from which the NSE makes its selection rather than having the NSE issue an address from its own prefixes?
2. How are we telling the difference between an vl3-NSE and an NSC as the originators of a request?

[glazychev-art]

@edwarnicke
I suggest logic like this:

How are we telling the difference between an vl3-NSE and an NSC as the originators of a request?

If Request has ExtraPrefixes it means that we received Request from vl3-NSE. If doesn't - from NSC

Usually the NSE owns issuing of IPs. Why would an NSC provide ExtraPrefixes in its Request and why would we use that as >the space from which the NSE makes its selection rather than having the NSE issue an address from its own prefixes?

NSC doesn't provide ExtraPrefixes. Only vl3-NSE should do it.
If we got the Request from NSC - we act like point2pointipam - issue an address from NSEs own prefixes.
If we got the Request from vl3-NSE - issue an address from ExtraPrefixes.

[edwarnicke]

@glazychev-art Could you talk through what you see as the sequence of events here end to end?

[glazychev-art]

@edwarnicke
Yes. Also, please take a look at networkservicemesh/cmd-nse-vl3-vpp#1 (comment), there is a set of chain elements for vl3-NSE client and vl3-NSE server.

So, we have 2 types of clients - NSC and vl3-NSE.

vl3-NSE
vl3-NSE client has cidr chain element , that adds ExtraPrefixRequest to Request. And also does some things to create interfaces (main and loopback), vrf and so on...

vl3-NSE client Request on the vl3-NSE server side:

1. Request get to cidr server chain element, that extracts us prefixes according to ExtraPrefixRequest
2. Request get to vl3-ipam server chain element. If there is ExtraPrefix in this Request (LINK) - we believe that this is vl3-NSE client. And if there is no SrcIpAddress - vl3-ipam allocates it from ExtraPrefix. We set SrcIpRequired = false
   Next, we need to pull DstIpAddress. We check if we have already allocated DstIp for requested service? (because we need only one DstIp for loopback) . If yes - use it, if no - allocate new address.
   Next, we need to add routes - add all prefixes, that has this vl3-ipam, because in theory we can reach all hosts through this endpoint.
3. Next vl3-NSE client becomes vl3-NSE server (after interfaces creation, vrf, registration and so on...). At this point we already have our own IPAddress from our ExtraPrefix. We need to pass it to vl3ipam.NewServer() to exclude it from allocation for the next clients.

NSC
NSC doesn't have cidr chain element and doesn't have ExtraPrefix. So, we set SrcIpRequired = true and extract SrcIP from vl3-NSE pool.

All ip-addresses have /32 mask

I think that's basically all. Do I need to clarify something?

[glazychev-art]

Close. See: networkservicemesh/api#126