Probably it requires at least the edge nodes to be all upgraded to prevent the leaking to the user. Either the deployment should guarantee that or some mechanism like capability exchange would be used.
IMHO prohibiting any usage of reserved bits is frustrating and goes against the original intention to even having "reserved bits". Thank, Yizhou -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Tom Herbert Sent: Tuesday, June 23, 2015 10:21 PM To: Dapeng Liu Cc: [email protected] Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network On Sat, Jun 20, 2015 at 1:04 PM, Dapeng Liu <[email protected]> wrote: > Hello all, > > We have submitted a draft for path detection in VXLAN overlay network. > http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detection/ > > The draft proposes a method for path detection in VXLAN network and it > defines the path detection packet format by using one reserve bit in > the VXLAN header. > > Comments & suggestions are welcomed. > "PD (1 bit) - Indicates it is a PD packet and needs to be handled as specified in this document." This does not seem not forward compatible since per RFC7348 reserved bits are ignored on receipt. Since the VXLAN draft purposely is putting valid headers in the VXLAN payload, I don't see anything that would prevent misinterpretation if such a packet is sent to a legacy device. Other attempts to extend VXLAN have hit this same problem, and it is probably also an issue in for nvgre. Thanks, Tom > > -- > Dapeng Liu > > > _______________________________________________ > 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
