Hi Acee, Em sex., 30 de set. de 2022 às 09:32, Acee Lindem (acee) <[email protected]> escreveu:
> 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]> > 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. > While uint32 isn't a problem per-se, using uint16 would be more precise since the Metric field of Intra-Area-Prefix LSAs is 16-bits wide. The "metric" leaf of Router-LSAs uses uint16 for instance. Only Summary and External LSAs need 24-bit wide metrics. But I think it's ok to leave it as it is. > > > 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. > Understood. > 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. > Ok. Makes sense considering that an NBMA network is essentially a pseudo-node, so all neighbors need to have the same cost. > > > 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. > Ok. Thanks for your time! Best Regards, -- Renato Westphal
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
