Hi Renato, From: Renato Westphal <[email protected]> Date: Friday, September 30, 2022 at 10:34 AM To: Acee Lindem <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [email protected]: questions
Em sex., 30 de set. de 2022 às 11:21, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> escreveu: Hi Renato, Thanks - see inline. On 9/30/22, 10:14 AM, "Renato Westphal" <[email protected]<mailto:[email protected]>> wrote: Hi Acee, Em sex., 30 de set. de 2022 às 09:32, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> escreveu: > Hi Renato, > > > > *From: *Renato Westphal <[email protected]<mailto:[email protected]>> > *Date: *Thursday, September 29, 2022 at 7:56 PM > *To: *Acee Lindem <[email protected]<mailto:[email protected]>> > *Cc: *"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, " > [email protected]<mailto:[email protected]>" <[email protected]<mailto:[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. > 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. Ok – I see it now. Thanks, Acee > > > 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
