Mahesh -
Let me respond to a couple of your points regarding IS-IS encoding. Responses to your other comments will be forthcoming. You said: <snip> >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. > <end snip> First, you have misinterpreted the text in RFC 8668 Section 3.2. It says (emphasis added): “All existing sub-TLVs defined in the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 are in the category of shared attribute sub-TLVs unless otherwise specified in this document.” RFC 8668 introduced a new top level TLV (25). Many Sub-TLVs which had been defined prior to RFC 8668 can also be included in the new TLV 25. This statement merely indicated that these existing sub-TLVs fall into the “shared” category unless otherwise specified. Section 5 of RFC 8668 then provided the authoritative status for all relevant sub-TLVs (including new sub-TLVs introduced by RFC 8668) – and this status is maintained in the IANA registry https://www.iana.org/assignments/isis-tlv-codepoints#isis-tlv-codepoints-advertising-neighbor-information Implying from this that sub-TLVs default to “shared” is a misinterpretation. Section 5 of this draft states “The number of Remote Interface IDs carried in this sub-TLV MUST equal the Number of L2 Bundle Member Descriptors advertised in the enclosing L2 Bundle Attribute Descriptor.” Which clearly implies the values are NOT shared – and this is explicitly indicated in the IANA section. But, if you still feel that “NOT shared” needs to be added to Section 5 that can be done. As regards the “lowest numbered LSP” text… TLV 25 is of variable length depending on how much sub-TLV information is present. It is possible, for example, that initially 100 bytes of information is advertised, then subsequently 150 bytes of information needs to be advertised. If the TLV was original advertised in LSP#5 (for example), there may not be enough room to insert the additional 50 bytes in LSP #5, so the entire TLV may get moved to LSP #6 (for example). This will then require flooding of the updated LSP #5 (with the TLV removed) and the updated LSP #6 with the TLV added. Depending on how these multiple LSP updates are propagated, it is possible that at a given moment in time that two copies of the same TLV exist in the LSPDB of a given node. In the absence of any pathology, this is a transient condition, but implementations need to be able to handle this case – and the draft therefore specifies using the “lowest numbered LSP” rule. There are other ways this ambiguity could occur – including pathology on the part of the sending implementation. HTH helps explain. Les >-----Original Message----- >From: Mahesh Jethanandani via Datatracker <[email protected]> >Sent: Monday, October 19, 2026 7:48 PM >To: The IESG <[email protected]> >Cc: [email protected]; [email protected]; >[email protected]; [email protected] >Subject: 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-<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> >ballot-positions/<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. > >--- > >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. > >--- > >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. > >--- > >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. > >--- > >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. > >--- > >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. > >---------------------------------------------------------------------- >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/ > >--- > >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/ > >--- > >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. > >--- > >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. > >--- > >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". > >--- > >Section 11, Acknowledgements: > >s/Gunter van de Velde/Gunter Van de Velde/ >s/Secdir review/SECDIR review/ > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
