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 <renatowestp...@gmail.com>
Date: Thursday, September 1, 2022 at 2:31 PM
To: "draft-ietf-ospf-y...@ietf.org" <draft-ietf-ospf-y...@ietf.org>,
"lsr@ietf.org" <lsr@ietf.org>
Subject: ietf-o...@2019-10-17.yang: questions
Resent-From: <alias-boun...@ietf.org>
Resent-To: <yingzhen...@futurewei.com>, Derek Yeung <de...@arrcus.com>,
<ingwherc...@mitre.org>, Jeffrey Zhang <zzh...@juniper.net>, Acee Lindem
<a...@cisco.com>
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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
