Subject: [lisp] #5: LISP protocol version is alive and kicking

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Sep 2009 08:53:08 -0400

Folks, we've had some discussion on issue #5 regarding LISP protocol
versioning.  It's quite clear that we don't have consensus behind any
specific proposal at the moment.

However I've starting to see vague support behind doing something in
this space.  In particular, we have Margaret's LISP format proposal,
which was discussed under #16.  Damien made a different proposal--to
actually have an ordered set of versions.  noel seems to support
something especially in terms of control plane negotiation.

Dino raised an objection against Damien's proposal that you don't want
to have multiple round trips of negotiation.  As far as I can tell,
Damien's proposal doesn't suffer from the issue Dino is concerned
about.  In particular, the only form of negotiation he had is that the
sender let you know what version he supported, often before you sent a
packet to the sender.

I'd encourage those interested in seeing forward progress on this
issue to get together and see if they can form a concrete proposal.
It may turn out that we don't know enough to turn this into something
concrete.

---

From: Damien Saucez <[email-masked]>
Date: Fri, 18 Sep 2009 09:19:33 +0200

> sender let you know what version he supported, often before you sent a
Yes, we do not really need negotiation. The first time a packet has to 
be exchanged between A and B, a Map-Request has to be sent. For the 
example, we will consider 1 packet from A to B and then a packet from B 
to A. Consider A runs version 42 of the LISP protocol and B runs version 
666.

1. A sends a Map-Request.
2. A receives a Map-Reply for B's EIDs: in the mapping, the LISP 
protocol version is 666
3. A sees that version is 666 but she only supports up to 42
4. A sends a data packet to B with protocol version 42 and a field 
indicates this protocol version number.
5. When B want to send a packet to A. Two solutions:

6a. B sends a Map-Request for A.
7a. The Map-Reply for A's EID is with protocol version number 42

6b. B has a data gleaning entry for A with protocol version field 42
7b. NOP

8. B sees that version is 42 then, even if B supports versions up to 
666, she will decide to use version 42 only.
9. B sends a data packet to A with protocol version 42 and a field 
indicates this protocol version number.

That's it! The negotiation is half-implicit ( ;-) ) And no extra delay 
is required.

The previous mails was just to show that protocol version must be in the 
data packets if we want to avoid extra delay due to explicit negotiation.

Regards,

Damien Saucez

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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 18 Sep 2009 00:45:45 -0700

Are we talking about mapping versions or protocol versions. This is  
very confusing. My comment about negotiation was about protocol  
versions. I object to protocol versions because they can be  
implemented with a new UDP port number of a new LISP control packet  
type in port number 4342.

The statement below "A runs version 42 of the LISP protocol ..." is  
misleading.

So let me comment below as if you are talking about mapping updates.

> Yes, we do not really need negotiation. The first time a packet has  
> to be exchanged between A and B, a Map-Request has to be sent. For  
> the example, we will consider 1 packet from A to B and then a packet  
> from B to A. Consider A runs version 42 of the LISP protocol and B  
> runs version 666.
>

When A receives a Map-Reply from B, it gets the latest version.

> 6a. B sends a Map-Request for A.

You don't have to do this. When A sent the initial Map-Request, the  
mapping was present for A. B can just verify it by sending a Map- 
Request back.

> That's it! The negotiation is half-implicit ( ;-) ) And no extra  
> delay is required.
>
> The previous mails was just to show that protocol version must be in  
> the data packets if we want to avoid extra delay due to explicit  
> negotiation.

This is a long description to make this point:

o Putting a mapping version number in a data packet is useful to tell  
an ETR when an ITR has an
   old mapping.

o This is useful because PTRs encapsulate packets to ETRs. But ETRs  
never return traffic to them so
   ETRs don't and can't have mappings for the PTRs (because PTRs don't  
have database-mapping entries
   since they are only encapsulators). So ETRs cannot send SMR-based  
Map-Requests to them.

o So the PTR can only tell the ETR to update it when the ETR finds out  
it has an old mapping.

