> On Sep 7, 2022, at 17:05, Acee Lindem (acee) > <[email protected]> wrote: > > Hi Renato, > > Thanks for you comments. However, at this point in the cycle, we’re not going > to make any additions to the model since it is has already been through the > complete review cycle. We will however fix things that are broken. > > > See inline responses below. > > From: Renato Westphal <[email protected] > <mailto:[email protected]>> > Date: Thursday, September 1, 2022 at 2:31 PM > To: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> > Subject: [email protected] <mailto:[email protected]>: > questions > Resent-From: <[email protected] <mailto:[email protected]>> > Resent-To: <[email protected] <mailto:[email protected]>>, > Derek Yeung <[email protected] <mailto:[email protected]>>, > <[email protected] <mailto:[email protected]>>, Jeffrey Zhang > <[email protected] <mailto:[email protected]>>, Acee Lindem <[email protected] > <mailto:[email protected]>> > Resent-Date: Thursday, September 1, 2022 at 2:30 PM > > Hi all, > > I have a few questions about the OSPF YANG module. I apologize if some of > these questions were already asked before, but I couldn't find anything in > the mailing list archives. > > I also listed a few improvement suggestions, but I'm not sure if the draft > can be updated at this point (it's status is listed as "RFC Ed Queue"). > > > 1. > /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces > > OSPFv3 is known to run a per-link basis whereas OSPFv2 runs on a > per-IP-subnet basis. So what does it mean to configure an interface for > OSPFv2 operation? Should OSPFv2 run only on the interface primary address, or > run separate OSPFv2 instances for each one of the interface addresses? The > latter option doesn't seem viable since interfaces live under OSPF instances > in the YANG hierarchy, but I'd like to hear what others think about this. > > We’re really only supporting the per-link configuration for both OSPFv2 and > OSPFv3 since this is what the vendors support. Per-subnet configuration could > be added via augmentation.
More than a couple vendors support range based configuration (for OSPFv2) probably stemming from a pretty old cisco i.e., https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/command/iro-cr-book/m_ospf-i1.html#wp2261032279 <https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/command/iro-cr-book/m_ospf-i1.html#wp2261032279> https://docs.frrouting.org/en/latest/ospfd.html#clicmd-network-A.B.C.D-M-area-A.B.C.D <https://docs.frrouting.org/en/latest/ospfd.html#clicmd-network-A.B.C.D-M-area-A.B.C.D> maybe: https://www.arista.com/en/um-eos/eos-open-shortest-path-first-version-2#xx1153530 <https://www.arista.com/en/um-eos/eos-open-shortest-path-first-version-2#xx1153530> ... Vendors that didn't pattern themselves from original IOS configuration probably lack this configuration, though. If that's the case, perhaps it would be best to associate any augmentation with a feature (unless it's a standalone module I guess)? Thanks, Chris. [as wg member] > [...] > > Thanks, > Acee > > Best Regards, > -- > Renato Westphal
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
