Re: [nvo3] Shim header of vxlan-gpe

["Liubing (Remy)" <[e-mail]>]

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.

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?

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