Re: [Lsr] [e-mail]: questions

["Acee Lindem (acee)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, September 1, 2022 at 2:31 PM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [e-mail]: questions
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, Derek Yeung <[e-mail]>, <[e-mail]>, Jeffrey Zhang <[e-mail]>, Acee Lindem <[e-mail]>
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.


2. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/address-family

Given how OSPFv2 doesn't support multiple address families, wouldn't it be a good idea to constrain this leaf to OSPFv3 instances only (e.g. using a `when` statement)?

I’ll consider this as long as there aren’t other ramifications.


3. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/instance-id

Based on the range of accepted values (`0 .. 31`), one must assume that this is a relative Instance-ID (based on RFC5838's address-family Instance-ID ranges). I think it would be useful to have that clear in the node description.

The range will be removed.


4. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/local-rib/route

I see this routing table lists destination networks only. Shouldn't there be a separate list for routes to border routers?

Many implementations (at least the efficient ones) store these in a separate table. This could be added via an augmentation.


5. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/local-rib/route/next-hops/next-hop

This list is keyed by the `next-hop` leaf, which is an IP address. Given that directly connected routes don't have an IP address, shouldn't this be a keyless list instead?

Since the local RIB only contains OSPF routes, they always have a next-hop.


6. /ietf-ospf:clear-database

I think the description of this RPC could benefit from a more detailed explanation. In addition to clearing the OSPF database, I assume all adjacencies need to be reset as well (in order to resync the LSDB). Could someone clarify what would be the expected behavior here?

I agree and will clarify.


7. How should route redistribution be configured? I see ietf-rip.yang has a separate container for that purpose, but ietf-ospf.yang (and other IGP modules) don't do the same. I also noticed the BGP model is using definition from ietf-routing-policy.yang.

Different vendors handle redistribution in different ways. This could be added with an augmentation if there were agreement.


8. Two standard configuration parameters (or "Configurable Constants") seem to be missing in the YANG module: RFC1583Compatibility (RFC 2328) and LinkLSASuppression (RFC 5340). Was that intentional?

These could be added via augmentation. I don’t believe LinkLSASuppression is implemented by anyone.



9. RFC 8405 specifies the following:

   If this SPF Back-Off algorithm is enabled by default, then in order
   to have consistent SPF delays between implementations with default
   configuration, the following default values SHOULD be implemented:

      INITIAL_SPF_DELAY         50 ms
      SHORT_SPF_DELAY          200 ms
      LONG_SPF_DELAY          5000 ms
      TIME_TO_LEARN_INTERVAL   500 ms
      HOLDDOWN_INTERVAL      10000 ms

The OSPF YANG module, however, doesn't have those default values. Shouldn't they be added?

We deliberately left defaults out of the model so that implementations could provide their own defaults for hello-interval, etc.  I remember we had a long discussion and ended up with “SHOULD” in RFC 8407.



10. RFC 7949 defines a mechanism to use IPv4 to transport OSPFv3 packets. Shouldn't there be a configuration leaf to enable that mechanism?

This could be added via an augmentation.

Thanks,
Acee



Best Regards,
--
Renato Westphal