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:[email protected]]
Sent: Thursday, December 3, 2020 5:01 PM
To: Wanghaibo (Rainsword) <[email protected]>; Bocci, Matthew (Nokia -
GB) <[email protected]>; [email protected];
[email protected]
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)
<[email protected]<mailto:[email protected]>>
Sent: 03 December 2020 09:13
To: Bocci, Matthew (Nokia - GB)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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:[email protected]]
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:[email protected]] On Behalf Of Bocci, Matthew (Nokia -
GB)
Sent: Tuesday, December 1, 2020 1:16 AM
To:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
