Subject: [lisp] Some basic questions ...

From: Marc Binderberger <[email-masked]>
Date: Mon, 17 Feb 2014 01:30:51 -0800

Hello LISP experts,

have two questions, mainly to understand the context a bit better.

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

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)

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

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?

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)

Thanks & Regards,
Marc

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Feb 2014 10:13:16 -0800

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

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

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

> Map-Notify restricted to be just an ACK? (having an extra type for it 

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.

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

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

> byte sequence exactly?  Loc-AFI + Locator? (both in network order, 

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-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 17 Feb 2014 17:31:53 -0800

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

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:
> 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.
> 
> 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.
> 
> (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?
> 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.
> 
> 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.
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Feb 2014 07:53:59 -0800

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

> 0a.00.00.02

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.

> source-lookup or things like reverse-path forwarding lookups. For 

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

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

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

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

> 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

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 20 Feb 2014 16:41:47 -0800

Hello Dino,

there was another question I forgot regarding the notifications: so 
when the map-notification is not used as an ACK for map-register but is 
actually informing the ETRs about events then how is the delivery 
guaranteed? The underlying IP/UDP transport may drop.

For map-register we periodically send again, so packet loss of 
map-registers is not a big problem. What is your idea for map-notifies? 
Some of the notifications may be singular events. Other of course could 
be periodic (e.g. merge notification triggered by the map-registers?).

Would I need an ACK for the map-notification (and some fast-timer 
re-send, e.g. every 1sec until ACKed) ?  That would take state/timer, 
although only until's it's ACKnowledged.

Thanks & Regards,
Marc

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Feb 2014 17:55:25 -0800

> guaranteed? The underlying IP/UDP transport may drop.

The Map-Server sends Map-Notify messages to the ETR and the ETR responds with Map-Notify-Ack messages.

> be periodic (e.g. merge notification triggered by the map-registers?).

These are not perioidic, because only when there are locator-set changes, the Map-Notify messages are sent by Map-Servers.

> although only until's it's ACKnowledged.

Yes, they are called Map-Notify-Ack messages. They contain the same contents as the Map-Notify but just with a different type value.

Dino