Re-, This nicely covers the pending point. Thanks Changwang.
Cheers, Med > -----Message d'origine----- > De : linchangwang <[email protected]> > Envoyé : jeudi 29 octobre 2026 12:18 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > The IESG <[email protected]>; [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, Acee, > > Thanks for the discussion and the thoughtful comments. > > I've attempted a revision—please see inline. > > In the latest version, we have added the possibility of using a > management-based approach to obtain the remote interface > identifier, and under the OPS Cons section, we have included a > note on how the two approaches might be handled when they coexist. > > Please check and let us know if you have any further comments. > > > Link: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-l2-bundle-member- > remote- > id%2F12%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce8b5806 > db58e4526207a08df35ae6ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639288695443164679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=tyjs0%2FJ%2F4fgXFSC8SyTber8di0wGYsahe2 > zVML25dh8%3D&reserved=0 > Diff: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > author-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-lsr-l2-bundle- > member-remote-id-11%26url2%3Ddraft-ietf-lsr-l2-bundle-member- > remote-id-12%26difftype%3D-- > html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce8b5806db58e4 > 526207a08df35ae6ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39288695443187773%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=Uo6OzbH613ZyHdEQAqVABpiOU5kSwZ%2Bqinah73XioH > A%3D&reserved=0 > > > > Thanks, > Changwang > > > 发件人: [email protected] <[email protected]> > 发送时间: 2026年10月29日 15:38 > 收件人: linchangwang (RD) <[email protected]>; The IESG > <[email protected]> > 抄送: [email protected]; draft-ietf-lsr-l2-bundle-member-remote- > [email protected]; [email protected]; [email protected] > 主题: RE: Mohamed Boucadair's Discuss on draft-ietf-lsr-l2-bundle- > member-remote-id-09: (with DISCUSS and COMMENT) > > > Hi Changwang, > > Thank you for the follow-up and changes so far [1]. Please see > inline. > > Cheers, > Med > > [1] > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > author-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-lsr-l2-bundle- > member-remote-id-09%26url2%3Ddraft-ietf-lsr-l2-bundle-member- > remote-id-11%26difftype%3D-- > html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce8b5806db58e4 > 526207a08df35ae6ebb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39288695443201570%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=PzXV4MX0mk9oNAM5PphNDjUDj8uPTRfrGlWjT3RY69g% > 3D&reserved=0 > > > -----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. > > [Changwang-] Thank you. In the latest version, we have added the > possibility of using a management-based approach to obtain the > remote interface identifier, and under the OPS Cons section, we > have included a note on how the two approaches might be handled > when they coexist. > > > > > # 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. > ------------------------------------------------------------------ > ------------------------------------------------------------------ > - > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组 > 。 > 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮 > 件中的信息。 > 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > 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! ____________________________________________________________________________________________________________ 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]
