Subject: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

From: [email-masked]
Date: Fri, 01 May 2015 18:01:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network Virtualization Overlays Working Group of the IETF.

        Title           : Generic Protocol Extension for VXLAN
        Authors         : Paul Quinn
                          Rajeev Manur
                          Larry Kreeger
                          Darrel Lewis
                          Fabio Maino
                          Michael Smith
                          Puneet Agarwal
                          Lucy Yong
                          Xiaohu Xu
                          Uri Elzur
                          Pankaj Garg
                          David Melman
	Filename        : draft-ietf-nvo3-vxlan-gpe-00.txt
	Pages           : 22
	Date            : 2015-05-01

Abstract:
   This draft describes extending Virtual eXtensible Local Area Network
   (VXLAN), via changes to the VXLAN header, with three new
   capabilities: support for multi-protocol encapsulation, operations,
   administration and management (OAM) signaling and explicit
   versioning.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-vxlan-gpe/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 2 May 2015 15:36:42 -0700

Hello authors of VxLAN-gpe,

thank you for moving forward with this.

Few comments: when reading the draft I found the use of "VXLAN GPE" 
inconsistent, which makes it a bit difficult to read. Sometimes "VXLAN GPE" 
seems to refer to the superset, i.e. VxLAN RFC 7348 plus the new extensions. 
Sometimes "VXLAN GPE" seems to refer to the new extensions only.

The UDP port comments are a good example:

5.  Backward Compatibility

5.1.  VXLAN VTEP to VXLAN GPE VTEP
	[...]
5.2.  VXLAN GPE VTEP to VXLAN VTEP
	[...]

reading this section a VXLAN GPE VTEP can send and receive 4789/udp packets. 
So "VXLAN GPE" means the superset here.  But in section ...

4.  Outer Encapsulations
	[...]
   Destination UDP Port: IANA has assigned the value 4790 for the VXLAN
   GPE UDP port.  This well-known destination port is used when sending
   VXLAN GPE encapsulated packets.

... you mean the extension features when talking about "VXLAN GPE" because 
4790/udp is not used for VxLAN (?).
I think section 3.2. is the cleanest description regarding the udp port value:

3.2.  Multi Protocol Support
	[...]
   P Bit:  Flag bit 5 is defined as the Next Protocol bit.  The P bit
      MUST be set to 1 to indicate the presence of the 8 bit next
      protocol field.  When P=1, the destination UDP port MUST be 4790.

      P = 0 indicates that the payload MUST conform to VXLAN as defined
      in [RFC7348], including destination UDP port.

Maybe you can modify the section 4 statement to say (again) the 4790 port is 
used for P=1. Or reference to section 3.2 ?

Btw, you mention "payload" in the quote above. I understand what you mean but 
first stumbled as I would name "payload" what is underneath the VxLAN-gpe 
header, i.e. the inner frame. You mean the payload of the outer IP packet.

One more nitpick:

section 5 is named "Backward Compatibility" but has a sub-section "5.4. VXLAN 
GPE and Encapsulated IP Header Fields". This seems more a compatibility to 
LISP than VxLAN?

To summarize: I found the assignment of a new UDP port on one hand and the 
discussion about "compatibility" on the other hand a bit confusing because I 
think they contradict. You are not compatible when you need a new UDP port, 
IMHO. Maybe describing VxLAN-gpe as a "new" encapsulation, with 4790/udp port 
and P must be 1. Then use one section to explain how your design choices make 
implementation re-use of VxLAN feasible?

Well, just my $0.02.  :-)

Thanks & Regards,
Marc

On Fri, 01 May 2015 18:01:10 -0700, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 4 May 2015 16:01:39 -0500

Hi VXLAN-gpe authors,

After reading many times and discussions with one of the 12 coauthors :)
I think I now understand better this draft.

The source of misunderstanding was the lack of problem statement. My
suggestion is to clearly define what this draft is intended to solve.

Due to the fact that VXLAN is mentioned so much and Section is almost
copied from RFC 7248 causes a lot of confusion.

What I understand is that this draft is addressing is non Layer 2 data
center networks. VXLAN addresses Layer 2 data center networks and
always assumes Ethernet frames in the payload.
Virtual machines always generate Layer 2 frames. VXLAN addresses
VM-to-VM communication.

In general not all data center networks are Layer based, i.e. some are
Layer 3 based and there are no VMs that's why VXLAN-GPE does not talk
about VMs.

I suggest that this point be clarified in the draft.

Given the above, my suggestion is to remove Ethernet from the list of
encapsulations and leave it to VXLAN.

Given the above, I think that next protocol field is not needed.
Version of IP is in the very first field in IP header. But maybe you
can convince me?

If VXLAN-gpe is UDP encapsulation of IP packets than it should be
discussed in intarea list, just like GUE which is being discussed.
Already Xiaohu suggested this on intarea list.

Regards,

Behcet

On Fri, May 1, 2015 at 8:01 PM,  <[email-masked]> wrote:
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Ian Cox <[email-masked]>
Date: Mon, 4 May 2015 23:41:40 +0000

I'll provide a reason why providing intentional indication for next layer is better than essentially guessing it.  Using  MPLS as an example. MPLS  has no indication in the label stack for intermediate nodes what the underlying payload is.  To achieve better load balancing of MPLS traffic most hardware today looks to see if the first nibble is 4 or 6 then parse into the payload under the belief that it is a IPv4 or v6 packet. The 4 or 6 guess for the underlying MPLS payload being an IP packet was fine until IEEE allocated MAC addresses starting with 6. Unintended results occur when you parse MAC addresses as IP addresses and feed than into the ECMP calculation.

Ian

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Monday, May 04, 2015 2:02 PM
To: [email-masked]
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

 Hi VXLAN-gpe authors,

Regards,

Behcet

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 May 2015 16:51:36 -0700

On 5/4/2015 4:41 PM, Ian Cox wrote:
> I'll provide a reason why providing intentional indication for next
> layer is better than essentially guessing it. Using MPLS as an example.
> MPLS has no indication in the label stack for intermediate nodes what
> the underlying payload is. To achieve better load balancing of MPLS
> traffic most hardware today looks to see if the first nibble is 4 or 6
> then parse into the payload under the belief that it is a IPv4 or v6
> packet. The 4 or 6 guess for the underlying MPLS payload being an IP
> packet was fine until IEEE allocated MAC addresses starting with 6.
> Unintended results occur when you parse MAC addresses as IP addresses
> and feed than into the ECMP calculation.

That sounds like a great reason to indicate "IP", but insufficient
reason to indicate IPv4 vs IPv6.

Joe

---

From: John E Drake <[email-masked]>
Date: Tue, 5 May 2015 00:14:47 +0000

This is one of many reasons why entropy labels were invented.  Intermediate nodes should not be looking at payloads. 

Yours Irrespectively,

John

> From: nvo3 [mailto:[email-masked]] On Behalf Of Ian Cox
> Sent: Monday, May 04, 2015 7:42 PM
> To: [email-masked]; [email-masked]
> I'll provide a reason why providing intentional indication for next layer is
> better than essentially guessing it.  Using  MPLS as an example. MPLS  has no
> indication in the label stack for intermediate nodes what the underlying
> payload is.  To achieve better load balancing of MPLS traffic most hardware
> today looks to see if the first nibble is 4 or 6 then parse into the payload
> under the belief that it is a IPv4 or v6 packet. The 4 or 6 guess for the
> underlying MPLS payload being an IP packet was fine until IEEE allocated MAC
> addresses starting with 6. Unintended results occur when you parse MAC
> addresses as IP addresses and feed than into the ECMP calculation.
> 
> 
> Ian
> 
> After reading many times and discussions with one of the 12 coauthors :) I
> think I now understand better this draft.
> 
> What I understand is that this draft is addressing is non Layer 2 data center
> networks. VXLAN addresses Layer 2 data center networks and always
> assumes Ethernet frames in the payload.
> Virtual machines always generate Layer 2 frames. VXLAN addresses VM-to-
> VM communication.
> 
> In general not all data center networks are Layer based, i.e. some are Layer 3
> based and there are no VMs that's why VXLAN-GPE does not talk about VMs.
> 
> Version of IP is in the very first field in IP header. But maybe you can
> convince me?
> 
> If VXLAN-gpe is UDP encapsulation of IP packets than it should be discussed
> in intarea list, just like GUE which is being discussed.
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 5 May 2015 00:20:07 +0000

That¹s why we have been using entropy labels, ingress node has the best
understanding of the context.

Cheers,
Jeff

-----Original Message-----
From: Joe Touch <[email-masked]>
Date: Monday, May 4, 2015 at 4:51 PM
To: Ian Cox <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

>>>submission

---

From: William Caban <[email-masked]>
Date: Mon, 4 May 2015 21:19:32 -0400

Here is a question or request to see if it makes sense. (Not sure if this is the right forum)

With the Next Protocol values stated in the draft:

This draft defines the following Next Protocol values: 
 0x1 : IPv4 
 0x2 : IPv6 
 0x3 : Ethernet 
 0x4 : Network Service Header [NSH]

Understanding the rapid evolution of overlay networks and the need to support future research in networking fields. What about including a "RAW" or "TEST" next protocol which network researchers and academia can use to develop future protocols over an overlay network without having to modify the overlay transport. Such extension could also be used for application vendors with unique protocol requirement for "raw" communication between end points in an overlay network. 

-William

> On May 4, 2015, at 20:20, Jeff Tantsura <[email-masked]> wrote:
>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 5 May 2015 01:25:35 +0000

