Subject: Re: [i2rs] more feedback on draft-ietf-i2rs-rib-data-model (issues #2 and #3)

From: Mach Chen <[email-masked]>
Date: Wed, 2 Dec 2015 06:13:10 +0000

Hi Chris,

Thanks for your valuable comments!

Please see my reply inline...

> From: i2rs [mailto:[email-masked]] On Behalf Of Chris Bowers
> Sent: Tuesday, December 01, 2015 4:42 AM
> To: [email-masked]
> 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.";
>      }
>