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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