That is the only and best use for version numbers in a data packet.  
And as Noel said, you only want to use versions when you want to  
support multiple variants of the mapping at one time. That's not  
necessary so a checksum is sufficient so the PTR can tell the ETR it  
has something different than the ETR does. And of course, the ETR  
always has the most current information because it owns it and is  
authoritative for it.

So if mapping updates don't happen often, why do mapping version  
numbers or checksums have to go in every data packet? That is the crux  
of the argument.

If you say that the mapping version number can go in some packets  
versus others. That means the PTR is asking at its own defined  
frequency for updates.

So if it can do that, it can do it in the control plane. It can do  
that with Map-Requests, and if it sends Map-Requests, it gets path  
liveness detection at the same time. That is why I suggest using RLOC- 
Probes.

So if you are sensitive to RLOC-Probes and say putting the request in  
a data-packet would be cheaper, then you have to deal with idle  
sources, and you still have the overhead of a Map-Reply returning.

Having said all this, my conclusion is that doing this in the control- 
plane gives you more flexibility and is not dependent on data  
frequency or behavior.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Fri, 18 Sep 2009 10:56:07 +0200

Dino,

I am talking about protocol version (e.g., the build release of the 
protocol), not the version of the mappping.

Dino Farinacci wrote:
> very confusing. My comment about negotiation was about protocol versions.
mine too.
> I object to protocol versions because they can be implemented with a 
> new UDP port number of a new LISP control packet type in port number 
> 4342.
>
I don't like the idea that the port give the version if you support 
several version, you consume several ports. If every body does like 
this, will face the port exhaustion rapidly and have the same problem 
that we have today with IPv4 address exhaustion. I am convinced that the 
cost of reserving 8 bits for a protocol version field is a cost that we 
can afford.
> So let me comment below as if you are talking about mapping updates.
sure, but I was not discussing mapping versions ;-)
> When A receives a Map-Reply from B, it gets the latest version.
ok
> mapping was present for A. B can just verify it by sending a 
> Map-Request back.
>
what if B itr and B etr are disjoint?
> This is a long description to make this point:
I don't agree, because we are not discussing the same thing. I put an 
example to answer Sam's mail and to confirm he was right. But I listen 
for your remark on map versioning that are interesting, even if it is 
another context.
> numbers or checksums have to go in every data packet? That is the crux 
Yes, but when they happen, how to know the change ASAP?
> liveness detection at the same time. That is why I suggest using 
> RLOC-Probes.
>
> Having said all this, my conclusion is that doing this in the 
> control-plane gives you more flexibility and is not dependent on data 
> frequency or behavior.
>
agree, it only depends the overhead you are ready to accept. But let me 
turn the argument back to you and ask: "so, why do not move the status 
bits in the control plane and remove them of the dataplane?"

Thanks,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 18 Sep 2009 02:19:41 -0700

>> versions.
>> I object to protocol versions because they can be implemented with  
>> a new UDP port number of a new LISP control packet type in port  
>> number 4342.
>>
> this, will face the port exhaustion rapidly and have the same  
> problem that we have today with IPv4 address exhaustion. I am  
> convinced that the cost of reserving 8 bits for a protocol version  
> field is a cost that we can afford.

But a version number is no different than a new type value for a  
control packet. If you encoded Map-Request, you just allocate a new  
type value.

> sure, but I was not discussing mapping versions ;-)

Okay. So save my response for Luigi.  ;-)

>>> Yes, we do not really need negotiation. The first time a packet  
>>> has to be exchanged between A and B, a Map-Request has to be sent.  
>>> For the example, we will consider 1 packet from A to B and then a  
>>> packet from B to A. Consider A runs version 42 of the LISP  
>>> protocol and B runs version 666.
>>>

If ITR-only A sends a Map-Request with its own mapping data to ETR- 
only B, B can send a verifying Map-Request back. There is no reason  
why an *ETR* can't send a Map-Request.

