On Tue, May 5, 2015 at 1:31 AM, Joe Touch <[email protected]> wrote: > > > On 5/4/2015 7:05 PM, Larry Kreeger (kreeger) wrote: >> 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? > > 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.
+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 > > Joe > >> >> Thanks, Larry >> >> On 5/4/15 4:51 PM, "Joe Touch" <[email protected]> wrote: >> >>> >>> >>> 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 >>> >>>> >>>> >>>> Ian >>>> >>>> -----Original Message----- >>>> From: nvo3 [mailto:[email protected]] On Behalf Of Behcet Sarikaya >>>> Sent: Monday, May 04, 2015 2:02 PM >>>> To: [email protected] >>>> Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt >>>> >>>> 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 protected]> 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. >>>>> >>>>> 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/ >>>>> >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
