Subject: Re: [lisp] [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt

From: [email-masked] (Noel Chiappa)
Date: Tue, 24 Sep 2013 11:07:10 -0400 (EDT)

{This is mostly to the LISP WG; NVO3 - which I candidly admit to knowing
almost nothing about, but which I justt joined - may or may not care. Sorry
this goes on for a bit, but this is important. I hope people will take the
time to read it - it's not _that_ long.}

    > From: Dino Farinacci <farinacci at gmail.com>

    > the P-bit is being proposed for LISP.

For those who missed what this was all about (I sure did), there is a new ID:

  http://tools.ietf.org/html/draft-lewis-lisp-gpe-00
  "LISP Generic Protocol Extension"

As a personal ID, this ID was not automagically announced to the LISP WG; I
only happened to just see it when I was updating the LISP bibliography this
weekend.

May I suggest that in the future, anyone posting a personal draft _send a
message to the WG_ - for people who are not subscibed to the full ID
announcement feed (I'm not, it's way too much traffic, 97% of which I don't
care about); otherwise, many people will have no idea that it's there.

Even better, run the basic idea through the WG _before_ you write the draft;
it may have a major flaw (as this one, I believe, does), or it may be a
direction we just don't want to go (in which case there's no use putting in
the effort to write an ID).

To briefly let people know what this is about, it allows carriage of non-IP
packets in LISP. This, I think, is basically a very good idea.

However, the particular proposal in this ID is, IMO, very badly flawed. It
proposes to take over the field used to carry i) the nonce (for neighbour xTR
reachability detection), and ii) the version of the mapping entry, and use
that field to carry the Ethertype.

Obviously, then, since one _cannot_ carry a non-IP packet without making it
_impossible_ to perform either of these functions: if only non-IP traffic is
being carried over a particular link, these two (important, IMO) control
functions will be _permanently_ disabled.

I don't believe this is acceptable.

    >> From: Lucy yong <lucy.yong at huawei.com>

    >> Regarding to the protocol evolution, does this mean that
    >> nonce/map-version features in LISP will be deprecated?
    >> IMO: Having the same field overloaded for many differen[t] purposes
    >> is not good way for the protocol evolution, it becomes messy.

Yes and no. The engineering analysis on this sort of thing is subtle.

With a limited length header, if you have several control functions that do
not need to be applied _on every packet_, I think it's reasonable to share a
field between them. One does have to carefully look at the functions to
decide if they really are things that one doesn't have to do on every packet.

The thing is that putting a separate field in for every possible function
will make the header a lot longer, which will have an impact on overhead
(somewhat problematic), and also MTU (even more problematic, especially if
MTU Discovery is not working properly).

I am given to understand that a number of organizations have hardware which
looks at the first two 32-bit words, so unfortunately making the header longer
is not available as a _short-term_ answer.

(Although I think we're just about reaching the limits of what we can cram
into a 2-word header, so it's probably time to start thinking about a longer
one.)

    > It means that the features need to be traded off. So the
    > market/user-base will decide what it wants to use that field for.

I have to tell you that I just about fell off my chair when I realized
what you were saying here.

I don't believe that is professionally acceptable to force users to chose
between i) carrying non-IP traffic, and ii) having some important control
functions available.

I understand that in the real world there are constraints, so we can't
necessarily 'clean sheet of paper' the answer; but at the same time, surely it
is not beyond our wit to find an answer that doesn't force users into making
that choice.

I have some ideas on what to do here (technically), but before I launch into
them I would like to hear if the WG agrees with me that this 'tradeoff' is
unacceptable.

Because, clearly, if the WG is happy with this, there's no point in my
bringing up alternatives.

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Sep 2013 08:13:55 -0700

For what's it worth (and for the record), I would not tradeoff the nonce for a protocol-ID. The data-plane features in LISP are far more important IMO then a protocol demux field we may never need to use.

Dino

