On Mon, Nov 16, 2015 at 1:45 PM, Surendra Kumar (smkumar) <smku...@cisco.com> wrote: > > Agree. I was just implying that the cost equivalent of discriminating v6/v4 > via the IP.ver field may already be paid even today. > Yes, a stack must verify that the version number matches the protocol number.The number of conditionals in the path to check protocol and version is the same regargless of rather there are two protocol numbers (for IPv4 and IPv6) and version number must be verified, or one number for IP and version number is used as a discriminator.
Tom > Surendra. > > -----Original Message----- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Monday, November 16, 2015 11:54 AM > To: Surendra Kumar (smkumar) <smku...@cisco.com>; Sandeep Kumar (Sandeep) > Relan <sre...@broadcom.com>; nvo3@ietf.org > Cc: to...@isi.edu; Shahram Davari <dav...@broadcom.com>; Anoop Ghanwani > <an...@alumni.duke.edu>; Larry Kreeger (kreeger) <kree...@cisco.com> > Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ > draft-ietf-nvo3-vxlan-gpe-01.txt ] > > > > On 11/15/2015 12:47 PM, Surendra Kumar (smkumar) wrote: >> I suspect some implementations may check the version even today. > > It's not about checking the version number. It's that the version number is > what should be used to differentiate different versions of IP, not the outer > (lower) layer next-protocol field. That field should really only say "IP", > i.e., not "IPv4" or "IPv6". > > The reason this didn't happen for Ethernet was because of a perception that > hardware would need "deep" packet information, which would be otherwise too > complex to extract. That situation was true for the first year or so of > deployment, but was quickly overtaken by technology capability. > > Yet another reason never to make a protocol design decision for a short-term > optimization. > >> Btw, wouldn't this lead to allocating yet another code-point in IP >> protocol name space for tunnels while code points already exist for v4 >> and v6 ? Would that be ok ? > > No; I was just remarking that we should have one codepoint for IP, not > different ones for IPv4, IPv6, and (eventually) whatever IP versions follow. > > Whether we have one or more codepoints for IP in ethernet or other lower > layers, there are already codepoints for IP "next protocol" being IP. > Unfortunately, IP makes the same error - it uses "4" for IPv4 and "41" > for IPv6; it should really have just stuck with one value. > > Joe > > >> >> Surendra. >> >> >> -----Original Message----- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Monday, November 09, 2015 9:46 AM >> To: Surendra Kumar (smkumar) <smku...@cisco.com>; Sandeep Kumar >> (Sandeep) Relan <sre...@broadcom.com>; nvo3@ietf.org >> Cc: to...@isi.edu; Shahram Davari <dav...@broadcom.com>; Anoop >> Ghanwani <an...@alumni.duke.edu>; Larry Kreeger (kreeger) >> <kree...@cisco.com> >> Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ >> draft-ietf-nvo3-vxlan-gpe-01.txt ] >> >> That would be a lot better, though it still suffers from the use of >> different codepoints for IPv4 and IPv6. >> >> The concept of version numbers shouldn't be this difficult. >> >> Joe >> >> On 11/7/2015 11:49 AM, Surendra Kumar (smkumar) wrote: >>> On a related note, seems like the VXLAN-GPE next protocol field can >>> do away with the new registry and re-use the IP protocol numbers: >>> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xht >>> m >>> l >>> >>> The only one not covered in that name space is NSH, which can be signaled >>> over UDP - which also limits the overhead. >>> >>> Regards, >>> Surendra. >>> >>> -----Original Message----- >>> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Joe Touch >>> Sent: Thursday, November 05, 2015 3:31 PM >>> To: Sandeep Kumar (Sandeep) Relan <sre...@broadcom.com>; >>> nvo3@ietf.org >>> Cc: Shahram Davari <dav...@broadcom.com>; Anoop Ghanwani >>> <an...@alumni.duke.edu>; Larry Kreeger (kreeger) <kree...@cisco.com>; >>> to...@isi.edu >>> Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ >>> draft-ietf-nvo3-vxlan-gpe-01.txt ] >>> >>> Question - why are there two next-protocols for IP? That's what the IP >>> version number is for. >>> >>> (yes, Ethernet messed this up with two different next-proto values, >>> but it was only because "it's faster in hardware", which ceased to be >>> true vs looking at the IP version number directly) >>> >>> I.e., this mechanism should not require revision to support future versions >>> of IP. That's why IP has its own version number field. >>> >>> Joe >>> >>> On 11/5/2015 2:13 PM, Sandeep Kumar (Sandeep) Relan wrote: >>>> With Reference to : draft-ietf-nvo3-vxlan-gpe-01.txt >>>> >>>> >>>> >>>> Dear Authors, >>>> >>>> >>>> >>>> I noticed that below request from Shahram (almost 6 weeks ago) has >>>> not been evaluated and considered in this draft discussion: >>>> >>>> >>>> >>>> Current draft defines the following Next Protocol values: >>>> >>>> >>>> >>>> 0x1 : IPv4 >>>> >>>> 0x2 : IPv6 >>>> >>>> 0x3 : Ethernet >>>> >>>> ... >>>> >>>> ... >>>> >>>> >>>> >>>> Appreciate kind consideration of assigning following value for >>>> Ethernet, in the Next Protocol field: >>>> >>>> >>>> >>>> 0x0 : Ethernet >>>> >>>> >>>> >>>> >>>> >>>> Thanks >>>> >>>> Sandeep Relan >>>> >>>> >>>> >>>> *From:*Shahram Davari >>>> *Sent:* Wednesday, September 23, 2015 4:03 PM >>>> *To:* Anoop Ghanwani; Larry Kreeger (kreeger) >>>> *Cc:* Sandeep Kumar (Sandeep) Relan; nvo3@ietf.org >>>> *Subject:* RE: [nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> There are existing VXLAN implementations that are deployed. The >>>> current VXLAN-GPE makes those hardware obsolete. If the new >>>> VXLAN-GPE would accept received packets with P=0 and Protocol-Type >>>> =0 as Ethernet and if it transmits P=1 and Protocol-Type=0 as >>>> Ethernet then existing Hardware can be used to support VXLAN-GPE >>>> Ethernet encapsulation, else new HW is required. >>>> >>>> >>>> >>>> Note that most implementations have configurable UDP Dest port #. >>>> >>>> >>>> >>>> Thx >>>> Shahram >>>> >>>> >>>> >>>> *From:*ghanw...@gmail.com <mailto:ghanw...@gmail.com> >>>> [mailto:ghanw...@gmail.com] *On Behalf Of *Anoop Ghanwani >>>> *Sent:* Wednesday, September 23, 2015 3:16 PM >>>> *To:* Larry Kreeger (kreeger) >>>> *Cc:* Sandeep Kumar (Sandeep) Relan; nvo3@ietf.org >>>> <mailto:nvo3@ietf.org>; Shahram Davari >>>> *Subject:* Re: [nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> Hi Larry, >>>> >>>> >>>> >>>> Perhaps Sandeep's question can be framed another way: >>>> >>>> >>>> >>>> Is it legal for a VXLAN-GPE implementation to accept/terminate >>>> tunneled packets with a P bit of 0 and a protocol of 0 or should it >>>> be discarding those? >>>> >>>> >>>> >>>> Anoop >>>> >>>> >>>> >>>> On Tue, Sep 22, 2015 at 10:56 AM, Larry Kreeger (kreeger) >>>> <kree...@cisco.com <mailto:kree...@cisco.com>> wrote: >>>> >>>> Hi Sandeep, >>>> >>>> >>>> >>>> According to RFC 7348, a VTEP must ignore the contents of the >>>> reserved flags and reserved fields. Therefore, they will ignore >>>> both the P-bit and the Next Protocol type field in the VXLAN GPE packet. >>>> As long as only Ethernet is encapsulated and OAM is not used, then >>>> version 0 of VXLAN GPE can be received properly by a RFC 7348 VTEP. >>>> VXLAN GPE implementations must parse the P-bit and Next Protocol >>>> field anyway, so parsing it consistently for both Ethernet and all >>>> other protocols makes sense to me. >>>> >>>> >>>> >>>> - Larry >>>> >>>> >>>> >>>> *From: *"Sandeep Kumar (Sandeep) Relan" <sre...@broadcom.com >>>> <mailto:sre...@broadcom.com>> >>>> *Date: *Monday, September 21, 2015 at 7:28 PM >>>> *To: *"nvo3@ietf.org <mailto:nvo3@ietf.org>" <nvo3@ietf.org >>>> <mailto:nvo3@ietf.org>> >>>> *Cc: *Shahram Davari <dav...@broadcom.com >>>> <mailto:dav...@broadcom.com>>, Larry Kreeger <kree...@cisco.com >>>> <mailto:kree...@cisco.com>> >>>> *Subject: *Re: [nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> Hello Larry, >>>> >>>> >>>> >>>> I did see Section 5 on backward compatibility guidelines. >>>> >>>> >>>> >>>> Still. I am not sure - why disrupt the VXLAN header format >>>> compatibility with RFC 7348, for the Ethernet payload. >>>> >>>> >>>> >>>> GPE draft could additionally accept a special case of P=0 mode with >>>> protocol =0x0 as valid for Ethernet Payload., along with newly >>>> defined P >>>> =1 & Protocol = Ethernet (0x03). >>>> >>>> >>>> >>>> This will make at least VXLAN header with Ethernet payload >>>> compatible with the RFC 7348, even if UDP destination port numbers differ. >>>> >>>> >>>> >>>> Thanks >>>> >>>> Sandeep Relan >>>> >>>> >>>> On Sep 21, 2015, at 6:23 PM, Larry Kreeger (kreeger) >>>> <kree...@cisco.com <mailto:kree...@cisco.com>> wrote: >>>> >>>> Hi Sandeep, >>>> >>>> >>>> >>>> If a VXLAN GPE implementation wants to interoperate with a legacy >>>> VXLAN VTEP, then it needs to not only accept them, but also be sure >>>> to send VXLAN compatible packets to the remote VTEP. This includes >>>> bits in addition to the P-bit, such as the O-bit and the version >>>> field. Rather than specifying just one case (the P-bit=0 for >>>> Ethernet) for a VXLAN GPE VTEP to encapsulate to a VXLAN VTEP, we >>>> wrote section 5 covering the interoperability case explicitly, and >>>> kept it unambiguously consistent for VXLAN GPE to VXLAN GPE VTEPs to >>>> always use the Next Protocol field. >>>> >>>> >>>> >>>> Thanks, Larry >>>> >>>> >>>> >>>> *From: *"Sandeep Kumar (Sandeep) Relan" <sre...@broadcom.com >>>> <mailto:sre...@broadcom.com>> >>>> *Date: *Monday, September 21, 2015 at 5:28 PM >>>> *To: *"nvo3@ietf.org <mailto:nvo3@ietf.org>" <nvo3@ietf.org >>>> <mailto:nvo3@ietf.org>> >>>> *Cc: *Shahram Davari <dav...@broadcom.com >>>> <mailto:dav...@broadcom.com>>, Larry Kreeger <kree...@cisco.com >>>> <mailto:kree...@cisco.com>> >>>> *Subject: *RE: [nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> Hello Larry ! >>>> >>>> >>>> >>>> Thanks for the detailed explanation. >>>> >>>> Now, I see a duplication (or maybe a conflict) between VXLAN - GPE >>>> draft and VXLAN RFC (7348), when sending Ethernet payload >>>> encapsulation: >>>> >>>> >>>> >>>> VXLAN - GPE mandates : P =1 & Protocol = Ethernet (0x03) >>>> >>>> VXLAN (RFC) mandates: P = 0 (reserved) & Protocol = 0x00 (reserved) >>>> >>>> >>>> >>>> Now, an Ethernet payload could be encapsulated by either of the >>>> above two incompatible VXLAN headers. >>>> >>>> Is there any other specific reason to make even the headers >>>> incompatible ? >>>> >>>> >>>> >>>> The VXLAN - GPE draft could maintain: P = 0 & Protocol = 0x00 for >>>> Ethernet encapsulated packets, and thereby maintain backward >>>> compatibility (at least) with the 8 octet header specified in VXLAN >>>> RFC (7348) . >>>> >>>> >>>> >>>> Thanks >>>> >>>> Sandeep Relan >>>> >>>> >>>> >>>> *From:*Larry Kreeger (kreeger) [mailto:kree...@cisco.com] >>>> *Sent:* Monday, September 21, 2015 4:52 PM >>>> *To:* Shahram Davari >>>> *Cc:* Sandeep Kumar (Sandeep) Relan; nvo3@ietf.org >>>> <mailto:nvo3@ietf.org> >>>> *Subject:* Re: [nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> VXLAN as define in RFC 7348 does not have a version field! It was >>>> added in VXLAN GPE. This is another reason to use a new UDP port, >>>> since VXLAN VTEPs will be ignoring this new version field! >>>> >>>> >>>> >>>> - Larry >>>> >>>> >>>> >>>> *From: *Shahram Davari <dav...@broadcom.com >>>> <mailto:dav...@broadcom.com>> >>>> *Date: *Monday, September 21, 2015 at 4:40 PM >>>> *To: *Larry Kreeger <kree...@cisco.com <mailto:kree...@cisco.com>> >>>> *Cc: *"Sandeep Kumar (Sandeep) Relan" <sre...@broadcom.com >>>> <mailto:sre...@broadcom.com>>, "nvo3@ietf.org >>>> <mailto:nvo3@ietf.org>" <nvo3@ietf.org <mailto:nvo3@ietf.org>> >>>> *Subject: *Re: [nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> Hi Larry >>>> >>>> >>>> >>>> why not use a different version number instead of burning a scarce >>>> UDP port number? >>>> >>>> Regards, >>>> >>>> Shahram >>>> >>>> >>>> >>>> >>>> On Sep 21, 2015, at 4:36 PM, Larry Kreeger (kreeger) >>>> <kree...@cisco.com <mailto:kree...@cisco.com>> wrote: >>>> >>>> Hi Sandeep, >>>> >>>> >>>> >>>> You are correct, that a VXLAN GPE implementation can be backward >>>> compatible to VXLAN by looking at the P-bit. Which is why we >>>> originally were sharing the same UDP port as VXLAN. The problem >>>> comes up when a VXLAN (only) VTEP gets a VXLAN GPE packet with >>>> the P-bit set, it has no idea what the P-bit means and >>>> subsequently ignores the bit (as the VXLAN RFC says it should). >>>> This means it expects an Ethernet frame to be directly following >>>> the VXLAN header...but since this the VXLAN GPE, the protocol >>>> field can be specifying some other protocol besides Ethernet. >>>> The VXLAN implementation would misinterpret the data and >>>> potentially misdeliver the data. >>>> >>>> >>>> >>>> If the tunnels between VTEPs are always point to point using a >>>> control plane, this scenario can be avoided, but if multicast is >>>> used, then you cannot mix VXLAN-only VTEPs (which are not >>>> forward compatible) with VLAN GPE VTEPs. So, the new UDP port >>>> was assigned to prevent a VXLAN GPE packet accidentally being >>>> sent to a VXLAN-only VTEP. Note that using the new UDP port is >>>> optional if this issue is not a problem in your environment >>>> based on not having a mix of VTEPs, or relying on a control >>>> plane to prevent this. >>>> >>>> >>>> >>>> - Larry >>>> >>>> >>>> >>>> *From: *nvo3 <nvo3-boun...@ietf.org >>>> <mailto:nvo3-boun...@ietf.org>> on behalf of "Sandeep Kumar >>>> (Sandeep) Relan" <sre...@broadcom.com <mailto:sre...@broadcom.com>> >>>> *Date: *Monday, September 21, 2015 at 4:24 PM >>>> *To: *"nvo3@ietf.org <mailto:nvo3@ietf.org>" <nvo3@ietf.org >>>> <mailto:nvo3@ietf.org>> >>>> *Subject: *[nvo3] destination UDP port : >>>> draft-ietf-nvo3-vxlan-gpe-00 >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> Concern/Query : What is the need to have another Destination >>>> UDP port number ? >>>> >>>> >>>> >>>> Reference : draft-ietf-nvo3-vxlan-gpe-00 (VXLAN - GPE) >>>> >>>> >>>> >>>> This draft mentions that : >>>> >>>> IANA has assigned the value 4790 for the VXLAN-GPE UDP port. >>>> >>>> >>>> >>>> Further, this draft specifies: >>>> >>>> >>>> >>>> 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 <https://tools.ietf.org/html/rfc7348>], >>>> including destination UDP port - 4789 >>>> >>>> >>>> >>>> >>>> >>>> What is the need for having another IANA assigned UDP >>>> destination port number ? >>>> >>>> >>>> >>>> I don't see any strong reasons on the need of another IANA >>>> assigned UDP destination port number ? >>>> >>>> I believe, the P Bit can take care of distinguishing between >>>> RFC 7348 VXLAN packet from VXLAN-GPE packets. >>>> >>>> >>>> >>>> Appreciate, any insight/ background on the requirement to define >>>> another new UDP destination port number for future VXLAN packets ? >>>> >>>> >>>> >>>> Thanks & regards >>>> >>>> Sandeep Relan >>>> >>>> >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org <mailto:nvo3@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org <mailto:nvo3@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
