Christopher Inacio 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: ---------------------------------------------------------------------- I don't understand how this can be implemented considering the last 2 paragraphs of Section 7: ``` IGPs provide no direct way for a router to learn the identifiers assigned by its neighbor to the individual bundle members, since the L3 protocol does not operate on the bundle members. The acquisition of the exact remote identifier value is therefore outside the scope of this document. Implementations MAY obtain the value through configuration or through implementation-specific discovery procedures. L2 protocols such as the Link Layer Discovery Protocol (LLDP) ([IEEE802.1AB]) and the Link Aggregation Control Protocol (LACP) ([IEEE802.1AX]) allow a router to discover the identity of the neighboring port on each member link, and implementations MAY use them as part of such procedures. Note, however, that the identifiers carried by these protocols are not required to match the L2 Bundle Member Link Local Identifiers advertised by the neighbor: the LLDP Port ID is subtype-dependent and is not necessarily a 32-bit numeric value, and the LACP Actor and Partner Port Numbers are 16-bit values assigned independently by each end. Any mapping between the identifiers discovered via these protocols and the neighbor's advertised L2 Bundle Member Link Local Identifiers is implementation-specific. To verify the correctness of the acquired remote identifiers, implementations SHOULD provide mechanisms to validate that received advertisements are consistent with the relationship defined above, i.e., that the value advertised as the remote identifier for a member equals the value advertised as the L2 Bundle Member Link Local Identifier for the corresponding member by the neighboring router. Mismatched pairs may indicate misconfiguration or incorrect discovery. ``` How can an implementation meet this MUST: `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.`? How would you validate that this `MUST` is met? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Brian W. for the SECDIR review. Thanks to the authors for a clear (especially for the non-BGP audience) and concise draft. I also support Med's comment about the diagram in section 5 and would change his comment to say that the field should be labeled `reserved` with a statement as to how it should be transmitted (e.g. all zeros). _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
