Hi Yubao, If it is clear enough then I would avoid adding more text to confuse people :-)
Thanks again for flagging this issue. Thanks, Ketan On Fri, Jun 17, 2022 at 2:52 PM <wang.yub...@zte.com.cn> wrote: > > Hi Ketan, > > > Thanks for your further explanations. > > Please see in line with [Yubao2]. > > > Thanks, > > Yubao > > > > 原始邮件 > *发件人：*KetanTalaulikar > *收件人：*王玉保10045807; > *抄送人：*draft-ietf-bess-srv6-servi...@ietf.org;BESS; > *日 期 ：*2022年06月17日 15:44 > *主 题 ：**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, > 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. > > > > [Yubao2] I think it is clear enough for many people, > > But if we can describe it more clearly, maybe it will be > better. > > For example, when we say that the Implicit NULL value is > set in the 24 bits, > > I think it should be the same as we say that the label > value 3 is set in the 24 bits, > > then the 24 bits should be 0x000003, not 0x000030. > > but now we imply that when 3 is set in the 24 bits, it > should be 0x000030, not 0x000003. > > I think this updated text may still implies that when an > Arg.FE2 is 3 and it is set in the 24 bits, > > the ESI label field should be set to 0x000030, not > 0x000003. > > I think the phrase "In either case" can be modified. > > For example: In the former case, the value is set in the > 24 bits. in the latter case, > > the implicit NULL value is set in the high order 20 bits or > the 0x000030 (but not an implicit NULL label) is set in the 24 bits.. > > > <rfc3032> > > iv. A value of 3 represents the "Implicit NULL Label". This > > is a label that an LSR may assign and distribute, but > > which never actually appears in the encapsulation. When > > an LSR would otherwise replace the label at the top of the > > stack with a new label, but the new label is "Implicit > > NULL", the LSR will pop the stack instead of doing the > > replacement. Although this value may never appear in the > > encapsulation, it needs to be specified in the Label > > Distribution Protocol, so a value is reserved. > > </rfc3032> > > > > 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
