Re: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Haibo,

This is not a change but a clarification to avoid exactly those kind of issues.

Thanks,
Ketan

From: Wanghaibo (Rainsword) <[e-mail]>
Sent: 03 December 2020 15:39
To: Ketan Talaulikar (ketant) <[e-mail]>; Bocci, Matthew (Nokia - GB) <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Hi Ketan,

         Thanks for your reply.

RFC 8277 has clearly described that the label field is only 20 bits.

At the beginning, we consider it to use the 20-bits to do the transposition. But in some interconnection tests, some vendors are use the 24-bits to do the transposition.

So I’m worried about that the change may cause incompatible interop.

Regards，
Haibo

From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Thursday, December 3, 2020 5:01 PM
To: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>; Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

Hi Haibo,

This clarification was explicitly added based on feedback that the authors received.

This document does not change the definition of the Label Field of RFC4364 and so it has always been 20 bits. There has been this text about 24-bit in other parts of the draft since RFC7432 allows that.

If you see the previous versions of this document, the encoding of the label was also previously clarified with a reference to RFC8277.

Regarding the BOS bit, the clarification is provided by RFC8277. Previously, this was under-specified by RFC3107. There are implementations around that do not check/examine the BOS field and assume a single label. You can see some of this history captured in RFC8277.

Thanks,
Ketan

From: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05


Dear authors and all,



 I find the following changes in the new version, which may cause incompatible changes in the implemented version.
[cid:image001.png@01D6C98C.A575E620]


The label field described in RFC4364:

4.3.4. How VPN-IPv4 NLRI Is Carried in BGP

   The labeled VPN-IPv4 NLRI itself is encoded as specified in

   [MPLS-BGP<https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where the prefix consists of an 8-byte RD followed by an

   IPv4 prefix.


 RFC 3107 describe the label field:

3. Carrying Label Mapping Information

      b) Label:



         The Label field carries one or more labels (that corresponds to

         the stack of labels [MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).  Each label is encoded as 3

         octets, where the high-order 20 bits contain the label value,

         and the low order bit contains "Bottom of Stack" (as defined in

         [MPLS-ENCAPS<https://tools.ietf.org/html/rfc3107#ref-MPLS-ENCAPS>]).


According to the definition, the label field in RFC 4364 should be 3 bytes,  but only 20 bits are used as the label value. So we may also use the entire 3 octets.

On the other hand,  if only 20 bits are used, do we need to add the BoS flag to the part when do the transposition?



Best Regards,

Haibo

From: BESS [mailto:[e-mail]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [bess] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-srv6-services-05

This email starts a two-week working group last call for draft-ietf-bess-srv6-services-05 [1]

Please review the draft and send any comments to the BESS list. Also, please indicate if you support publishing the draft as a standards track RFC.

This poll runs until Monday 14th December 2020.

We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
There is currently one IPR disclosure.

In addition, we are polling for knowledge of implementations of this draft, per the BESS policy in [2].

Thank you,
Matthew & Stephane


[1] https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw