Hi Yubao, Please check inline below.
On Fri, Jun 17, 2022 at 12:28 PM <wang.yub...@zte.com.cn> wrote: > > Hi Ketan, > > > Please see in line with [Yubao]. > > > Thanks, > > Yubao > > > > 原始邮件 > *发件人：*KetanTalaulikar > *收件人：*王玉保10045807; > *抄送人：*draft-ietf-bess-srv6-servi...@ietf.org;BESS; > *日 期 ：*2022年06月17日 13:33 > *主 题 ：**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, > 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> > https://datatracker.ietf.org/doc/html/rfc8365#section-5.1.3 > > > [Yubao] But an Arg.FE2 is not always 24 bits, it can be 16 bits, 8 bits, > or 23 bits. That's the difference between VNI and Arg.FE2. > > For example, when the Argument Length of an Arg.FE2 is 16 > bits, and the value of that Arg.FE2 is 17, > > and it is "set in the 24 bits" of an ESI label field, > > My understanding is that, that 24 bits ESI label field > should be set to 0x000011 (RFC8365 VNI style), not 0x001100 or 0x000110 > (RFC7432 MPLS style). > > Is my understanding correct? > KT> Yes. In your example, the Arg value is 17 and it is just encoded in the ESI label field. Much as a VNI value of 17 would be encoded. > I ask this question because I indeed noticed that there are > already different implements. > > In previous mail, I used the phrase "bit order" to refer to > these different implementations. > > I think it will be better to clarify this with more detailed > description. > KT> Following is the proposed updated text for sec 6.1. Would this be clear enough? 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); otherwise, it is set to the Implicit NULL value (i.e., as 0x000030). In either case, the value is set in the 24 bits. When using the Transposition Scheme, the Transposition Length MUST be less than or equal to 24 and less than or equal to the AL. > By the way, RFC8365 won't use the ESI label field. > > So I think it is not very clear to simply refer to RFC8365. > Some detailed clarifications may still be needed. > > > > 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> > https://datatracker.ietf.org/doc/html/rfc8277#section-2.2 > > > [Yubao] So when the function part of an End.DT4 SID is just 16 bits (not > 20 bits) and its value is 17 which is carried in the label field, > > the value of the 20 bits label field should be 0x00011, not > 0x00110, > > is my understanding correct? > KT> Yes. There is no error/issue with the L3VPN text so I don't know why would anyone do "0x00110". > I think the factor that the length of the Function part or > Argument part of a SRv6 SID will be varied, > > that factor may make it need more clarifications in the > draft. > KT> Again, not sure what more is required besides the correction indicated above in the EVPN text. Thanks, Ketan > > 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
