Subject: RE: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model for Routing Information Protocol (RIP)) to Proposed Standard

From: Xufeng Liu <[email-masked]>
Date: Fri, 1 Dec 2017 21:50:19 +0000

Hi Reshad,

Can you please double-check the revision 06 of the document? draft-ietf-rtgwg-yang-rip-04 used bfd-grouping-base-cfg-parms, and was taken out by draft-ietf-rtgwg-yang-rip-05. Please let us know if this is not the case, or we need to do something differently.

Thanks,
- Xufeng

> -----Original Message-----
> From: Reshad Rahman (rrahman) [mailto:[email-masked]]
> Sent: Wednesday, November 29, 2017 11:49 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model
> for Routing Information Protocol (RIP)) to Proposed Standard
> 
> Hi,
> 
> The RIP YANG model uses bfd-grouping-base-cfg-parms from BFD YANG. That
> grouping does not exist in latest revision (it has been renamed). Also, as per
> discussions we had with OSPF/ISIS YANG authors, the grouping which should be
> used from BFD is client-cfg-parms.
> 
> Regards,
> Reshad.
> ________________________________________
> From: rtgwg <[email-masked]> on behalf of The IESG <iesg-
> [email-masked]>
> Sent: Tuesday, November 28, 2017 11:29 AM
> To: IETF-Announce
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model for
> Routing Information Protocol (RIP)) to Proposed Standard
> 
> The IESG has received a request from the Routing Area Working Group WG
> (rtgwg) to consider the following document: - 'A YANG Data Model for Routing
> Information Protocol (RIP)'
>   <draft-ietf-rtgwg-yang-rip-06.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 2017-12-12. 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 describes a data model for the Routing Information
>    Protocol (RIP).  Both RIP version 2 and RIPng are covered.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/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:
>     draft-bjorklund-netmod-rfc7223bis: A YANG Data Model for Interface
> Management (None - IETF stream)
>     draft-ietf-netmod-revised-datastores: Network Management Datastore
> Architecture (None - IETF stream)
>     draft-acee-netmod-rfc8022bis: A YANG Data Model for Routing Management
> (NDMA Version) (None - )
>     draft-bjorklund-netmod-rfc7277bis: A YANG Data Model for IP Management
> (None - IETF stream)
>     draft-ietf-ospf-yang: Yang Data Model for OSPF Protocol (None - IETF stream)
> 
> 
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 1 Dec 2017 22:05:26 +0000

Hi Xufeng,

You are correct, I looked at the wrong version.

If explicit-neighbors feature is not supported, would you want to have the BFD client parameters (client-cfg-parms) configured in RIP? Otherwise operator needs to look at neighbors discovered and configure parameters under BFD for that neighbor. And when a new neighbor shows up, the same thing has to be done again.

Please see email discussion with OSPF/ISIS YANG authors.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/KNipAESw8fGKuUKrCxFlhdkRA0Y

Regards,
Reshad.

________________________________________
From: Xufeng Liu <[email-masked]>
Sent: Friday, December 1, 2017 4:50 PM
To: Reshad Rahman (rrahman); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model for Routing Information Protocol (RIP)) to Proposed Standard

Hi Reshad,

Thanks,
- Xufeng

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 5 Dec 2017 16:31:31 +0000

Hi Reshad,

Thanks for the review comment. Can you please check the following?
Regards,
- Xufeng

> Sent: Friday, December 1, 2017 5:05 PM
> To: Xufeng Liu <[email-masked]>; [email-masked]
> If explicit-neighbors feature is not supported, would you want to have the BFD
> client parameters (client-cfg-parms) configured in RIP? Otherwise operator
> needs to look at neighbors discovered and configure parameters under BFD for
> that neighbor. And when a new neighbor shows up, the same thing has to be
> done again.

[Xufeng] Yes. It would be better to have such a capability. Now that a newer version of the BFD model (draft-ietf-bfd-yang-07) have been posted, it would be better to use the  new grouping "client-cfg-parms" and be consistent with other IGPs. Please review if the followings are the proper changes:

  module ietf-rip {
+     import ietf-bfd-types {
+      prefix "bfd-types";
+    }

          container bfd {
            if-feature bfd;
            description "BFD configuration.";
-           leaf enabled {
-             type boolean;
-             default false;
-             description
-               "'true' if BFD is enabled for the interface.";
-           }
+           uses bfd-types:client-cfg-parms;
          }

  }

       +--rw interfaces
       |  +--rw interface* [interface]
       |     +--rw interface                  if:interface-ref
       |     +--rw bfd {bfd}?
-       |     |  +--rw enabled?   boolean
+      |     |  +--rw enable?                     boolean                         <== From grouping client-cfg-parms
+      |     |  +--rw local-multiplier?           multiplier
+      |     |  +--rw (interval-config-type)?
+      |     |     +--:(tx-rx-intervals)
+      |     |     |  +--rw desired-min-tx-interval     uint32
+      |     |     |  +--rw required-min-rx-interval    uint32
+      |     |     +--:(single-interval)
+      |     |        +--rw min-interval                uint32

[Xufeng] BTW. A comment about the leaf "enable" above: in most published models, "enabled" is used instead of "enable". Do you want to make it consistent?
 
> Subject: RE: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model
> Can you please double-check the revision 06 of the document? draft-ietf-rtgwg-
> yang-rip-04 used bfd-grouping-base-cfg-parms, and was taken out by draft-ietf-
> rtgwg-yang-rip-05. Please let us know if this is not the case, or we need to do
> something differently.
> 
> Thanks,
> - Xufeng
> 
> > Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG
> > Data Model for Routing Information Protocol (RIP)) to Proposed
> > Standard
> >
> > Hi,
> >
> > The RIP YANG model uses bfd-grouping-base-cfg-parms from BFD YANG.
> > That grouping does not exist in latest revision (it has been renamed).
> > Also, as per discussions we had with OSPF/ISIS YANG authors, the
> > grouping which should be used from BFD is client-cfg-parms.
> >
> > Regards,
> > Reshad.
> > Subject: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data
> > Model for Routing Information Protocol (RIP)) to Proposed Standard
> >
> > (rtgwg) to consider the following document: - 'A YANG Data Model for
> > Routing Information Protocol (RIP)'
> > 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 2017-12-12. 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
> >
> >
> >     draft-acee-netmod-rfc8022bis: A YANG Data Model for Routing
> > Management (NDMA Version) (None - )
> >     draft-bjorklund-netmod-rfc7277bis: A YANG Data Model for IP

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 5 Dec 2017 18:51:31 +0000

Hi Xufeng,

Changes below look good. 

As for changing 'enable' to 'enabled', I had checked what OSPF and ISIS were using and in both cases it is 'enable'. But yes I agree it should be consistent.

Regards,
Reshad.  
Sent: Tuesday, December 5, 2017 11:31 AM

Hi Reshad,

  module ietf-rip {

          container bfd {
            if-feature bfd;

  }

       +--rw interfaces