> Sent: Tuesday, May 05, 2015 5:02 AM
> To: [email-masked]
> After reading many times and discussions with one of the 12 coauthors :) I think
> I now understand better this draft.
> 
> Due to the fact that VXLAN is mentioned so much and Section is almost copied
> from RFC 7248 causes a lot of confusion.
> 
> networks. VXLAN addresses Layer 2 data center networks and always assumes
> Ethernet frames in the payload.
> Virtual machines always generate Layer 2 frames. VXLAN addresses VM-to-VM
> communication.
> 
> Version of IP is in the very first field in IP header. But maybe you can convince
> me?

Hi Behcet,

You may be interested to read the following email (https://www.ietf.org/mail-archive/web/nvo3/current/msg01520.html).

Best regards,
Xiaohu

> If VXLAN-gpe is UDP encapsulation of IP packets than it should be discussed in
> intarea list, just like GUE which is being discussed.

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 5 May 2015 01:54:00 +0000

Hi William,

This makes sense to me.  I think we could have a couple experimental values.  In fact if you look at section 9.2 you will see that there is no mention of the values 254 or 255 (while all other values are accounted for).  I think these value makes sense to allocate for experimental use.

 - Larry

From: William Caban <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 4, 2015 6:19 PM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: Ian Cox <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Joe Touch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

 0x1 : IPv4

 0x2 : IPv6

 0x3 : Ethernet

 0x4 : Network Service Header [NSH<https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-00#ref-NSH>]

-William

On May 4, 2015, at 20:20, Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Jeff

-----Original Message-----
From: Joe Touch <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 4, 2015 at 4:51 PM
To: Ian Cox <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

Joe

Ian

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Monday, May 04, 2015 2:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

Hi VXLAN-gpe authors,

Regards,

Behcet

On Fri, May 1, 2015 at 8:01 PM,  <[email-masked]<mailto:[email-masked]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Virtualization Overlays
Working Group of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

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

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

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

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

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 5 May 2015 02:05:01 +0000

Hi Joe,

Please see my response in this thread
http://www.ietf.org/mail-archive/web/nvo3/current/msg04612.html .

Also, could you explain the problems that would be caused by indicating
IPv4/IPv6 directly rather than requiring implementations to look at two
places to determine this?

Thanks, Larry

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 May 2015 23:30:01 -0700

> This draft defines the following Next Protocol values: 

The above is a mistake, IMO.

One ID should indicate "IP". The rest should be decided within the IP
header.

Let's not have to revisit this WHEN (not if) there's another IP.

Joe

> 
>  0x3 : Ethernet 
> 
>  0x4 : Network Service Header [NSH <https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-00#ref-NSH>]
> 
> 
> On May 4, 2015, at 20:20, Jeff Tantsura <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> From: Joe Touch <[email-masked] <mailto:[email-masked]>>
>> To: Ian Cox <[email-masked] <mailto:[email-masked]>>,
>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>,
>> "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>>>> To: [email-masked] <mailto:[email-masked]>
>>>> On Fri, May 1, 2015 at 8:01 PM,  <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 May 2015 23:31:16 -0700

> places to determine this?

1. it accounts for only IPv4 and IPv6, not any subsequent values

2. it encourages the encapsulation layer to handle these two
differently, when they should not be handled differently

IP is a protocol. v4 and v6 are versions.

Joe

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 5 May 2015 15:40:29 +0000

Hello,

> On May 4, 2015, at 5:01 PM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi VXLAN-gpe authors,
> 

The introduction of the draft states the following:

"The VXLAN header does not specify the protocol
   being encapsulated and therefore is currently limited to
   encapsulating only Ethernet frame payloads."

" This document describes extending VXLAN to support additional payload
   types beyond Ethernet frames.."

Is this unclear?  If so, what do you propose?

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 5 May 2015 11:49:04 -0500

> Is this unclear?  If so, what do you propose?

The explanation is above in my mail.

L2 based and L3 based data center networks are quite well known in
nvo3, e.g. RFC 6820.
So people would understand it.

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 5 May 2015 11:52:18 -0500

> IP is a protocol. v4 and v6 are versions.

+1

I think that Ethernet and NSH are not needed. NSH is not a protocol,
it is some abstract data. How NSH will be encapsulated is being
discussed in SFC WG.
So if the payload is only IP, then why do we need the next protocol field?

Behcet

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 5 May 2015 17:23:24 +0000

>IP is a protocol. v4 and v6 are versions.

While I completely agree architecturally, when it comes down to
implementations, the only downside I see are that it uses multiple Next
Protocol code points. Perhaps I am not looking far beyond my own
mortality, but I don't imagine there will be a huge proliferation of IP
versions in the future such that this will make a significant impact.
Encoding the IP version in the next protocol simplifies implementations,
and requiring an additional decision based on the IP version field will
not make current implementations suddenly able to handle IPv7 (or will it
be v8?) when it arrives.  There will be plenty of runway to allocate a
VXLAN GPE code point for it before there are implementations that will
know how to parse the new IP protocol.  If in the future there looks to be
a problem with proliferation of IP versions, a code point can always be
allocated for IP (any version) for VXLAN GPE to avert the problem for my
distant descendants.

 - Larry

---

From: "Black, David" <[email-masked]>
Date: Tue, 5 May 2015 17:35:07 +0000

That's a completely reasonable request, and moreover, allocation of values
for test and experimentation a generally good idea.

For more on this topic, see RFC 3692:

https://datatracker.ietf.org/doc/rfc3692/
https://www.rfc-editor.org/rfc/rfc3692.txt

Thanks,
--David

From: nvo3 [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
Sent: Monday, May 04, 2015 9:54 PM
To: William Caban; Jeff Tantsura
Cc: Ian Cox; [email-masked]; [email-masked]; Joe Touch
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

Hi William,

 - Larry

 0x1 : IPv4

 0x2 : IPv6

 0x3 : Ethernet

-William

Cheers,
Jeff

-----Original Message-----
From: Joe Touch <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 4, 2015 at 4:51 PM
To: Ian Cox <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

Joe

Ian

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Monday, May 04, 2015 2:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt

Hi VXLAN-gpe authors,

Regards,

Behcet

Abstract:

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 May 2015 10:48:23 -0700

On 5/5/2015 10:23 AM, Larry Kreeger (kreeger) wrote:
...
> Protocol code points.

Here are the primary downsides:

a) multiple codepoints at the top level

b) the need to continually add new codepoints for new versions

c) (and this is the big one)
	NO savings in processing, in fact, it makes processing worse

Not only do you need to find the version (as codepoint or within the IP
header), but if you have the same information in two places you now need
to verify that the two match and decide what to do when they don't.

I.e., a person with one watch always knows what time it is; a person
with two watches is never sure.

There is simply NO utility in copying information that is equally easily
available and it ONLY invites error.

Joe

---

From: William Caban <[email-masked]>
Date: Tue, 5 May 2015 14:41:58 -0400

> On May 5, 2015, at 12:52 PM, Behcet Sarikaya <[email-masked]> wrote:
> 

Next Protocol Ethernet type is needed for scenarios where you want to encapsulate Ethernet based protocols which do not use IP (i.e. VLAN, FCoE, etc).

_William

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 May 2015 19:31:17 -0700

> to verify that the two match and decide what to do when they don't.
If they don't match the packet should dropped-- this behavior is
already implemented.

> with two watches is never sure.
To follow through with your analogy, a person with one watch can give
the time but has no way to say that it is correct. A person with two
watches can not only give the time but also an assurance that the time
is correct (when the times on the watches match).

Redundant information in a packet is the basis for verifying the
packet against corruption. Since, the IPv6 version number is not
protected by any IP layer checksum, a single bit flip can change an
IPv4 packet  into an IPv6 packet without detection. With version
specific code-points we have another method to detect this corruption.

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 May 2015 11:25:51 -0700

On 5/5/2015 7:31 PM, Tom Herbert wrote:
....
> If they don't match the packet should dropped-- this behavior is

That's additional hardware that you didn't need if you didn't replicate
the field.

> packet against corruption. 

IPv6 assumes that the "link layer" protects the packet; here that's
covered by the UDP checksum.

So copying bits inside areas covered by the checksum to other areas
covered by that checksum has NO effect on detecting single-bit errors.

Further, if you're really serious about protection, use CRC-16 or better.

> Since, the IPv6 version number is not
> protected by any IP layer checksum, 

It's a payload of a UDP packet in the cases we're discussing, and that
would assume UDP over the entire message. Otherwise, you're taking
EXACTLY the same risk with the IP packet you'd be taking running over
any other L2 with potential corruption.

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 May 2015 16:16:06 -0500

> Next Protocol Ethernet type is needed for scenarios where you want to encapsulate Ethernet based protocols which do not use IP (i.e. VLAN, FCoE, etc).

Is this scenario(s) explained in the draft?

I said Ethernet next protocol header is not needed because that case
is already handled by VXLAN.

Behcet

---

From: Diego Garcia del Rio <[email-masked]>
Date: Mon, 11 May 2015 14:37:15 -0700

yes but if you're using GPE as an encap mechanism then any payload type
needs to be explicitly named.

On Mon, May 11, 2015 at 2:16 PM, Behcet Sarikaya <[email-masked]>
wrote:

> > Next Protocol Ethernet type is needed for scenarios where you want to
> encapsulate Ethernet based protocols which do not use IP (i.e. VLAN, FCoE,
> etc).
> >
>