On Sep 24, 2013, at 8:07 AM, [email-masked] (Noel Chiappa) wrote:

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

---

From: Lucy yong <[email-masked]>
Date: Tue, 24 Sep 2013 15:19:47 +0000

+1. LISP is the LISP.
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Tuesday, September 24, 2013 10:14 AM
To: Noel Chiappa
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Dino

On Sep 24, 2013, at 8:07 AM, [email-masked] (Noel Chiappa) wrote:

> {This is mostly to the LISP WG; NVO3 - which I candidly admit to 
> knowing almost nothing about, but which I justt joined - may or may 
> not care. Sorry this goes on for a bit, but this is important. I hope 
> people will take the time to read it - it's not _that_ long.}
> 
> 
> As a personal ID, this ID was not automagically announced to the LISP 
> WG; I only happened to just see it when I was updating the LISP 
> bibliography this weekend.
> 
> May I suggest that in the future, anyone posting a personal draft 
> _send a message to the WG_ - for people who are not subscibed to the 
> full ID announcement feed (I'm not, it's way too much traffic, 97% of 
> which I don't care about); otherwise, many people will have no idea that it's there.
> 
> Even better, run the basic idea through the WG _before_ you write the 
> draft; it may have a major flaw (as this one, I believe, does), or it 
> may be a direction we just don't want to go (in which case there's no 
> use putting in the effort to write an ID).
> 
> 
> To briefly let people know what this is about, it allows carriage of 
> non-IP packets in LISP. This, I think, is basically a very good idea.
> 
> However, the particular proposal in this ID is, IMO, very badly 
> flawed. It proposes to take over the field used to carry i) the nonce 
> (for neighbour xTR reachability detection), and ii) the version of the 
> mapping entry, and use that field to carry the Ethertype.
> 
> Obviously, then, since one _cannot_ carry a non-IP packet without 
> making it _impossible_ to perform either of these functions: if only 
> non-IP traffic is being carried over a particular link, these two 
> (important, IMO) control functions will be _permanently_ disabled.
> 
> With a limited length header, if you have several control functions 
> that do not need to be applied _on every packet_, I think it's 
> reasonable to share a field between them. One does have to carefully 
> look at the functions to decide if they really are things that one doesn't have to do on every packet.
> 
> The thing is that putting a separate field in for every possible 
> function will make the header a lot longer, which will have an impact 
> on overhead (somewhat problematic), and also MTU (even more 
> problematic, especially if MTU Discovery is not working properly).
> 
> I am given to understand that a number of organizations have hardware 
> which looks at the first two 32-bit words, so unfortunately making the 
> header longer is not available as a _short-term_ answer.
> 
> (Although I think we're just about reaching the limits of what we can 
> cram into a 2-word header, so it's probably time to start thinking 
> about a longer
> one.)
> 
> 
> I don't believe that is professionally acceptable to force users to 
> chose between i) carrying non-IP traffic, and ii) having some 
> important control functions available.
> 
> necessarily 'clean sheet of paper' the answer; but at the same time, 
> surely it is not beyond our wit to find an answer that doesn't force 
> users into making that choice.
> 
> 
> I have some ideas on what to do here (technically), but before I 
> launch into them I would like to hear if the WG agrees with me that 
> this 'tradeoff' is unacceptable.
> 

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

---

From: Fabio Maino <[email-masked]>
Date: Wed, 25 Sep 2013 11:22:35 -0700

Hi Noel,
there's certainly no intention of keeping this out of the LISP WG, since 
this is not part of the charter we just thought an individual submission 
was more appropriate.

We just started from the very practical consideration of the 
proliferation of encapsulations in the data center, and the lack of 
multiprotocol support in both VXLAN and LISP.

 From a vendor perspective having a more rationale encapsulation with 
multiprotocol support seems a good goal, as it simplifies the 
implementations and improves interoperability.

