Hi Acee, Thanks for your response. Please see my inline comments below.
Em qua., 7 de set. de 2022 às 18:05, Acee Lindem (acee) <[email protected]> escreveu: > 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. > Understood. I only have a couple of additional comments for things that might be worth fixing before the RFC is released: 1. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/interface-id This leaf's type should be u32 and not u16. 2. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/database/as-scope-lsa-type/as-scope-lsas/as-scope-lsa/ospfv3/body/intra-area-prefix/prefixes/prefix/metric This leaf's type should be u16 and not "ospf-metric" (u32). 3. While the "lls" feature is present in the model, the "ospfv2-lsa-option" base identity is missing an identity for the L-Bit specified by RFC 5613. While that could be added via augmentation, I think it would make sense to have an "l-bit" identity as part of the base model. 4. /ietf-routing:routing/control-plane-protocols/control-plane-protocol/ietf-ospf:ospf/areas/area/interfaces/interface/neighbors/neighbor/cost Shouldn't the description be updated to include NBMA networks in addition to p2mp and hybrid networks? > 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. > I was referring to the local RIB, where OSPF connected routes are calculated as a "byproduct" of the SPF algorithm. Example: https://pastebin.com/raw/zyDASfm2 (the connected routes are the ones without nexthops). In any case, section 16.1.1 of RFC 2328 says that nexthop addresses aren't required for point-to-point interfaces. So I'm still wondering whether a keyless list wouldn't be a better option. Best Regards, -- Renato Westphal
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
