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 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/
>
> _______________________________________________
> I-D-Announce mailing list
> [email protected]
> 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
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
