Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Acee,

Thanks for your quick response.

My question was : Can we put an informative reference to
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
(of which you are co-author) in the OSPF L2 Bundles draft?

This assumes that an upcoming version of this augmentation-v1 draft will
cover the configuration/enablement of this feature.

Thanks.
Ketan


On Tue, Oct 4, 2022 at 8:07 PM Acee Lindem (acee) <[e-mail]> wrote:

> Hi Ketan,
>
>
>
> See inlie.
>
>
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Tuesday, October 4, 2022 at 10:23 AM
> *To: *"Rob Wilton (rwilton)" <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, Christian Hopps <
> [e-mail]>, Acee Lindem <[e-mail]>
> *Subject: *Re: Robert Wilton's No Objection on
> draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)
>
>
>
> Hi Rob,
>
>
>
> Thanks for your review and please check inline below for responses.
>
>
>
> The updates as discussed below will be included in the next update.
>
>
>
>
>
> On Tue, Oct 4, 2022 at 3:14 PM Robert Wilton via Datatracker <
> [e-mail]> wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-ospf-l2bundles-06: No Objection
>
> 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:
> ----------------------------------------------------------------------
>
> Hi,
>
> I support Lars's discuss.
>
> I don't really object to publishing this document, although I don't really
> like
> the fact that the LAG member information that is being propagated isn't of
> any
> relevance to OSPF routing itself, and OSPF is being used only as a generic
> information propagation mechanism.  However, I acknowledge that horse has
> probably bolted long ago.
>
>
>
> KT> What we are doing here is adding more information for use in the TE-DB
> that is related to OSPF adjacencies. Originally, Opaque LSAs were
> introduced in OSPF for carrying additional info for TE-DB - even though
> that info was not really consumed by OSPF protocol. I can understand that
> "the line" may be blurred in this respect.
>
>
>
>
> One point that is not clear to me, is the configuration/management of this
> feature:  Is the expectation that OSPF implementations that support this
> RFC
> would automatically propagate bundle member information? Or would this be
> disabled by default and need to be enabled through configuration?
>
>
>
> KT> There should not be automatic enablement. It needs to be enabled via
> configuration. We will add an Operational Considerations section to clarify
> this with the following text added:
>
>
>
> <NEW>
>
> Implementations MUST NOT enable the advertisement of Layer 2 bundle member
> links and their attributes in OSPF LSAs by default and MUST provide a
> configuration option to enable their advertisement on specific links.
>
> </NEW>
>
>
>
>  If there is
> configuration associated with this feature then would it be part of a
> updated
> version of the standard OSPF YANG model, or is it via YANG module
> augmentation
> to the base OSPF YANG module?
>
>
>
> KT> I would expect the enablement to be an augmentation to the base OSPF
> YANG model.
>
>
>
> If this is configurable then having an
> informational reference to how/where this OSPF feature can be configured
> would
> likely be helpful.
>
>
>
> KT> We do not currently have this covered. I believe this can be added in
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
> - however, this is not something that has been discussed in the WG or with
> the authors of this document.
>
>
>
> Acee/Yingzhen, if you agree that the OSPF YANG augmentation draft can
> cover this, then we can add a reference in this document.
>
>
>
> The OSPF YANG model (as has been the case with all the protocol YANG
> models) has been a moving target for years in terms of features, YANG
> types, and YANG conventions. At this point, it will soon be published as
> RFC 9129. New features will be included in follow-on drafts including
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
> which would be a better reference.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
> Regards,
> Rob
>
>
>