Paul, I am not sure applying P bit in LISP header will address the backward compatibility in LISP. The lisp-gpe draft does not address how LISP-gpe router handles the packet when receiving it from LISP router with N,E, or V bit set. Furthermore, the statement of "The receiving (legacy) LISP router will ignore N, E and V bits, when the P bit is set." in the draft indicates the request of change on legacy LISP router.
Regarding to the protocol evolution, does this mean that nonce/map-version features in LISP will be deprecated? IMO: Having the same field overloaded for many difference purposes is not good way for the protocol evolution, it becomes messy. Regards, Lucy -----Original Message----- From: Paul Quinn (paulq) [mailto:[email protected]] Sent: Monday, September 09, 2013 9:03 PM To: Lucy yong Cc: [email protected] Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt Lucy, Thank you for your comments. The P bit provides much needed flexibility for the protocol. First and foremost, it enables the creation of a single on the wire protocol that encompasses both VXLAN and LISP (please see http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 for the associated LISP draft). The P bit also enables the evolution of the protocol, allowing the format to change as needed with a simple bit change. Thank you, Paul On Sep 6, 2013, at 3:20 PM, Lucy yong <[email protected]> wrote: > Hi Paul, > > I read this draft. Both this draft and our draft > http://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/ propose > adding prototype type field in VXLAN header in supporting L3 overlays (or > other) beside L2 overlays. The only difference between two is that this draft > requests using P bit to indicate the presence of protocol type field in VXLAN > header. We don't think this is necessary. For the backward compatibility, we > propose treating protocol type value 0 as Ethernet payload. > > This draft gives two ways to do L2 overlay. If P bit is set and protocol type > value 0x6558, L2 payload is follow, or P bit is unset, L2 payload is follow. > IMHO, this is bad. > > Regards, > Lucy > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Paul Quinn (paulq) > Sent: Friday, September 06, 2013 5:04 PM > To: [email protected] > Subject: [nvo3] Fwd: New Version Notification for > draft-quinn-vxlan-gpe-00.txt > > FYI for the group. > > Paul > > Begin forwarded message: >> >> A new version of I-D, draft-quinn-vxlan-gpe-00.txt has been >> successfully submitted by Paul Quinn and posted to the IETF >> repository. >> >> Filename: draft-quinn-vxlan-gpe >> Revision: 00 >> Title: Generic Protocol Extension for VXLAN >> Creation date: 2013-08-27 >> Group: Individual Submission >> Number of pages: 13 >> URL: >> http://www.ietf.org/internet-drafts/draft-quinn-vxlan-gpe-00.txt >> Status: http://datatracker.ietf.org/doc/draft-quinn-vxlan-gpe >> Htmlized: http://tools.ietf.org/html/draft-quinn-vxlan-gpe-00 >> >> >> Abstract: >> This draft describes a mechanism for adding multi-protocol support >> to Virtual eXtensible Local Area Network (VXLAN). Protocol >> identification is carried in the VXLAN header and is used to describe >> the encapsulated payload. >> >> >> >> >> 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. >> >> The IETF Secretariat >> > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
