Hi Chris, Thanks for your valuable comments!
Please see my reply inline... > From: i2rs [mailto:[email protected]] On Behalf Of Chris Bowers > Sent: Tuesday, December 01, 2015 4:42 AM > To: [email protected] > Subject: [i2rs] more feedback on draft-ietf-i2rs-rib-data-model (issues #2 and > #3) > > I2RS WG and draft authors, > I created two more issues related to draft-ietf-i2rs-rib-data-model on the > I2RS > Wiki: > http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel > They are copied below as well. > Thanks, > Chris > > Issue 2: Make definition of route state "active" more precise: > Current definition in section 2.3 (repeated in 2.6) . ACTIVE: Indicates > whether > a route is fully resolved and is a candidate for selection. > Propose to replace with: > . ACTIVE: Indicates whether a route has at least one fully resolved nexthop > and is therefore eligible for installation in the FIB. The proposed text looks good to me. > Issue 3: route-change notification > The current route-change notification seems to have many of the right > components. However, the usage is ambiguous. Below is proposed text to > clarify the usage as well as some modifications of the data model to make this > usage clearer. > An implementation of this RIB data model MUST support sending route-change > notifications whenever a route transitions between the following states: > . from the active state to the inactive state . from the inactive state to the > active state . from the installed state to the uninstalled state . from the > uninstalled state to the installed state A single notification MAY be used > when > a route transitions from inactive/uninstalled to active/installed or in the > other > direction. > ________________________________________ > The following changes to the yang model affecting the route-change > notification, in particular the route-change-reasons should also be > considered. > It may also make sense to make the route-change-reason a list in order to > return multiple route-change0reasons. This would be useful for the the case > where a nexthop becoming resolved makes a route A active which is of better > preference than a currently active route B, which results in the route A being > installed. Or the text should clarify that this case requires two > notifications. Or > the text should clarify which single reason should be given in this case. The implication is that there will be two notifications for your case. If the route-change-reason is list, then the route-state and route-installed-state also should be. I'd prefer for each notification for a single route change and the relevant change reason. Will clarify this in the next revision. > notification route-change { > description > "Route change notification."; > leaf rib-name { > type string; > mandatory true; > description > "A reference to the name of a rib."; > } > leaf rib-family { > type rib-family-def; > mandatory true; > description > "A reference to address family of a rib."; > } > uses route-prefix; > leaf route-installed-state { > type route-installed-state-def; > mandatory true; > description > "Indicates whether the route is currently installed in the FIB or > uninstalled."; > } > leaf route-state { > type route-state-def; > mandatory true; > description > "Indicates whether a route is active or inactive."; > } > leaf route-change-reason { > type route-change-reason-def; > mandatory true; > description > "Return the reason that caused the route change."; > } > } > > identity route-change-reason { > description > "Base identify from which all route change > reasons are derived."; > } > > identity lower-route-preference { > base "route-change-reason"; > description > "This route was installed in the FIB because it had a lower route > preference value (and thus a higher route preference) than the route it > replaced."; > } > > identity higher-route-preference { > base "route-change-reason"; > description > "This route was uninstalled from the FIB because it had a higher > route preference value (and thus a lower route preference) than the route that > replaced it."; > } > > # Based on the current data model, which does not appear to define a route > metric, # it is not clear what scenario will result in higher metric being the > route change reason. > identity higher-metric { > base "route-change-reason"; > description > "Higher metric "; > } Yes, indeed. Will delete this identify. Thanks, Mach > > identity resolved-nexthop { > base "route-change-reason"; > description > "This route was made active because at least one of its nexthops > was resolved."; > } > > identity unresolved-nexthop { > base "route-change-reason"; > description > "This route was made inactive because all of its nexthops are > unresolved."; > } > > typedef route-change-reason-def { > type identityref { > base "route-change-reason"; > } > description > "Route change reason def."; > } > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
