Mahesh – Thanx for updated ballot.
The sentence in question is: “If multiple instances of this sub-TLV are received within the same L2 Bundle Attribute Descriptor (e.g., during transient conditions), implementations MUST use the first occurrence in the lowest numbered Link State Protocol Data Unit (LSP) fragment and ignore subsequent occurrences.” This sentence is not fully accurate – which I think leads to your confusion. Referencing RFC 8868: For a given L3 adjacency… For a given set of bundle members… There may be multiple L2 Bundle Attribute Descriptors. Depending on the amount of/type of data this could require multiple L2 Bundle Attribute Descriptors and/or require multiple L2Bundle Member Attributes TLVs – which in turn might require multiple LSPs. This leads to the possibility that multiple instances of remote ID sub-TLVs for the same bundle member could occur in any of the following ways: 1)Multiple such sub-TLVs in a single L2 Bundle Attribute Descriptor. (This would be pathological behavior on the part of the sending implementation) 2)Multiple such sub-TLVs for the same bundle member in two different L2Bundle Attribute Descriptors. This could be pathological (if within a single TLV or within multiple TLVs in the same LSP) or a transient in the TLV movement case. To capture this more correctly I propose to revise the above sentence: “If multiple instances of this sub-TLV associated with the same bundle member are received, either within a single L2 Bundle Attribute Descriptor or in multiple L2 Bundle Attribute Descriptors, implementations MUST use the first occurrence in the lowest numbered Link State Protocol Data Unit (LSP) and ignore subsequent occurrences.” Does this work for you Mahesh? Les From: Mahesh Jethanandani <[email protected]> Sent: Wednesday, October 21, 2026 8:39 PM To: linchangwang <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Mahesh Jethanandani's No Objection on draft-ietf-lsr-l2-bundle-member-remote-id-09: (with COMMENT) Hi Changwang and Les, Thanks, -10 addresses my comments. I will update my ballot. Thanks also to Les for the correction on RFC 8668 §3.2. One small follow-up on §5: Les's explanation (a TLV 25 moving between fragments) is a cross-fragment case, but the sentence still scopes the rule to "within the same L2 Bundle Attribute Descriptor", where duplicates can't span fragments. Consider rewording it to cover the same bundle member appearing in TLV 25 instances in different LSP fragments. Cheers. On Oct 21, 2026, at 4:38 PM, linchangwang <[email protected]<mailto:[email protected]>> wrote: Hi Mahesh, Thank you for your careful review and thoughtful feedback. Your comments have been addressed in latest version. https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/10/ https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-l2-bundle-member-remote-id-09&url2=draft-ietf-lsr-l2-bundle-member-remote-id-10&difftype=--html Pls check and let us know if there are any further comments. Please see some replies inline with [Changwang]. Thanks, Changwang 发件人: Mahesh Jethanandani via Datatracker <[email protected]<mailto:[email protected]>> 发送时间: 2026年10月20日 10:48 收件人: The IESG <[email protected]<mailto:[email protected]>> 抄送: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 主题: Mahesh Jethanandani's No Objection on draft-ietf-lsr-l2-bundle-member-remote-id-09: (with COMMENT) Mahesh Jethanandani has entered the following ballot position for draft-ietf-lsr-l2-bundle-member-remote-id-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for a short, focused extension. -09 is much tighter than -06, after it was reviewed by Gunter. I've tried not to repeat points already on the ballot. Section 8, Operational Considerations: 480 > Implementations MUST NOT enable the advertisement of the L2 Bundle 481 > Member Interface Remote Identifier sub-TLV by default and MUST 482 > provide a configuration option to enable its advertisement on 483 > specific links. This copies the first sentence of RFC 9356 Section 5 but drops the second, which points to the OSPF YANG model (RFC 9129) and says the needed configuration and operational elements are expected to come as an augmentation. That pointer belongs here too, and arguably matters more. Section 7 now leaves configuration as the only deterministic way to get the remote identifier. The document therefore introduces a per-link enable knob, possibly per-member remote-identifier configuration, and validation state that an operator will want to read. I'd ask the authors to say how these are expected to be modeled (RFC 9129 for OSPF, RFC 9130 for IS-IS), even if the augmentation lives in a separate document. The authors might also look at draft-ietf-opsawg-rfc5706bis while they're in this section. With manual configuration, a few practical questions come up. What happens to configured remote identifiers when the neighbor reboots and reassigns its local identifiers? How are mismatches reported? How does an operator tell "not configured" apart from "configured but wrong"? A few sentences on each would help deployers. [Changwang] OK. In the Operational Considerations section, add YANG modeling guidance and describe how to address the three operational issues associated with manual configuration. --- Section 3, illustrative text vs. Section 3.2 MUST: 172 > The descriptions in this section are intended to be illustrative and 173 > are not meant to be normative. 207 > advertised as follows. Note that IS-IS can advertise a set of 208 > members in a single L2 Bundle Attribute Descriptor, so the L2 Bundle 209 > Member Interface Remote Identifier sub-TLV MUST carry multiple remote 210 > interface identifiers, one for each bundle member advertised in the 211 > associated L2 Bundle Member Descriptor. Section 3 says it's illustrative, then Section 3.2 has a MUST. The same requirement is already stated normatively in Section 5 (line 319). I would drop the BCP 14 keyword here. Also, line 211 should say "L2 Bundle Attribute Descriptor", not "L2 Bundle Member Descriptor". A Member Descriptor is a single 4-octet identifier. [Changwang] OK. Remove “MUST” and replace “L2 Bundle Member Descriptor” with “L2 Bundle Attribute Descriptor”. --- Section 5, relationship to RFC 8668 shared-attribute rules: 336 > The L2 Bundle Member Interface Remote Identifier sub-TLV MUST NOT 337 > appear more than once within the sub-TLV set of a single L2 Bundle 338 > Attribute Descriptor. If multiple instances of this sub-TLV are 339 > received within the same L2 Bundle Attribute Descriptor (e.g., during 340 > transient conditions), implementations MUST use the first occurrence 341 > in the lowest numbered Link State Protocol Data Unit (LSP) fragment 342 > and ignore subsequent occurrences. RFC 8668 Section 3.2 says every sub-TLV in the neighbor registry is a "shared attribute" sub-TLV unless specified otherwise, and that if multiple copies of a shared sub-TLV appear, all copies MUST be ignored. The new sub-TLV is clearly per-member, like the L2 Bundle Member Adj-SID sub-TLVs in RFC 8668 Section 4. The IANA request in Section 10 marks the TLV 25 column as "y" rather than "y(s)", which, per the registry note, means the sub-TLV may appear in TLV 25 but is not shared across members. Even so, the body text should say explicitly that this is not a shared-attribute sub-TLV. That tells the reader why the "use the first" rule here differs from RFC 8668's "ignore all" rule. I also don't follow the "lowest numbered LSP fragment" wording. An L2 Bundle Attribute Descriptor sits inside a single TLV 25, which sits in a single fragment, so duplicates within one descriptor are always in the same fragment. Is there a cross-fragment case the authors have in mind, such as the same member appearing in descriptors in different TLV 25 instances? If so, that case deserves its own rule. If not, the fragment clause can go. [Changwang] In the IS-IS extensions, add text clarifying that the new sub-TLV is not a shared-attribute sub-TLV. Leave the wording regarding “lowest numbered LSP” unchanged. --- Section 6, BGP-LS error handling: 419 > With respect to the roles defined in Section 3 of [RFC9552], a BGP-LS 420 > Producer originates this sub-TLV as part of the BGP-LS Attribute of 421 > the Link NLRI describing the parent L3 link, following the mapping 422 > described above. A BGP-LS Propagator does not perform semantic 423 > validation of this sub-TLV and does not remove it due to semantic or 424 > syntactic length mismatches beyond the 'Attribute Discard' fault 425 > handling defined in Section 8.2.2 of [RFC9552]. I read this several times and I'm still not sure what lines 423-425 are saying. Unlike Section 4, Section 6 never states that Length must be 4 or what happens when it isn't. Under RFC 9552 Section 8.2.2, a speaker that recognizes this sub-TLV and finds an invalid length treats the whole BGP-LS Attribute as malformed and applies 'Attribute Discard'. That drops every TLV in the attribute, not just this one. I would state that consequence plainly. This also supports Med's point that RFC 9552 needs to be a normative reference. [Changwang] OK. Revise this paragraph to clearly state that if the sub-TLV’s length is invalid, all TLVs in the BGP-LS Attribute are discarded immediately. --- Section 9, normative behavior in Security Considerations: 511 > misdiagnose the scope of a failure. To limit the impact of stale 512 > information, an originator MUST NOT continue to advertise a remote 513 > identifier that it knows to be no longer valid. This is a protocol requirement, so it belongs in Section 7. "Knows" is also doing a lot of work here. With configured values, the originator generally has no signal that the value has gone stale, unless it runs the reciprocity check described above. Tying this requirement to that check would make it actionable. [Changwang] The relevant protocol text has been added to Section 8 (Operational Considerations). The only change to this sentence in Section 9 (Security Considerations) is to tie “knows” to the validation mechanism described in Section 7. --- Section 12.1, normative references: 489 > considerations of [RFC8668], [RFC9356], [RFC9552], [RFC9085] and 490 > [RFC9086] are applicable to this document. In addition, the RFC 9086 (BGP-LS EPE) is now cited only here. It looks like a leftover from the "Peer Adj Link" text that was removed after Gunter's review. Nothing in -09 uses EPE, so I would drop it. Similarly, IEEE 802.1AX is listed as normative, but -09 uses it only as an example of a bundle technology and of a possible discovery aid, with acquisition out of scope. Informative seems right, consistent with how IEEE 802.1AB is treated. [Changwang] Accepted. Remove the reference to RFC 9086 and move IEEE 802.1AX to the Informative References section. ---------------------------------------------------------------------- NIT ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Abstract: 20 > bundle members for traffic engineering (TE) purposes. This document 21 > describes how Open Shortest Path First (OSPF) and Intermediate System 22 > to Intermediate System (IS-IS) would advertise the remote interface s/would advertise/advertise/ [Changwang] Accepted. --- Section 2, Use Case: 141 > ends. So, there would be requirements for the controller to figure 142 > out the connectivity relationships between bundle members. s/So, there would be requirements for the controller to figure out/The controller therefore needs to determine/ [Changwang] Accepted. --- Section 3.2, IS-IS figure: 218 > L2 Bundle Member Link Local Identifiers of Member #1,#2,...,#n 219 > sub-TLV(s) As laid out, this reads as if the link local identifiers are sub-TLVs. Putting "Sub-TLV(s)" on its own line would avoid that. [Changwang] Accepted. --- Sections 4, 5, 6 and 10, code points: 260 > | Type (TBA) | Length (4) | Michael Richardson suggested distinct placeholders during the RTGDIR review, and Les and Tom Petch agreed on the list. That change hasn't landed yet. Using TBA1 through TBA4 in both the bodies and Section 10 would make IANA's job unambiguous. [Changwang] Each TBA is associated with a different registry, so there is no need to label them TBA1 through TBA4. --- Section 10, OSPFv3 registry: 562 > This document adds the following new sub-TLV to the "OSPFv3 Extended- 563 > LSA Sub-TLVs" registry. In this registry, the "L2BM" column has an 564 > additional value "X", which indicates that a sub-TLV is not a sub-TLV 565 > of the Router-Link TLV and MUST NOT appear within the L2 Bundle 566 > Member Attributes sub-TLV. The explanation of "X" isn't needed, since the value requested is "Y". [Changwang] Accepted. --- Section 11, Acknowledgements: s/Gunter van de Velde/Gunter Van de Velde/ s/Secdir review/SECDIR review/ [Changwang] Accepted. ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! Mahesh Jethanandani [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
