Hi Med, 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 发件人: Mohamed Boucadair via Datatracker <[email protected]> 发送时间: 2026年10月16日 17:21 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; [email protected] 主题: Mohamed Boucadair's Discuss on draft-ietf-lsr-l2-bundle-member-remote-id-09: (with DISCUSS and COMMENT) Mohamed Boucadair 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: ---------------------------------------------------------------------- Hi Liyan, Changwang, Xiaolong, Les, and Peter, Thank you for the effort put into this specification. Special thanks for having such a clear recommended default value (MUST be disabled) for these extensions. Please find below some few points for discussion: # What is the exact problem to be solved? The text has this brief sentence: CURRENT: If the remote interface identifier could be advertised for each member link, the pairing relationships between the local and remote interfaces would be clear. Moreover, the information about remote ids can be retrieved directly from the nodes themselves. Mirroring that information in IGP may or may not be needed, operationally. I suggest to make the problem space clear enough that this is about allowing BGP-LS to convey such information rather than using a management system to do the correlation. Can you please add some text among those lines? Changwang> OK. The description has been added in the latest version. # Coupling Local/Remote id TLVs Focusing only the normative behavior (i.e., starting from Section 4), we do have for example: CURRENT: It can be carried as a sub-TLV of the OSPF L2 Bundle Member Attributes sub-TLV [RFC9356]. … It can be carried as a sub-TLV of the BGP-LS L2 Bundle Member Attributes TLV [RFC9085]. Unless you have a case where sending a remove id without being coupled with a local id makes sense operationally, I suggest to have some text about expected behavior when only the remote ids are received, but not local id TLVs. Changwang> OK. Given that the local IDs are a fixed portion of the existing L2 Bundle Member advertisements (i.e., not a TLV/sub-TLV), it is not possible for the local ID to be absent. The description has been added in the latest version. Text: “A receiver first associates this sub-TLV with the bundle member identified by the enclosing L2 Bundle Member Attributes sub-TLV”. # Impact on correlation with local-ids A remote interface ID with value of zero MUST be ignored and handled as if the value was unknown. If this is ignore before correlating with local-ids, this may get things messy. Please make it clear this must be done only after coupling local/remote ids. Changwang> OK. The corresponding descriptive handling has been incorporated into the latest version. # Mirroring constraint CURRENT: 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. I interpret this MUST (and wording) as it forbids a node to advertize a remote-id if it didn’t revive a local-id from a peer. Is this intended? Changwang> OK. The corresponding descriptive handling has been incorporated into the latest version. New text: “The relationship between the local and remote identifiers is reciprocal. When an L2 Bundle Member Link advertisement is sent by the neighbor, the remote interface identifier MUST match the non-zero 32-bit value that the neighboring router advertises as the L2 Bundle Member Link Local Identifier for that same bundle member.” # BGP-LS is required to implement the BGP-LS Extension CURRENT: 12.2. Informative References … [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/info/rfc9552>. Please move this one to normative Changwang> OK. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Say the obvious OLD: A remote interface ID with value of zero is not valid and MUST be ignored and handled as if the sub-TLV was not present. NEW: A remote interface ID with value of zero is not valid and MUST be ignored and handled as if the sub-TLV was not present by a receiver. Changwang> OK. New: A receiver first associates this sub-TLV with the member of the enclosing L2 Bundle Member Attributes TLV instance. After this association, a remote interface ID with value of zero is not valid and MUST be ignored and handled by the receiver as if the sub-TLV was not present (i.e., the remote identifier of that member is treated as unknown). # Check CURRENT: MUST NOT advertise a value of zero for the Remote Interface ID, since a value of zero is reserved to indicate that the remote interface identifier is unknown, consistent with the Link Local Identifier defined in [RFC4202] (see Section 7). I failed to find which part of 4202 you were referring to. Changwang> Section 2.1 Shouldn’t this be rfc5307#section-1.1 where we have: If the Link Remote Identifier is unknown, it is set to 0. Changwang> RFC 5307 is defining IS-IS specific encoding (RFC 4203 is the corresponding OSPF reference). RFC 4202 is the correct reference. # Clarity OLD: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEW: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Changwang> OK. # Ordering preference CURRENT: 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. Wonder whether it is better to recommend local ids sub-TLV to appear first. Changwang> The Local IDs are NOT sub-TLVs – they are a fixed portion of the L2Bundle Member Description – so this is not possible. Nor would it be desirable even if it were possible i.e., a specific order of two different sub-TLVs is never defined by the protocols as it imposes a meaningless restriction on receivers. Cheers, Med ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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]
