Subject: [nvo3] Consensus call on encap proposals

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Thu, 21 Jul 2016 14:56:24 +0000

WG
 
There was a discussion in the NVO3 WG meeting in Berlin following strong advice from our Area Director that we need to come to a consensus on converging on a common encapsulation. Two sets of questions were asked:
(1) Should the WG move forward with one standards track encap?
(2) For a given encap, do you have significant technical objections?

This email relates to the second of these questions. Please refer to the separate email titled “Consensus call on moving forward with single encap” for discussion related to point (1).

We would recommend that those not familiar with RFC 7282 "On Consensus and Humming in the IETF" may wish to read it for a fuller understanding of how the IETF handles challenging consensus decisions and why.

We would like to determine the consensus on the following points on the list (there is a separate thread concerning point (2)):

1) Does anyone have a significant technical objection to selecting Geneve as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical objection.

2) Does anyone have a significant technical objection to selecting VXLAN-GPE as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical objection.

3)Does anyone have a significant technical objection to selecting GUE as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical objection.

Please reply to this email thread on the NVO3 list by 29th July 2016.

Please DO NOT use this thread to argue or debate the importance or details of any technical objections that arise.  That can be done in other threads. This thread should be used to state your initial objection. Any objections raised will be summarized in an additional email at the end of this consensus call so that the WG can discuss the results in detail.

While the list of technical issues has been collected for each encapsulation, the chairs are discussing how to develop an acceptable solution.   The goal is to have an answer before IETF 97.  The chairs will follow up to the list shortly.

Regards

Matthew and Sam

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2016 11:24:37 -0700

> 1) Does anyone have a significant technical objection to selecting Geneve as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical objection.

I object to Geneve because it will not be a cost-effective solution in all types of products it will be needed in. 

> 2) Does anyone have a significant technical objection to selecting VXLAN-GPE as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical object…

I support VXLAN-GPE because it can work in existing VXLAN deployments in compatibility mode as well as allowing the introduction of new (already known) features.

> 3)Does anyone have a significant technical objection to selecting GUE as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical objection.

I object to GUE because it will not be a cost-effective solution in all types of products it will be needed in.

Dino

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jul 2016 11:27:59 -0700

Dino,

I'm curious - what is your basis for "cost"?

The overheads in these protocols is as low as any other currently in
widespread use.

Joe

On 7/21/2016 11:24 AM, Dino Farinacci wrote:
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2016 13:22:33 -0700

> Dino,
> 
> I'm curious - what is your basis for "cost”?

(1) Time to market due to complexity in chip design.
(2) More are used for logic versus needed SRAM space for table entries.
(3) Additional latency in processing packets.

> The overheads in these protocols is as low as any other currently in

Not at the data-plane. No one processes IPv4 options except for the RA option. And that is why IPv4 goes fast. And IPv6 is following this path as well but there are new proposals out that will slow it down due to more processing. When I say “slow” here I mean the cost-effectiveness as described in the 3 bullets above.

Dino

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jul 2016 13:30:27 -0700

> Not at the data-plane. No one processes IPv4 options except for the RA option. And that is why IPv4 goes fast. And IPv6 is following this path as well but there are new proposals out that will slow…

These are data plane functions for ingress/egress processing, which
already does things like IPsec tunnel mode, IP in IP, IP in UDP in IP, etc.

I'm not sure about the others, but why is GUE so complex? It would still
allow data plane processing using existing IP forwarding, including DPI
access to port numbers.

Joe

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Jul 2016 00:13:09 +0200

> already does things like IPsec tunnel mode, IP in IP, IP in UDP in IP, etc.

All with fix length headers. These packet formats allow the hardware to do a few input checks in fixed places. 

Crypto is way different and a very complex but it is a "can't ship without it" feature. 

> I'm not sure about the others, but why is GUE so complex? It would still

Jump, test type, decide if you support it, validate the value field, do the feature of the type (if you support it), then add length, go to next type, rinse and repeat. 

And that doesn't even consider if there are sequencing requirements among the TLVs. 

> allow data plane processing using existing IP forwarding, including DPI

Not following and I think not relevant. 

Dino

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jul 2016 15:30:53 -0700

Thanks - I was trying to understand the basis of your objection.

You appear to be against variable packet formats in an form (which is
your choice, but I don't understand how we can develop protocols that
aren't instantly ossified that way).

You also seem to think security is optional. It thought those days were
over as well.

Fair enough.

Joe

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2016 15:37:19 -0700

> Thanks - I was trying to understand the basis of your objection.

No prob.

> aren't instantly ossified that way).

Back during the IPng directorate days we (router vendors) wanted variable length addresses but fixed length packets. We wanted the destination address to be in byte 0 of the network layer header.  ;-)

In this case of encapsulation protocols, like I said at the mic, if you are going to put an option in a header and later add new functionality, you have to make big changes to the new product that supports it. If you have to make this change, you may as well just define a new header. So just get a new UDP port number with a new protocol.

Rather than put in TLVs guessing what the future may hold while every packet now has to parse these more complicated headers.

Write a block in Verilog, and make the block fit when other logic designers (like 100 of them) are doing the same. You merge the blocks, they don’t fit, then you go back and take things out. What happens in the 2nd and subsequent revs is SRAMs get smaller or features get dropped out.

> You also seem to think security is optional. It thought those days were

I did not say that. I said complicate functions (like doing crypto in hardware) is something YOU MUST do so there is no choice. Other than a working system, the next absolute requirement is a working system that can do security.

Dino

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jul 2016 15:45:20 -0700

> In this case of encapsulation protocols, like I said at the mic, if you are going to put an option in a header and later add new functionality, you have to make big changes to the new product that…

Port numbers are assigned for entire services, not for each component
nor for each version of a protocol anymore (see the two docs of BCP
165).  So at best you're just saying that the entire header is redefined
for each version number in the header (which admittedly is just a
two-step check - port and version - rather than a one-step of just port).

> Write a block in Verilog, and make the block fit when other logic designers (like 100 of them) are doing the same. You merge the blocks, they don’t fit, then you go back and take things out. What h…

That seems like you're designing to only what you can fab efficiently
right now and you expect to have a sequence of a thousand flowers in a
row. Which means you've only replaced variable headers in one protocol
with a large, varying set of fixed headers. It's hard to see the latter
as a win, especially when what you can implement in hardware in 3 years
will be quite different.

Joe

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2016 15:57:30 -0700

> nor for each version of a protocol anymore (see the two docs of BCP

GUE is a different service than Geneve. They both have different ports, do they not? 

This was our premise with LISP. That if we needed to have a version 2, get a new UDP port number rather than carry a version number in every packet for really no good reason. 

People said you shouldn’t do that. That we can’t allocate ports willy nilly. Fast forward 8 years. We have new UDP port allocations for VXLAN, VXLAN-GPE, GUE, and Geneve. And you know there are more.

So I would like to be a purist as the next guy, but this organization doesn’t exercise purity.

> two-step check - port and version - rather than a one-step of just port).

Yep. But not version. Your port number is your version number.

> row. Which means you've only replaced variable headers in one protocol

It never gets to 1000. Not in the data-plane. Let’s be practical and not over-estimate how fast vendors can adapt to new things.  ;-)

> with a large, varying set of fixed headers. It's hard to see the latter

Yes, that each goes fast. You pay the cost later when you need the feature and it is more well defined.

How long has it been since we created the IPv6 header, and vendors still do not know what to do with the flow field. We are using 28 bits in every packet for nothing. And now we have to build more compression algs to make IPv6 work better on RANs.

> as a win, especially when what you can implement in hardware in 3 years

No, it really doesn’t change as often as you might think.

Dino

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jul 2016 16:04:51 -0700

> GUE is a different service than Geneve. They both have different ports, do they not? 
Yes, those are completely different.

> This was our premise with LISP. That if we needed to have a version 2, get a new UDP port number rather than carry a version number in every packet for really no good reason. 

That won't happen, as per BCP 165. You're expected to support versioning
inside your protocol, not by consuming the port number space.

> People said you shouldn’t do that. That we can’t allocate ports willy nilly. Fast forward 8 years. We have new UDP port allocations for VXLAN, VXLAN-GPE, GUE, and Geneve. And you know there are mor…
Sure - for whole-cloth new services. Applications for incremental
updates or multiple ports for components of a service are routinely
rejected.

> Yep. But not version. Your port number is your version number.
Absolutely not. Again, see BCP 165.

A port number defines a service, not a version thereof.

...
> How long has it been since we created the IPv6 header, and vendors
> still do not know what to do with the flow field. 

Until it is - which is happening as we speak to reduce reordering in
multipath routing.

We don't deploy new IP protocols every 3 years, but every few years a
new feature becomes more widely supported. That's the point of
extensible protocols - to change gradually and incrementally.

Joe

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2016 16:14:48 -0700

Joe, let’s agree to disagree. Thanks for the discussion.

Dino

> On Jul 21, 2016, at 4:04 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Jul 2016 04:45:45 +0200

On Jul 22, 2016 12:13 AM, "Dino Farinacci" <[email-masked]> wrote:
> Jump, test type, decide if you support it, validate the value field, do
the feature of the type (if you support it), then add length, go to next
type, rinse and repeat.
> And that doesn't even consider if there are sequencing requirements among
the TLVs.
Dino, GUE does not use TLVs. It uses flag-fields like in GRE.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Jul 2016 07:00:54 +0200

On Jul 21, 2016 4:56 PM, "Bocci, Matthew (Nokia - GB)" <
[email-masked]> wrote:
>
> WG
>
> There was a discussion in the NVO3 WG meeting in Berlin following strong
advice from our Area Director that we need to come to a consensus on
converging on a common encapsulation. Two sets of questions were asked:
> This email relates to the second of these questions. Please refer to the
separate email titled “Consensus call on moving forward with single encap”
for discussion related to point (1).
>
> We would recommend that those not familiar with RFC 7282 "On Consensus
and Humming in the IETF" may wish to read it for a fuller understanding of
how the IETF handles challenging consensus decisions and why.
>
> We would like to determine the consensus on the following points on the
list (there is a separate thread concerning point (2)):
>
> 1) Does anyone have a significant technical objection to selecting Geneve
as the single NVO3 Standards track document?  Please be as concrete and
detailed as possible as to your technical objection.
- TLVs are expensive to process in both HW and SW. They also create a
potential DOS vector.
- Four byte overhead per TLV is significant.
- 16 bit protocol number is overkill. It is unlikely that Geneve will ever
carry more than 20 protocols. This is a significant portion of primary
header and lookup on 16 bit value is expensive often done with hash instead
of simple indexed array (which is suitable for an 8 bit field).
- Similar to above, 16 bit TLV option type is an expensive lookup.
- The draft allows the length of a (non-critical) TLV to be determined
either by length field or canonical length of type. This allows the
possibility of having two completely different interpretations of the same
protocol fields, where both can claim conformance.
- There is no security mechanism defined within the protocol to provide
integrity or authenticity of the VNI.
- When encapsulating Ethernet four byte alignment of the inner header is
not preserved. This is an issue on certain host CPU architectures such as
Sparc.
- The draft does not mention congestion control considerations.
- The draft allows a host to send a zero UDP6 checksum, but does not
demonstrate how requirements in section 4 of RFC6936 are met.

> 2) Does anyone have a significant technical objection to selecting
VXLAN-GPE as the single NVO3 Standards track document?  Please be as
concrete and detailed as possible as to your technical objection.
- VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host
receives a VXLAN packet for some protocol other than Ethern the payload
will be misinterpreted. A separate port number was required. I assume that
a user using VXLAN in HW must upgrade HW to use VXLAN-GPE
- VXLAN-GPE has very little extensibility.
- There is no allowance in VXLAN-GPE for custom extensions to the protocol.
- There are no guidelines as to how reserved bits or fields are intended to
be used or allocated (please see thread on my question about RCO in
VXLAN-GPE).
- There is no security mechanism within the protocol for integrity or
authenticity of the VNI. The security considerations section otherwise
defers security to the encapsulated protocol, there is no consideration for
security of the VXLAN header itself.
- VXLAN-GPE allows a receiver to ignore a non-zero UDP checksum. This
violates RFC1122 .
- The draft makes no mention of congestion control considerations.
- The draft recommends using a zero UDP checksum with IPv6 without
reference or consideration of RFC6935 or RFC6936.
- Ethernet encapsulation has the same alignment issue as Geneve.

> 3)Does anyone have a significant technical objection to selecting GUE as
the single NVO3 Standards track document?  Please be as concrete and
detailed as possible as to your technical objection.
> Please DO NOT use this thread to argue or debate the importance or
details of any technical objections that arise.  That can be done in other
threads. This thread should be used to state your initial objection. Any
objections raised will be summarized in an additional email at the end of
this consensus call so that the WG can discuss the results in detail.
>
> While the list of technical issues has been collected for each
encapsulation, the chairs are discussing how to develop an acceptable
solution.   The goal is to have an answer before IETF 97.  The chairs will
follow up to the list shortly.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Jul 2016 00:07:04 -0700

> Dino, GUE does not use TLVs. It uses flag-fields like in GRE.

