Hi Gunter, Thank you for your thoughtful comments. All your comments have been addressed in latest version.
Link:https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/07/ Diff: https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-l2-bundle-member-remote-id-06&url2=draft-ietf-lsr-l2-bundle-member-remote-id-07&difftype=--html Pls check and let us know if there are any further comments. Thanks, Changwang 发件人: Gunter van de Velde (Nokia) <[email protected]> 发送时间: 2026年9月17日 19:48 收件人: [email protected] 抄送: lsr <[email protected]>; Acee Lindem <[email protected]> 主题: Shepherding AD review for draft-ietf-lsr-l2-bundle-member-remote-id-06 Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-lsr-l2-bundle-member-remote-id-06 # Please find enclosed a shepherding AD review of the v06 draft. Before starting IETF LC i would like to explore few observations about the current writeup. # [major#1] Section 7 does not define an interoperable remote identifier The document does not yet specify how an implementation obtains the exact 32-bit value carried in the new sub-TLV. The link remote identifier defined by RFC 4202, Section 2.1 is a non-zero 32-bit value assigned by the remote LSR. Section 7 says that the LLDP Port ID SHOULD be used and that LACP Actor and Partner Port IDs may be used to derive the value. Neither statement is sufficient to ensure that both ends produce the same 32-bit identifier: * An LLDP Port ID is subtype-dependent and is not necessarily four octets or even numeric. It can, for example, be based on an interface name, MAC address, network address, or locally assigned value. * “Derived from” the LACP identifiers does not specify a mapping, byte order, collision handling, or which component of the LACP port information is used. * More importantly, neither mechanism guarantees that the result is the value the peer advertises as its local identifier in its L2 Bundle Member Descriptor. This is central to the operation of the extension. If R1 advertises one value as the remote identifier and R2 advertises a different value as its local member identifier, the controller cannot correlate the two advertisements. Please define the relationship precisely. One possible model would be: "The advertised remote identifier is the exact non-zero 32-bit identifier used by the neighboring LSR in its L2 Bundle Member Descriptor for that member link." The document could then specify how that value is carried or learned using IEEE 802.1AB or IEEE 802.1AX. If no standardized discovery mechanism carries that exact value, it would be clearer to say that acquisition is outside the scope of this document and may use configuration or implementation-specific discovery. In either case, the document also needs to say what an originator does when the value is unknown, changes, or ages out. # [major#2] The IS-IS multiplicity rule is applied at the wrong level Section 5 says that the new sub-TLV MUST NOT appear more than once in the same L2 Bundle Member Attributes TLV. That conflicts with the structure defined by RFC 8668. A single outer L2 Bundle Member Attributes TLV, type 25, may contain more than one L2 Bundle Attribute Descriptor. Each descriptor has its own member list and its own set of sub-TLVs. Consequently, there may legitimately be one Remote Identifier sub-TLV in each descriptor. The restriction should instead be scoped to an individual L2 Bundle Attribute Descriptor, for example: "The sub-TLV MUST NOT appear more than once in the sub-TLV set of a single L2 Bundle Attribute Descriptor." # [major#3] The BGP-LS parent object and protocol mapping need correction Section 3.3 identifies the parent as a “Peer Adj Link” and cites RFC 9086, Section 5.2. That section defines the BGP-EPE Peer Adjacency SID context. It is not the IGP Link NLRI used to describe the parent L3 link for L2 bundle attributes. RFC 9085, Section 2.2.3 specifies that the L2 Bundle Member Attributes TLV is carried in the BGP-LS Attribute associated with the Link NLRI describing the parent L3 IGP link. The example and terminology in Section 3.3 should be corrected accordingly. Section 6 also needs normative mapping rules. In particular, it should state that: * The new TLV is nested under the L2 Bundle Member Attributes TLV, type 1172, associated with the parent IGP Link NLRI. * An OSPF member and its remote identifier map one-to-one to a BGP-LS type 1172 instance. * For IS-IS, the ordered list of remote identifiers maps positionally to the ordered local member list, and each pair is exported in the corresponding BGP-LS member instance. * The handling of an unknown remote identifier is specified, including whether an all-zero list entry is omitted during BGP-LS export. Please also elaborate the behavior of a BGP-LS Producer, Propagator, and Consumer. In particular, RFC 9552, Section 8.2.2 assigns semantic validation to the Consumer; a Propagator is not expected to remove an unknown or semantically invalid fixed-length TLV merely because its Length is unexpected. # [major#4] The security considerations do not cover the new trust boundary Section 9 says that the document introduces no new security issues. That conclusion does not follow once Section 7 permits the advertised value to be learned from LLDP or LACP. IGP authentication protects the advertisement after the originating router has created it. It does not authenticate the local Layer 2 information from which the router obtained the remote member mapping. Spoofed, stale, or inconsistent discovery information could therefore produce a false member association, which a controller might then use for traffic engineering or failure correlation. Some Security Consideration ideas to explore: * The trust placed in LLDP, LACP, configuration, or other acquisition mechanisms. * The effect of stale or spoofed mappings. * Whether reciprocal advertisements should be used to validate a mapping. * What happens when the two directions disagree. * Withdrawal or replacement of the value when its source changes or ages out. * The additional topology detail exposed by advertising individual member-port relationships. The BGP-LS isolation reference should also be RFC 9552, Section 10, rather than RFC 8402. RFC 9552 contains the applicable BGP-LS security and topology-confidentiality considerations. # [Minor] Section 2 - Use Case The examples assume that the controller can correlate the two ends merely by comparing the advertised identifiers. Please mention the prerequisite that each remote identifier must equal the corresponding peer-local member identifier. It would also be useful to note that an absent value means “not learned or not advertised,” not that the peer has no corresponding member. This matters when one endpoint implements the extension and the other does not. # [minor] Section 3 - Protocol Overview Some protocol-object names should be corrected: * In OSPF, the exact RFC 9356 name is “L2 Bundle Member Attributes sub-TLV,” not “L2 Bundle Member Attributes TLV.” * The IS-IS object containing the member list is the “L2 Bundle Attribute Descriptor.” The draft also uses “L2 Bundle Member Attribute Descriptor,” which is not the RFC 8668 name. * An individual four-octet item is an “L2 Bundle Member Descriptor”; it does not itself contain a list of members. * “Peer Adj Link” in the BGP-LS figure should be replaced by the appropriate IGP Link NLRI context (see prior comment). # [minor] Section 4 - OSPF Extension Please add receiver behavior for an invalid Length. For example, say whether the sub-TLV is ignored when Length is not four. The document should also state that an originator MUST NOT advertise zero, since zero is reserved by RFC 4202 to mean that the remote identifier is unknown. For clarity, the direct container specifications could also be cited: * RFC 7684 for the OSPFv2 Extended Link TLV. * RFC 8362 for the OSPFv3 Router-Link TLV. # [minor] Section 5 - IS-IS Extension In addition to the multiplicity issue raised above: * “the first bundle member listed in the L2 Bundle Member Descriptor” should be “the first L2 Bundle Member Descriptor listed in the L2 Bundle Attribute Descriptor.” * State that Length must be a non-zero multiple of four. * State that the number of remote identifiers must equal the Number of L2 Bundle Members in the enclosing descriptor. * Define receiver behavior when either condition is false. * Explicitly say that zero is permitted only as a positional placeholder for an unknown remote identifier. * Consider saying that the sub-TLV should be omitted when all remote identifiers are unknown. * Explain how an originator splits descriptors when the one-octet length limits of the enclosing structures would otherwise be exceeded. The sentence saying that MP-TLV applicability “SHOULD be set to N” is also odd. This is registry metadata, not per-packet behavior. “The MP-TLV applicability is N” would be clearer and consistent with RFC 9885. Many thanks, looking forward to your feedbacks Kind Regards, Gunter Van de Velde Routing Area Director ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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! _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
