Subject: Re: [i2rs] Router Models

From: t.petch <[email-masked]>
Date: Fri, 1 Mar 2013 10:39:42 +0000

Russ

FYI

I understand that you sent an e-mail to the list with an attached
diagram but, if so, it was way over the limit that trips my spam filters
so I never got it.

The archive strips attachments so there is nothing there.

I accessed the URI you gave and downloaded 500kbyte which displays as
28x30 pixels of not very much.  I note that it starts with
ÿØÿà ... .Adobe... Exif
whereas a jpeg usually starts with
ÿØÿà ... JFIF

There is a Lot to be Said for ASCII Art.

Tom Petch

----- Original Message -----
From: "Russ White" <[email-masked]>
To: "Rob (William) Rice" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 26, 2013 6:30 PM

> > 1. Within your Routing Process boxes, I think what you mean by "A"
> > is the injection of the same type of raw data the routing process
> > receives from normal protocol neighbor (e.g., LSAs for OSPF,
> > paths/NLRI for BGP). By "B," I think you mean injecting items that
> > are the product of the routing protocol's processing of this raw
> > data (i.e., protocol-specific routes). Am I understanding you
> > correctly on this? "B" is not a modification to the routing protocol
> > logic itself, is it? Would it be clearer to have another box below
> > the Policy cloud to represent the set of routes the protocol
> > computes, with the Policy cloud representing the internal protocol
> > logic that transforms the input data into routes?
>
> I'm using A to represent information put into the routing process like
a
> peer running the same routing protocol would put information into that
> routing process, and B to represent modifications to the policy the
> routing process uses to choose which route to present to the RIB.
>
> B is not a modification to the actual algorithm the process uses to
> select the best paths --that would be really, really bad. :-)
>
> I would argue that putting information directly into the OSPF LSA
> database -- for instance, modifying a type 1 LSA to include a link
that
> wasn't advertised by the originator of that type 1 LSA -- would also
be
> "bad juju." Once you start messing with the internal data structures
of
> algorithms and protocols which count on the consistency and accuracy
of
> those data structures to make accurate and timely decisions, you're
> someplace you really don't want to be.
>
> > 2. Does the RIB in your diagram include all routes from all sources
> > or just best routes (those to be used for forwarding)?
>
> All the routes from all sources. The RIB would select which routes to
> present to the FIB based on it's internal policy (such as admin
> distance). Perhaps the "policy cloud" should really be below the RIB,
> between the RIB and the FIB.
>
> > 3. Is the policy cloud hovering above the RIB box applying whatever
> > rules the implementation uses (e.g., admin distance) to select best
> > routes? Maybe also rules for filtering routes accepted from various
> > sources? I'm trying to understand the difference between "C" and
> > "D."
>
> Yes...
>
> > 4. Can you clarify why you think injecting at "D" is "bad juju"?
> > Presumably, "D" says "x is the best route to destination N,
> > regardless of anything anyone else says"?
>
> This is bad, IMHO, because it's mixing local policy with remote policy
> in a way that's not obvious to an engineering examining the local
> forwarding table, and because it bypasses the normal checks that
prevent
> the formation of routing loops, unreachable next hops, overwriting
> connected routes, and other things of that sort.
>
> If you want a route to be installed "no matter what other process
> think," then the preference on the route (the "administrative
> distance"), should be set to cause this particular route to be
installed
> instead of any route presented by another process, within the rule set
> allowed by the local RIB process.
>
> In general, I think overriding the internal algorithms and policies
> implemented by protocols and processes is a "bad thing." We should
> strive to work with and through those internal algorithms and
policies,
> not around them.
>
> :-)
>
> Russ
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 27 Feb 2013 11:41:50 -0800

Greetings all,

