[Lsr] [e-mail]: questions

[Renato Westphal <[e-mail]>]

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.

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)?

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.

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?

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?

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?

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.

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?

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?

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


Best Regards,
-- 
Renato Westphal