>>> 8. B sees that version is 42 then, even if B supports versions up  
>>> to 666, she will decide to use version 42 only.
>>> The previous mails was just to show that protocol version must be  
>>> in the data packets if we want to avoid extra delay due to  
>>> explicit negotiation.
>>
> I don't agree, because we are not discussing the same thing. I put  
> an example to answer Sam's mail and to confirm he was right. But I  
> listen for your remark on map versioning that are interesting, even  
> if it is another context.

Sure, but for protocol versioning, you are exchanging the protocol  
version for every mapping transaction. That is redundant and not  
necessary. If A is running version 42 and B is running version 666,  
why does it need to ask this for every Map-Request exchange.

It might lead one to believe the protocol versions *could be*  
different per EID being requested. Don't think that was your intent.  
So the point is, the versioning exchange is too granular.

>> o Putting a mapping version number in a data packet is useful to  
>> tell an ETR when an ITR has an
>>  old mapping.
>>
>>  ETRs don't and can't have mappings for the PTRs (because PTRs  
>> don't have database-mapping entries
>> o So the PTR can only tell the ETR to update it when the ETR finds  
>> out it has an old mapping.
>>
>> necessary so a checksum is sufficient so the PTR can tell the ETR  
>> it has something different than the ETR does. And of course, the  
>> ETR always has the most current information because it owns it and  
>> is authoritative for it.
>>
>> numbers or checksums have to go in every data packet? That is the  
>> crux of the argument.

It you are RLOC-probing once a minute for liveness, I think getting  
one-minute granularity for a mapping update is pretty darn good/fast.  
For going faster, you use the techniques in draft-meyer-lisp-mn-00.txt.

But stationary LISP sites don't need the LISP-MN techniques.

>> So if you are sensitive to RLOC-Probes and say putting the request  
>> in a data-packet would be cheaper, then you have to deal with idle  
>> control-plane gives you more flexibility and is not dependent on  
>> data frequency or behavior.
>>
> agree, it only depends the overhead you are ready to accept. But let  
> me turn the argument back to you and ask: "so, why do not move the  
> status bits in the control plane and remove them of the dataplane?"

Because status bit changes you might want to reflect faster than  
mapping update changes. Up/down transitions happen more often than  
mapping updates. Plus with the L-bit, you can turn them off now.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 18 Sep 2009 02:23:07 -0700

> control packet. If you encoded Map-Request, you just allocate a new  

This wasn't clear. I meant if you wanted to encode a newly format Map- 
Request, you just allocate a new Type value for packets that get  
encoded in UDP 4342 messages.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Sep 2009 08:54:45 -0400

(Just in case it gets lost again, the topic is protocol versioning, not 
map versioning.)
There are at least two loosely related issues when it comes to protocol 
versioning.
Below, Damien is discussing, I believe, versioning of the data plane 
encapsulation.  He argues that you need the version number in the data 
packet to avoid a round trip.  I am not so sure.  My comments follow his 
note.  I believe what is needed is a data plane version number in the 
control protocol.

The other question is whether we need to have versioning in the control 
plane protocol.   This in turn has two pieces.  There is the exchange 
between neighbors (ITR<->Map Server, ...) and the end-to-end map request 
itself.  I think we are best to assume here that there is a single 
version of the protocol.  There can be extensions (TLVs), but the basic 
structure better get fixed by the first time we release a PS. 
Otherwise, the mapping exchange itself starts to pick up extra round 
trips, and that is just a nightmare.

Yours,
Joel

Damien Saucez wrote:
...
> data packets if we want to avoid extra delay due to explicit negotiation.
...

If the original map request had A's data encapsulation version number, 
then when it arrived at B, B could then combine that information with 
A's support, and could compute the correct version number of the data 
encapsulation protocol to use between A and B.  That information could 
be included in the map-reply.
In theory, no indication of the data encapsulation version number is 
then needed in the protocol between A and B.
In  practice, if each data encapsulation version uses a different UDP 
port, this exchange tells the two parties what port and format to use 
for the data packets.  And the exchange has to happen anyway.
Hence, I do not see a need for an explicit data encapsulation version in 
the data encapsulation itself.  If we remove the UPD encapsulation (for 
example on IPv6, depending upon the outcome of that ongoing and tedious 
discussion), then we have to decide whether, for robustness, we want a 
data encapsulation version indication in the data packets themselves.

Whether the version number for the data plane protocol is a pair <port 
number to use, relative version> or is just a port number with an 
assumption that if you don't recognize the other guys port number, then 
yours is older and you should just use the older one, or some other 
mechanism, is a detail to be resolved.

Yours,
Joel

---

From: Damien Saucez <[email-masked]>
Date: Fri, 18 Sep 2009 18:23:15 +0200

Dino Farinacci wrote:
>> that we have today with IPv4 address exhaustion. I am convinced that 
>> the cost of reserving 8 bits for a protocol version field is a cost 
>> that we can afford.
>
yes, but to avoid a RTT for negotiation, you also put it in the data 
packets.
> Okay. So save my response for Luigi.  ;-)
;-)
>>>> the example, we will consider 1 packet from A to B and then a 
>>>> packet from B to A. Consider A runs version 42 of the LISP protocol 
>>>> and B runs version 666.
>>>>
> If ITR-only A sends a Map-Request with its own mapping data to 
> ETR-only B, B can send a verifying Map-Request back. There is no 
> reason why an *ETR* can't send a Map-Request.
>
yes, you can optimize and then send a map-request in prevention of 
future traffic if you know that you will be the iTR for the packets back 
to A, so why not using the data gleaning?

