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? # 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. # 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. # 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? # 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 ---------------------------------------------------------------------- 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. # 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. Shouldn’t this be rfc5307#section-1.1 where we have: If the Link Remote Identifier is unknown, it is set to 0. # 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # 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. Cheers, Med _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
