Subject: RE: comments on draft-ietf-rtgwg-yang-rip-00

From: Xufeng Liu <[email-masked]>
Date: Fri, 4 Dec 2015 20:43:14 +0000

Hi Chris,

Thanks for your review and valuable comments. Will address these within a couple of weeks and include them in the next revision.

Best regards,

- Xufeng

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Monday, November 30, 2015 6:17 PM
To: [email-masked]
Subject: comments on draft-ietf-rtgwg-yang-rip-00

RTGWG and draft authors,

I have the following comments and suggestions on draft-ietf-rtgwg-yang-rip-00.  A diff can be found on github at:

http://bit.ly/1RhCABx
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2015/commit/a7c1050e1eb83eb3bf31af074d0fa1f6e0e66867

The most important comments are copied below.

1) I see that the data model defines distribute-list as a way of defining
policy for filtering routes. I think it would be useful to include a
more complete data model for routing policy, either instead of or in
addition to distribute-list. One option is to import
draft-ietf-rtgwg-policy-model and use the apply-policy-group in the same
way that draft-ietf-isis-yang-isis-cfg uses it.
[Xufeng] Will update in the next version.
********

2)I think it would make sense to incorporate draft-ietf-bfd-yang in a
similar manner to how draft-ietf-ospf-yang and
draft-ietf-isis-yang-isis-cfg incorporate it.
[Xufeng] Agree. This has been planned. The recent comments from BFD model authors are that they will update the BFD model to provide a consistent way for protocols to use, and they will ask OSPF and ISIS to adjust. We can use the BFD grouping as OSPF and ISIS now, but we will need to do the same adjustments later.
************

3) It does not seem to me that all of the route attributes under the
rip->ipv4->routes operational state really belong in this RIP data
model. For example, the need-flash and need-download-to-rib attributes
do not seem to be RIP specific. If they apply to route entries for other
protocols then perhaps they should be put in a separate yang module.
Regardless of where they end up, they need to be more clearly defined
than the existing definitions in the model. I think many of the route
attributes defined here should be removed from this RIP data model.

The same comment applies to flash-update-threshold and
next-flash-update.
[Xufeng] Will evaluate a better option, collaborating with other protocol models.
********

4) The current description of rpc clear-rip-route says that it:
         "Clears RIP routes from the IP routing table and routes
         redistributed into the RIP protocol for the specified RIP
         instance or for all RIP instances in the current context."
It is not clear how one acccomplishes the clearing of all RIP instances
in the current context. Do it use a special keyword like "all" or does
it happen when no argument it passed or something else?
[Xufeng] Will clarify.
********

Thanks,
Chris