Subject: [i2rs] Router Models

From: Russ White <[email-masked]>
Date: Mon, 25 Feb 2013 17:59:12 -0500

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: Edward Crabbe <[email-masked]>
Date: Mon, 25 Feb 2013 16:06:53 -0800

Russ;

Thanks for kicking off this discussion.  Comments inline:

> policy, forwarding information, and configuration.
I agree; this is an extremely starting place for the discussion.

> dangerous, and we don't want to go there.
Not sure I agree here, and, given the use cases I see cropping up, not sure
others do either.

> discuss whether that should be through configuration or not (IMHO, it
Agree with the first part.  W/r/t use of configuration, it's not clear on
whether this can achieved solely via config given the proposed
ephemeral nature of some forms of I2RS policy and the generally persistant
nature of config on most devices.  Having said that, it is clear that some
portion of policy injection will reside in config.

> (like either of the other two routing processes shown in the diagram).
Strongly agree.

> - I2RS should not mess with D. This is bad juju.
Generally agree.

> - I2RS should not mess with E, this is FORCES.
Agree, as does the charter.

> - I2RS should not mess with F, this is OpenFlow.
Sorry,  this is inaccurate.  Openflow and ForCES actually have a
significant amount of overlap in terms of functionality and targets,
especially w/r/t to the simplified model you've drawn here.  Both interact
with a model of the forwarding plane via the control plane, with a somewhat
arbitrary degree of complexity masking in the fp models based on the use
case.

Having said that, both I (and the charter) agree that I2RS doesn't have any
business being here.

> support some simple commands from an I2RS controller.

It really depends on how we how we design modularity and capability
negotiation for the protocol, and what portion of the capability set we
define as being mandatory in the core protocol.  I don't think having a
separate process is a bad thing regardless.

You seem to suggest something similar above in your comments regarding
injection ->(C), so perhaps I'm misunderstanding.

> The second is that

Yep, I'm pretty sure I'm not understanding your argument here.  There are
clearly use cases that would involve direct injection of state independent
of a ancillary distributed protocol, say, for example, injection of
ephemeral PBR state for a variety of security use cases.  Interaction with
the RIB is clearly in charter , and I believe (as do you apparently) that
this is best done without assumption of direct interaction with the actual
RIB process, ie: this should be modeled as a separate 'I2RS' routing
process and subject to some notion of relative protocol priority.

So, thoughts...
> build the right pieces to support those use cases.

Again, thanks for starting this discussion on the list.

best,

  -ed

---

From: Russ White <[email-masked]>
Date: Mon, 25 Feb 2013 21:32:07 -0500

> Not sure I agree here, and, given the use cases I see cropping up, not
> sure others do either.  

I'm actually very concerned about the direct injection of information
into the local database of a protocol --because I'm not certain what
sort of "rules," we could follow here to ensure the loop freeness of the
protocol's algorithms once we start down this road, nor can we be
certain an operator working at 2am on a routing problem will be "okay,"
with a route they don't understand the origin of, can't trace down to an
originating device, etc.

There might be solutions to these problems, but I don't see any
immediately available answers (nor do I think we've even worked out what
the problems might be), so I'm hesitant to claim injecting information
at "A" a "good idea."

So put me in the column, "this might be okay, but I need to be convinced
we've spent a good amount of time thinking through whether or not this
is a good idea before we do it."

> Agree with the first part.  W/r/t use of configuration, it's not clear
> on whether this can achieved solely via config given the proposed
> ephemeral nature of some forms of I2RS policy and the generally
> persistant nature of config on most devices.  Having said that, it is
> clear that some portion of policy injection will reside in config.   

The problem here is somewhat the same as above --if changes aren't
recorded in the configuration, how much complexity are we adding to the
network management problem verses removing from the network management
problem? If an engineer has to look at multiple outside processes to
understand why specific things are happening, rather than a single
configuration set, what the impact going to be on MTTR?

Are we shooting ourselves in the foot to get to a faster draw stroke?

Again, more information needed...

> injection ->(C), so perhaps I'm misunderstanding.    

My general argument would be this:

Whether or not there's a local process is outside the scope of the WG to
mess with. We should deal with the data models and protocol(s) on the
wire, not with defining a new "routing process," the interfaces we
expect that new process to have with other processes on the box, and
other stuff. The number of processes, interfaces between those
processes, and other "internal stuff," should be left to implementers
--to encourage interesting ways of doing things, and to simplify the
problem at hand...

> Yep, I'm pretty sure I'm not understanding your argument here.  There
> are clearly use cases that would involve direct injection of state
> independent of a ancillary distributed protocol, say, for example,
> injection of ephemeral PBR state for a variety of security use cases.

In this case, you would simply define the data model and the bits in the
protocol that tell the router what PBR state you'd like to achieve, and
leave it up to the coder to determine who on the local box receives that
information, and how they act on it. It could be that some
implementations already have PBR processes, while others don't, and
others might handle PBR in their BGP process (yes, I'm making stuff up
here) --I don't think we, as a WG, want to be saying things like, "you
must have a local I2RS process, and it must do this, and not do that."

:-)

