Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

["Larry Kreeger (kreeger)" <[e-mail]>]

On 9/24/15, 8:14 AM, "Lucy yong" <[e-mail]> wrote:

> 
>
>See inline below.
>
>-----Original Message-----
>From: Tom Herbert [mailto:[e-mail]]
>Sent: Thursday, September 24, 2015 10:08 AM
>To: Lucy yong
>Cc: Anoop Ghanwani; Larry Kreeger (kreeger); Sandeep Kumar (Sandeep)
>Relan; [e-mail]; Shahram Davari
>Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00
>
>> What we may want to say, then, is that if a P bit of 0 is used then
>> none of the other flags must be set.  This would prevent someone from
>> generating a packet with a P bit of 0 and trying to use new GPE
>>features.
>>
>> [Lucy] The P bit is used for version purpose too.  The rule is if the
>> GPE need support new features to Ethernet payload, it has to set P bit
>> and use the protocol field to indicate Ethernet payload.
>>
>> The rule is: GPE accepts a special case of P=0 mode as valid for
>> Ethernet Payload., and P =1 (mode) & Protocol = Ethernet (0x03). When
>> a P bit of 0 is used, none of the other flags must be set.
>>
>>
>>
>> This works under condition/rule that VXLAN protocol enhancement MUST
>> be stopped.
>>
>Lucy,
>
>I'm not sure why the constraint needs to be so stringent. The P bit can
>be used to discriminate between VXLAN and VXLAN-GPE received on the same
>port. i.e if P bit is set, it is a VXLAN-GPE packet. If it is not set it
>is VXLAN packet and the rest of the fields are processed accordingly. New
>features can be added to either protocol in this way using the other
>reserved bits independently. This allows backwards compatibility to
>receive VXLAN on a VXLAN-GPE port (doesn't help with the forward
>compatibility problem though).
>[Lucy] What you say is the draft intention. My comment is to say, if we
>add this rule as Anoop suggested "When
>a P bit of 0 is used, none of the other flags must be set.", it will only
>work if no more VXLAN enhancement in future, e.g. using a new bit for
>something. If there will be, it will cause an issue for interworking
>between two. I just want to point out for caution.

If I can restate what I think you two agree on, it is:  If VXLAN evolves
independently from VXLAN GPE, then a VXLAN GPE endpoint that understands
only how to be backward compatible with RFC7348 VXLAN will not be able to
be compatible with the unknown evolution of RFC748.

For this reason, I would discourage anyone from taking RFC7348 VXLAN on a
separate evolutionary path from VXLAN than what VXLAN GPE is.  I would
encourage any IETF work on evolving VXLAN to instead evolve VXLAN GPE
which has an actual version field to prevent unknown forwarding behavior
from occurring if a VXLAN GPE version 0 endpoint receives an evolved (next
version) of VXLAN GPE.

 - Larry


>
>Lucy
>
>Tom