Re: [bess] 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 ?

[Rabadan, Jorge (Nokia - US/Sunnyvale)]

Hi Yubao,

RFC7432 assumes MPLS transport and hence label fields are 20-bit long.
RFC8365 though assumes NVO transport and the label fields are 24-bit long.

That’s why Ketan mentioned the label field in EVPN routes is 24-bit long.

Thanks.
Jorge

From: BESS  on behalf of wang.yub...@zte.com.cn 

Date: Friday, June 17, 2022 at 6:04 AM
To: ketant.i...@gmail.com 
Cc: draft-ietf-bess-srv6-servi...@ietf.org 
, bess@ietf.org 
Subject: Re: [bess] 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 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:





   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.







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.





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 0x11?

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 0x11?

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 
0x11?





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 
mailto: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.





   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 0x30 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.





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/SA

Re: [bess] 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 ?

[Ketan Talaulikar]

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  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  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
>>
>>
>> [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 0x11 (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 0x30).  *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 0x03, not 0x30.
>
> but now we imply that when 3 is set in the 24 bits, it
> should be 0x30, not 0x03.
>
> 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 0x30, not
> 0x03.
>
> 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 0x30 (but not an implicit NULL label) is set in the 24 bits..
>
>
> 
>
>   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.
>
> 
>
>
>
>   By the way, RFC8365 won't use the ESI

Re: [bess] 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 ?

[wang.yubao2]

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  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




[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 0x11 (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 0x30).  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 0x03, not 0x30.

but now we imply that when 3 is set in the 24 bits, it should 
be 0x30, not 0x03.

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 0x30, not 0x03.

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 
0x30 (but not an implicit NULL label) is set in the 24 bits..








  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.   














  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/htm

Re: [bess] 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 ?

[Ketan Talaulikar]

Hi Yubao,

Please check inline below.

On Fri, Jun 17, 2022 at 12:28 PM  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
>
>
> [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 0x11 (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 0x30).  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
>
>
> [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  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:
>>
>>
>> 
>>
>>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*.
>>
>> 
>>
>>
>> 
>>
>> 7.5.  ESI Label Extended Community
>>
>>
>>This Extended Community is a new transitive Extended Community having
>>
>>a Type field val

Re: [bess] 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 ?

[wang.yubao2]

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




[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 0x11 (RFC8365 VNI style), not 0x001100 or 0x000110 (RFC7432 MPLS 
style).

  Is my understanding correct?

  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.

  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




[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?

  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. 




I hope this clarifies.

Thanks,
Ketan 




On Fri, Jun 17, 2022 at 9:33 AM  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:








   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.












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.









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 0x11?


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 0x11?


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 
0x11?










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

Re: [bess] 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 ?

[Ketan Talaulikar]

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  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:
>
>
> 
>
>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*.
>
> 
>
>
> 
>
> 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*.
>
> 
>
>
> 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 0x11?
>
> 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 0x11?
>
> 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 0x11?
>
>
>
> 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  wrote:
>
>>
>> Hi authors,
>>
>>
>> There may be conflicting description in
>> draft-ietf-bess-srv6-services-15#section-6.1.1
>> 
>> on the usage of Transposition Length.
>>
>>
>> 
>>
>>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 0x30 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.
>>
>> 
>>
>>
>> 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 "

Re: [bess] 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 ?

[wang.yubao2]

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:








   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.












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.









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 0x11?


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 0x11?


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 
0x11?










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  wrote:






Hi authors,






There may be conflicting description in 
draft-ietf-bess-srv6-services-15#section-6.1.1  on the usage of Transposition 
Length.  









   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 0x30 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.






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] [RFC8277] is 20 
bits while in [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 b

Re: [bess] 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 ?

[Ketan Talaulikar]

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  wrote:

>
> Hi authors,
>
>
> There may be conflicting description in
> draft-ietf-bess-srv6-services-15#section-6.1.1
> 
> on the usage of Transposition Length.
>
>
> 
>
>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 0x30 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.
>
> 
>
>
> 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 ] [RFC8277
] is 20 bits while in
[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