Subject: Re: [lisp] [#5] LISP protocol version

From: Damien Saucez <[email-masked]>
Date: Thu, 10 Sep 2009 19:17:04 +0200

Sorry for re-opening this thread.

Margaret Wasserman wrote:
>
> On Aug 13, 2009, at 10:40 AM, Noel Chiappa wrote:
>>
>> Do we need a separate issue? To me, it's all part of 'protocol 
>> extensibility'
>> (although I guess, now that I write that phrase, that it covers a lot of
>> ground... :-). (It's not like I wildly object, just trying to 
>> minimize the
>> amount of scribal work.. :-)
>
> Sorry, I didn't realize (or forgot) that there was already an issue 
> open for this.
>
>> Again, we have a separate control-plane channel. So an xTR can easily 
>> check
>> to see if another node is running LISP by sending a LISP control-plane
>> message to it. If a particular user-data UDP encapsulation _then_ 
>> produces an
>> ICMP error, that pretty much says 'this encapsulation not supported'.
>>
>> Or we could define a control-plane interaction to ask/reply what 
>> user-data
>> encapsulations are supported. And there's always the Map-Reply thing 
>> (above),
>> too.
>
> These are good points.  A control-plane mechanism to determine what 
> version(s) of LISP an xTR supports (whether it is part of the mapping 
> reply or a separate control message) would address most of my reasons 
> for wanting a LISP data header version.  If necessary, the control 
> plane could even be used to negotiate what version to use.  This 
> negotiation could be very simple, like we use the highest version we 
> both support, but it would make it clear what version of LISP data 
> packets the ETR should expect to receive from a specific ITR.
Well, control-traffic to negotiate the version is a good idea and 
definitely has to be studied. However, a version number field is still 
helpful. For example, without a version field, gleaning won't work. 
Gleaning is used to avoid wasting time waiting for a mapping, you then 
send packets without any control-plane version negotiation. If you have 
the version in the LISP header, it is easy, you know the maximum LISP 
version you can use with the destination.

In addition, with the version field, you can even simplify the 
"negotiation protocol" to the minimum. A sends a Map-Request for B (with 
the maximum version you can support, just in case of crazy pre-mapping 
fetching from B) and the Map-Reply from B contains the maximum version 
that is supported by B's eTRs. Traffic can then be sent from A to B. 
When B has to send traffic to A, it sends a Map-Request to A and 
receives the version that is supported by A, B can then send traffic 
correctly to A.

Regards,

Damien Saucez

> Margaret
>
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 01:19:12 -0700

> definitely has to be studied. However, a version number field is  
> still helpful. For example, without a version field, gleaning won't  
> work. Gleaning is used to avoid wasting time waiting for a mapping,  
> you then send packets without any control-plane version negotiation.  
> If you have the version in the LISP header, it is easy, you know the  
> maximum LISP version you can use with the destination.

What type of gleaning are you referring to Damien? Data gleaning or  
gleaning the mapping data from a received Map-Request?

> "negotiation protocol" to the minimum. A sends a Map-Request for B  
> (with the maximum version you can support, just in case of crazy pre- 
> mapping fetching from B) and the Map-Reply from B contains the  
> maximum version that is supported by B's eTRs. Traffic can then be  
> sent from A to B. When B has to send traffic to A, it sends a Map- 
> Request to A and receives the version that is supported by A, B can  
> then send traffic correctly to A.

I don't think it needs to be this complicated. Let me show you with an  
example.

Say you have a map-cache entry that looks like this:

   10.0.0.0/8 -> {L1, p1, w50}, {L2, p1, w50}

That is what the current mapping database entries look like in xTRs L1  
and L2. Now let's say the site wants to change to active-backup rather  
than active-active. So then both L1 and L2 are changed to have this:

   10.0.0.0/8 -> {L1, p1, w50}, {L2, p2, w50}

So what happens is that the new mapping is registered with the map- 
server. So non-cachers that want to talk to this site will get the  
active-backup mapping. Existing cachers need to change from the active- 
active mapping to the active-backup mapping. So either L1 or L2 can do  
the following:

(1) When they are RLOC-probed by cachers, they return the active- 
backup mapping.
(2) They each send SMR-based Map-Requests which causes verifying Map- 
Requests to be received. L1 and L2 then send Map-Replies with the  
active-backup mapping.

or:

(3) Wait for the clock-sweep operational time-outs of the map-cache  
entries.

What I am trying to show here is that there is exactly 2 versions. The  
old one and the new one.

If a 3rd mapping was created, there is no reason for cachers to know  
about the 2nd mapping because the 3rd mapping is the latest and  
greatest. And you don't care if some cachers have the 1st mapping or  
the 2nd mapping cached. All they need is to get the 3rd mapping.

Therefore version numbers are not needed in the data plane for the  
control plane.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Fri, 11 Sep 2009 10:43:58 +0200

Dino,

> gleaning the mapping data from a received Map-Request?
data gleaning.
>> (with the maximum version you can support, just in case of crazy 
>> pre-mapping fetching from B) and the Map-Reply from B contains the 
>> sent from A to B. When B has to send traffic to A, it sends a 
>> Map-Request to A and receives the version that is supported by A, B 
>> can then send traffic correctly to A.
>
Oops, I think that we are not in sync, by version, I mean LISP protocol 
version, not mapping version. Or, if you prefer, how to know the meaning 
of each bit without having completely negotiated it before.

Cheers,

Damien Saucez
> So what happens is that the new mapping is registered with the 
> map-server. So non-cachers that want to talk to this site will get the 
> active-backup mapping. Existing cachers need to change from the 
> active-active mapping to the active-backup mapping. So either L1 or L2 
> can do the following:
>
> (1) When they are RLOC-probed by cachers, they return the 
> active-backup mapping.
> (2) They each send SMR-based Map-Requests which causes verifying 
> Map-Requests to be received. L1 and L2 then send Map-Replies with the 
> active-backup mapping.
>
> or:
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 01:55:40 -0700

>>> still helpful. For example, without a version field, gleaning  
>>> won't work. Gleaning is used to avoid wasting time waiting for a  
>>> mapping, you then send packets without any control-plane version  
>>> negotiation. If you have the version in the LISP header, it is  
>>> easy, you know the maximum LISP version you can use with the  
>>> destination.
>>

But you can't trust the encapsulator if you don't verify the EID. That  
is, if you have an encapsulator that uses its own address for sending  
from an EID that doesn't belong to it, you don't want to return  
traffic to that locator for the given EID.

That encapsulator can put any version number it wanted to in the data  
packet, so how do you trust it?

>>> Request to A and receives the version that is supported by A, B  
> Oops, I think that we are not in sync, by version, I mean LISP  
> protocol version, not mapping version. Or, if you prefer, how to  
> know the meaning of each bit without having completely negotiated it  
> before.

Okay.  ;-)