Russ

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Feb 2013 08:25:28 +0100

> stashed a copy here, as well: http://www.riw.us/temp/router%20model.jpg).

Whatever the model is, I would hope that it is consistent with what we
already have in this document:

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Feb 2013 11:43:47 +0100

> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09

Yes, I2RS folks, please have a look. The scope of the NETMOD routing model seems to fit Russ's description in that it also aims at the same locations A, B, C. There are some differences in terminology but these shouldn't be insurmountable.

If you have any comments or suggestions regarding the NETMOD data model, please let us know asap because that I-D is already overdue.

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Rob (William) Rice" <[email-masked]>
Date: Tue, 26 Feb 2013 14:08:16 +0000

Russ,

I think this diagram is a good start at defining the interface points. I have a couple clarifying questions.

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?

2. Does the RIB in your diagram include all routes from all sources or just best routes (those to be used for forwarding)?

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."

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"?

Thanks,

Rob

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Russ White
> Sent: Monday, February 25, 2013 5:59 PM
> To: [email-masked]
> Subject: [i2rs] Router Models
> 
> Y'all:
> 
> stashed a copy here, as well:
> http://www.riw.us/temp/router%20model.jpg).
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Feb 2013 09:26:21 -0500

Two difficulties with this diagram for our purposes:
1) We are (sooner or later, assuming we succeed) going to also be 
manipulating many other properties that are not shown (Queues, marking, 
firewalls, ...
2) I think it is important to show processes, because I think that there 
is significant confusion as to which processes are the consumers of what 
information.

Thank you or drawing this to help clarify the situation.

Yours,
Joel

PS: While not a big deal, I would like to try to be careful to focus on 
the information models, not the data models, when we go forward from this.

On 2/25/2013 5:59 PM, Russ White wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Feb 2013 09:34:15 -0500

As I read the documents, our references to a "local process" for the 
I2RS agent do not mandate an implementation.  Process in this context is 
a way of describing a collection of state and manipulation logic for 
working with the I2RS messages (protocol machinery and storage). 
Whether it is actually implemented as a separate process, a thread, or 
part of some other processing logic in the router is a local 
implementation matter, and not our business.

Yours,
Joel

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 26 Feb 2013 08:50:45 -0800

+1

On Tue, Feb 26, 2013 at 6:34 AM, Joel M. Halpern <[email-masked]>wrote:

> As I read the documents, our references to a "local process" for the I2RS
> agent do not mandate an implementation.  Process in this context is a way
> of describing a collection of state and manipulation logic for working with
> the I2RS messages (protocol machinery and storage). Whether it is actually
> implemented as a separate process, a thread, or part of some other
> processing logic in the router is a local implementation matter, and not
> our business.
>
> Yours,
> Joel
> ______________________________**_________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>

---

