Hello Ketan Thank you for your quick reply and the updated document.
I am still unclear, though, that IEEE802.1AX is normative or informative. Nothing critical anyway. Regards -éric From: Ketan Talaulikar <ketant.i...@gmail.com> Date: Tuesday, 4 October 2022 at 11:03 To: Eric Vyncke <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, "draft-ietf-lsr-ospf-l2bund...@ietf.org" <draft-ietf-lsr-ospf-l2bund...@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "cho...@chopps.org" <cho...@chopps.org>, "Acee Lindem (acee)" <a...@cisco.com> Subject: Re: Éric Vyncke's Yes on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT) Hi Eric, Thanks for your review and please check inline below for responses. The changes as discussed below will reflect in the next draft update. On Tue, Oct 4, 2022 at 1:20 PM Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ospf-l2bundles-06: Yes 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-ospf-l2bundles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-l2bundles-06 CC @evyncke Thank you for the work put into this document: it is short, clear, and will be useful. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. A follow up on the Ericsson IPR would be welcome though if there is any update. As a side note, yet another definition for the overloaded "SID" ;-) I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### IEEE802.1AX as informative ? The only occurence of IEEE802.1AX appears to me as informative: ` for instance a Link Aggregation Group (LAG) [IEEE802.1AX]` => suggest to change the reference type to informative rather than normative. KT> This reference actually extends to the term "bundle" and consequently "bundle member" throughout the document. The reason for using "for instance" is because there are non-standard mechanisms for grouping of links that could also use this feature. Will update text to clarify the association of "LAG" with "bundle" in the introduction. ### Section 2 ``` ... Therefore advertisements of member links MUST NOT be done when the member link becomes operationally down or it is no longer a member of the identified L2 bundle. ``` OTOH, if the information is for an external party (e.g., a controler), having information of an operationally-down link could be useful. Are the authors sure that this would never be used ? KT> OSPF does not advertise links (rather adjacencies) via its LSAs that are not operationally UP. There are other mechanisms (MIBs/models) to report the operational status of links. For TE use-cases the presence of a link in the TE-DB (derived from LSDB) indicates that the links are up and usable - the application (e.g., a path computation element) does not need to perform additional checks on their operational state. The primary motivation for including bundle members and their attributes is to contribute this information into the TE-DB for use-cases like steering traffic over specific member links. Hence, we choose to retain the same semantics for bundle member advertisements. ### Section 2, length field `Length: Variable.` while it is probably obvious, it would probably not hurt to specify the units and what is included. KT> Ack - will update. ### Section 2, extensibility Should there be some text on how to decide applicable/non-applicable for any new link attribute TLV that could be added in the coming years ? KT> Sure - will clarify. Typically, attributes that have Layer 3 semantics would not be applicable while Layer 2 attributes would apply for inclusion in the L2 Bundle Member Sub-TLV. Thanks, Ketan ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