You really don't want to negotiate, because that could take multiple  
packet exchanges. You don't want to be dropping packets for multiple  
RTT times.

But at least you know how I feel about mapping versioning.

Cheers,
Dino

>
> Cheers,
>
> Damien Saucez
>> I don't think it needs to be this complicated. Let me show you with  
>> an example.
>>
>> That is what the current mapping database entries look like in xTRs  
>> L1 and L2. Now let's say the site wants to change to active-backup  
>> rather than active-active. So then both L1 and L2 are changed to  
>> have this:
>>
>> active-active mapping to the active-backup mapping. So either L1 or  
>> L2 can do the following:
>>
>> Map-Requests to be received. L1 and L2 then send Map-Replies with  
>> the active-backup mapping.
>>
>> or:
>>
>> What I am trying to show here is that there is exactly 2 versions.  
>> The old one and the new one.
>>
>> If a 3rd mapping was created, there is no reason for cachers to  
>> know about the 2nd mapping because the 3rd mapping is the latest  
>> and greatest. And you don't care if some cachers have the 1st  
>> mapping or the 2nd mapping cached. All they need is to get the 3rd  
>> mapping.
>>

---

From: Damien Saucez <[email-masked]>
Date: Fri, 11 Sep 2009 11:12:16 +0200

Dino Farinacci wrote:
>>>> you then send packets without any control-plane version 
agree, versioning is a hint (like Reach-bits were).
>> protocol version, not mapping version. Or, if you prefer, how to know 
>> the meaning of each bit without having completely negotiated it before.
>
> Okay.  ;-)
>
That's been clear for a long time  ;-)

Regards,

Damien Saucez

>>> map-server. So non-cachers that want to talk to this site will get 
>>> the active-backup mapping. Existing cachers need to change from the

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 09:12:16 -0700

>>>>> "negotiation protocol" to the minimum. A sends a Map-Request for  
>>>>> B (with the maximum version you can support, just in case of  
>>>>> crazy pre-mapping fetching from B) and the Map-Reply from B  
>>>>> contains the maximum version that is supported by B's eTRs.  
>>>>> Traffic can then be sent from A to B. When B has to send traffic  
>>>>> to A, it sends a Map-Request to A and receives the version that  
>>>>> is supported by A, B can then send traffic correctly to A.
>>>>
>>> know the meaning of each bit without having completely negotiated  
>>> it before.
>>
>> Okay.  ;-)
>>
>> You really don't want to negotiate, because that could take  
>> multiple packet exchanges. You don't want to be dropping packets  
>> for multiple RTT times.
>>

I want to make it perfectly clear, I still would like to see studies  
on this. Because we can all learn and understand the value/cost  
tradeoffs. I think what you guys are doing is a great effort!

Dino