We had flags in GRE (I am one of the authors of GRE) and source-routes. No one implemented any of them. We wanted to be extensible, no hardware would do it. The features weren’t worth it. Maybe you can change that with GUE. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Jul 2016 01:38:25 -0700

> - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host receives a VXLAN packet for some protocol other than Ethern the payload will be misinterpreted. A separate port number was required. I assume that a user using VXLAN in HW must upgrade HW to use VXLAN-GPE

Tom, one clarification. Did you really mean VXLAN-GPE is not compatible with VXLAN-GPE or did you mean VXLAN?

This is how a VXLAN-GPE encapsulator (an upgraded system) can talk to a VXLAN decapsulator (an existing system) with the LISP control-plane:

(1) The encapsulator does a lookup on a MAC address to the mapping system.
(2) What gets retunred is the decapsultor’s IP address and an encapsulation format. In this case the encapsulation format is VXLAN.
(3) The VXLAN-GPE supuported encapsulator then encapsulates packets with UDP port 4789.

I am told you can do this with BGP as well by negotiating what encapsulations are supported.

Dino

---

From: Jon Hudson <[email-masked]>
Date: Fri, 22 Jul 2016 01:57:34 -0700

On Fri, Jul 22, 2016 at 1:38 AM, Dino Farinacci <[email-masked]> wrote:

> This is how a VXLAN-GPE encapsulator (an upgraded system) can talk to a
> VXLAN decapsulator (an existing system) with the LISP control-plane:
>
> (2) What gets retunred is the decapsultor’s IP address and an
> encapsulation format. In this case the encapsulation format is VXLAN.

However, most product managers are not nearly as clever as you are Dino,
and as far as I know Users who today have HW that supports vxlan will have
to buy new switches or line cards to support vxlan-gpe.

Though if someone knows of a vendor who plans to support vxlan-gpe on their
already installed vxlan supporting hardware please speak up. I certainly
did not check with every vendor.

Jon

-- 
"Do not lie. And do not do what you hate."

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Jul 2016 02:11:13 -0700

> However, most product managers are not nearly as clever as you are Dino, and as far as I know Users who today have HW that supports vxlan will have to buy new switches or line cards to support vxlan-gpe.

Oh yes, count on that. It has to be a multiple up-sell steps.  ;-) But customers are getting smart and hence the trust erosion with vendors.

> Though if someone knows of a vendor who plans to support vxlan-gpe on their already installed vxlan supporting hardware please speak up. I certainly did not check with every vendor. 

Good luck with that.  ;-)

Dino

---

From: Jesse Gross <[email-masked]>
Date: Fri, 22 Jul 2016 09:44:45 +0000

> On Jul 21, 2016, at 4:56 PM, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:

I object to VXLAN-GPE because of the three proposed encapsulations, it is the only one without any extensibility mechanism.

Given the number of extensions to VXLAN (some of which are overlapping), it seems like extensibility is a clear need. In addition, both Geneve and GUE have had extensions introduced since their initial definition. It does not seem the need for further extensions is likely to end in the near future.

> 3)Does anyone have a significant technical objection to selecting GUE as the single NVO3 Standards track document?  Please be as concrete and detailed as possible as to your technical objection.

I object to GUE due to its inability to have a significant number of extensions in a regular and interoperable way. The base flags structure is limited (note 7 of 16 flags have already been used before the document has been published) and requires specific knowledge in the dataplane of all prior defined extensions to even parse a given field. The draft does have private data but since this is unstructured and untyped, it will be very difficult to make it interoperable between different users. In the past, ways around this have been proposed such as a flag indicating that an extended set of flags are present or overlaying the private data with some structure (such as TLVs). However, having multiple extension mechanisms in a single protocol seems overly complex and likely to result in incomplete implementations.

I am also concerned that there currently appears to be significantly fewer implementations of GUE compared to the other two protocols, which could be seen as an indication of industry interest.

---

From: Jesse Gross <[email-masked]>
Date: Fri, 22 Jul 2016 09:54:57 +0000

> I am told you can do this with BGP as well by negotiating what encapsulations are supported.

Of course, this also applies to any other encapsulation protocol, both BGP and other control planes have done this. I don't see that VXLAN-GPE is any more or less compatible with existing deployments than the alternatives.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Jul 2016 14:30:27 +0100

> Of course, this also applies to any other encapsulation protocol, both BGP and other control planes have done this. I don't see that VXLAN-GPE is any more or less compatible with existing deploymen…

Agree. The Encapsulation Format returned from the LISP mapping database, can return a Geneve format type. 

Here is what is documented right now:

