Re: [Lsr] Éric Vyncke's Yes on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]>
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) <[e-mail]>
> 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 <[e-mail]>
>> *Date: *Tuesday, 4 October 2022 at 11:03
>> *To: *Eric Vyncke <[e-mail]>
>> *Cc: *The IESG <[e-mail]>, "[e-mail]"
>> <[e-mail]>, "[e-mail]" <
>> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]"
>> <[e-mail]>, "Acee Lindem (acee)" <[e-mail]>
>> *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 <
>> [e-mail]> 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
>>
>>
>>