Aijun –
https://www.rfc-editor.org/rfc/rfc9352.html#name-srv6-endx-sid-and-srv6-lan-
Note the indication that the sub-TLVs apply to TLV 25.
Les
From: Aijun Wang <[email protected]>
Sent: Saturday, July 19, 2025 9:24 PM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Dongjie <[email protected]>; Peter Psenak (ppsenak) <[email protected]>;
[email protected]; lsr <[email protected]>
Subject: Re: [Lsr] Re: Review of draft-dong-lsr-l2bundle-srv6-03
Hi, Les:
Where is the contents in RFC 9352 that mentions the “L2Bundle Member”?
Aijun Wang
China Telecom
On Jul 20, 2025, at 01:27, Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>>
wrote:
Jie –
As I said in my reply, I now correctly understand the point of your draft.
However, given that RFC9352 has been published and clearly specifies that SRv6
END.X sub-TLVs as defined in that document can be sent in TLV 25 for L2 Bundle
members, we now have a problem. If your draft were to progress, the end result
would be that there would be two standardized ways to send the same information
for L2Bundle members. This would then introduce interoperability issues. Some
nodes might support what is specified in RFC 9352 but not support the new way
you propose (or vice versa).
Given the length of time RFC9352 has been published we cannot ignore this
possibility.
If you had presented your draft much earlier (I note V0 was published in Feb
2021 – before last call on
draft-ietf-lsr-isis-srv6-extensions<https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/19/>
which became RFC9352 – but for some reason you never presented this idea until
now) then it would have been possible to alter that draft to indicate that the
current SRv6 END.X SID sub-TLV was NOT applicable to TLV 25 and we would not
have had this ambiguity.
I appreciate what your intent is, but I think the interoperability issues may
well outweigh the encoding efficiency benefits that can be achieved with what
is proposed in your draft.
Good idea – but I think it is likely too late.
Les
From: Dongjie (Jimmy) <[email protected]<mailto:[email protected]>>
Sent: Saturday, July 19, 2025 1:21 PM
To: Peter Psenak
<[email protected]<mailto:[email protected]>>;
Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
lsr <[email protected]<mailto:[email protected]>>
Subject: RE: [Lsr] Re: Review of draft-dong-lsr-l2bundle-srv6-03
Hi Peter,
Thanks for your pointer to RFC 9513. Although in the IANA section of RFC 9513,
the L2BM flag of the SRv6 related sub-TLVs is set to Y, the whole document has
no mentioning of the use of these sub-TLVs in L2 bundle scenario. This document
provides complementary description about the applicability of SRv6 related
sub-TLVs for L2 bundle in OSPFv3, following the style in RFC 9356.
That said, as in my previous reply to Les, the major purpose of this draft is
to introduce compact encoding of SRv6 SIDs for L2 bundle member links in IS-IS.
Best regards,
Jie
From: Peter Psenak
<[email protected]<mailto:[email protected]>>
Sent: Saturday, July 19, 2025 12:32 AM
To: Dongjie (Jimmy) <[email protected]<mailto:[email protected]>>; Les
Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
lsr <[email protected]<mailto:[email protected]>>
Subject: Re: [Lsr] Re: Review of draft-dong-lsr-l2bundle-srv6-03
Jimmy,
On 18/07/2025 12:17, Dongjie (Jimmy) wrote:
Hi Les,
Thanks for your review and pointers to the related information.
For IS-IS, this document proposes new sub-TLVs to achieve compact encoding of
SRv6 SIDs of the L2 bundle member links, following the approach used in RFC
8668.
For OSPFv3, RFC 9356 only defines the mechanism and encoding for carrying
SR-MPLS SIDs, SRv6 is not covered. Although IANA has set the L2BM flag for the
SRv6 related sub-TLVs, there is no explicit documentation of their usage for L2
bundle.
[RFC9513<https://www.iana.org/go/rfc9513>] is very clear allowing these for L2
links. What are you adding in this draft to it?
thanks,
Peter
Hope this could be discussed and clarified during the LSR session.
-Jie
-----Original Message-----
From: Les Ginsberg (ginsberg) <[email protected]><mailto:[email protected]>
Sent: Friday, July 18, 2025 4:56 AM
To:
[email protected]<mailto:[email protected]>;
lsr <[email protected]><mailto:[email protected]>
Subject: Review of draft-dong-lsr-l2bundle-srv6-03
Regarding https://datatracker.ietf.org/doc/draft-dong-lsr-l2bundle-srv6/ - this
draft has been around for a few years - but I wasn't aware of it - and don't
recall it ever being presented - though I may have overlooked it.
But as I saw it on the agenda for IETF 123 I took a look at it.
The functionality it defines has already been defined.
For IS-IS see
https://www.rfc-editor.org/rfc/rfc9352.html#name-advertising-srv6-adjacency-
Note that the sub-TLV is allowed in TLV 25:
https://www.rfc-editor.org/rfc/rfc9352.html#name-srv6-endx-sid-and-srv6-lan-
For OSPF the equivalent functionality is defined in
https://www.rfc-editor.org/rfc/rfc9356
Therefore there is no need for draft-dong-lsr-l2bundle-srv6.
I would suggest that it be dropped from the agenda.
Apologies to the draft authors for not spotting this sooner.
Les
_______________________________________________
Lsr mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
