Hi Ketan,
Thanks! I got it.
Actually the description in draft-ietf-bess-bgp-srv6-args-05 is very clear.
My consideration is from the implementation point of view, but it is OK to
ignore it in the draft.
Best regards,
Sandy
Original
From: KetanTalaulikar <ketant.i...@gmail.com>
To: 张征00007940;
Cc: rtg-...@ietf.org <rtg-...@ietf.org>;bess@ietf.org
<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org
<draft-ietf-bess-bgp-srv6-args....@ietf.org>;
Date: 2025年03月03日 16:07
Subject: Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05
Hi Sandy,
The transposition scheme is a purely BGP encoding thing and orthogonal to the
AL validation/checks.
One can choose not to do transposition, or do transposition with various sizes
(up to what fits in the label field). The AL validation check has to be done
and applied in all cases where ARGs are used (e.g., End.DT2M).
I hope this clarifies.
Thanks,
Ketan
On Mon, Mar 3, 2025 at 1:31 PM <zhang.zh...@zte.com.cn> wrote:
Hi Ketan,
Thank you very much for your response!
RFC9252 indicates that either 24 bits or 20 bits can be used for efficient
encapsulation, but the transposition scheme is not used exclusively for EVPN
Type 1 and 3 routing.
So there is no need to change RFC9252 to force the use of 24 bits for the
transposition scheme.
Validation method used in draft-ietf-bess-bgp-srv6-args-05 fails when different
AL values are used in Type 1 and 3.
Therefore, in my opinion, it is better to use a unified transposition length of
24 bits for Type 1 and 3 to avoid validation failures.
So my suggestion is that when adding the reference to the transposition scheme
of Section 4, a sentence may be added to indicate that the transposition
lengths of type 1 and type 3 should be unified (24 bits is better) when using
the transposition scheme.
Best regards,
Sandy
Original
From: KetanTalaulikar <ketant.i...@gmail.com>
To: 张征00007940;
Cc: rtg-...@ietf.org <rtg-...@ietf.org>;bess@ietf.org
<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org
<draft-ietf-bess-bgp-srv6-args....@ietf.org>;
Date: 2025年03月03日 14:28
Subject: Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05
Hi Sandy,
Please check inline below for responses.
On Fri, Feb 28, 2025 at 9:38 PM <zhang.zh...@zte.com.cn> wrote:
Hi Ketan,
Sorry, my description in my last email was not accurate enough.
Please let me sort out the comments:
In section 3.2.1 in RFC9252, it says that the transposition length can be 20
(due to the MPLS label field size).
KT> The following is the text in
https://www.rfc-editor.org/rfc/rfc9252.html#section-3.2.1
The size of the MPLS Label field limits the bits transposed from the SRv6 SID
value into it. For example, the size of the MPLS Label field is 20 bits in
[RFC4364] and [RFC8277], and the size is 24 bits in [RFC7432].
This is due to the difference in encoding between L3VPN and EVPN.
From the description of section 4 in RFC9252,
"for the EVPN Ethernet Auto-Discovery (A-D)
per Ethernet Segment (ES) route described further in Section 6.1.1,
only the Argument of the SID needs to be signaled. This Argument
part of the SRv6 SID MAY be transposed in the Ethernet Segment
Identifier (ESI) Label field of the ESI Label extended community, and
the SID value in the SRv6 Services TLV is set to 0 along with the
inclusion of the SRv6 SID Structure Sub-Sub-TLV. "
My understanding is that only Argument is signaled for ES filtering.
KT> The argument part of the SID is signaled in the Route Type 1. The rest of
the SID in Route Type 3.
In section 3.1 in draft-ietf-bess-bgp-srv6-args, it says:
“Additionally, as a
non-zero ARG value is being signaled, the Argument Length (AL) MUST
be set to the size of the ARG, and the size SHOULD be a multiple of
8.”
In my understanding the entire 24 bits (not 20 bits) label size advertised in
type 1 and 3 should be used for the transposition scheme. In this case, the
transposition length may be set to 24 only.
KT> The draft-ietf-bess-bgp-srv6-args does not talk about transposition since
that is unchanged from RFC9252. Please refer to the relevant sections in RFC
9252 for the EVPN Route Types 1 and 3 where you will find the text for the
transposition aspects for those specific routes.
https://www.rfc-editor.org/rfc/rfc9252.html#section-6.1
https://www.rfc-editor.org/rfc/rfc9252.html#section-6.3
As draft-ietf-bess-bgp-srv6-args says, the functions defined in this draft also
apply to the transposition scheme.
So according to the above description, the TPOS-L is 24 only in this case.
KT> It can be up to 24 - i.e., a smaller value is also possible as per RFC9252.
I don't see the reason why we need to change RFC9252 and mandate that TPOS-L
has to be 24.
Thanks,
Ketan
Best regards,
Sandy
Original
From: KetanTalaulikar <ketant.i...@gmail.com>
To: 张征00007940;
Cc: rtg-...@ietf.org <rtg-...@ietf.org>;bess@ietf.org
<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org
<draft-ietf-bess-bgp-srv6-args....@ietf.org>;
Date: 2025年02月28日 15:13
Subject: Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05
Hi Sandy,
I am still unable to understand your point. Is it possible for you to please
explain with an example?
Thanks,
Ketan
On Thu, Feb 27, 2025 at 9:57 PM <zhang.zh...@zte.com.cn> wrote:
Hi Ketan,
Thank you for the coming update!
For the second comment, from section 6.1.1 of RFC9252,
‘When using the Transposition Scheme, the Transposition Length MUST be less
than or equal to 24 and less than or equal to the AL.’
If I understand right, the sentence means that the Transposition length can be
24 or less.
I am wondering the verification should be yes or no when the transportation
length isn’t the same but the label value is.
So IMO it may be simpler to limit the transportation length to 24 bits.
Best regards,
Sandy
Original
From:KetanTalaulikar<ketant.i...@gmail.com>
To:张征00007940;
Cc:rtg-...@ietf.org;bess<bess@ietf.org>;draft-ietf-bess-bgp-srv6-args....@ietf.org;
Date:2025-02-27 21:36:43
Subject:Re: Rtgdir early review of draft-ietf-bess-bgp-srv6-args-05
Hi Sandy,
Thanks for your review. Please check inline below for responses.
On Thu, Feb 27, 2025 at 6:56 PM Zheng Zhang via Datatracker <nore...@ietf.org>
wrote:
Reviewer: Zheng Zhang
Review result: Ready
Hello,
I have been selected as the Routing Directorate reviewer for this draft.
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-srv6-args/
Document: draft-ietf-bess-bgp-srv6-args-05
Reviewer: Zheng (Sandy) Zhang
Review Date: Feb 27th, 2025
Intended Status: Standards Track
Summary:
This draft is well written and clear.
No issues found. This document is ready for publication.
Major issues: None.
Nits: None.
Comments:
The functionality defined in this document also applies to the transposition
scheme defined in RFC9252. It might be better to add a reference to RFC9252
Section 4 in the last paragraph of the first section.
KT> We also got the very same feedback from the Genart review
(https://mailarchive.ietf.org/arch/msg/bess/l1I-NBJB3XzRe8Z0HLuQWpR7nzY/) and
we'll add that in the next update.
Since this draft applies
to route types 1 and 3, and the associated label is 3 octets, it is appropriate
to only apply 24 bits here to the transposition scheme. So it would be best to
add a sentence or two to the above.
KT> This is already covered by RFC9252 - e.g.,
https://www.rfc-editor.org/rfc/rfc9252.html#section-6.1.1 ... do let me know if
I am missing something.
Thanks,
Ketan
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