From: Russ White <[email-masked]>
Date: Tue, 26 Feb 2013 13:30:38 -0500

> 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

---

From: Russ White <[email-masked]>
Date: Tue, 26 Feb 2013 13:38:16 -0500

> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09

Looking at this document, it seems more like a data model for a routing
table, rather than an actual model of how different processes interact
to build a routing table... Some specific points:

- I would say separating "static routes," and "routing protocol
processes," is a false division --a static route is nothing more than a
human injecting topology information a routing protocol might normally
inject. The primary difference is not in the way the routes are handled
by the routing table, but in that there is no feedback mechanism for
static routes.

- What this document calls "direct routes," are really just routes
injected by the local routing process; these are treated differently
because they have an administrative distance set so other routing
processed cannot overwrite them. I don't think these should be seen as
being handled "differently" by the RIB.

- While it is sometimes true that a single routing protocol process only
interacts with one RIB on the device, it is also true that it might
interact with multiple RIBs on the device. This is something we need to
be careful of in the I2RS design.

Overall, I think the models match well enough to work together... The
model in the netmod document would need to have policy
application/injection points added to give it the fullness I think we
need for I2RS.

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Feb 2013 13:41:37 -0500

I think we strongly agree that we want t inject non-protocol specific 
routing information at C rather tan D.  Is it consistent with your model 
to think of C as talking to the RIB manager?

Yours,
Joel

---

From: Russ White <[email-masked]>
Date: Tue, 26 Feb 2013 14:07:26 -0500

> manipulating many other properties that are not shown (Queues, marking,

One thing at a time... :-)

> is significant confusion as to which processes are the consumers of what

I've redone the diagram to account for some of the comments so far...
Attached, and also at:

http://riw.us/temp/router%20model.jpg

- I've tried to show the difference between a policy, a local database,
and a process in this version. I don't know if it's clear, but hopefully
it is.

- A is the direct injection of information to a routing process, without
using the "front door," through what appears to be to the routing
process a peering mechanism.

- B is the policy the routing process uses to influence which routes are
presented to the RIB process.

- C is an interface to the RIB process that looks, to the RIB process,
like any other routing process (whether local or remote).

- D is the set of filters or policies the RIB uses to determine which
routes to insert in its local database, such as route filters. There
might need to be a similar point of insertion before the local database
of each routing protocol to represent route filters and such, as well.

- E is the set of policies the RIB uses to choose among the routes in
its local database to the FIB. I'm primarily thinking of administrative
distance here, but there might be others.

I would argue I2RS shouldn't be inserting stuff at A. I don't know of a
use case to insert stuff at C, but that could be because I'm not
imaginative enough (the only policy I know of here is administrative
distance, and I can't imagine someone want to make it so the
administrative distance is somehow reversed!).

Is this better? Am I missing other parts? What about a policy cloud
within the routing process before the local database? Once we get this
piece sorted, I'll be glad to start adding pieces for interfaces to
interfaces.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 26 Feb 2013 14:24:40 -0500

> use case to insert stuff at C, but that could be because I'm not

E, not C here... Sorry for the typo.

:-)

Russ

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Tue, 26 Feb 2013 11:54:35 -0800

Greetings Russ,

	Some thoughts in line...

> dangerous, and we don't want to go there.

Agreed

> discuss whether that should be through configuration or not (IMHO, it

In principal, agreed - however, a standardized way of driving that (e.g. via NETCONF) would be quite useful (and we are not there yet), but not in scope here.

> (like either of the other two routing processes shown in the diagram).

Agreed

> - I2RS should not mess with D. This is bad juju.

As above with the other policy insertion point.

> - I2RS should not mess with E, this is FORCES.

Agnostic, here

> - I2RS should not mess with F, this is OpenFlow.

I assume F (which is not on the diagram) is between the FIB and the local processor, in which case, I agree

> process," does is add complexity.

The goal of I2RS should be to support an external interface to the RIB process of a routing element.  If a system designer wants to use I2RS internally within a single routing element instance, that would be valid, but is not the target of the protocol.  My feeling is that most routing system developers/platforms already have that link sorted out :)