>>>> in the data packets if we want to avoid extra delay due to explicit 
>>>> negotiation.
>>>
>> example to answer Sam's mail and to confirm he was right. But I 
no I don't want this. That's true that you only this info in the 
map-request and in the first packet that arrives the ETR. But, how can 
you detect (from the iTR place) when the first packet is arrived the ETR 
as the first packet at the ETR may be only the second or the third from 
the ITR due to loss.
> For going faster, you use the techniques in draft-meyer-lisp-mn-00.txt.
I think that we will never answer this question perfectly. You suggest 
that mapping can be wrong for a while (let say 1 minute). With Luigi and 
the mapping versioning, we suggest to reduce the inconsistency time down 
to the minimum. The choice will be a tradeoff: what is the requirements 
of the operators?
> mapping updates. Plus with the L-bit, you can turn them off now.
but status bit is just a hint, you still have to check if it is true, 
otherwise you have a very simple DoS attack with a single packet.

Damien Saucez

---

From: Damien Saucez <[email-masked]>
Date: Fri, 18 Sep 2009 18:39:15 +0200

Joel M. Halpern wrote:
> (Just in case it gets lost again, the topic is protocol versioning, 
> not map versioning.)
> There are at least two loosely related issues when it comes to 
> protocol versioning.
> packet to avoid a round trip.  I am not so sure.  My comments follow 
> his note.  I believe what is needed is a data plane version number in 
> the control protocol.
yes, but then you need an extra rtt for the negotiation. Do not forget 
that the place where the Map-Request is processed and the place where 
the packet will effectively arrive may not be the same.
>
> The other question is whether we need to have versioning in the 
> control plane protocol.   This in turn has two pieces.  There is the 
> exchange between neighbors (ITR<->Map Server, ...) and the end-to-end 
> map request itself.  I think we are best to assume here that there is 
> a single version of the protocol.  There can be extensions (TLVs), but 
> the basic structure better get fixed by the first time we release a 
> PS. Otherwise, the mapping exchange itself starts to pick up extra 
> round trips, and that is just a nightmare.
I agree for the nightmare.