Is this extensible? :-) or are we going to stop creating more encapsulations. :-)

Dino

---

From: David Melman <[email-masked]>
Date: Fri, 22 Jul 2016 13:40:57 +0000

> Though if someone knows of a vendor who plans to support vxlan-gpe on their already installed vxlan supporting hardware please speak up. I certainly did not check with every vendor.

As a silicon vendor, Marvell have the same silicon that supports both VXLAN and VXLAN-GPE.  Our customers can indeed support both on the same hardware.

David

From: nvo3 [mailto:[email-masked]] On Behalf Of Jon Hudson
Sent: Friday, July 22, 2016 11:58 AM
To: Dino Farinacci
Cc: Matthew Bocci; Tom Herbert; [email-masked]
Subject: Re: [nvo3] Consensus call on encap proposals

Jon

Dino

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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Jul 2016 18:44:23 +0200

> Tom, one clarification. Did you really mean VXLAN-GPE is not compatible
with VXLAN-GPE or did you mean VXLAN?
Yes

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Jul 2016 18:47:35 +0200

On Jul 22, 2016 11:44 AM, "Tom Herbert" <[email-masked]> wrote:
> > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN
host receives a VXLAN packet for some protocol other than Ethern the
payload will be misinterpreted. A separate port number was required. I
assume that a user using VXLAN in HW must upgrade HW to use VXLAN-GPE
>MB
That is to day VXLAN-GPE is not compatible with VXLAN.

---

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 22 Jul 2016 16:59:25 +0000

Some NICs on the market can support VxLAN-GPE while originally designed for VxLAN only
That was part of the work towards the path VxLAN-GPE took

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: nvo3 [mailto:[email-masked]] On Behalf Of Jon Hudson
Sent: Friday, July 22, 2016 1:58 AM
To: Dino Farinacci <[email-masked]>
Cc: Matthew Bocci <[email-masked]>; Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: [nvo3] Consensus call on encap proposals

Jon

Dino

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Jul 2016 05:14:24 -0400

David,

Thank you.   This is helpful information.
Can you comment at all on extensibility & support for VXLAN-GPE & the other
options?

Regards,
Alia

On Jul 22, 2016 3:41 PM, "David Melman" <[email-masked]> wrote:

> > Though if someone knows of a vendor who plans to support vxlan-gpe on
> their already installed vxlan supporting hardware please speak up. I
> certainly did not check with every vendor.
>
>
>
> As a silicon vendor, Marvell have the same silicon that supports both
> VXLAN and VXLAN-GPE.  Our customers can indeed support both on the same
> hardware.
>
>
>
> David
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Jon Hudson
> *Sent:* Friday, July 22, 2016 11:58 AM
> *To:* Dino Farinacci
> *Cc:* Matthew Bocci; Tom Herbert; [email-masked]
> *Subject:* Re: [nvo3] Consensus call on encap proposals
>
>
>
>
>
>
>
> Though if someone knows of a vendor who plans to support vxlan-gpe on
> their already installed vxlan supporting hardware please speak up. I
> certainly did not check with every vendor.
>
>
>
> Jon
>
>
>
>
> Dino
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 23 Jul 2016 23:47:03 +0000

Alia,

Just trying to understand — is there a particular reason why you pick on extensibility? What set of extension requirements do you have in mind?

The historical evolution of data path encaps seems to indicate a decreasing (not increasing) number of extensions and capability to support them (e.g., L2TPv2 -> L2TPv3, Original GRE -> Current GRE).

Thanks,

— Carlos.

On Jul 23, 2016, at 10:14 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

David,

Thank you.   This is helpful information.
Can you comment at all on extensibility & support for VXLAN-GPE & the other options?

Regards,
Alia

David

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jon Hudson
Sent: Friday, July 22, 2016 11:58 AM
To: Dino Farinacci
Cc: Matthew Bocci; Tom Herbert; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Consensus call on encap proposals

Jon

Dino

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Jul 2016 21:58:15 -0400

Carlos,

The technical objections raised in the face-to-face meeting were all about
extensibility being a concern.  This,  those concerns need to be addressed.

I would recommend listening to the recording to remind or learn what
conversation happened.

Regards,
Alia

On Jul 23, 2016 7:47 PM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

> Alia,
>
> Just trying to understand — is there a particular reason why you pick on
> extensibility? What set of extension requirements do you have in mind?
>
> The historical evolution of data path encaps seems to indicate a
> decreasing (not increasing) number of extensions and capability to support
> them (e.g., L2TPv2 -> L2TPv3, Original GRE -> Current GRE).
>
> Thanks,
>
> — Carlos.
>
> On Jul 23, 2016, at 10:14 AM, Alia Atlas <[email-masked]> wrote:
>
> David,
>

