Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 14:35:06 -0400

On Tue, May 20, 2014 at 09:23:13AM -0700, Sriganesh Kini wrote:
> On Tue, May 20, 2014 at 8:06 AM, Dean Bogdanovic <[email-masked]> wrote:
> 
> > Changes done by I2RS agent should have only device impact, not network
> >> impact. If there is desire to change across network, then each I2RS agent
> >> on each device should be updated.
> >>
> >
> >  It is not simple to classify a change to a device as having an impact
> > scoped to just that device. E.g a route that is added to a device with a
> > different preference can have network-wide traffic impact.
> >
> >
> >  How can I explain this better. The static route on device will be routed
> > to the next destination, but at the next destination the dynamic protocol
> > will take effect, unless, another static route directs the traffic
> > differently. Makes sense?
> 
> 
> I think what you really wanted to say is - An I2RS agent must not interface
> with an I2RS agent on another network element. If an I2RS client requires
> to interface with I2RS agents on multiple network elements, it must do so
> itself without putting requirements on the I2RS agent on one network
> element to interface with the I2RS agent on another network element.

As mentioned elsewhere, I tend to perceive I2RS's impact on the network as
being similar to that of a routing protocol.  If I want something I do to a
given device to propagate, the state that is injected must either be
suitable for injection into another routing protocol (redistribute into BGP,
or IGP, e.g.) or must be fully local.

We will have cases for both.

For Sri's point, if I inject state in to router A and it overlaps with state
in router B, it better be because that state had arrived via a routing
protocol.  In such a case, the interaction between I2RS and the protocol
would already be defined.

-- Jeff

---

From: "Russ White" <[email-masked]>
Date: Fri, 13 Jun 2014 07:16:14 -0400

> being similar to that of a routing protocol.  If I want something I do to
a given
> device to propagate, the state that is injected must either be suitable
for
> injection into another routing protocol (redistribute into BGP, or IGP,
e.g.) or
> must be fully local.
> For Sri's point, if I inject state in to router A and it overlaps with
state in
> router B, it better be because that state had arrived via a routing
protocol.  In
> such a case, the interaction between I2RS and the protocol would already
be
> defined.

This is the correct way to see this problem -- we don't want to inject
complex and fancy "stuff" into I2RS to handle every conceivable
overlap/conflict/etc. We are injecting routing information into a local RIB
which is then distributed through normal routing -- there are already rules
in place to handle overlapping information coming from two different routing
protocols on every platform that runs more than one routing protocol.
Devices from different vendors running multiple routing processes already
interoperate on today's networks.

Let's not invent new solutions to a problem that has already been solved
with real deployed code.

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Jun 2014 09:54:12 +0200

Hi Russ,

> We are injecting routing information into a local RIB
> which is then distributed through normal routing

You mean that such "distribution" will be based on common protocol to
protocol redistribution rules and filters right (I2RS being here one
of the src or dst protocol) ?

If so I agree, if not how do you imagine this to be accomplished ?

Normally RIB does not "push" routes up to producers in fact it has no
clue who would even want it :-)

Thx,
R.