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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
