Hi Renato, From: Renato Westphal <[email protected]> Date: Thursday, September 29, 2022 at 7:56 PM To: Acee Lindem <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [email protected]: questions
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: 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. Ack. 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). No – ospf-metric type is correct with the range limiting the metric to 24 bits. 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. The L-bit is never set in an LSA so it is not needed. https://www.rfc-editor.org/rfc/rfc5613.html#section-2.1 Should we ever add operational state with the options received, it would be needed and could be added in that augmentation. 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? No. You only have a single cost for an NBMA network. 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. A next-hop of zero is used in those cases. Thanks, Acee Best Regards, -- Renato Westphal
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
