Med - Would appreciate your response on this. No doubt you are busy - but if you could take the time to respond that would be helpful.
Les >-----Original Message----- >From: Les Ginsberg (ginsberg) <[email protected]> >Sent: Thursday, October 29, 2026 3:05 PM >To: Acee Lindem <[email protected]>; [email protected] >Cc: linchangwang <[email protected]>; The IESG <[email protected]>; >[email protected]; [email protected]; >[email protected] >Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-lsr-l2-bundle-member- >remote-id-09: (with DISCUSS and COMMENT) > >Med - > >V12 of the draft has been published and addresses your remaining comment. >But, I have to say - I am very much in agreement w Acee here. > >The draft is defining how the IGPs can advertise the remote IDs of L2 Bundle >members. >We are not discussing how some third party might acquire that information >from some other source - nor are we discussing how an entity with two >conflicting sources for the same information might decide which one to trust. >We are simply defining how to advertise this information in the IGPs. > >I think the text added to satisfy your one remaining issue is out of scope and >inappropriate for this draft. >Why would other related IGP drafts then not be expected to discuss what >happens if there is another source for link bandwidth or link delay or...? > >I would prefer that the new text be removed - but I guess if you insist we can >leave it in there - but it really seems out of place. > >?? > > Les > >>-----Original Message----- >>From: Acee Lindem <[email protected]> >>Sent: Thursday, October 29, 2026 2:48 AM >>To: [email protected] >>Cc: linchangwang <[email protected]>; The IESG ><[email protected]>; >>[email protected]; [email protected]; >>[email protected] >>Subject: Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-l2-bundle- >member- >>remote-id-09: (with DISCUSS and COMMENT) >> >>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]
