Re: [lisp] Some basic questions ...

> Hello LISP experts,
> 
> have two questions, mainly to understand the context a bit better.

No prob Marc. Thanks for the email. I'll attempt to answer them but others can chime in as well.

> Q1: map-notify message.
> 
> maybe it's the name but I always expected this message is for the Map 
> Server to inform ETRs. Kind of a "push" method. But reading RFCs 6830 

That is exactly what it is. It is used as a event notification from the Map-Server to the ETRs that register for a particular EID-prefix. So when a locator-set changes, the old locators can be notified. The main reason to call it a "Map-Notify" was for this purpose. And you can now understand why by looking at the data-center use-case documents that have been published by Yves and Victor.

> and 6833 again it seems that the Map-Notify is simply an ACK for a 
> received and processed Map-Register message. Take the Map-Register 
> message, set the type to Map-Notify and send back.

So when a registerer requests Map-Notifies, it will get them for various reasons. The first is the case I said above and the other case is to acknowledge a Map-Register.

> Now, the use as ACK is not a contradiction to the broader use as a push 
> message. So my question to the LISP experts and inventors is: is 
> Map-Notify restricted to be just an ACK? (having an extra type for it 
> seems generous)

It is not restricted to just an ack. There is also another use case. Here it is:

(1) You have two xTRs, each sitting behind different NAT devices.
(2) The xTRs get private addresses assigned to their interfaces. So they are using them as "local RLOCs". But no one will be able to encapsulate to them so they need to find out their global RLOC addresses.
(3) Each of the two xTRs are at the same LISP site and can receive encapsulated packets for the same EID-prefix.
(4) When they each discover their global RLOCs (by mechanisms descrbied in draft-ermagen-lisp-nat-traversal), they each register their own global RLOC. They register with the "merge-request" bit set so the Map-Server will add both xTR global RLOCs to the locator-set.
(5) So now, if an xTR gets a Map-Request, it will want to send a Map-Reply with the merged-locator set. Well how will it do that when it only knows its own?
(6) A Map-Notify is used here by the Map-Server to tell each xTR about the other's global RLOC.

> Q2: Locator-Status-Bits (LSBs).
> 
> RFC 6830 says in section 6.3:
> 
>   When an ETR decapsulates a packet, it will check for any change in
>   the 'Locator-Status-Bits' field.
> 
> I interpret this that if an ITR sets the Locator-Status-Bits then it 
> would do so permanently. In other words the LSBs are not set used in an 
> "alert style" (means: only set when an RLOC change happened) ?

If an ITR detects that other xTRs at its site have gone down, it will clear the LSBs for that xTR. The LSBs are used as a hint to tell remote xTRs that something went wrong from the perspective of a local xTR at the site.

If you have, say, 3 xTRs at a site and you want to take one out of service for maintenance or whatever, the other 2 could clear the LSB bit for that xTR to gracefully migrate remote encapsulation traffic to this site to only the 2 xTRs.

> Wondering what requirements this imposes on the data plane. It may not 
> be possible for the "hardware" (NP, ASIC, FPGA) to check the incoming 
> LSBs. So if LSBs are sent permanently this would likely require to punt 
> every Nth packet to the control plane?

This is not different than a cost to do a source lookup for a IP multicast packet. Yes, you would have to do a source-EID lookup on the received packet at the ETR and update the LSBs for the map-cache entry.

> Q3: the lexicographic order of RLOCs.
> 
> Maybe stupid question but the lexicographic order is computed over what 
> byte sequence exactly?  Loc-AFI + Locator? (both in network order, 
> Loc-AFI first)

The value of the locator address itself. So for instance an RLOC set below is sorted in lexiographic order:

10.0.0.1
10.0.0.2
128.0.0.1
128.128.0.1
128.192.0.1
2001:1000::1
2002:1000::1
2002:1111::1

Dino

> 
> 
> 
> Thanks & Regards,
> Marc
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp