Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt

From: [email-masked]
Date: Wed, 12 Aug 2020 21:37:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

        Title           : YANG Model for OSPFv3 Extended LSAs
        Authors         : Acee Lindem
                          Sharmila Palani
                          Yingzhen Qu
	Filename        : draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt
	Pages           : 27
	Date            : 2020-08-12

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: tom petch <[email-masked]>
Date: Thu, 13 Aug 2020 10:02:55 +0000

From: Lsr <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 13 August 2020 05:37

I said before that it was tough to review because of a lack of references in the YANG module and that remains true.
You have two Boolean to enable extended LSA on for ospf, one for area.  Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it took me some time to find it.  RFC8362 defines two parameters ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the model; yes you have a Boolean under area but I think its meaning requires a reading of RFC8362 Appendix B and that is missing and the description is unclear and the name is wrong.  Also the RFC has a SHOULD in it which the model does not implement.  You reference s.6.2 but I think that wrong, that it is Appendices A and B that describe this.

On type, you say there are three possible values. Precisely.  Can you have the type set to 'ospf' and support ospfv3?  If so, your model fails.  Or does ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of ospf per se?

The reference statement after the description could do with a title as you have for the revision description

My point about link type is that you are augmenting ospf-yang which uses an enum so in places users will be required to use an enum and in others a uint8 which could be confusing

Tom Petch

Abstract:

_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr