Thanks for the references thomas! I was replying from my phone and had a hard time finding these.
On Thu, Sep 24, 2015 at 12:24 AM, <[email protected]> wrote: > Hi Diego, > > Diego Garcia del Rio : > >> On BGP-evpn we can use the tunnel-type extended community and add a >> new type specifically for vxlan-gpe. Given the backwards compatibility >> of vxlan gpe we can assume that a gpe capable end point should be >> capable of receiving "classic" vxlan. >> > [...] > >> I don't recall off the top of my head if we can specify more than one >> tunnel type in evpn per endpoint so that we could potentially signal >> vanilla vxlan and gpe. >> > > Yes, the BGP Encapsulation extended community in RFC5512 section 4.5 > allows to advertize more than one encap. > And distinct codepoints for VXLAN and VXLAN-GPE have been allocated to > IANA already [1]. > > Note that draft-ietf-idr-tunnel-encaps-00 which generalizes the use of > RFC5512 also allows to specify the destination port in a BGP-based control > plane. > > Best, > > -Thomas > > [1] > http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types > > > > >> >> >> >> On Sep 23, 2015, at 16:59, Larry Kreeger (kreeger) <[email protected]> >>> wrote: >>> >>> Hi Tom, >>> >>> As it says in section 5.2 "A method for determining the capabilities of a >>> VXLAN VTEP (GPE or non-GPE) is out of the scope of this draft.² We are >>> assuming this is going to be handled by the control or management plane, >>> and not burden the data plane with a bit to signal this. >>> >>> - Larry >>> >>> >>> On 9/23/15, 4:42 PM, "Tom Herbert" <[email protected]> wrote: >>>> >>>> Larry, >>>> >>>> Have you thought about adding maybe VXLAN-GPE capable bit that an >>>> endpoint could use to indicate it's capable of receiving VXLAN-GPE on >>>> a VXLAN port? >>>> >>>> Tom >>>> >>>> On Wed, Sep 23, 2015 at 4:21 PM, Larry Kreeger (kreeger) >>>> <[email protected]> wrote: >>>> >>>>> Hi Shahram, >>>>> >>>>> Yes, most VXLAN implementations allow the destination UDP port to be >>>>> configurable because we took too long to get a UDP port assigned by >>>>> IANA. I >>>>> also believe that some implementations will want to run both VXLAN and >>>>> VXLAN-GPE on the same UDP port. This is another reason why I would >>>>> favor >>>>> removing the clause ³including destination UDP port² from the end of >>>>> the >>>>> P-bit=0 sentence in section 3.2. >>>>> >>>>> I think checking the P-bit=0 is good enough, with no need to check the >>>>> Next >>>>> Protocol field at all since the contents of the field should be >>>>> undefined >>>>> when P-bit=0 and should be ignored. Likewise, I do not see any reason >>>>> to >>>>> define Next Protocol = 0 to indicate an Ethernet payload (the current >>>>> draft >>>>> has NP=0 as reserved, and NP=3 as Ethernet), since a RFC 7348 >>>>> implementation >>>>> should be ignoring that field regardless. I¹m referring to section 5 >>>>> of RFC >>>>> 7348 which states "Reserved fields (24 bits and 8 bits): MUST be set to >>>>> zero >>>>> on transmission and ignored on receipt." >>>>> >>>>> Thanks, Larry >>>>> >>>>> >>>>> From: Shahram Davari <[email protected]> >>>>> Date: Wednesday, September 23, 2015 at 4:02 PM >>>>> To: Anoop Ghanwani <[email protected]>, Larry Kreeger >>>>> <[email protected]> >>>>> Cc: "Sandeep Kumar (Sandeep) Relan" <[email protected]>, >>>>> "[email protected]" >>>>> <[email protected]> >>>>> 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: [email protected] [mailto:[email protected]] On Behalf Of >>>>> Anoop >>>>> Ghanwani >>>>> Sent: Wednesday, September 23, 2015 3:16 PM >>>>> To: Larry Kreeger (kreeger) >>>>> Cc: Sandeep Kumar (Sandeep) Relan; [email protected]; 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) >>>>> <[email protected]> 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" <[email protected]> >>>>> Date: Monday, September 21, 2015 at 7:28 PM >>>>> To: "[email protected]" <[email protected]> >>>>> Cc: Shahram Davari <[email protected]>, Larry Kreeger >>>>> <[email protected]> >>>>> 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) < >>>>> [email protected]> >>>>> 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" <[email protected]> >>>>> Date: Monday, September 21, 2015 at 5:28 PM >>>>> To: "[email protected]" <[email protected]> >>>>> Cc: Shahram Davari <[email protected]>, Larry Kreeger >>>>> <[email protected]> >>>>> 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:[email protected]] >>>>> Sent: Monday, September 21, 2015 4:52 PM >>>>> To: Shahram Davari >>>>> Cc: Sandeep Kumar (Sandeep) Relan; [email protected] >>>>> 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 <[email protected]> >>>>> Date: Monday, September 21, 2015 at 4:40 PM >>>>> To: Larry Kreeger <[email protected]> >>>>> Cc: "Sandeep Kumar (Sandeep) Relan" <[email protected]>, >>>>> "[email protected]" >>>>> <[email protected]> >>>>> 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) < >>>>> [email protected]> >>>>> 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 <[email protected]> on behalf of "Sandeep Kumar >>>>> (Sandeep) >>>>> Relan" <[email protected]> >>>>> Date: Monday, September 21, 2015 at 4:24 PM >>>>> To: "[email protected]" <[email protected]> >>>>> 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], 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 >>>>> [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 >> > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
