Copying the LISP working group mailing list.
>> This implies that both gpe LISP and legacy LISP may be used in the market. >> Is that true only IP-in-IP application need nonce feature? Mobility is >> important requirement for cloud applications, so gpe LISP needs to develop >> other solution for this feature? Sorry, this is a hard sale. > > If you use IP-in-IP you don't need to set the P-bit, making the nonce > available for use. Yes, there are applications where the nonce is useful. > [Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will not > support that. Why do we want to remove this in the protocol evolution? Lucy, we are not removing anything. Like I said (and I don't want to continually repeat myself) that the features are tradeoffs. The motivation for the change was to get VXLAN to have protocol demuxing. [Lucy] For VXLAN to support protocol demuxing, no need to use P bit. We have the proposal (https://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/). And in the spirit of keeping the packet formats for VXLAN and LISP as identical as VXLAN will have it, the P-bit is being proposed for LISP. [Lucy] This logic means that if VXLAN does not need P bit, LISP does not have to have it either, right? It also indicates that you do not see the applications for gpe LISP router, is that right? IMO: LISP and VXLAN have different UDP port numbers, which is sufficient to differentiate the two. This is a proposal. The LISP working group must decide if the draft becomes a working group document. [Lucy] People need carefully evaluation this proposal impact on LISP. Regards, Lucy Dino > > Lucy > > Dino > >> >> Regards, >> Lucy >> >> >> >> -----Original Message----- >> From: Dino Farinacci [mailto:farina...@gmail.com] >> Sent: Tuesday, September 10, 2013 10:56 AM >> To: Lucy yong >> Cc: Paul Quinn (paulq); n...@ietf.org >> Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt >> >>> 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. >> >> No it does not mean that. It means that the features need to be traded off. >> So the market/user-base will decide what it wants to use that field for. >> >> Dino >> >> _______________________________________________ >> nvo3 mailing list >> n...@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > n...@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