Please, don't forget that the WG is focused on experimentation of 
different solutions. With a protocol version number, we can thus tests 
different solutions to see which are the best. When the best protocol 
will be found, then we'll remove this extra field. Do we really need to 
care about legacy in this WG?
> Hence, I do not see a need for an explicit data encapsulation version 
> in the data encapsulation itself.  If we remove the UPD encapsulation 
> (for example on IPv6, depending upon the outcome of that ongoing and 
> tedious discussion), then we have to decide whether, for robustness, 
> we want a data encapsulation version indication in the data packets 
> themselves.
>
I believe that we are going in a wrong direction with the trend of 
adding more and more state. I do prefer having redundant information 
(the same info that may not be used if a packet has already been 
received) than having to keep state and then build a complex control 
protocol to maintain all this state coherent. Do we really need to make 
the LISP header as smaller as possible for the sacrosanct MTU?

> assumption that if you don't recognize the other guys port number, 
> then yours is older and you should just use the older one, or some 
> other mechanism, is a detail to be resolved.
>
I personally don't like the idea of having one port number per version. 
Again, if every protocol does that, the port space will be exhausted 
rapidly. I understand that from an implementation point of view a port 
number is easier, the check is implicitly done on the port number by a 
UDP classifier and you do not need to change the old implementations, 
just add the new one that will listen the new port.

Damien Saucez

---

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

Good post IMO. Agree on all counts.

Dino

On Sep 18, 2009, at 5:54 AM, Joel M. Halpern wrote:

> encapsulation.  He argues that you need the version number in the  
> data packet to avoid a round trip.  I am not so sure.  My comments  
> follow his note.  I believe what is needed is a data plane version  
> number in the control protocol.
>
> exchange between neighbors (ITR<->Map Server, ...) and the end-to- 
> end map request itself.  I think we are best to assume here that  
> there is a single version of the protocol.  There can be extensions  
> (TLVs), but the basic structure better get fixed by the first time  
> we release a PS. Otherwise, the mapping exchange itself starts to  
> pick up extra round trips, and that is just a nightmare.
>
> Yours,
> Joel
>
> Damien Saucez wrote:
> ...
> If the original map request had A's data encapsulation version  
> number, then when it arrived at B, B could then combine that  
> information with A's support, and could compute the correct version  
> number of the data encapsulation protocol to use between A and B.   
> That information could be included in the map-reply.
> In  practice, if each data encapsulation version uses a different  
> UDP port, this exchange tells the two parties what port and format  
> to use for the data packets.  And the exchange has to happen anyway.
> Hence, I do not see a need for an explicit data encapsulation  
> version in the data encapsulation itself.  If we remove the UPD  
> encapsulation (for example on IPv6, depending upon the outcome of  
> that ongoing and tedious discussion), then we have to decide  
> whether, for robustness, we want a data encapsulation version  
> indication in the data packets themselves.
>
> Whether the version number for the data plane protocol is a pair  
> <port number to use, relative version> or is just a port number with  
> an assumption that if you don't recognize the other guys port  
> number, then yours is older and you should just use the older one,  
> or some other mechanism, is a detail to be resolved.
>
> Yours,
> Joel
>
>
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 08:29:04 -0400

I think people are still talking past each other.

damien, can I see if I'm explaining you correctly?

You are trying to communicate with a LISP site.  You receive a mapping
reply for that site.  In that map reply we can include information on
what versions of LISP that site sends.

You send a packet to that site.  If no version information is included
in the packet, then the site may not know what version to use in its
responses.

It can just wait until it gets a map reply from you.  However in the
case where the site is going to use gleaned map cache information, it
may not have anything other than that first packet to find out what
version to use.

You might argue that the map request could have carried your version
information.  However, because of square routing and other concerns,
the map request and data packet may go to different places.

Have I got it right?

---

From: Damien Saucez <[email-masked]>
Date: Mon, 21 Sep 2009 15:44:54 +0200

Sam,

> what versions of LISP that site sends.
more precisely, the version it can receives.
> It can just wait until it gets a map reply from you.  
yes
> However in the
if you do not use data gleaning then, you do not need the version in the 
data packet as you will send a request and thus learn the version with 
the reply.
> the map request and data packet may go to different places.
yes, so putting the version in the map request is useless for our 
problem (but could help in some simple cases).
> Have I got it right?
Yes.

Damien Saucez