Since for both VXLAN and LISP there are already HW implementations the 
hard part is to provide some form of backward compatibility, that would 
allow a deployment of HW supporting the multiprotocol format to 
interoperate with legacy devices. The *-gpe drafts, are a proposal to do 
just that.

For lisp-gpe, unfortunately, it comes to the expenses of the nonce and 
versioning fields, that is certainly a higher cost to pay, compared with 
the extension of vxlan. In the judgement of the authors of the drafts 
this might be an acceptable compromise. That said I certainly respect 
your dissenting opinion.

To move forward I suggest we discuss the requirements and the different 
points of view, and we should try to see if there's a way to achieve a 
larger  set of goals of what lisp-gpe does today.

We have a great chance to talk in person next week at the LISP interim 
in Herndon, where I'm sure we can do a good use of aisle time.

Looking forward to meet you next week,
Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 25 Sep 2013 12:03:52 -0700

> Hi Noel,
> there's certainly no intention of keeping this out of the LISP WG, since this is not part of the charter we just thought an individual submission was more appropriate.
> 
> We just started from the very practical consideration of the proliferation of encapsulations in the data center, and the lack of multiprotocol support in both VXLAN and LISP.

Sorry I have to disagree. The protocols that LISP supports are *IP* protocols and the protocols that VXLAN supports are *the rest* since it is layer-2 solution. So this appears to be just rearranging the deck chairs.

> From a vendor perspective having a more rationale encapsulation with multiprotocol support seems a good goal, as it simplifies the implementations and improves interoperability.

We had a clear demarcation point that was workable, now we have yet another option. So IMO this is not a simplification.

> Since for both VXLAN and LISP there are already HW implementations the hard part is to provide some form of backward compatibility, that would allow a deployment of HW supporting the multiprotocol format to interoperate with legacy devices. The *-gpe drafts, are a proposal to do just that.
> 
> For lisp-gpe, unfortunately, it comes to the expenses of the nonce and versioning fields, that is certainly a higher cost to pay, compared with the extension of vxlan. In the judgement of the authors of the drafts this might be an acceptable compromise. That said I certainly respect your dissenting opinion.
> 
> To move forward I suggest we discuss the requirements and the different points of view, and we should try to see if there's a way to achieve a larger  set of goals of what lisp-gpe does today.
> 
> We have a great chance to talk in person next week at the LISP interim in Herndon, where I'm sure we can do a good use of aisle time.
> 

I hope we can use private time to discuss this and not working group time, since the reason we are having an interim meeting is to close on the architecture draft(s).

Dino

---

From: Lucy yong <[email-masked]>
Date: Wed, 25 Sep 2013 19:37:22 +0000

Please see my reply inline [lucy].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fabio Maino
Sent: Wednesday, September 25, 2013 1:23 PM
To: Noel Chiappa
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Hi Noel,

 From a vendor perspective having a more rationale encapsulation with multiprotocol support seems a good goal, as it simplifies the implementations and improves interoperability.
[Lucy] disagree. This certainly makes LISP more complex and harder to interwork. The lisp-gpe draft has many holes on the interworking.

For lisp-gpe, unfortunately, it comes to the expenses of the nonce and versioning fields, that is certainly a higher cost to pay, compared with the extension of vxlan. In the judgement of the authors of the drafts this might be an acceptable compromise. That said I certainly respect your dissenting opinion.
[Lucy] Although VXLAN encapsulation had intention to align with LISP at beginning, if expanding it to support multiprotocol, it means the separation between two because LISP does not have goal. In fact, VXLAN and LISP already uses different UDP port number, it is sufficient to separate them. Lisp-gpe proposal will result a bad LISP protocol. Hope that the WG give a cautious consideration.

Lucy

---

From: Fabio Maino <[email-masked]>
Date: Wed, 25 Sep 2013 21:54:12 -0700

> I hope we can use private time to discuss this and not working group time, since the reason we are having an interim meeting is to close on the architecture draft(s).

sure. Architecture draft(s) are the absolute priority.