---

From: Naoki Matsuhira <[email-masked]>
Date: Fri, 29 Jul 2016 17:34:17 +0900

> (2) For a given encap, do you have significant technical objections?

I want to inform to this mailing list that I proposed ME6E-FP and 
ME6E-PR at the yokohama meeting. I also have proposal M46E-FP and 
M46E-PR (past called SA46T).

These encapsulation technologies are based on address mapping. ME6E use 
IPv6 address which mapping MAC address, and M46E use IPv6 address which 
mapping IPv4 address.

I understand too many encapsulation technologies, however these my 
proposal are simple, and may contribute to the Internet.

I believe address mapping approach is unique, so I want to propose again.

sorry not the answer to the question.

Naoki Matsuhira

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Jul 2016 11:13:00 -0400

I'd like to have people focus on the key point of this thread.

Are there serious technical objections (and specifically what are they) to
moving forward with VXLAN-GPE as the standards-track protocol?

Are there serious technical objections (and specifically what are they) to
moving forward with GENEVE as the standards-track protocol?

Are there serious technical objections (and specifically what are they) to
moving forward with GUE as the standards-track protocol?

We need to capture any relevant objections.  So far, there's been some
discussion on extensibility - with Tom Herbert providing concrete concerns.

I have concluded that almost all the authors would prefer to have no
standards track solution if they can't guarantee that theirs is that
standard.

I do hear concerns about whether a decision will be too late.   I think
that a decision can only be helpful.   It goes back to when is the best
time to plant a tree - with the answer of 20 years ago or now.

Regards,
Alia

On Fri, Jul 29, 2016 at 4:34 AM, Naoki Matsuhira <[email-masked]>
wrote:

> I want to inform to this mailing list that I proposed ME6E-FP and ME6E-PR
> at the yokohama meeting. I also have proposal M46E-FP and M46E-PR (past
> called SA46T).
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 Jul 2016 09:06:04 -0700

On Fri, Jul 29, 2016 at 1:34 AM, Naoki Matsuhira
<[email-masked]> wrote:
> I want to inform to this mailing list that I proposed ME6E-FP and ME6E-PR at
> the yokohama meeting. I also have proposal M46E-FP and M46E-PR (past called
> SA46T).
>
> These encapsulation technologies are based on address mapping. ME6E use IPv6
> address which mapping MAC address, and M46E use IPv6 address which mapping
> IPv4 address.
>
> I understand too many encapsulation technologies, however these my proposal
> are simple, and may contribute to the Internet.
>
It's not unique (very little is any more ;-) ), it's another
manifestation of identifier/locator split ;-). Please look at ILA
(draft-herbert-nvo3-ila-02) which we are proposing in int-area. An
encoded Ethernet address might might be suitable as another addressing
variant in ILA.

Tom

---

From: Fabio Maino <[email-masked]>
Date: Fri, 29 Jul 2016 11:36:05 -0700

On 7/22/16 9:47 AM, Tom Herbert wrote:
>
> On Jul 22, 2016 11:44 AM, "Tom Herbert" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > On Jul 22, 2016 3:38 AM, "Dino Farinacci" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > >
> > > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a 
> VXLAN host receives a VXLAN packet for some protocol other than Ethern 
> the payload will be misinterpreted. A separate port number was 
> required. I assume that a user using VXLAN in HW must upgrade HW to 
> use VXLAN-GPE
> > >
> > > Tom, one clarification. Did you really mean VXLAN-GPE is not 
> compatible with VXLAN-GPE or did you mean VXLAN?
> > >
> > Yes
> >MB

We have had in the past the discussion about forward/backward 
compatibility, and IMO it wasn't very productive.

I observe that a VXLAN-GPE packet that carries an ethernet frame can be 
parsed by a VXLAN receiver (provided UDP port is properly configured). I 
think some implementors/deployers may take advantage of this property, 
but this is a minor point.

What I think is important, and it was one of the design goals of 
VXLAN-GPE, is that an implementation of VXLAN-GPE includes an 
implementation of VXLAN at no additional cost. This is one of the 
reasons that makes VXLAN-GPE attractive for HW implementations.

Fabio

> > > This is how a VXLAN-GPE encapsulator (an upgraded system) can talk 
> to a VXLAN decapsulator (an existing system) with the LISP control-plane:
> > >