| Hi, Robert:
Thanks! I think you give the right reference and the existing work. The proposed draft should consider the difference with this RFC.
Hi, Les:
Where is the contents in RFC 9352 that mentions the “L2Bundle Member”?
On Jul 20, 2025, at 01:27, Les Ginsberg (ginsberg) <ginsberg=[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 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
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
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] 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]>
Sent: Friday, July 18, 2025 4:56 AM
To: [email protected]; lsr <[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]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
|
