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

["Acee Lindem (acee)" <[e-mail]>]

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



    >
    >
    > 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... 

Thanks,
Acee