<clip>
On 26Feb2013, at 18.48, Shane Amante <[email-masked]> wrote:
>>> 
> Taking a look at (b) and looking at your diagram, it seems as though (b) should be within the boxes you have labelled "Routing Process".  More specifically, I think you need more "clouds" ;-) sitting directly above the "Local Database" (Loc-RIB?) that, at a minimum, represent protocol adjacencies (e.g.: BGP neighbor adjacencies) where I2RS _should_ be allowed to apply (BGP) policy to those routing protocol sessions, in order to permit filtering of _and_ manipulation of attributes in those routes inbound to or outbound from the routing protocol process, (just like we do in today's networks).  I would think that this additional cloud would represent something like the Adj-RIB-In/Adj-RIB-Out, at least wrt a BGP Routing Process.
> 
> With respect to (a) above, namely placement of aggregate/summarization/etc. routes, I believe that would most likely belong inside of and/or injected into the "policy" cloud (inside the "Routing Process" box) through "B" in your diagram.  IOW, I place a summarization route in the routing process, which then flows two directions: i) up into the routing processes database and outward through the routing protocol, using normal routing update protocol mechanisms; and, ii) down to the RIB process for consideration as to whether it should be installed in the FIB after passing through "D" and "E", of course.
> 
I think Shane brings up some salient points.  However, I do wonder if the same could be accomplished by injecting the routes "below" the individual routing protocols policy engine/cloud and allow for the redistribution "up (in the diagram)" based on that policy engine (under the control of a system that uses I2RS, but that policy may actually be driven by another protocol (interesting point, do we want I2RS to drive policy configuration, or use something else, ala NETCONF).  

As Shane says, that policy engine is different from different vendors, so I'm not sure if it would be any easier to implement policy config via a common model in I2RS v.v. NETCONF.  

Another option would be for I2RS to bypass the policy engine on the protocol all together and enforce policy on the I2RS "controller".  In that approach, you could either bypass the policy engine in reality, or virtually, by defining a policy in the protocol engine that allowed I2RS to bypass local policy (think global "accept").

--  
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
Check my calendar availability: https://tungle.me/cdl

---

From: Russ White <[email-masked]>
Date: Fri, 01 Mar 2013 13:11:49 -0500

> I'd find it helpful if we could agree to use Alia's terminology from
> draft-atlas-i2rs-problem-statement-01, specifically "Policy Database"
> and "RIB Manager", or clarify what's wrong with that terminology.

IMHO, this terminology isn't specific enough to drive the discussion...
The policy manager, as shown in problem-statement, controls what kind of
policy for which elements which is inserted where? What's the difference
between the connection to the "routing and signaling protocols," box,
and the "RIB Manager?"

Further, the drawing in problem-statement appears to assume a local
process called the "I2RS agent," which intercedes between the policy and
database injection points and the I2RS client/applications. I don't
think we're going to build a solid data model if we're building a model
around a local process, with it's own internal database, processes, and
policy, rather than targeting the ultimate end users of the information
(the policy and database in each of the independent processes).

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 01 Mar 2013 13:20:07 -0500

> I would hope more folks in the WG want that too.  :-)
> 
> On a more general note ... first, thanks for putting this diagram 
> together.  At least now we have a decent picture to start a 
> discussion.
> 
> I think you've mostly (?) been focused on routes being received by 
> and processed by a router that, ultimately, are distilled into a
> FIB. That's certainly important, but I think that we also need to
> look in the other direction, namely: routes that get /exported/ from
> one, or more, routers into an IGP or BGP.  

> a)
> placement of aggregate/tie-down/summarization/flow-spec routes, (at
> certain routers at certain places in the topology); 

I would think of this as inserting information through the normal
peering process, or through a "static route," (which is just another
routing process) + the policy needed to import/redistribute that route
into BGP. So, assuming B in the diagram is bidirectional, setting up the
policy for what the routing process receives from the RIB as well as
what the routing process presents to the RIB.

> b) "route
> filters" applied to, for example, eBGP neighbor sessions inbound &
> outbound 

This is where I think the diagram needs another "policy cloud," showing
a policy insertion point between "Peering" and the "local database."