Fabio

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 26 Sep 2013 20:35:25 +0200

> Sorry I have to disagree. The protocols that LISP supports are *IP* protocols and the protocols that VXLAN supports are *the rest* since it is layer-2 solution. So this appears to be just rearrangi…

This trouble me... why do we want to mix LISP and VXLAN? What is the
gain in it? I only smell complexity. L2 in L3 over L3?

How will a mix of LISP and VXLAN benefit the administrators of
datacenters, end-users in the end?

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

(I really start to really dislike gmails new better editor)

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Sep 2013 11:57:25 -0700

> gain in it? I only smell complexity. L2 in L3 over L3?

We shouldn't but let the authors reply. If you want to carry more than IP protocols in LISP, then you use the L2 UDP port and carry MAC addresses in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one control-plane, the LISP mapping database using LISP-DDT.

> datacenters, end-users in the end?

The VXLAN authors have to answer that. They came afterwards (by 5 years).

Dino

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Sep 2013 19:43:30 +0000

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, September 26, 2013 1:57 PM
To: Roger Jørgensen
Cc: Fabio Maino; [email-masked]; Noel Chiappa; [email-masked]
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

[Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP protocol. However, Overlay virtual networks that use VXLAN encapsulation may be implemented in other way too, e.g. SDN controller, not LISP protocol. Therefore, there is a desire to extend VXLAN encapsulation to support multiple protocols beside L2 only and make it a generic overlay encapsulation schematics to support an overlay application.

BTW: IMO: using UDP port to indicate payload type is not elegant design, but acceptable for history reason only.

Lucy  

Dino

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Sep 2013 19:51:27 +0000

Dino,

Current VXLAN format is much simpler format compared to LISP format. To use it with LISP protocol, do you need to modify VXLAN format to support LISP features?

Regards,
Lucy

-----Original Message-----
From: Lucy yong 
Sent: Thursday, September 26, 2013 2:44 PM
To: 'Dino Farinacci'; Roger Jørgensen
Cc: Fabio Maino; [email-masked]; Noel Chiappa; [email-masked]
Subject: RE: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, September 26, 2013 1:57 PM
To: Roger Jørgensen
Cc: Fabio Maino; [email-masked]; Noel Chiappa; [email-masked]
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Lucy  

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Sep 2013 13:34:30 -0700

> Current VXLAN format is much simpler format compared to LISP format. To use it with LISP protocol, do you need to modify VXLAN format to support LISP features?

Lucy, the format is exactly the same. If you choose to not implement the LISP data plane features and disable the flags, then it is exactly the same implementation as LISP. 

However ...

VXLAN is actually harder because if you get a cache miss, you have to look in another table to find a group address to encapsulate to. So if you take a closer look under the cover, it is arguably harder. It requires a hardware implementation to build a different lookup memory or partition one memory to do two different types of lookups.

Dino

---

From: Lucy yong <[email-masked]>
Date: Thu, 26 Sep 2013 21:06:22 +0000

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Thursday, September 26, 2013 3:35 PM
To: Lucy yong
Cc: Roger Jørgensen; Fabio Maino; [email-masked]; Noel Chiappa; [email-masked]
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

However ...

[Lucy] I get it. Thank you for the explanation. It tells me that it is better not going that way.

Lucy

Dino

---

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Fri, 27 Sep 2013 13:14:04 +0000

Lucy,

inline

On 26/09/13 21:51, "Lucy yong" <[email-masked]> wrote:

>Dino,
>
>Current VXLAN format is much simpler format compared to LISP format. To
>use it with LISP protocol, do you need to modify VXLAN format to support
>LISP features?
>
>Regards,
>Lucy
>
>>>> there's certainly no intention of keeping this out of the LISP WG,
>>>>since this is not part of the charter we just thought an individual
>>>>submission was more appropriate.
>>>> 
>>> Sorry I have to disagree. The protocols that LISP supports are *IP*
>>>protocols and the protocols that VXLAN supports are *the rest* since it
>>>is layer-2 solution. So this appears to be just rearranging the deck
>>>chairs.
>> 
>We shouldn't but let the authors reply. If you want to carry more than IP
>protocols in LISP, then you use the L2 UDP port and carry MAC addresses
>in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with one
>control-plane, the LISP mapping database using LISP-DDT.
>
>[Lucy] Agree. This is one way to implement L2 or L3 overlay by using LISP
>protocol. However, Overlay virtual networks that use VXLAN encapsulation
>may be implemented in other way too, e.g. SDN controller, not LISP
>protocol. Therefore, there is a desire to extend VXLAN encapsulation to
>support multiple protocols beside L2 only and make it a generic overlay
>encapsulation schematics to support an overlay application.

The NVO3 WG has a consensus (I believe) that the functions of mapping
overlay addresses to underlay addresses (NVE to NVA, or NVE to NVE control
plane), and the function that actually keeps that mapping information (NVA
control plane) should be kept separate.  In that way, an SDN northbound
interface on the NVA solves that problem for you.  More-over this allows
one to choose its own NVE-to-NVA CP and NVE-NVE data plane/controlplane,
while the SDN northbound model stays the same.

>but acceptable for history reason only.

Why ?

---

From: Lucy yong <[email-masked]>
Date: Fri, 27 Sep 2013 17:58:10 +0000

Hi Yves,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yves Hertoghs (yhertogh)
Sent: Friday, September 27, 2013 8:14 AM
To: Lucy yong; Dino Farinacci; Roger Jørgensen
Cc: Fabio Maino (fmaino); [email-masked]; Noel Chiappa; [email-masked]
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Lucy,

inline

On 26/09/13 21:51, "Lucy yong" <[email-masked]> wrote:

>use it with LISP protocol, do you need to modify VXLAN format to 
>support LISP features?
>
>Regards,
>Lucy
>
>>>protocols and the protocols that VXLAN supports are *the rest* since 
>>>it is layer-2 solution. So this appears to be just rearranging the 
>>>deck chairs.
>> 
>We shouldn't but let the authors reply. If you want to carry more than 
>IP protocols in LISP, then you use the L2 UDP port and carry MAC 
>addresses in LISP. You can carry all of MAC, IPv4, and IPv6 EIDs with 
>one control-plane, the LISP mapping database using LISP-DDT.
>
>[Lucy] Agree. This is one way to implement L2 or L3 overlay by using 
>LISP protocol. However, Overlay virtual networks that use VXLAN 
>encapsulation may be implemented in other way too, e.g. SDN controller, 
>not LISP protocol. Therefore, there is a desire to extend VXLAN 
>encapsulation to support multiple protocols beside L2 only and make it 
>a generic overlay encapsulation schematics to support an overlay application.

The NVO3 WG has a consensus (I believe) that the functions of mapping overlay addresses to underlay addresses (NVE to NVA, or NVE to NVE control plane), and the function that actually keeps that mapping information (NVA control plane) should be kept separate.  In that way, an SDN northbound interface on the NVA solves that problem for you.  More-over this allows one to choose its own NVE-to-NVA CP and NVE-NVE data plane/controlplane, while the SDN northbound model stays the same.
[Lucy] SDN controller in my text is about NVA. Nothing to do with SDN northbound interface. We may cross each other's view. Yes, the nvo3 architecture/framework specifies the model and these components. That model allows NVE and NVA to be separated and have a protocol in between to convey the mapping information. The WG does not confine a protocol solution yet. That is my point. 

>
>BTW: IMO: using UDP port to indicate payload type is not elegant 
>design, but acceptable for history reason only.

Why ?
[Lucy] TCP/UDP port is used for demultiplexing transport connection or identifying a service. Demultiplex payload type does not fit into neither purpose and consumes the port numbers. Please take a look. http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/

Regards,
Lucy