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. 

Yes, it may appear that way but we stated explicitly that IPv4 addresses appear before IPv6 addresses. So within an address-family the byte value is the order.

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.

It really isn't important about the order. We just wanted multiple ETRs at a site to use the same order so the LSBs were consistenly mapped to the RLOC address in the locator-set.

> 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 

Yes, you are not the first person who has mentioned this.

> pipelined-ASICs this was another stage to be added. I other words: 
> receiving LSBs for all packets from an ITR, detecting a change in 

This is true. We do believe though that LSBs will be mostly used in CPE routers where the boxes are either micro-coded or forwarding is done in software.

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

You could implement it this way. But that could be a lot of packets going to the punt path.

> 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 

We wanted a data-plane/fast way to swtich from one RLOC to another. That is put some simple control-plane functionality in the fast path of forwarding.

> simple scheme and don't support it if your hardware isn't ready, there 
> are more methods available for RLOC change detection" ?

Set the L-bit to 0 in the LISP header if you don't want it.

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

Understand. Thanks for asking and wondering.

Dino

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