Re: [Lsr] Last Call: <draft-ietf-lsr-ospfv3-extended-lsa-yang-25.txt> (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

[tom petch <[e-mail]>]

From: Acee Lindem <[e-mail]>
Sent: 15 January 2024 20:30

Hi Tom,

Since this YANG model describes the RFC 8362 encodings, those encodings should be the primary reference all the leaves and identifies.

<tp>

Acee

I think that you are wrong.  The historian in me knows that given a choice or primary or secondary sources, the secondary can only get it wrong; you always go back to the primary (unless or until the primary is replaced which is not the case for most of the definitions here).

> On Jan 13, 2024, at 07:42, tom petch <[e-mail]> wrote:
>
> From: Lsr <[e-mail]> on behalf of The IESG <[e-mail]>
> Sent: 11 January 2024 14:35
>
<snip>

> <tp>
> Most of my comments on this I-D from August are addressed but I still have some doubts.
>
> p.11 identity nu-bit
> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a better reference

Agreed. However, I think including both references would be good since RFC 8362 includes the
flags in TLVs

>
> identity la-bit
> here RFC8362 changes the meaning so I think the reference to RFC8362 is ok

Actually, for the LA-bit, both references would be good.

> p.11 identity p-bit
> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a better reference

Same as nu-bit.

> p.12 identity dn-bit
> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a better reference

Same as nu-bit.

> p.12 identity e-bit
> this is not esplained in the referenced RFC8362; in fact, this one defeats me.  It is present in  a diagram, s.3.6,  but with no explanation.  Reading RFC5340 it could be A.4.3 but I am not sure

If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, there are type 1 and type 2 metrics. Type 1 are simply added to intra-area metric to the originator. Type 2 metrics are considered greater than type 1 metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 extended-LSA encodings. Since the description is brief, I’ll include it in its entirety.

<tp>
Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but in the modern  context of SR, IPv6, OSPFv3, extended LSA etc I did not recognise the terse allusion.

And why do you not include the AC bit defined in RFC9513?

Tom Petch
 
Thanks,
Acee




>
> Tom Petch
>
>
>
> Abstract
>
>
>   This document defines a YANG data model augmenting the IETF OSPF YANG
>   model to provide support for OSPFv3 Link State Advertisement (LSA)
>   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
>   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr