Re: [nvo3] Shim header of vxlan-gpe

["Fabio Maino (fmaino)" <[e-mail]>]

Hi Remy,
Thanks for your comments.

See my notes below. I’ll include this discussion in Monday’s presentation as well.

From: "Liubing (Remy)" <[e-mail]>
Date: Friday, October 25, 2019 at 6:01 PM
To: Fabio Maino <[e-mail]>, Lizhong Jin <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Shim header of vxlan-gpe

Hi Fabio,

I also have some questions regarding to the shim header.

If I understand it correctly, the logic of the shim header is similar  to the non-critical TLV in GENEVE. But I think some clarification is required.

Quote from the draft: "Implementations that are not aware of a given shim header MUST ignore the header and proceed to parse the next protocol." The definition of "implementations" is not clear enough. The implementation can be a transit node or the NVE and the related operations should be differentiated. In my opinion, the NVE should not or even must not ignore any shim header, while the transit node can do this.

[FM] The goal of the shim headers is to provide a simple mechanism to incrementally deploy new GPE features without the need to update the implementation of each transit node between two tunnel endpoints, while not panting the packet with shim headers of unknown type to the ‘slow’ path.

I’ll update the text to clarify that the MUST ignore refers to transit nodes.


Another point may need to be clarified: does "...are not aware of a given shim header..." mean that the device have to at least know that there is a shim header and how long it is so that it can skip the header to parse the next protocol? If the device can't recognize any shim header, i.e. it does not know the meaning of "0x80 to 0xFF", the packet must be dropped in this case?

[FM] The shim headers MUST have the specified format, so an implementation of GPE will be able to parse shim headers as long as their type is between 0x80 and 0xFF (and they’re formatted properly).

I’ll update the text in this way, that I hope will address also Lizhong comment:

Transit nodes that are not aware of a given shim header type MUST ignore the header and proceed to parse the next protocol.
Shim headers can be used to incrementally deploy new GPE features without updating the implementation of each transit node between two tunnel endpoints, and without panting the packet with shim headers of unknown type to the ‘slow’ path.



Thanks,
Fabio

Best regards,
Remy

From: nvo3 [mailto:[e-mail]] On Behalf Of Fabio Maino (fmaino)
Sent: Thursday, October 24, 2019 6:15 AM
To: Lizhong Jin <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [nvo3] Shim header of vxlan-gpe

Hi Lizhong,
Sorry for the delay.

Vxlan-gpe version 08 should now contain the appropriate reference to [I-D.lemon-vxlan-lisp-gpe-gbp]. Let me know if I’m missing anything.

I know designing ASICs with the added flexibility required by the shim headers comes at a cost. Ultimately implementations will have to choose which extensions to support, and how much buffer to dedicate for unsupported extensions. I don’t think there’s a general rule that can be applied. Do you have any suggestion? Restricting to control plane functions might be too much, even some of the OAM features might end up  being implemented in the dataplane.

Wrt GBP it’s a fairly well known  use case, but not universally deployed so we wanted to leave to implementors the decision to support or not that extension.

Thanks,
Fabio






From: Lizhong Jin <[e-mail]<mailto:[e-mail]>>
Date: Saturday, October 12, 2019 at 7:29 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Shim header of vxlan-gpe
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Fabio Maino <[e-mail]<mailto:[e-mail]>>, Larry Kreeger <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Saturday, October 12, 2019 at 7:29 PM


Hi GPE authors,
I recently review the GPE draft and the shim header design. I saw the "Next Protocol" assigned to GBP changed from 0x6 to 0x80, and the reference of [I-D.lemon-vxlan-lisp-gpe-gbp] should be updated from version 01 to version 02 which confused me in my first reading. I am not clear why GBP do such kind of update, do you have any design principles for the "Next Protocol" assignment for range from 0x80 to 0xFF? Some practical design principles in the document would benefit the industry.
And since shim header is a TLV style, I tend to ask if it would be practical to restrict the shim header to be used only for OAM and control purpose. That would greatly simplify the ASIC design.

Regards
Lizhong