Re: [Lsr] [e-mail]: questions

[Renato Westphal <[e-mail]>]

Em sex., 30 de set. de 2022 às 11:21, Acee Lindem (acee) <[e-mail]>
escreveu:

> Hi Renato,
>
> Thanks - see inline.
>
> On 9/30/22, 10:14 AM, "Renato Westphal" <[e-mail]> wrote:
>
>     Hi Acee,
>
>     Em sex., 30 de set. de 2022 às 09:32, Acee Lindem (acee) <
> [e-mail]>
>     escreveu:
>
>     > Hi Renato,
>     >
>     >
>     >
>     > *From: *Renato Westphal <[e-mail]>
>     > *Date: *Thursday, September 29, 2022 at 7:56 PM
>     > *To: *Acee Lindem <[e-mail]>
>     > *Cc: *"[e-mail]" <[e-mail]>,
> "
>     > [e-mail]" <[e-mail]>
>     > *Subject: *Re: [e-mail]: 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) <
> [e-mail]>
>     > 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