> Taking a look at (b) and looking at your diagram, it seems as though 
> (b) should be within the boxes you have labelled "Routing Process". 
> More specifically, I think you need more "clouds" ;-) sitting 
> directly above the "Local Database" (Loc-RIB?) that, at a minimum, 
> represent protocol adjacencies (e.g.: BGP neighbor adjacencies)
> where I2RS _should_ be allowed to apply (BGP) policy to those
> routing protocol sessions, in order to permit filtering of _and_
> manipulation of attributes in those routes inbound to or outbound
> from the routing protocol process, (just like we do in today's
> networks).  I would think that this additional cloud would represent
> something like the Adj-RIB-In/Adj-RIB-Out, at least wrt a BGP Routing
> Process.

Yep.

> In summary, although I think you chose your words carefully when 
> describing "A" by proposing that I2RS avoid (forbid?) "direct 
> injection of information [in]to a routing process", I think there's 
> an important point we should not miss here.  Namely, I2RS can do 
> that, but only _when_ I2RS informs the routing process, which then 

Or rather when I2RS uses the "normal, front door," APIs provided by the
routing process to interact with those local databases. What we don't
want is the ability to inject a route into the BGP table that just
overwrites other routes, no matter what other policy might be
implemented within the BGP process itself.

I expect there will always be some way to say, "this route must win,"
such as weight in IOS, or admin distance, but we don't want to bypass
these sorts of things, we want to work with them.

> [2] While we're here, I'm not sure where (if it all) you intended
> for routing protocol redistribution to be illustrated in your
> diagram. Given that different vendors have vastly different
> models/ideas of how this is accomplished in their code, I'm not sure
> such a thing is even practical or possible.  :-(

See above, about the bidirectional nature of B in the diagram... I think
that would cover the redistribution case. You might have to include D,
as shown, in the process of redistribution as well (for instance,
redistribution in a particular implementation might be a push from the
RIB process to each impacted routing process --so we need to account for
both push and pull models here).

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 01 Mar 2013 13:22:48 -0500

> It might be useful to have an upfront agreement on the definitions of terms like RIB, FIB, routing table and forwarding table. Previously, we had an interesting discussion about them in the NETMOD mailing list, see this thread:

I suspect there are so many definitions that we're going to need to come
up with I2RS specific definitions and enforce them in our particular set
of drafts to make this work... We're not going to get to a consensus
across the entire IETF --at least I don't think we will...

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 01 Mar 2013 13:25:18 -0500

> It took me a while to figure out that different types of information are being manipulated at each arrow. The diagram would be easier to understand if each arrow was labeled with the type of object which is being inserted or retrieved at each interface:
> 
> A: Local routing process state
> B: Routing process to RIB process export policy rules
> C: Routes in the RIB
> D: RIB process import policy rules
> E: RIB process to FIB best route selection rules

Yes --thanks... I think it is probably important to make certain we not
only define the type of operation at each point, but also the data being
injected/received, at least broadly... The point in building the data
model would then be to define these data transfers more specifically,
and then the protocol work to figure out how to carry the data
specifically called for in an intelligible way, I think...

But I'm thinking way ahead of the ball at this point, and just throwing
out some possible lines of approach. Nothing definite here!

:-)

Russ

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 2 Mar 2013 20:42:24 +0100

I agree that we MAY start from defined router model with defined I2RS
use-cases, so both not each separate. I argued before that we SHOULD
define both parts of communication that includes the router but my
ideas may be ignored,

AB

