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) <a...@cisco.com> wrote: > Hi Ketan, > > > > See inlie. > > > > *From: *Ketan Talaulikar <ketant.i...@gmail.com> > *Date: *Tuesday, October 4, 2022 at 10:23 AM > *To: *"Rob Wilton (rwilton)" <rwil...@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>, Christian Hopps < > cho...@chopps.org>, Acee Lindem <a...@cisco.com> > *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 < > nore...@ietf.org> 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 > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr