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