Subject: [nvo3] Shim header of vxlan-gpe

From: Lizhong Jin <[email-masked]>
Date: Sun, 13 Oct 2019 10:29:11 +0800

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

---

From: "Fabio Maino (fmaino)" <[email-masked]>
Date: Wed, 23 Oct 2019 22:14:34 +0000

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 <[email-masked]>
Date: Saturday, October 12, 2019 at 7:29 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Shim header of vxlan-gpe
Resent-From: <[email-masked]>
Resent-To: Fabio Maino <[email-masked]>, Larry Kreeger <[email-masked]>, <[email-masked]>
Resent-Date: Saturday, October 12, 2019 at 7:29 PM

Hi GPE authors,

Regards
Lizhong

---

From: "Liubing (Remy)" <[email-masked]>
Date: Sat, 26 Oct 2019 01:01:38 +0000

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:[email-masked]] On Behalf Of Fabio Maino (fmaino)
Sent: Thursday, October 24, 2019 6:15 AM
To: Lizhong Jin <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] Shim header of vxlan-gpe

Hi Lizhong,
Sorry for the delay.

Thanks,
Fabio

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

Hi GPE authors,

Regards
Lizhong

---

From: Lizhong Jin <[email-masked]>
Date: Mon, 28 Oct 2019 07:08:25 -0700

Hi Fabio,
Thanks for the reply. I read the version 08, and it is OK now.
At first glance, I though Next Protocol of values from 0x0 to 0x7F was only
for dataplane processing. But later I found GBP moved from 0x6 to 0x80
which broke my assumption. Could you help to explain why GBP do such change
since you are also author of GBP?
Agree that some suggestions for the assignment is difficult. But from the
implementation point of view, if some shim headers are not critical (As
Remy mentioned), it would be better to have a way to skip them, and get to
the Next Protocol of values from 0x0 to 0x7F directly. That will ease the
ASIC design, some new defined non-critical shim headers will not break
existing GPE implementation.

Regards
Lizhong

On Thu, Oct 24, 2019 at 6:14 AM Fabio Maino (fmaino) <[email-masked]>
wrote:

> 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 <[email-masked]>
> *Date: *Saturday, October 12, 2019 at 7:29 PM
> *To: *"[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Shim header of vxlan-gpe
> *Resent-From: *<[email-masked]>
> *Resent-To: *Fabio Maino <[email-masked]>, Larry Kreeger <
> [email-masked]>, <[email-masked]>
> *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
>