Em sex., 30 de set. de 2022 às 11:21, Acee Lindem (acee) <[email protected]> escreveu:
> Hi Renato, > > Thanks - see inline. > > On 9/30/22, 10:14 AM, "Renato Westphal" <[email protected]> wrote: > > 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. > > See https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.4.5 I was referring to Intra (and not Inter) Area-Prefix-LSAs (section A.4.10). I found this problem using a strongly-typed programming language that doesn't accept implicit type conversions. > > > > > > > > > 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 > > > Also, I'm considering the next-hop list change to keyless you suggested. > If it is not too late as I thought of a case where next-hop address is not > unique. That case being parallel equal-cost unnumbered links between two > OSPF routers where the routers use the same borrowed loopback address for > all the parallel links, Sigh... > Indeed. If it's not too late I think it would be a good change. Best Regards, -- Renato Westphal
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
