Hi Christopher, Thank you for your review. We appreciate your thoughtful comments and suggestions.
All 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 发件人: Christopher Inacio via Datatracker <[email protected]> 发送时间: 2026年10月20日 4:10 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; [email protected] 主题: Christopher Inacio's Discuss on draft-ietf-lsr-l2-bundle-member-remote-id-09: (with DISCUSS and COMMENT) Christopher Inacio has entered the following ballot position for draft-ietf-lsr-l2-bundle-member-remote-id-09: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't understand how this can be implemented considering the last 2 paragraphs of Section 7: ``` IGPs provide no direct way for a router to learn the identifiers assigned by its neighbor to the individual bundle members, since the L3 protocol does not operate on the bundle members. The acquisition of the exact remote identifier value is therefore outside the scope of this document. Implementations MAY obtain the value through configuration or through implementation-specific discovery procedures. L2 protocols such as the Link Layer Discovery Protocol (LLDP) ([IEEE802.1AB]) and the Link Aggregation Control Protocol (LACP) ([IEEE802.1AX]) allow a router to discover the identity of the neighboring port on each member link, and implementations MAY use them as part of such procedures. Note, however, that the identifiers carried by these protocols are not required to match the L2 Bundle Member Link Local Identifiers advertised by the neighbor: the LLDP Port ID is subtype-dependent and is not necessarily a 32-bit numeric value, and the LACP Actor and Partner Port Numbers are 16-bit values assigned independently by each end. Any mapping between the identifiers discovered via these protocols and the neighbor's advertised L2 Bundle Member Link Local Identifiers is implementation-specific. To verify the correctness of the acquired remote identifiers, implementations SHOULD provide mechanisms to validate that received advertisements are consistent with the relationship defined above, i.e., that the value advertised as the remote identifier for a member equals the value advertised as the L2 Bundle Member Link Local Identifier for the corresponding member by the neighboring router. Mismatched pairs may indicate misconfiguration or incorrect discovery. ``` How can an implementation meet this MUST: `The remote interface identifier advertised by a router for a bundle member MUST be the exact non-zero 32-bit value that the neighboring router advertises as the L2 Bundle Member Link Local Identifier for that same bundle member.`? How would you validate that this `MUST` is met? Changwang>Thanks! The text has been revised in the latest version, with supplementary explanations included. It constrains only the value itself and does not require advertisement. If the value has not been learned, it should not be advertised. Validation is performed exclusively on the receiving side and may be conducted by any receiver. Both compliance with this MUST requirement and verification of such compliance depend solely on data advertised by the protocol itself; no out-of-band mechanism is assumed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Brian W. for the SECDIR review. Thanks to the authors for a clear (especially for the non-BGP audience) and concise draft. I also support Med's comment about the diagram in section 5 and would change his comment to say that the field should be labeled `reserved` with a statement as to how it should be transmitted (e.g. all zeros). Changwang> Med’s comment on the diagram in Section 5 was simply to remove “++++++++++”; it did not concern any specific field. The extra portion must not be treated as a reserved field and set to zero during transmission. In IS-IS, unlike OSPF, there is no padding of fields to 32 bit boundaries. Thanks! ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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! _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