> - What specific operation can you think of that doesn't quite fit into

I do believe that it would be useful for I2RS to get the full candidate database from the various protocols (maybe as they feed in from the routing processes), before best path winnowing is done.  I assume that is in scope here, but is not completely clear.

> <router model.jpg>_______________________________________________
> i2rs mailing list
> [email-masked]

--  
李柯睿
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: "Rob (William) Rice" <[email-masked]>
Date: Tue, 26 Feb 2013 20:54:11 +0000

Russ,

Thanks for the clarifications. I am still a little fuzzy about what you mean by "...B to represent modifications to the policy the
routing process uses to choose which route to present to the RIB." To use an example from BGP, maybe this could mean configuring an inbound prefix list or other type of policy filter. If so, then B is an interface to change the configuration of the routing protocol rather than the data (e.g., Adj-RIB-In contents), right? Of course, this type of configuration change affects not only what the protocol sends to the RIB, but may also affect what the protocol readvertises to its neighbors. 

A link state routing protocol probably has a lot fewer "policies" one might tweek, if I'm understanding this right.

Rob

> From: Russ White [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2013 1:31 PM
> To: Rob (William) Rice
> Cc: [email-masked]
> Subject: Re: [i2rs] Router Models
>

---

From: Russ White <[email-masked]>
Date: Tue, 26 Feb 2013 16:10:27 -0500

> routing process uses to choose which route to present to the RIB." To use an example from BGP, maybe this could mean configuring an inbound prefix list or other type of policy filter. If so, then B…

Communities within BGP, for instance, or the metric on an OSPF route.
Yes, link state protocols would have fewer of these than BGP would --but
I think a good bit of the BGP policy model Shane wants would fit here...
(?).

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 26 Feb 2013 16:13:19 -0500

> In principal, agreed - however, a standardized way of driving that 
> (e.g. via NETCONF) would be quite useful (and we are not there yet),
>  but not in scope here.

Agreed...

> The goal of I2RS should be to support an external interface to the 
> RIB process of a routing element.  If a system designer wants to use
>  I2RS internally within a single routing element instance, that would
>  be valid, but is not the target of the protocol.  My feeling is that
>  most routing system developers/platforms already have that link 
> sorted out :)

I think this is an important/interesting point... Thanks for bringing it
up.

> I do believe that it would be useful for I2RS to get the full 
> candidate database from the various protocols (maybe as they feed in
>  from the routing processes), before best path winnowing is done.  I
>  assume that is in scope here, but is not completely clear.

Yes, I think it is.

---

From: Scott Whyte <[email-masked]>
Date: Tue, 26 Feb 2013 18:14:53 -0800

> E, not C here... Sorry for the typo.

Ok that's helpful :)

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.
Then we could eliminate the need to define "normal", and cast the
goals of I2RS in terms of it's "local process's" interaction with the
local "Policy Database Manager" and the local "RIB Manager", using
Joel's meaning of "local process". Suggested text:

I2RS uses standardized APIs on a routing element to accept and process
messages, constructing input to the policy database manager and RIB
manager as needed.  It is not intended to replace these local
managers, although an implementation of a router using I2RS without
them would be valid, at least from the I2RS perspective.

Although at this point I'm not clear where this would go :)

-Scott

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

---

From: Shane Amante <[email-masked]>
Date: Tue, 26 Feb 2013 19:48:11 -0700

Russ,

> I think a good bit of the BGP policy model Shane wants would fit here...

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.  Good examples of this, (which have been discussed in the use-cases drafts), are:
a) placement of aggregate/tie-down/summarization/flow-spec routes, (at certain routers at certain places in the topology);
b) "route filters" applied to, for example, eBGP neighbor sessions inbound & outbound
   i) One example of the above is placement of RT-constraint-like filters on a per-neighbor basis in Route Reflectors, because 'downstream' PE software does not (likely, will never?) support RFC 4684.
   ii) Another example is application of "routing policy" at the border of your AS to filter what you receive and, at the same time, manipulate BGP attributes of those routes that are accepted, e.g.: set BGP communities, set LOCAL_PREF, etc.  Likewise, applying and outbound routing policy to filter what is allowed (intended!) to be announced to your neighbors.

