Hi Med, Please see inline.
> On Oct 29, 2026, at 3:37 AM, [email protected] wrote: > > Hi Changwang, > > Thank you for the follow-up and changes so far [1]. Please see inline. > > Cheers, > Med > > [1] > 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-11&difftype=--html > >> -----Message d'origine----- >> De : linchangwang <[email protected]> >> Envoyé : mercredi 21 octobre 2026 10:42 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> The IESG <[email protected]> >> Cc : [email protected]; draft-ietf-lsr-l2-bundle-member-remote- >> [email protected]; [email protected]; [email protected] >> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-l2- >> bundle-member-remote-id-09: (with DISCUSS and COMMENT) >> >> >> Hi Med, >> >> Thank you for your review. >> We appreciate your thoughtful comments and suggestions. >> >> All your comments have been addressed in latest version. >> .. >> >> 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]; draft-ietf-lsr-l2-bundle-member-remote- >> [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.) >> >> >> ------------------------------------------------------------------ >> ---- >> 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. > > [Med] Thanks for the changes. I was looking for a mention of the > management-based approach to retrieve the ids (declared out of scope) and a > statement (under OPS Cons) that mismatches might be observed if both are put > into effect. In such case, I think that the info retrieved via > management-based approach would win. Even if a management system is used, the devices with the links in the bundle would still need to do the correlation between each component link's local and remote interface ID. We are already advertising the local-ids for the bundle links in the IGPs and this just adds the remote-ids. Hence, I don't see your point. Thanks, Acee > >> >> # 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”. >> > > [Med] ACK. > >> # 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. >> > > [Med] Thanks. > >> # 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.” >> >> > > [Med] ACK. > >> # 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, >> >> >> Please move this one to normative >> >> Changwang> OK. > > [Med] Thanks. > >> >> ------------------------------------------------------------------ >> ---- >> 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). >> > > [Med] This is indeed better. > >> >> # 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. >> > > [Med] Thanks. > >> # 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. > [Med] ACK. > > >> >> # 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. >> > > [Med] ACK. > >> Cheers, >> Med >> > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
