Re: [lisp] Some basic questions ...

Hello Dino & LISP experts,

thanks for the quick reply.

I have some follow-up questions, simplest first.

Q3': I'm a bit slow with the lexiographic order and from a web search I 
have seen both, "treat it as a text string" as well "treat it as a byte 
sequence".

> 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

so this is sorting according to the text representation (?!). Okay. 
Because a "byte string comparison would give a different result:

0a.00.00.01
0a.00.00.02
20.01.10.00.00.00.00.00.00.00.00.00.00.00.00.01
20.02.10.00.00.00.00.00.00.00.00.00.00.00.00.01
20.02.11.11.00.00.00.00.00.00.00.00.00.00.00.01
80.00.00.01
80.80.00.01
80.c0.00.01

Would this be worth an addendum to RFC6830?  Or maybe it's just me :-)
Anyway, got it now.

Q1': Thanks for the clarification on the map-notify. 

Q2': regarding the LSBs:

> 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.

true but there had been times when "hardware" could not do 
source-lookup or things like reverse-path forwarding lookups. For 
pipelined-ASICs this was another stage to be added. I other words: 
receiving LSBs for all packets from an ITR, detecting a change in 
hardware, then punting to control plane seems to put the bar for the 
hardware higher than just a simple check for the L bit and punting 
whenever it is set (which would be only for a few packets after the ITR 
knows about the source RLOC changes).

My question is mainly about: what was the reason to go for "sending 
LSBs all packets" (when LSBs are supported) ?  Is the answer to "it's a 
simple scheme and don't support it if your hardware isn't ready, there 
are more methods available for RLOC change detection" ?

Just trying to understand, not arguing about right/wrong/better/[...] .

Thanks & Regards,
Marc

On Mon, 17 Feb 2014 10:13:16 -0800, Dino Farinacci wrote:
>> 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
> 