Subject: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

From: "Susan Hares" <[email-masked]>
Date: Thu, 12 Jun 2014 18:26:01 -0400

I've posted a version of white-i2rs-use-case-05 with the recommendations at the front of the document.  I look forward to additional comments.  I appreciate Tom Petch and Dean B.'s comments on these drafts. 

URL:    http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt

Sue Hares

---

From: t.petch <[email-masked]>
Date: Fri, 13 Jun 2014 12:49:19 +0100

---- Original Message -----
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>; "Edward Crabbe" <[email-masked]>
Sent: Thursday, June 12, 2014 11:26 PM

> I've posted a version of white-i2rs-use-case-05 with the
recommendations at the front of the document.  I look forward to
additional comments.  I appreciate Tom Petch and Dean B.'s comments on
these drafts.

Sue

I am flattered; I am not sure that I deserve such mention.

I am more interested in the use cases part of the I-D, seeing
requirements and info-model as the next stage when use cases are agreed,
and they look fine (perhaps /may Data Centers/many Data Centers/).

I note the reference to ISIS which I find significant.  My experience is
more of OSPF but appreciate that that is rare with Operators.  However,
both are Link State and so very different to BGP which makes me think
about the use of RIB.  The NETMOD routing-cfg started with RIBs, dropped
them and then reinstated them (after consulting with I2RS), whereas for
me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in
LSDB, which is very different in detail (as much research as Lada has
done across three differing platforms, I am not certain that the NETMOD
has sufficient routing expertise to get this perfect:-(.

I think you need a definition of RIB, perhaps by a Normative reference
to rib-info-model, but for me that leaves unclear the relationship
between routing instance, routing protocol and RIB, at least when you
get into requirements.

Likewise, this I-D is cast in terms of a table identifier and a route
process identifier, whereas routing-cfg has  routing-instance [name]
with router-id, ribs, interfaces, routing-protocols etc  I have a sense
of two divergent models of what a router is for all the discussions.

REQ1 last sentence should probably include removing process

REQ2 I think is about source-based routing but it does not quite say
that, rather reading as if source or destination routing were equally
valid options

REQ3 again the wording seems odd - I think you mean that traffic with a
given destination (or source?) prefix should be discarded, but that is
not what it says

REQ4 I find vague, as I do anything with the word policy in it:-(
Something concrete (communities, MED, ...) would help

REQ6 makes me wonder what is a RIB when it is not local

REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like
something more concrete.  Again, I wonder if it is technically possible
to present information in a consistent manner given the difference in
underlying concepts of protocols.

REQ9 - again all embracing and as such, probably impossible, at least as
written.  Limiting it just to BGP and a link-state protocol, again that
seems challenging.

REQ10 - policies again, and it is unclear who is doing the time
management.  Some configuration protocols do have timer-based
facilities, but not NETCONF; do you mean here that I2RS must have
functionality based on timers (e.g. between 08:00 and 17:00 EDT, route
this via Europe and Japan?)

Tom Petch

> URL:
http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt
>
> Sue Hares
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Jun 2014 14:11:35 +0200

> between routing instance, routing protocol and RIB, at least when you

Sounds like recurring deja vu:

- http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html

- http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html

Lada

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

---

From: "Russ White" <[email-masked]>
Date: Fri, 13 Jun 2014 09:06:25 -0400

> I note the reference to ISIS which I find significant.  My experience is
more of
> OSPF but appreciate that that is rare with Operators.  However, both are
Link
> State and so very different to BGP which makes me think about the use of
> RIB.  The NETMOD routing-cfg started with RIBs, dropped them and then
> reinstated them (after consulting with I2RS), whereas for me, RIBs are BGP
> (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is very
> different in detail (as much research as Lada has done across three
differing
> platforms, I am not certain that the NETMOD has sufficient routing
expertise
> to get this perfect:-(.

There are two different "RIBs," at least in theory -- vendor implementations
may vary. To try and separate things out, let's describe a few tables, see
if that's a complete description, and then try to name these things.

- There is the set of all the reachability information received by any given
process. I would correlate this to the BGP-RIB-IN, or the LSDB in OSPF or
IS-IS.

- There is the set of best paths determined by the particular process. I
would correlate this to the SPT in OSPF or IS-IS, and the BGP best path
table.

- There is the set of paths actually installed in the local device memory,
and off of which the local forwarding tables are built. Each process running
on the device installs reachability information into this table, and there
is some arbitration method within each implementation designed to determine
which process "wins," when there are multiple installs for the same
destination, as well as "callbacks" for when routes are removed, and even
perhaps "backup routes," and the like.

- There is the set of forwarding table entries actually used for forwarding
traffic. Note there may be two layers of these, but they typically include
mac header rewrites, tunnel headers, and the like -- none of which any of
the "ribs" described above would contain (they would only contain a next
hop, not the actual rewrite information).

If there are any I've missed, please feel free to add them in. This draft is
supposed to be addressing use cases that are centered on the third one above
in a "generic" way (not specific to some routing protocol, etc.).

> REQ1 last sentence should probably include removing process

I'm fine with including this, but I can't think of a use case off the top of
my head... 

> REQ2 I think is about source-based routing but it does not quite say that,
> rather reading as if source or destination routing were equally valid
options

It intends to say that both source and destination routing are equally valid
options from the perspective of installed stuff into the RIB (#3 above).

> REQ3 again the wording seems odd - I think you mean that traffic with a
given
> destination (or source?) prefix should be discarded, but that is not what
it
> says

This is akin to remote triggered black holes -- a route to interface null0,
which can be targeted either through the source (source routing) or the
destination.

> REQ4 I find vague, as I do anything with the word policy in it:-(
Something
> concrete (communities, MED, ...) would help

This isn't really MED (that would fall into the BGP use cases draft), but
rather mostly focused on setting the next hop, backup routes, source routes,
and other places where you might forward based on things like port numbers,
etc.

> REQ6 makes me wonder what is a RIB when it is not local

I suppose it could be remote in some way. Think of the RIB of a virtual
router that then installs routes using OpenFlow into a remote switch -- is
the RIB remote, or the FIB? I don't really know... I guess it might make
more sense just to take the word "local" out here.

> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like something
> more concrete.  Again, I wonder if it is technically possible to present
> information in a consistent manner given the difference in underlying
> concepts of protocols.

This is actually restricted to the RIB (#3 above) by the context of the
draft, but it might be useful to add some restrictive language here.

> written.  Limiting it just to BGP and a link-state protocol, again that
seems
> challenging.

Again, this is implied to be restricted to the RIB (#3 above) by the context
of the draft. Adding some restrictive language here might be useful, or it
might be overkill (your choice :-) ).

> REQ10 - policies again, and it is unclear who is doing the time
management.
> Some configuration protocols do have timer-based facilities, but not
> NETCONF; do you mean here that I2RS must have functionality based on
> timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and
Japan?)

Time based processing here generally means, "last route installed wins,
given all equal preferences otherwise," or perhaps, "time is the
tiebreaker." This area might need work, as this makes the final state
non-atomic (order dependent). The problem is there's no way to ensure
everyone is using different preference levels, etc. Any thoughts here
welcome.

:-)

Russ

---

From: Dean Bogdanovic <[email-masked]>
Date: Sun, 15 Jun 2014 13:06:08 +0000

Susan,

I like the new format much better. It makes the reading more clear from beginning. I disagree with REQ10. REQ10 implies that the i2rs will store data in persistent storage. 

I have another use case for the draft, mobile backhaul. Currently governments are preparing to release some new spectrum bands for public usage. It will be a very different approach, as the lease period will be significantly reduced from 15 years to hours. Idea is to use small cells with this new spectrum to respond to increasing demand from mobile users in that geographical area, like a sports, music venue or certain city areas that get very populated during certain peak hours. In such cases, mobile backhaul has to be able to respond to such increase in demand and that will require changing of forwarding policies in the backhaul. I2RS is a very good match for that task and following requirements should be listed: REQ01, REQ02, REQ07, REQ08, REQ09.

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 15 Jun 2014 16:52:09 -0400

Dean:

Please look at the 
http://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/

It provides the mobile backhaul use case.  If you want to suggest changes,
I'm a co-author.  

Sue 

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Sunday, June 15, 2014 9:06 AM
To: Susan Hares
Cc: t.petch; <[email-masked]>; Jeffrey Haas; Edward Crabbe; Russ White
Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

Susan,

I like the new format much better. It makes the reading more clear from
beginning. I disagree with REQ10. REQ10 implies that the i2rs will store
data in persistent storage. 

I have another use case for the draft, mobile backhaul. Currently
governments are preparing to release some new spectrum bands for public
usage. It will be a very different approach, as the lease period will be
significantly reduced from 15 years to hours. Idea is to use small cells
with this new spectrum to respond to increasing demand from mobile users in
that geographical area, like a sports, music venue or certain city areas
that get very populated during certain peak hours. In such cases, mobile
backhaul has to be able to respond to such increase in demand and that will
require changing of forwarding policies in the backhaul. I2RS is a very good
match for that task and following requirements should be listed: REQ01,
REQ02, REQ07, REQ08, REQ09.

Dean

On Jun 13, 2014, at 9:06 AM, "Russ White" <[email-masked]>
 wrote:

>> State and so very different to BGP which makes me think about the use 
>> of RIB.  The NETMOD routing-cfg started with RIBs, dropped them and 
>> then reinstated them (after consulting with I2RS), whereas for me, 
>> RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in 
>> done across three
> There are two different "RIBs," at least in theory -- vendor 
> implementations may vary. To try and separate things out, let's 
> describe a few tables, see if that's a complete description, and then try
to name these things.
> 
> - There is the set of all the reachability information received by any 
> given process. I would correlate this to the BGP-RIB-IN, or the LSDB 
> in OSPF or IS-IS.
> 
> - There is the set of best paths determined by the particular process. 
> I would correlate this to the SPT in OSPF or IS-IS, and the BGP best 
> path table.
> 
> - There is the set of paths actually installed in the local device 
> memory, and off of which the local forwarding tables are built. Each 
> process running on the device installs reachability information into 
> this table, and there is some arbitration method within each 
> implementation designed to determine which process "wins," when there 
> are multiple installs for the same destination, as well as "callbacks" 
> for when routes are removed, and even perhaps "backup routes," and the
like.
> 
> - There is the set of forwarding table entries actually used for 
> forwarding traffic. Note there may be two layers of these, but they 
> typically include mac header rewrites, tunnel headers, and the like -- 
> none of which any of the "ribs" described above would contain (they 
> would only contain a next hop, not the actual rewrite information).
> 
> If there are any I've missed, please feel free to add them in. This 
> draft is supposed to be addressing use cases that are centered on the 
> third one above in a "generic" way (not specific to some routing protocol,
etc.).
> I'm fine with including this, but I can't think of a use case off the 
> top of my head...
> 
>> valid
> It intends to say that both source and destination routing are equally 
> valid options from the perspective of installed stuff into the RIB (#3
above).
> This is akin to remote triggered black holes -- a route to interface 
> null0, which can be targeted either through the source (source 
> routing) or the destination.
> 
> This isn't really MED (that would fall into the BGP use cases draft), 
> but rather mostly focused on setting the next hop, backup routes, 
> source routes, and other places where you might forward based on 
> things like port numbers, etc.
> 
> I suppose it could be remote in some way. Think of the RIB of a 
> virtual router that then installs routes using OpenFlow into a remote 
> switch -- is the RIB remote, or the FIB? I don't really know... I 
> guess it might make more sense just to take the word "local" out here.
> 
>> something more concrete.  Again, I wonder if it is technically 
>> possible to present information in a consistent manner given the 
>> difference in underlying concepts of protocols.
> 
> This is actually restricted to the RIB (#3 above) by the context of 
> the draft, but it might be useful to add some restrictive language here.
> 
>> REQ9 - again all embracing and as such, probably impossible, at least 
>> as written.  Limiting it just to BGP and a link-state protocol, again 
>> that
> seems
>> challenging.
> 
> Again, this is implied to be restricted to the RIB (#3 above) by the 
> context of the draft. Adding some restrictive language here might be 
> useful, or it might be overkill (your choice :-) ).
> 
> Time based processing here generally means, "last route installed 
> wins, given all equal preferences otherwise," or perhaps, "time is the

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 16 Jun 2014 17:40:29 +0000

Susan,

	Following find my comments in re this document..

	General Comments.

	1) There is a need to better define what is meant by the "halfway point" between completely replacing the distributed control plane and configuring it all. It would seem to be that this "halfway point" is different based on what is being programmed. To that end it would be useful to call out higher level reqs some suggestions.

	2) Dissemination Scope of an I2RS Instruction Set ( Block of instructions intended to be atomic ) - An instruction set may be local or global in nature as it pertains to affected the distributed control plane when configured on a network element.

		a)  A locally scoped instruction set may configure routing state in the RIB for comparison purposes but that state may not be disseminated via the distributed control  plane. 

		b) A globally scoped instruction set must configure routing state in the RIB for comparison purposes and that state is available for dissemination subject to any other policy.

	3) Ephemeral/Persistent Scope of an I2RS Instruction Set

		a) Should the instruction set persist? What comes to mind for me are the "configuration" like changes i.e RT-C, FlowSpec . 

	4) Liveness/Safety Properties - Would like to see some discussion in re these items.

	5) Uses Cases - I believe addl use cases whose focus is on configuration like services would be desirable. As an ex.. RT-C..

	Specific Comments 

	C1 - P1 - Para 2

	..." Such a system would not interact...." The paragraph uses a routing and best path selection as an example. I assume that this not limited to this application but spans configuration like state etc....

	C2 - P3 -Para 1

	"This represents a "halfway point" ..." This needs a clearer definition, I would suggest wording regarding  how the distributed control plane will be augmented by the addition of I2RS

	C3 - P3 - Para 3 

	"...Each unique has been" Typo missing the word reqs.

	C4 - P3 - Para 5

	The reaction to Network Based Attacks may also include other actions i.e mirror, drop ...I assume you are not limiting the response to the attack to only re-direct.

	C5 - P4 - Para 4 1st Bullet

	Can the I2RS agent interact with other tools and get the desired info in this case available routes in the RIB? In general can I2RS provide a framework to collect data from multiple sources including directly from a router, RR, NM?

	C6 - P4 - Para 4 2nd Bullet

	Need to describe in how state learned via I2RS agent and state learned via distributed control plane interact across the set of applications ( See Above General Comments. )

	C7 - P5 - Para 4 3rd Bullet

	What is the ask for here? Is there a consistent definition of /dev/null being sought?

	C8 - P5 -Para 4 4th Bullet

	Not sure what this req is. Is it saying the policies configured via distributed control plane, local  and/or via I2Rs should have some form of id? Why is this needed if the policy no matter where it is learned is recorded in the running configuration??

	C10 - P5 - Para `1

	"In hub and spoke..." There are other hub/spoke solutions i.e Virtual Hub Rekhter et al...that do not rely on a centralized server.

Jim Uttaro
	
-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Dean Bogdanovic
Sent: Sunday, June 15, 2014 9:06 AM
To: Susan Hares
Cc: Jeffrey Haas; <[email-masked]>; Russ White; Edward Crabbe; t.petch
Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

Susan,

Dean

---

From: t.petch <[email-masked]>
Date: Tue, 17 Jun 2014 09:55:10 +0100

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Sent: Friday, June 13, 2014 1:11 PM
> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html

or, once again with feeling,

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

Tom Petch

> > something more concrete.  Again, I wonder if it is technically
possible

---

From: t.petch <[email-masked]>
Date: Tue, 17 Jun 2014 10:11:01 +0100

----- Original Message -----
From: "Russ White" <[email-masked]>
Sent: Friday, June 13, 2014 2:06 PM

<snip>
> There are two different "RIBs," at least in theory -- vendor
implementations
> A  - There is the set of all the reachability information received by
any given
> B - There is the set of best paths determined by the particular
process. I
> C - There is the set of paths actually installed in the local device
memory,
> D - There is the set of forwarding table entries actually used for
forwarding
> If there are any I've missed, please feel free to add them in. This
draft is
> in a "generic" way (not specific to some routing protocol, etc.).

Looks comprehensive.  D may vary, but I think that it is outside the
remit of I2RS.

It is B that I am doubtful about. It is fine for BGP or RIP, but I do
not see it for link state protocols, that is for me, the SPT is not a
table of routes, backup routes and so on but, well shortest paths.

Do you see an IS-IS, or OSPF, table comparable to the BGP table?

Tom Petch

<snip>

---

From: t.petch <[email-masked]>
Date: Tue, 17 Jun 2014 10:25:18 +0100

Part two, on the specific Q.

Tom Petch

----- Original Message -----
From: "Russ White" <[email-masked]>
Sent: Friday, June 13, 2014 2:06 PM

<snip>
> I'm fine with including this, but I can't think of a use case off the
top of
> my head...

Nor can I , but the first sentence talks of instal and remove, the last
sentence only of instal; I would like the two to be in line.

> > REQ2 I think is about source-based routing but it does not quite say
that,
valid
> options from the perspective of installed stuff into the RIB (#3
above).

I would reword it to say "source based routes, and destination based
routes" (unless you mean 'source-and-destination based routes')

> This is akin to remote triggered black holes -- a route to interface
null0,
> which can be targeted either through the source (source routing) or
the

Again, it is a matter of wording, I am guessing that what you mean is
"The ability to install a route for a given prefix to a null destination
...."

> This isn't really MED (that would fall into the BGP use cases draft),
but
> and other places where you might forward based on things like port
numbers,

OK, I did not really think MED but wanted something concrete:-)  Again,
adding a few words makes such a difference, such as

"The ability to interact with various policies configured on the
forwarding devices, such as by changing the next hop, backup routes and
such like, ...."

> I suppose it could be remote in some way. Think of the RIB of a
virtual
> more sense just to take the word "local" out here.

Yes, WFM

> > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like
something
> This is actually restricted to the RIB (#3 above) by the context of
the
> draft, but it might be useful to add some restrictive language here.

Yes please - I think that when you move from the context of a discussion
of a specific revision of a specific I-D on a WG mailing list to a
published I-D, then what was clear may become too vague to convey the
intended meaning

> Again, this is implied to be restricted to the RIB (#3 above) by the
context
> Time based processing here generally means, "last route installed
wins,

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Jun 2014 09:15:51 -0400

> Do you see an IS-IS, or OSPF, table comparable to the BGP table?

Without making specific comment on what *should* be present in the model,
there are three classes of clearly (IMO) useful information available from
the IGPs:

- The LSDB, which provides topology
- The TEDB
- The active route for a given destination at a given node as per SPF
  computations.

The third item is RIB-like and is the usual input to broader router
route-selection of an active path from multiple candidates.

The third item will probably have tie-in to our RIB models.

The first two items are places where abstractions in the model may make
sense, but there's also some benefit to simply exposing protocol mechanics
in the models.  The difference is "this is a type-X LSA in OSPF" vs. "this
is a link, this is a node, here are how they connect".

The abstraction is a bit more useful in an I2RS context.
The protocol mechanics are likely to be something that gets a protocol
specific module in the owning Working Group.

There will be interesting overlaps in the above two, and one of the more
interesting bits of coordination work I2RS will have.

-- Jeff

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 17 Jun 2014 13:28:16 +0000

Susan,

I sent you my comments to this draft back in March and this was your reply :-)
http://www.ietf.org/mail-archive/web/i2rs/current/msg01319.html

Dean

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jun 2014 11:23:42 -0400

Lada and Tom:  

You've convinced me that I should define the term RIB and FIB in the
draft-white-i2rs-use-case-05.  Would you like to suggest any text?
Otherwise give me a day or so to come up with text for this draft. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of t.petch
Sent: Tuesday, June 17, 2014 4:55 AM
To: Ladislav Lhotka
Cc: Jeffrey Haas; [email-masked]; Edward Crabbe; Susan Hares
Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Sent: Friday, June 13, 2014 1:11 PM

Tom Petch

possible

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jun 2014 11:35:16 -0400

Dean:

Thank you for those comments in March.  

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 9:28 AM
To: Susan Hares
Cc: t.petch; <[email-masked]>; Jeffrey Haas; Edward Crabbe; Russ White
Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

Susan,

I sent you my comments to this draft back in March and this was your reply
:-) http://www.ietf.org/mail-archive/web/i2rs/current/msg01319.html.

Thank you for the reply to my questions.  I apologize. I missed sending
you're a reply.  I will reply on that mail thread.  My co-authors and I are
working on a revision based on your comments. 

Dean

On Jun 15, 2014, at 4:52 PM, Susan Hares <[email-masked]> wrote:

> It provides the mobile backhaul use case.  If you want to suggest 
> changes, I'm a co-author.
> 
> Sue
> 
> I like the new format much better. It makes the reading more clear 
> from beginning. I disagree with REQ10. REQ10 implies that the i2rs 
> will store data in persistent storage.
> 
> governments are preparing to release some new spectrum bands for 
> public usage. It will be a very different approach, as the lease 
> period will be significantly reduced from 15 years to hours. Idea is 
> to use small cells with this new spectrum to respond to increasing 
> demand from mobile users in that geographical area, like a sports, 
> music venue or certain city areas that get very populated during 
> certain peak hours. In such cases, mobile backhaul has to be able to 
> respond to such increase in demand and that will require changing of 
> forwarding policies in the backhaul. I2RS is a very good match for 
> that task and following requirements should be listed: REQ01, REQ02,
REQ07, REQ08, REQ09.
>>> State and so very different to BGP which makes me think about the 
>>> use of RIB.  The NETMOD routing-cfg started with RIBs, dropped them 
>>> and then reinstated them (after consulting with I2RS), whereas for 
>>> me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent 
>>> in LSDB, which is very different in detail (as much research as Lada 
>>> has done across three
>> differing
>> - There is the set of all the reachability information received by 
>> any given process. I would correlate this to the BGP-RIB-IN, or the 
>> LSDB in OSPF or IS-IS.
>> 
>> typically include mac header rewrites, tunnel headers, and the like 
>> -- none of which any of the "ribs" described above would contain 
>> (they would only contain a next hop, not the actual rewrite information).
>> 
>>> that, rather reading as if source or destination routing were 
>>> equally valid
>> options
>> 
>> It intends to say that both source and destination routing are 
>> equally valid options from the perspective of installed stuff into 
>> the RIB (#3
> above).
>> 
>>> REQ9 - again all embracing and as such, probably impossible, at 
>>> least as written.  Limiting it just to BGP and a link-state 
>>> protocol, again that
>> seems
>>> challenging.
>> 
>> wins, given all equal preferences otherwise," or perhaps, "time is 
>> the tiebreaker." This area might need work, as this makes the final 
>> state non-atomic (order dependent). The problem is there's no way to 
>> ensure everyone is using different preference levels, etc. Any 
>> thoughts here welcome.
>> 
>> :-)
>> 
>> Russ
>>

---

From: t.petch <[email-masked]>
Date: Tue, 17 Jun 2014 16:29:51 +0100

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Russ White" <[email-masked]>; "'Susan Hares'" <[email-masked]>;
<[email-masked]>; "'Jeffrey Haas'" <[email-masked]>; "'Edward Crabbe'"
<[email-masked]>
Sent: Tuesday, June 17, 2014 2:15 PM
Subject: Re: tables was: Re: [i2rs] draft-white-i2rs-use-case-05.txt has
been posted

> interesting bits of coordination work I2RS will have.

Jeff

We have just got a netmod-isis draft
draft-litkowski-netmod-isis-cfg-00.txt
and I look for items of the third type, and at first sight, I do not see
them, just as I cannot recall seeing them in SMI models, either
standards-based or proprietary (unlike the LSDB).  Of course
they can be added but ....
well, I have said enough about it.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Tue, 17 Jun 2014 16:32:42 +0100

Sue

Probably best to do it yourself.  I did offer a reprise of previous IETF
work in

but it did not gain traction in NETMOD, so I would not expect it to
here.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'t.petch'" <[email-masked]>; "'Ladislav Lhotka'"
<[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>; <[email-masked]>; "'Edward
Crabbe'" <[email-masked]>
Sent: Tuesday, June 17, 2014 4:23 PM
Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

> > > additional comments.  I appreciate Tom Petch and Dean B.'s
comments
> on
> > > them and then reinstated them (after consulting with I2RS),
whereas
> for
> in
> equally
> > > given destination (or source?) prefix should be discarded, but
that
> is
> least as

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Jun 2014 17:45:28 +0200

Hi Sue,

as for RIB, I’d suggest to use the definition from draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2), or at least one that’s compatible with it. We actually agreed on this definition previously with the guys working on the RIB info model.

Thanks, Lada

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jun 2014 11:50:36 -0400

Lada:

Thanks for the pointer to text. 

Sue Hares 

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 11:45 AM
To: Susan Hares
Cc: t.petch; Jeffrey Haas; [email-masked]; Edward Crabbe
Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

Hi Sue,

as for RIB, I'd suggest to use the definition from
draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2), or at least one
that's compatible with it. We actually agreed on this definition previously
with the guys working on the RIB info model.

Thanks, Lada

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jun 2014 11:53:02 -0400

Tom: 

Thank you for the pointer to your earlier message.  What do you think of
Lada's suggestion of 
"draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2)"? 

Sue 

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 11:33 AM
To: Susan Hares; 'Ladislav Lhotka'
Cc: 'Jeffrey Haas'; [email-masked]; 'Edward Crabbe'
Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

Sue

but it did not gain traction in NETMOD, so I would not expect it to here.

Tom Petch

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'t.petch'" <[email-masked]>; "'Ladislav Lhotka'"
<[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>; <[email-masked]>; "'Edward Crabbe'"
<[email-masked]>
Sent: Tuesday, June 17, 2014 4:23 PM
Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

comments
whereas
that

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Jun 2014 12:50:34 -0400

> draft-litkowski-netmod-isis-cfg-00.txt

Thanks, I'll add it to my reading list.

> they can be added but ....

Already present, but not necessarily in the IGP MIBs:
   inetCidrRouteProto OBJECT-TYPE
       SYNTAX     IANAipRouteProtocol
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
              "The routing mechanism via which this route was learned.
               Inclusion of values for gateway routing protocols is
               not intended to imply that hosts should support those
               protocols."
       ::= { inetCidrRouteEntry 9 }

Multiple route candidates don't show up in this sort of MIB due to the
excruciating details of the abstract indices. (AKA "why we don't want to do
SNMP for this stuff any more".)

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Jun 2014 13:01:35 -0400

Jeff: 
+1 on adding  netmod-isis-cfg-00.txt to my reading list.    +1! On the SNMP
and MIB indexes. 
Sue 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 12:51 PM
To: t.petch
Cc: Jeffrey Haas; Russ White; 'Susan Hares'; [email-masked]; 'Edward Crabbe'
Subject: Re: tables was: Re: [i2rs] draft-white-i2rs-use-case-05.txt has
been posted

> and I look for items of the third type, and at first sight, I do not 
> see them, just as I cannot recall seeing them in SMI models, either 
> standards-based or proprietary (unlike the LSDB).  Of course they can 
> be added but ....

-- Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jun 2014 11:15:26 +0200

> they can be added but ....

This is provided already by the core "ietf-routing" module's RPC method "active-route". The ISIS module properly augments the definition of this RPC with ISIS-specific route attributes.

Lada

---

From: t.petch <[email-masked]>
Date: Thu, 19 Jun 2014 10:19:06 +0100

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'t.petch'" <[email-masked]>; "'Ladislav Lhotka'"
<[email-masked]>
Cc: "'Jeffrey Haas'" <[email-masked]>; <[email-masked]>; "'Edward
Crabbe'" <[email-masked]>
Sent: Tuesday, June 17, 2014 4:53 PM

Sue

I lost the argument against that definition on the NETMOD list so I
expect I would lose it again on the I2RS list:-(

But I would commend to you the taxonomy of Russ as in
http://www.ietf.org/mail-archive/web/i2rs/current/msg01794.html
where he talks of two different RIBs but has yet to say which they are;
for me, it is the one I tagged A that is a RIB.

Lada would I think be closer to C, but Lada's definition allows multiple
RIBs per address family as, sort of, does
draft-ietf-i2rs-rib-info-model, which Russ does not yet mention.

Then again the BGP RFC have a clear view of a RIB which for me is A.

So, I think that achieving consensus on what a RIB is and is not is the
biggest challenge facing I2RS and that understanding I-Ds will be more
difficult without it.

Tom Petch

here.
> Cc: "'Jeffrey Haas'" <[email-masked]>; <[email-masked]>; "'Edward
Crabbe'"
> > > > LSDB, which is very different in detail (as much research as
Lada
> > has
> > > > between routing instance, routing protocol and RIB, at least
when
> > you
> > > > with router-id, ribs, interfaces, routing-protocols etc  I have
a
> > sense
> > > > to present information in a consistent manner given the
difference
> > > > written.  Limiting it just to BGP and a link-state protocol,
again

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jun 2014 11:53:12 +0200

> expect I would lose it again on the I2RS list:-(

Actually, you didn’t lose that argument in NETMOD! As you know, the routing-cfg draft then had been using the term “routing table” for some time. However, an action item from IETF 87 was "to harmonize things with the information model defined by the I2RS working group” [1]. One of the results of this harmonisation was the change “routing table” -> “RIB”.

IMO, whatever names are chosen, it is important to define the terms properly. I understand Sue’s proposal aims at this direction, and I certainly hope it won’t lead to a de-harmonisation with NETMOD terms.

Lada

[1] http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod