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) <evyn...@cisco.com> 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 <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> 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
