Subject: Re: [i2rs] RIB Model draft

From: Nitin Bahadur <[email-masked]>
Date: Thu, 10 Oct 2013 00:09:52 +0000

Hi Joel,

>Given that metrics are not comparable between routing protocols, or even
>between distinct instances of routing protocols, why are the metrics in
>the general RIB model instead of the protocol specific models?

>From the draft:
"Route metric is used for comparing routes learned by the same protocol.
If a controller wishes to program 2 or more routes to the same
destination, then it can use
the metric field to disambiguate the 2 routes."

So forget "protocol". If a controller programs 2 routes to same dest, it
needs a metric
value to distinguish between the 2 routes.

>Similarly, why is AS Path in this model, rather than in the BGP model?
>Whether the decision is implemented in BGP or a common RIB model would
>seem implementation specific, but from a model perspective it seems to
>be a BGP-specific property rather than a generic RIB property.

I agree that AS-path is a BGP thing. However there is no other construct to
represent inter-domain paths today. From the draftŠ

"A route can have an as-path associated with it to indicate which set of
autonomous systems has to be traversed to reach the final destination. The
as-path attribute can be used by the RIB manager in multiple ways. The RIB
manager can choose paths with lower as-path length. Or the RIB manager can
choose to not install paths going via a particular AS. How exactly the RIB
manager uses the as-path is outside the scope of this document."

Note that the above text has no reference to BGP.

>The load balancing attributes seem to reflect a particular
>implementation strategy.  While a not unreasonable strategy, the
>modeling seems pretty implementation specific.  This applies to both the
>specifics of load balance weight and the interaction of that weight with
>protection preference.

I would be happy to hear alternatives for modeling this.

>Having no-decrementTTL has a general nexthop attribute seems a mistake.
>In fact, having a next hop with no decrement seems very dangerous, since
>one could have a looping tunnel chain with no decrementing.  Is this
>really something we want in the model?  (I can't stop someone from doing
>it in an implementation.)

No-decrement-ttl is the only way to simulate a Pipe model. Someone has to
be
very careful in using this, otherwise as you said - they'll cause routing
loops. But the same argument is true with any programming from the
controller.
I can always program the RIB of 2 edge routers in a way that packets are
ping-ponging
between them (until TTL expires).

>While the model should permit handling the TTL propagation into and out
>of tunnels, it should not mandate support for specific modes.  How do we
>indicate that support for things like the NO_PROPAGATE_TTL flag is
>optional, or conversely always set?

<nexthop-attributes> ::= [<rib-family>] [<nexthop-flags>]
<nexthop-flags> ::= [<NO_DECREMENT_TTL>] [<NO_PROPAGATE_TTL>]

Above indicates that nexthop-flags is an optional attribute. And it also
indicates that the
NO_PROPAGATE_TTL flag is an optional flag attribute. Support being
optional is a matter of
Data-model negotiation (outside scope of this document). Indicating always
set - I don't have a
good answer.

>Minor: I presume that the cardinality of 0 is allowed in the
>relationship between route and nexthop-list to reflect incomplete route
>entries? 
> If so, shouldn't the text say so?

It's a typo. It should be 1. Every route needs to have a nexthopŠthe
nexthop can be unresolved.

>Nit: figure 2 should include multicast.

Yup.

Thanks
Nitin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Oct 2013 20:21:07 -0400

Thank you for your responses.  Further in-line.  (Deleted text where 
there is agreement.)

> value to distinguish between the 2 routes.

Why would a single I2RS Client program two routes for the same prefix 
with different next-hops?  Is there a use case that drives us to want to 
allow this?

> Note that the above text has no reference to BGP.

AS Paths are a BGP construct.  If you are not running BGP then the 
question above (about two paths from the I2RS agent) would seem to 
apply.  If you do have a BGP running, then the BGP is usually where that 
sort of policy lives.  My concern is that this mechanism assumes a RIB 
agent that handles BGP specific operations.  I would prefer to leave BGP 
mediation to the BGP model.

> I would be happy to hear alternatives for modeling this.

Maybe we should defer modeling the details of load balancing?

> between them (until TTL expires).

Well, my concern is exactly your parenthetical (until the TTL expires.) 
  I do understand that people want to support pipe mode.  Is there some 
way this could be attached to the tunnel entry behavior, rather than 
being a general next-hop property.  It is rather specific, and making it 
general seems weak modeling.

> Data-model negotiation (outside scope of this document). Indicating always

I am not concerned with how we represent that something is optional in a 
message.  That's easy.  And I understand that negotiation is outside the 
scope of this model.  But it is the model's job to indicate which 
capabilities are required to be supported on the underlying device, and 
which are optional.  This presumably would then be reflected in the 
negotiation or capabilities exchange mechanism.  As currently written, a 
reader is led to conclude that a compliant device / I2RS Agent must 
support all of the capabilities in the model.  I hope that is not the 
intent.

...

---

From: "Russ White" <[email-masked]>
Date: Thu, 10 Oct 2013 06:40:46 -0400

> Why would a single I2RS Client program two routes for the same prefix with
> different next-hops?  Is there a use case that drives us to want to allow
this?

There are two cases --a backup route, and load balancing. The way to handle
both cases is to have a marker of some type indicating what's going on.
Assuming based on metrics is a bad thing. 

The process on the forwarding device should not be in the position of
evaluating between two different routes installed by the same client process
for the same destination through the route metric. Route metrics of all
types --AS Path, etc.-- are local to the routing process, and should be
treated as meaningless outside it (with special exceptions, such as
importing/exporting routes for L3VPNs and the like). 

So if the idea that we will be installing multiple routes from a client into
the RIB, and asking the RIB to decide between these routes based on metrics
passed with the route itself --that's not a good construct. The decision
should be made by the client process before it sends two such routes; that
work shouldn't be pushed onto the RIB or some other process outside the
client.

> mediation to the BGP model.

Completely agree... We don't need BGP constructs at the RIB level at all.
Same reasoning as above.

> Maybe we should defer modeling the details of load balancing?

I'm not so certain it's difficult (?)... There seem to be two options:

1. The client sends multiple routes, each marked with some sort of tag
saying, "this is a load share." 
2. The client puts multiple routes into a single transaction, something like
NLRIs in a BGP packet.

Beyond this, the local process handles anything that has to be done to
manage things... Part of the problem with dealing with a data model before a
protocol is we're immediately diving into how to represent something in a
globally meaningful way, rather than simply how to just get the information
across the wire.

> general seems weak modeling.

Again, agreed... This could be a rewrite attribute, rather than a next hop
attribute --in fact, it should be. I can imagine cases where the next hop
can be reached either through a tunnel, or not through a tunnel, and tunnel
entry depends on some policy. If you mark all traffic to a particular
destination "don't decrement the ttl," then you're risking a loop in traffic
that's not entering the tunnel for policy reasons. Not a good thing.

:-)

Russ

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 10 Oct 2013 18:13:02 +0000

Hi Joel/Russ,

>with different next-hops?  Is there a use case that drives us to want to

I'll remove "route_metric" unless someone comes up with a useful use-case.

>mediation to the BGP model.

There were folks who had expressed interest in inter-domain paths. That's
why this
was added. I agree with you that the handling logic will be BGP'ish and
there is an
implicit assumption that the RIB agent can handle this.

However, it's obvious (at least to me), that most of the use-cases for
I2RS will be
intra-domain and a device that does not support inter-as/bgp should be
fine for
most of the deployment use-cases.

There are 2 ways to handle this:
1) Say inter-domain routes is out of scope of the RIB and any inter-domain
extensions should be
   part of a separate draft.
2) Say inter-domain routes is an optional feature for i2rs agents.

>Maybe we should defer modeling the details of load balancing?

If we ignore load-balancing, we'll miss on a big chunk of functionality.

>general seems weak modeling.

Let me think more about this...

>which are optional.

Yes, that's a good point. I haven't figured out a way to express this and
I understand that
expressing this is very important.
Should this be expressed in the info-model or the data-model?

>This presumably would then be reflected in the

Speaking as a router vendor - Not all Juniper devices will be able to
support all the
gory details in the rib model. So the intent is indeed NOT to enforce
support of all the options.
Each network device will support a subset of the features. And as you
mentioned earlier, we
Need to specify the REQUIRED vs OPTIONAL features.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 10 Oct 2013 18:19:08 +0000

Hi Russ/Joel,

>that's not entering the tunnel for policy reasons. Not a good thing.

I think the key take away for me from here is that the "decrement" is a
property of 
the tunnel and not the route. So if one wants to treat the tunnel as a
pipe, then
they should configure it so on the tunnel and not on the route.

Given that, it makes sense to get rid of the no-decrement-ttl and
no-propagate-ttl
from the draft.

Thanks
Nitin

---

From: t.petch <[email-masked]>
Date: Fri, 11 Oct 2013 09:57:42 +0100

----- Original Message -----
From: "Nitin Bahadur" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>; "Russ White" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 10, 2013 7:13 PM
<snip>
>mediation to the BGP model.

There were folks who had expressed interest in inter-domain paths.
That's
why this
was added. I agree with you that the handling logic will be BGP'ish and
there is an
implicit assumption that the RIB agent can handle this.

<tp>
I keep on thinking that producing designs without agreed requirements,
use cases, is often a costly mistake.

My thinking on use cases was quite different, but unless and until we
have the discussion on eg
 draft-white-irs-use-case-00.txt et al.
who knows?

Tom Petch

<snip>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2013 08:47:00 -0400

Tom,

A discussion would be great!  Why don't you start it?

Alia

On Fri, Oct 11, 2013 at 4:57 AM, t.petch <[email-masked]> wrote:

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Sriganesh Kini <[email-masked]>
Date: Sat, 12 Oct 2013 08:30:18 -0700

> I'll remove "route_metric" unless someone comes up with a useful use-case.

I agree that a single I2RS client should never program two routes for the
same prefix. If there are clients/applications other than the one that
installed the route that would like to read the route_metric to take
actions related to billing, SLA, alarms etc, would it read those routes
directly from the client instead of the RIB ?

- Sri