From: Lsr <[email protected]> on behalf of Renato Westphal <[email protected]> Sent: 30 September 2022 00:55
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]<mailto:[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: <tp> Too late. The I-D, after 1129 days, has completed AUTH48 and its release as an RFC is imminent. Tom Petch 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
