Subject: [Lsr] Last Call: <draft-ietf-ospf-yang-23.txt> (YANG Data Model for OSPF Protocol) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 02 Jul 2019 09:55:17 -0700

The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Data Model for OSPF Protocol'
  <draft-ietf-ospf-yang-23.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2019-07-17. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This document defines a YANG data model that can be used to configure
   and manage OSPF.  The model is based on YANG 1.1 as defined in RFC
   7950 and conforms to the Network Management Datastore Architecture
   (NDMA) as described in RFC 8342.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc4973: OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering (Experimental - Independent Submission Editor stream)
    rfc1765: OSPF Database Overflow (Experimental - IETF stream)

---

From: tom petch <[email-masked]>
Date: Fri, 5 Jul 2019 16:30:38 +0000

I think that this could do with a few tweaks.

RFC 7884 is in the YANG module but not in the I-D references nor in the
body of the I-D.

The names of the TLV are not quite the same as in IANA and since new TLV
are not regarded as updates to RFC7770, then precision is called for in
order to find them with confidence via IANA

I cannot find router-address-tlv in IANA nor is there a YANG reference
clause and since there was some confusion over router-id in 2018, this
is one I want to check against its RFC, whatever that is.

The RPC can disrupt routing; elsewhere I have seen such actions limited
by a default
nacm:deny all
so users have to be positively configured to invoke the RPC.

I am unclear about rpc clear-neighbor.  Yes, it clears the adjacency but
what then?  Is it held down, allowed to come back up or what?

rpc or action?  I have yet to work out the pros and cons of each but was
rather expecting action as opposed to rpc for these.

leaf cost {type uint16
mostly have a range, but some do not; should they?

 typedef ospf-metric { type uint32 {  range "0 .. 16777215";
but
 leaf cost { type ospf-metric {  range "0..16777214";
looks odd; if intended, I suggest adding a note of explanation

some leaf metric are type ospf-metric others are type uint16; again
looks odd (but may be intended)

references to bfd-yang are not consistent
 RFC YYYY - YANG Data Model for Bidirectional
         Forwarding Detection (BFD).
 draft-ietf-bfd-yang-xx.txt:
     YANG Data Model for Bidirectional Forwarding Detection (BFD)";
I think the former clearer

I notice that many of the YANG enumeration have numeric values, others
do not, which makes me curious; not wrong but since YANG does not put
them on the wire, I think that having no numeric value is commoner

With priority
e.g.  list unreserved-bandwidth {
     leaf priority {
which is high and which is low?

Likewise with boolean e.g.
           leaf best { type boolean; description
               "Indicates if the alternate is the preferred.";
does true mean the alternate is preferred?

This I-D is big - 125pp - and I will not finish reviewing it by July
17th but expect to do so some time later in the month - I will post
again when I have.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; "Stephane Litkowski"
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, July 02, 2019 5:55 PM
Subject: [Lsr] Last Call: <draft-ietf-ospf-yang-23.txt> (YANG Data Model
for OSPF Protocol) to Proposed Standard

>     rfc4973: OSPF-xTE: Experimental Extension to OSPF for Traffic
Engineering (Experimental - Independent Submission Editor stream)
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 30 Jul 2019 01:22:31 +0000

Hi Tom, 

On 7/5/19, 12:30 PM, "tom petch" <[email-masked]> wrote:

See inline. 

This is defined in RFC 3630 for OSPFv2 Traffic Engineering LSAs. I've added separate opaque containers for the different opaque LSA types. 
I hope this makes things a lot clearer. 

I don't see this for RFC 8349 RPCs. Can you cite some examples? 

No - it is not held down - just cleared as the corresponding CLI command has done for 25 years. 

I think RPC is appropriate in this case as this is what we've implemented in other models. 
    
    leaf cost {type uint16

I've made all these consistent and added the ospf-link-metric type for the cases of the 16-bit link metric. 

Fixed. 

It depends on whether numeric values were previously provided in the OSPF MIBs.
    
    With priority

I believe priority 0 is the highest. RFC 3630 doesn't state this explicitly. 

Yes - clarified the description.

Thanks,
Acee 

    
    Tom Petch