Hi Eric, We've just posted an update that includes the changes we discussed: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-07
Thanks, Ketan On Tue, Oct 4, 2022 at 4:28 PM Ketan Talaulikar <[email protected]> wrote: > Hi Eric, > > IMHO the reference to IEEE801.1AX needs to be normative. FWIW, this is the > case also in RFC8668 that provides the similar functionality in ISIS. > > Thanks, > Ketan > > > On Tue, Oct 4, 2022 at 4:23 PM Eric Vyncke (evyncke) <[email protected]> > wrote: > >> 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 <[email protected]> >> *Date: *Tuesday, 4 October 2022 at 11:03 >> *To: *Eric Vyncke <[email protected]> >> *Cc: *The IESG <[email protected]>, "[email protected]" >> <[email protected]>, "[email protected]" < >> [email protected]>, "[email protected]" <[email protected]>, "[email protected]" >> <[email protected]>, "Acee Lindem (acee)" <[email protected]> >> *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 < >> [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