On 2/25/13, Russ White <[email-masked]> wrote:
> Y'all:
>
> Because of a long and protracted exchange off list with a number of
> folks, I've come to the conclusion that we can't (really) start with a
> data model --even working from the use cases to a data model seems to be
> difficult. I think we need to come to agreement on what a router looks
> like first.
>
> No, not blue, grey, green, or... :-)
>
> Look at the attached (hopefully the attachment works --if not, I've
> stashed a copy here, as well: http://www.riw.us/temp/router%20model.jpg).
>
> Let's ignore the question of whether or not there is some sort of I2RS
> local process --more on this in a sec.
>
> Note I'm not claiming:
>
> - This is the only possible model for a router's operation
> - This is a model that is widely used and deployed
> - This is a model that contains every piece of a possible router
>
> What I am claiming is this is a useful model that will help us
> understand what we want to do, and what we don't want to do --and, I
> hope, it will lead to a better understanding of the difference between
> policy, forwarding information, and configuration.
>
> IMHO:
>
> - If a process wants to inject information at A, then it can simply
> participate in the routing protocol in question --so I2RS doesn't really
> need to do anything there. In fact, I would argue that injecting
> information at A without participating in the protocol could be very
> dangerous, and we don't want to go there.
>
> - I2RS should be in the business of injecting information at B. We can
> discuss whether that should be through configuration or not (IMHO, it
> should be).
>
> - I2RS should be in the business of injecting information at C (because
> the current use cases demand it). In fact, C should be a bidirectional
> interface that looks, to the RIB, just like an on-box routing process
> (like either of the other two routing processes shown in the diagram).
>
> - I2RS should not mess with D. This is bad juju.
>
> - I2RS should not mess with E, this is FORCES.
>
> - I2RS should not mess with F, this is OpenFlow.
>
> Now, to return to the idea of a "local process." There are several
> issues to assuming a "local I2RS process." The first is that it
> restricts implementation in a way that might be unacceptable in all
> situations. Smaller devices with only partial I2RS interfaces might find
> it painful to build a separate process, with all that entails, just to
> support some simple commands from an I2RS controller. The second is that
> assuming a local process really doesn't help us in any material way to
> define anything. When we're in the process of building a data model for
> interacting with BGP policy, for instance, how does saying, "well, the
> local I2RS process has a data model that looks like x, which it
> translates into data model y to talk through some local interface to the
> BGP process," really help? The only thing I can see assuming a "local
> process," does is add complexity.
>
> So, thoughts...
>
> - Is this a reasonable model of a controlled device?
> - What would you add?
> - What would you subtract?
> - What specific operation can you think of that doesn't quite fit into
> the model as it's shown?
>
> Hopefully, this will kick off some discussion here, and bring us to a
> place where we can go back to the two use cases the WG originally agreed
> to restrict itself to, and make some progress in understanding how to
> build the right pieces to support those use cases.
>
> :-)
>
> Russ
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 4 Mar 2013 09:51:15 -0500

The diagram is a high-level conceptual picture mostly showing
connections from i2rs
to other aspects of the box.  The RIB Manager is, I think, the exception.

Alia

---

From: Russ White <[email-masked]>
Date: Mon, 04 Mar 2013 17:42:53 -0500

> to other aspects of the box.  The RIB Manager is, I think, the exception.

Of course --my point was that to drive the data model, and better
understand the interaction between I2RS and the devices we want to
interact with, we need something that's more specific.

Different purposes, but both are needed, IMHO.

:-)

Russ

---

From: Alia Atlas <[email-masked]>
Date: Mon, 4 Mar 2013 17:47:35 -0500

Yes, I think that your diagram is a good start. I hope your ASCII art
fu is better than mine :-)

For the "functional analysis" of I2RS discussion, I think that a
diagram or two would be a good idea as well - to make it clear what
aspects are interesting, in-scope, and generally likely to be safe.
Do you have time to draw something a bit more detailed up?

Of course, it's not going to fully describe all the aspects - but
things like mucking with data learned via routing (as opposed to
policy in processing that data or in specifying data "owned" by the
network element) is pretty clearly hazardous.

Thanks,
Alia

---

From: Scott Whyte <[email-masked]>
Date: Wed, 6 Mar 2013 17:21:55 -0800

> implemented within the BGP process itself.

I guess I'm having a hard time following all this.  If you move the
routing process policy cloud and "B" (bidirectional now) up between
the peering and local database, similar to what you said above, you'd
get this clean front-door requirement for I2RS<->routing protocol
interactions, and I2RS<->RIB interactions would remain at "C".  What
am I missing?

-Scott

-- 
panem et circenses - a winning strategy for over 2000 years!