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 protected]] On Behalf Of Larry Kreeger (kreeger) Sent: Monday, May 04, 2015 9:54 PM To: William Caban; Jeff Tantsura Cc: Ian Cox; [email protected]; [email protected]; Joe Touch Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt 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 protected]<mailto:[email protected]>> Date: Monday, May 4, 2015 6:19 PM To: Jeff Tantsura <[email protected]<mailto:[email protected]>> Cc: Ian Cox <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Joe Touch <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt 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<https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-00#ref-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 protected]<mailto:[email protected]>> wrote: 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 protected]<mailto:[email protected]>> Date: Monday, May 4, 2015 at 4:51 PM To: Ian Cox <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-vxlan-gpe-00.txt 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]<mailto:[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]<mailto:[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<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
