Hi Aijun.

Look here: https://www.rfc-editor.org/rfc/rfc8668.html

Thx
R.

On Sun, Jul 20, 2025 at 6:24 AM Aijun Wang <[email protected]>
wrote:

> 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) <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
> <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]>
> *Sent:* Saturday, July 19, 2025 1:21 PM
> *To:* Peter Psenak <[email protected]>; Les Ginsberg
> (ginsberg) <[email protected]>;
> [email protected]; lsr <[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]>
> *Sent:* Saturday, July 19, 2025 12:32 AM
> *To:* Dongjie (Jimmy) <[email protected]>; Les Ginsberg (ginsberg) <
> [email protected]>; [email protected]; lsr <
> [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]> <[email protected]>
>
> Sent: Friday, July 18, 2025 4:56 AM
>
> To: [email protected]; lsr <[email protected]> 
> <[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]
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to