Eric -
Thanx very much for the review. Please see inline. >-----Original Message----- >From: Éric Vyncke via Datatracker <[email protected]> >Sent: Thursday, October 22, 2026 6:58 AM >To: The IESG <[email protected]> >Cc: [email protected]; [email protected]; >[email protected]; [email protected] >Subject: Éric Vyncke's No Objection on draft-ietf-lsr-l2-bundle-member- >remote-id-10: (with COMMENT) > >Éric Vyncke has entered the following ballot position for >draft-ietf-lsr-l2-bundle-member-remote-id-10: 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 for the work done in this document. > >Due to lack of time, I only did a quick review and have identified the >following non-blocking issues: > >### Section 7 > >First paragraph: it is unclear whether the 'remote interface identifier' is >unique per bundle or per router/node/device or even per network as the 3rd >paragraph hints at a central controler? > [LES:] WE have referenced https://www.rfc-editor.org/rfc/rfc4202.html#section-2.1 multiple times. It states (emphasis added): “An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it.” I believe that addresses your concern. >`To verify the correctness of the acquired remote identifiers, implementations >SHOULD provide mechanisms` I am afraid that this should not be part of an >implementation issue but rather a property if this protocol. I.e., this >protocol appears unspecified. > [LES:] We have stated earlier in this section: “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.” So you are right – but not sure what the concern is. We believe “how” the identifiers are acquired is necessarily outside the scope of this specification. >Per IESG guidance >https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-<https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/> >use-of-bcp-14-key-words/<https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/>, >explain what are the consequence of bypassing the SHOULD. > [LES:] The last sentence of the paragraph you cited states: “Mismatched pairs may indicate misconfiguration or incorrect discovery.” To me that addresses the concern i.e., if you don’t do this check then you not detect incorrect values. ?? Les >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