FWIW, I believe that most, if not all, of the above use cases are discussed in: <http://tools.ietf.org/html/draft-keyupate-irs-bgp-usecases-01>[1] and, potentially, your draft as well.

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.

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 carries out associated action(s) (on I2RS'es behalf) which will manipulate the state of routing information carried by that process, e.g.: filtering incoming/outgoing routes, manipulating LOCAL_PREF, setting/stripping communities, etc.  And, of course, I2RS must do this is a completely transparent manner so that operators understand I2RS initiated this change vs. I2RS doing something "under the covers" that is non-obvious (or, worse, not visible) to operators.

Thanks,

-shane

[1] We missed the deadline to post an updated version of the draft with the updated "I2RS" WG name, but I promise we will do so when the I-D submission queue reopens.  We do not, at the moment, have plans to change the content of the draft, so please read through it now if you, or other WG members, have not already.

[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.  :-(

---

From: Aldrin Isaac <[email-masked]>
Date: Tue, 26 Feb 2013 22:31:29 -0500

Hi Russ,

I would think that the most bang for the buck is to start with defining an interface to C.  As you point out, messing with A is probably not a good place to start.  Changes at B, D & E will likely occur much less frequently than C, and probably infrequently enough to be handled via configuration -- I2RS interfaces for these could probably come as a phase-2.  C would seem to be where the most activity will be and the best place to start working.  Just 2 cents from the audience.

Best regards,
Aldrin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Feb 2013 10:20:47 +0100

> to build a routing table... Some specific points:

The present data model is just a skeleton, and additional YANG modules will be needed to define configuration and state data for individual routing protocols, route filters etc. On the other hand, the data model is quite specific in terms of how the components - protocols, routing tables and route filters - are allowed to interact. It is important to get this part right - also for the purposes of i2rs.

> by the routing table, but in that there is no feedback mechanism for

Actually, there is no such division. Static routes are represented using a special (pseudo)protocol of the type 'static'. A list of static routes is then a part of the configuration of this protocol, but static routes will also appear in a routing table, but being state data there. 

> being handled "differently" by the RIB.

They are not handled differently. They appear normally in routing table(s) with the 'source-protocol' attribute set to 'direct', and their appearance is triggered by the configuration of IP addresses on interfaces.

> be careful of in the I2RS design.

Whilst each routing protocol is connected to exactly one routing table per address family, the configuration may specify, for every routing table, one or more "recipient routing tables", so the routes may indeed be shared among multiple tables, subject to route filters.

> application/injection points added to give it the fullness I think we

Assuming that policies = route filters, the I-D specifies such points: route filters may be applied (i) between a routing protocol and its connected routing table, and (ii) between a routing table and its recipient routing table. The figure in sec. 4 shows an example.

Thanks, Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Feb 2013 10:31:59 +0100

> between the RIB and the FIB.

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:

http://www.ietf.org/mail-archive/web/netmod/current/msg06920.html

It turned ot that each of the two major router vendors uses these terms in a somewhat different sense, and neither of them is identical with how they are used in IETF documents. 

Lada

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 27 Feb 2013 10:50:16 +0100

Any (new) developed terminology by I2RS docs should refer to existing IETF RFCs.

E.g., 
FIB
=> initial term definition = RFC 1812, Appendix B, Glossary:
   Forwarding Information Base (FIB)
        The table containing the information necessary to forward IP
        Datagrams, in this document, is called the Forwarding
        Information Base.  At minimum, this contains the interface
        identifier and next hop information for each reachable
        destination network prefix. 

BTW: RFC 1812 is still the "default (IPv4) router model".

=> initial FIB data model = RFC 2096 (-> RFC 4292)

There are two options for I2RS:
- already existing definition, Y/N?
- existing definition sufficient, Y/N?
IF {Y,Y} THEN just refer
IF {N,-} THEN develop term definition
IF {Y,N} THEN develop derived definition (and refer to base term)

Albrecht

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Mittwoch, 27. Februar 2013 10:32
To: Russ White; Rob (William) Rice
Cc: [email-masked]
Subject: Re: [i2rs] Router Models

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Feb 2013 11:21:37 +0100

>        destination network prefix.

Right, but note that this is called RIB in Cisco docs:

http://blog.ioshints.info/2010/09/ribs-and-fibs.html

This definition also doesn't really answer the question whether FIB contains only active routes - I assume it does.

The BGP spec (RFC 4271) seems to imply the following definitions:

- RIB: data structures internal to each routing protocol instance;

- routing table: bag of routes obtained from different sources, possibly with multiple routes for the same prefix; 

- forwarding table = FIB: a cleaned-up table containing only selected active routes.

Lada

---

From: Ivan Pepelnjak <[email-masked]>
Date: Wed, 27 Feb 2013 11:32:26 +0100

Actually both RIB and FIB (or "routing table" and "CEF table") on a 
Cisco router would fit the description from RFC 1812 quoted below.

Ivan

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 27 Feb 2013 14:50:18 +0100

Ladislav,
I did just use "FIB" as an example term. I wasn't refering to any RIB-related text.
BTW: RFC 1812 provides NOT a definition for "RIB". DEFINITIONS are contained in APPENDIX B.
This does not preclude that the RFC contains DESCRIPTIONS of the term, however, you are looking for terminology definitions.

Appropriate references for such terms:
Firstly IETF RFCs.
Any vendor-specific information may not be referred in my understanding.

To Ivan:
Cisco was the primary author of RFC 1812, hence I would suspect not any major divergences ...:-)

-Albrecht

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivan Pepelnjak
Sent: Mittwoch, 27. Februar 2013 11:32
To: [email-masked]
Subject: Re: [i2rs] Router Models

Actually both RIB and FIB (or "routing table" and "CEF table") on a Cisco router would fit the description from RFC 1812 quoted below.

Ivan

On 27.02.2013 11:21 , Ladislav Lhotka wrote:
> - routing table: bag of routes obtained from different sources, 
> possibly with multiple routes for the same prefix;
>
>> IF {N,-} THEN develop term definition IF {Y,N} THEN develop derived 
>> definition (and refer to base term)
>>
>> Albrecht
>>
>>
>>> 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.
>>>

---

From: Bruno Rijsman <[email-masked]>
Date: Wed, 27 Feb 2013 15:31:45 +0000

RE> I've redone the diagram to account for some of the comments so far... 
RE> [...]
RE> Is this better? 

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

-- Bruno

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Feb 2013 11:24:51 -0800

Ok - then what you are describing as policy going in at point B is
what I've been thinking of as data to the protocol (not quite at A -
changing the data) - such as dynamically attaching a prefix to the
local router or changing a local link metric.  If you think of those
as policy, that's ok and helps reconcile.

I think we're in emphatic agreement that i2rs MUST NOT mess with the
data a protocol receives from its peers and the router itself does not
own.

Alia

---

From: Scott Whyte <[email-masked]>
Date: Wed, 27 Feb 2013 14:14:20 -0800

> [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/i…

Thanks for bringing up the uses cases you did for getting info out of
the RIB, its not something I considered very much.   Another use case
showing redistribution is the only solution to some problem (even
using I2RS's hopefully larger toolbox) would be helpful to understand
why we need it.  From Russ' diagram it seems you'd need I2RS to touch
things at D or E down towards the dataplane, and simultaneously it
would have to take state up from C (ok as defined) and push it over to
A for advertisement to the rest of the control plane, while possibly
receiving other state from remote clients. I think this simple diagram
can not handle that much state moving in so many directions and I'm
not sure I2RS should either.

-Scott