Subject: Re: [lisp] Map-Versioning

From: Luigi Iannone <[email-masked]>
Date: Tue, 7 Jul 2009 16:28:38 +0200

On Jun 22, 2009, at 21:00 , Dino Farinacci wrote:

>> Yes, but let me push things a bit .. ;-)
>> What about splitting the nonce_version number in two parts as  
>> suggested in our draft? This is very helpful in case of  
>> unidirectional traffic.
>
> Let's focus on this part for now. Which I think is an important  
> issue. Let's frame the situation up as we have site A sending  
> packets to site B. The traffic is unidirectional to home in on your  
> point.
>
> Let's call the ITRs at site A ITR "a" and ITR "a'" and "b" and "b'"  
> are the ETRs at site B. Even if a or a' send to b or b', those LISP  
> routers at site B don't have any map-cache state for site A.
>
> When site B wants to update it's mapping database entries, neither b  
> or b' will SMR because it thinks it's not talking to anyone. Plus,  
> it has no offered data to send them, so it can't send an SMR-bit.
>
> You like the idea of putting two version numbers in so Site A can  
> tell Site B what version of B's mappings it is using.
>
> Tell me if I am ac curatively describing your position?
>
> ... (pause and think before continuing below)

After one week thinking... ;-))

Agreed
(one could argue that B can keep mappings for A just to have some more  
security checks when coupled with the nonce, but this is another story)

>
> If the LISP routers at site B see that anyone is out of date, they  
> would need to send something to the ITRs of site A. Well we don't  
> want the LISP routers of site B to send a Map-Reply because that  
> could be unsolicited. We would want the ITRs to send a Map-Request  
> over the mapping database infrastructure to get updated. But we want  
> them to do it at the rate that site B can handle the Map-Request load.
>
> So one solution is for the site B LISP routers to send a Map-Request  
> to site A with the SMR-bit set. Which in turn has the site A LISP  
> routers send a Map-Request. This would fall into the current design.
This is what we call "Map-Update-Notification" in draft-iannone-lisp- 
versioning.

>
> ... (pause and think before continuing below)

After a second week thinking.... ;-))

This is the whole point, with the current design of LISP design you  
have not mean to make B understand that A is using a stale mapping.

What you can do is to "guess" that that's the case. What if you have  
the case (I already pointed this out previously, but had no answer) A  
will stop send for a while, in the meantime the mapping changes, then  
A starts to send with the same mapping because the original TTL is not  
expired. How you deal with that?

Please Dino, do not reply that when A starts again sending traffic, B  
will send a Map-Request with SMR bit just to be sure that A will  
update the mapping.  If we use Map-Request/Map-reply for everything,  
LISP will consume the whole Internet's bandwidth in signaling.

Putting versioning into the header (meaning 2 version numbers),  
despite what you think,  does the job (and even more) in a very   
simple and elegant way.

It does not need any further space/state in the mapping, since the  
point is to give a different semantic to part of the 8 bytes used for  
the LISP header.

>
> But while we have been experimenting with RLOC reachability  
> liveness, you might think of an option where site A LISP routers  
> might be sending Map-Requests to site B routers to make sure the  
> locators the site A routers are using are up and operational. Well  
> depending on how often this is done, the keepalive replies which are  
> in the form of Map-Replies would have more up to date mapping data.

1. Active probing does not scale (you yourself pointed this out some  
time ago).

2. This approach has limited reactivity.

3. One can argue that RLOC reachability should be ensured by the  
routing infrastructure (think about fast-reroute) and not by LISP.

>
> All I'm trying to say here is that maybe using the basic Map-Request  
> and Map-Reply machinery we can solve liveness and fast mapping  
> updates at the same time.

Careful here. Your statement does not consider the overhead in terms  
of probing that you have to do in order to discover things that  
versioning tells you right away. Think about it....

Luigi

> Just thinking out loud,
> Dino

---

From: John Zwiebel <[email-masked]>
Date: Tue, 14 Jul 2009 09:39:58 -1000

> After one week thinking... ;-))

A few observations....

In para 3:
   --  if you are allocating only 15 bits for the map version why  
does your example use 24 bits?
   -- There appears to be some formatting problems here, is it just  
that the brackets are facing the wrong way?

    As an example, using 24 bits, if the Mapping Version Number is 0,
    versions in ]1; (2**14)-1[ are greater and versions in [2**14;
    (2**15)-1[ are smaller.

   -- FWIW:  s/half the versions is/ half the versions are

5.0: "carrying"
    The purpose of carring these version numbers is two-fold, allowing

    FWIW  change "does not hold" to "is not true" and I get it.  I  
first read
    it to mean the first condition was 'holding' the Map-Update- 
Notification.

     If the first condition does not hold the
    Map-Update-Notification (see Section 8) is used to make the ITR  
aware
    that a newer mapping is available.

     "detailed"
    header format is detailled in Section 6 (Figure 2).

5.1
   -- The ETR receives a packet from where?  What is a "domain"?  (I  
think you mean EID-space)
	I had to read this entire section and start the next before I  
figured it out.

   -- what is a LEID?

   -- rather than "can" shouldn't this be MUST|SHOULD|MAY?  (or is  
this a decision to be made later?)

       packets coming from that ITR with smaller mapping version number
       can be silently dropped, since most likely there is a spoof or  
the

5.2
   -- likewise, starting this section with "when an ETR receives a  
packet", misled me into what you were
	trying to describe.

  -- sent
       been send and a Map-Reply has been received.  The latter sent by

-- s/anyhow/somehow
       corrupted anyhow, the mapping version in the EID-to-RLOC Cache is

6.0
-- FWIW, IMHO minutes should be used and therefore the number of bits  
allocated should be fewer so
	I'd rather see.  (or perhaps we could use 1/10 of a minute?  11 days  
to run through the version
	number circle seems awfully long, especially for something that  
shouldn't change that much.)

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      / |Res|    Source Mapping V.N.      |  Destination Mapping V.  
N.  |
    LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
      / |Res|    Source Mapping V.N.    |res|  Destination Mapping V.  
N.|
    LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

9.3
   -- I cannot see how this would work.  If it were up to me at this  
early stage I'd just have everyone update
	on a flag day to a OS image that supports map-versioning.  Yes,  
there will be a lot of headaches making
	this happen, but far, far fewer than trying to debug why things  
aren't interoperating.  (2cents)

10.1
   -- Huh?  ;-)

10.2
   -- s/loses/looses

    DDoS attacks, where an xTR looses processing power doing version

10.4
   -- s/scenario/scenarii

    The scenarii presented in the previous sections are correct if ETR

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 14 Jul 2009 22:21:36 +0200

John,

thanks a lot for the comments, they will be included.

very few answer inline.

Cheers

Luigi

> does your example use 24 bits?

Agree.
In the draft we do not propose exactly how many bits to use. How  
intent was to discuss this in the WG.

>    versions in ]1; (2**14)-1[ are greater and versions in [2**14;

Mathematical notation. The part with brackets "facing the wrong way"  
means that the last value is not included.

> -- FWIW, IMHO minutes should be used and therefore the number of  
> bits allocated should be fewer so
> 	I'd rather see.  (or perhaps we could use 1/10 of a minute?  11  
> days to run through the version

Agreed. Upgrading should be concerted with all people participating in  
the LISP testbed  and the main developers of LISP.