Hi Yubao, The label fields per RFC7432 are 24-bit. When carrying actual MPLS labels in them, the high-order 20 bits are to be used per RFC7432. The rest of the 4 bits are not meant for TC/S though. Moreover, for SRv6 we are following the convention of VXLAN where 24-bit VNI is encoded in the EVPN label fields - refer https://datatracker.ietf.org/doc/html/rfc8365#section-5.1.3
Now contrast this with encodings that follow RFC8277 where the label field itself is 20-bit and leaves 3 bits reserved (not really TC semantics) and 1 bit for S (bottom of the stack semantics but only for the purpose of encoding a stack of labels) - refer https://datatracker.ietf.org/doc/html/rfc8277#section-2.2 I hope this clarifies. Thanks, Ketan On Fri, Jun 17, 2022 at 9:33 AM <wang.yub...@zte.com.cn> wrote: > > Hi Ketan, > > > Thanks for your clarifications. > > But I still don't notice that RFC7432 has said that the label value is 24 > bits, > > I just found these paragraphs in RFC7432 or rfc7432bis: > > > <rfc7432#section9.2.1> > > The MPLS Label1 field is encoded as 3 octets, where *the high-order* > > * 20 bits* contain *the label value*. The MPLS Label1 MUST be > downstream > > assigned, and it is associated with the MAC address being advertised > > by the advertising PE. The advertising PE uses this label when it > > receives an MPLS-encapsulated packet to perform forwarding based on > > the destination MAC address toward the CE. The forwarding procedures > > are specified in Sections 13 and 14. > > ... > > The MPLS Label2 field is an optional field. If it is present, then > > it is encoded as 3 octets, where *the high-order 20 bits* contain *the* > > * label value*. > > </rfc7432> > > > <rfc7432bis> > > 7.5. ESI Label Extended Community > > > This Extended Community is a new transitive Extended Community having > > a Type field value of 0x06 and the Sub-Type 0x01. It may be > > advertised along with Ethernet Auto-discovery routes, and it enables > > split-horizon procedures for multihomed sites as described in > > Section 8.3 ("Split Horizon"). The ESI Label field represents an ES > > by the advertising PE, and it is used in split-horizon filtering by > > other PEs that are connected to the same multihomed Ethernet segment. > > > The ESI Label field is encoded as 3 octets, where *the high-order* > > * 20 bits* contain *the label value*. > > </rfc7432bis> > > > In these paragraphs, It is clear that the MPLS Label/ESI label can only > carry a label value which is no more than 20 bits. > > Have I missed something important? > > When the ESI label field of RFC7432 carries a 20 bits ESI label 17, the 24 > bits ESI label field should be 0x000110 or 0x000011? > > When the ESI label field of draft-ietf-bess-srv6-services-15 carries a 20 > bits Arg.FE2 17, the 24 bits ESI label field should be 0x000110 or 0x000011? > > When the ESI label field of draft-ietf-bess-srv6-services-15 carries a 16 > bits Arg.FE2 17, the 24 bits ESI label field should be 0x000110 or 0x001100 > or 0x000011? > > > > Thanks, > > Yubao > > > > > 原始邮件 > *发件人：*KetanTalaulikar > *收件人：*王玉保10045807; > *抄送人：*draft-ietf-bess-srv6-servi...@ietf.org;BESS; > *日 期 ：*2022年06月16日 22:04 > *主 题 ：**Re: Whether the TC/S field of the ESI label field can be used to > carry a portion of Arg.FE2 according to draft-ietf-bess-srv6-services-15 ?* > Hi Yubao, > Sorry for the delay in response and thanks for catching this issue. We'll > try to correct this during the AUTH48 process. > > Please check inline below. > > On Thu, May 26, 2022 at 8:20 AM <wang.yub...@zte.com.cn> wrote: > >> >> Hi authors, >> >> >> There may be conflicting description in >> draft-ietf-bess-srv6-services-15#section-6.1.1 >> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-15#section-6.1.1> >> on the usage of Transposition Length. >> >> >> <draft-ietf-bess-srv6-services-15#section-6.1.1> >> >> The 24-bit ESI label field of the ESI label extended community >> >> carries the whole or a portion of the Argument part of the SRv6 SID >> >> when the ESI filtering approach is used along with the Transposition >> >> Scheme of encoding (Section 4) and otherwise set to Implicit NULL >> >> value. *In either case*, *the value* is set in *the high order 20 >> bits* >> >> (e.g., as 0x000030 in the case of Implicit NULL). When using the >> >> Transposition Scheme, the *Transposition Length* MUST be less than or >> >> *equal to 24* and less than or equal to the Argument Length. >> >> </draft-ietf-bess-srv6-services-15> >> >> >> I think that "The value" which is set in "the high order 20 bits" should >> be the same thing as "the whole or a portion of the Argument part of the >> SRv6 SID", >> >> If this is true, the length of "The value" (which is also the >> Transposition Length) can only be as much as 20, it can't be equal to 24. >> >> Otherwise, "The value" may have to be carried in the high X bits of the >> ESI label field (wherein X is the argument length), not always the "the >> high order 20 bits". >> >> >> > KT> This is an error in the draft. Since the field is 24-bit, we should > just say "set in the 24 bits" instead of the existing text "set in the high > order 20 bits". This applies to all EVPN encodings in the draft. > >> >> >> I also noted that in some other sections(e.g. Section 5.1), it is clearly >> described that the Transposition Length MUST be no more 20. >> > KT> This depends on the encoding for the specific AFI/SAFI. For those that > use the RFC8277 label encoding, the transposition length is limited to 20. > That is why the "high order" clarification came in but it does not apply to > EVPN. Please also see the following text in Sec 3.2.1 > > The size of the MPLS label field limits the bits transposed from the > SRv6 SID value into it. E.g., the size of MPLS label field in [RFC4364 > <https://datatracker.ietf.org/doc/html/rfc4364>] [RFC8277 > <https://datatracker.ietf.org/doc/html/rfc8277>] is 20 bits while in [RFC7432 > <https://datatracker.ietf.org/doc/html/rfc7432>] is 24 bits. > > >> >> So I think may be the transposition length for EVPN routes is not >> necessary to be greater than 20. >> > KT> For EVPN encodings the field is 24-bit and so we can transpose up to > 24 bits. > >> >> If it is greater than 20, the TC/S field of the ESI label may have to be >> used, >> > KT> There is no TC/S encoding in the ESI label field. > >> >> and the bit order may be not the same "In either case". >> > KT> I am not sure what you mean by bit order. If you are referring to byte > ordering then everything is in network byte order. > > Thanks, > Ketan > >> >> Because that if the Transposition Length is less than 21, it MUST be >> cairried in the high order 20 bits (along with some padding bits) according >> to the history of this draft, not just the high X bits. >> >> Is my understanding correct? >> >> >> Glad to receive any clarifications. >> >> >> Thanks, >> >> Yubao >> >> >> >> >> >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
