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]> 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]> > 发送时间: 2026年10月20日 10:48 > 收件人: The IESG <[email protected]> > 抄送: [email protected]; [email protected]; > [email protected]; [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]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
