Subject: [i2rs] RIB definition ...

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 15:13:27 +0100

Hi,

As we have seen today I2RS is scoped to interface with RIB. Great. But
what is the precise definition of RIB here ? Are we talking about
currently known RIBs or is the RIB definition yet to be defined. I
think it should be something defined now as pretty much all other work
will depend on it. I bet everyone in the room has different opinion on
it ;)

Example:

Assume I have invented a routing protocol which routes based on tuple
of dst IP address + port number. (Latency sensitive applications go on
different links that non time sensitive ones).

Is I2RS effort going to help me to push such routing data to the box's
RIB or not ? Note that I am not talking about pushing bunch of ACLs to
100s of my boxes doing PBR.

Thx,
R.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Mar 2013 10:22:08 -0400

> what is the precise definition of RIB here ? Are we talking about

I already raised pretty much the same question before:

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

I think one of the initial documents (architecture?) should include a detailed terminology section.

Lada

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 15:30:28 +0100

Hi Ladislav,

Yes I think this is a crux of this WG. I saw your mail in the past but
no precise answer from anyone ;)

Moreover even if one provides a RIB definition on one box today how do
we make it extensible so new network applications can be deployed on
it tomorrow.

Worse how do we accomplish consistent RIBs being supported across
multiple vendors ? Otherwise I can't see how read/write of any data
can be abstracted for network wide services provisioning using I2RS.

Regards,
R.

---

From: Scott Whyte <[email-masked]>
Date: Thu, 14 Mar 2013 07:32:05 -0700

> 100s of my boxes doing PBR.

Why do we need to go beyond defining an interface to the RIB to make 
your use case work?

-Scott

-- 
People who are essentially without the power to implement their ideas in 
the real world must leverage the power of their reputations.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 15:34:40 +0100

Hi Scott,

> Why do we need to go beyond defining an interface to the RIB to make your
> use case work?

I am talking precise about that definition of RIB interface. Not how
the RIB works in given vendor of network element. That is
implementation detail.

Basically a list of values one can write or read to/from RIB. Have you
seen any document with such list yet ?

Cheers,
R.

---

From: Scott Whyte <[email-masked]>
Date: Thu, 14 Mar 2013 07:41:14 -0700

> seen any document with such list yet ?

So we agree that what a RIB looks like is out of scope, and we need to 
insure extensibility beyond proposed use cases for the actual RIB 
interface?  If so I think the group is well on track to get there, as we 
grind through use cases and existing data models.

-Scott

---

From: Russ White <[email-masked]>
Date: Thu, 14 Mar 2013 10:44:55 -0400

No, but I did try to address at least a partial list in one of the use cases draft. I think this would really entail building a data model for "the entity officially known as the rib." Is the current YANG model a good solution to the question? It seems like we should answer that question before writing another one.

I suspect we'll need either need to extend an existing ones to get where we want? 

I think the right place to start might be to explicitly include the objects that need to be manipulated in each use case.

Maybe we need a "standard set" of things that need to be included in each use case? 

Thoughts?

:-)

Russ

<><
[email-masked]
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 15:46:11 +0100

I think we agree that RIB elements for read and write must be clearly
defined. And should be extensible.

But is RIB abstraction sufficient for I2RS ?

For example as we know each VRF contains it's own RIB (different table
id). So protocol must be able to also encode which RIB we are talking
to.

Further who will instantiate the VRF in this case ? Will I2RS be able
to create a RIB instance on the fly ? How will we attach such RIB
instance to interfaces ? There is dozens of details here without which
I am afraid we can't go productively forward.

Best,
R.

On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte <[email-masked]> wrote:
> insure extensibility beyond proposed use cases for the actual RIB interface?
> If so I think the group is well on track to get there, as we grind through
> use cases and existing data models.
>
> -Scott
>
>>
>> Cheers,
>> R.
>>
>
>
> --
> People who are essentially without the power to implement their ideas in the
> real world must leverage the power of their reputations.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Mar 2013 10:53:23 -0400

> id). So protocol must be able to also encode which RIB we are talking

Well, according to RFC 4271, RIB (i.e., Adj-RIBs, Loc_RIB and Adj-RIBs-Out) are data structures internal to a BGP speaker. I suspect that what I2RS aims at interacting with is what 4271 calls "Routing Table".

Lada

---

From: Scott Whyte <[email-masked]>
Date: Thu, 14 Mar 2013 07:58:40 -0700

> I am afraid we can't go productively forward.

I guess I'm confused now on what you consider propietary implementation 
detail of a RIB, but I'll assume you are still talking strictly about a 
RIB abstraction and increasing its scope to multiple RIBs communicating 
with a single I2RS agent.

Not sure about dozens of details, but your four good questions above all 
seem to revolve around a single issue, handling of multiple RIBs, which 
I think is important to have as a use case.

-Scott

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 15:58:50 +0100

Yes from what I understand I2RS aims to interact with "global RIB" aka
inet.X tables and ACLs. Not to protocol local RIBs.

Hence my question what actual data can be read and written to such
RIBs by I2RS.

Rgs,
R.

> On Thu, Mar 14, 2013 at 3:53 PM, Ladislav Lhotka <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 16:02:00 +0100

My main question is what L2-L4 fields for the packet lookup I can
program to the 'RIB" by I2RS. Very precise and simple.

The use case for multiple RIBs is just being shown in the room. L3VPN
PE auto-provisioning ;)

Best,
R,.

On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte <[email-masked]> wrote:
> detail of a RIB, but I'll assume you are still talking strictly about a RIB
> abstraction and increasing its scope to multiple RIBs communicating with a
> single I2RS agent.
>
> seem to revolve around a single issue, handling of multiple RIBs, which I
> think is important to have as a use case.
>
> -Scott
>
>
>
>>
>> Best,
>> R.
>>
>>
>>>>> your
>>> interface?
>>> the

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 14 Mar 2013 15:09:18 +0000

On 3/14/13 10:44 AM, "Russ White" <[email-masked]> wrote:

>
>No, but I did try to address at least a partial list in one of the use
>cases draft. I think this would really entail building a data model for
>"the entity officially known as the rib." Is the current YANG model a
>good solution to the question? It seems like we should answer that
>question before writing another one.

There is a current YANG draft trying to cover the most basic of a routing
table

http://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/?include_text
=1

>I think the right place to start might be to explicitly include the
>objects that need to be manipulated in each use case.
>

"Cast a wide net for every possible use case" and "Narrow requirements to
bite sized chunks"

The same principal can be used to define the RIB as well.:-) Start with a
vanilla RIB definition consisting of basic common objects, but allow it to
be extended for fancy applications.

Yi

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 16:13:59 +0100

I have no shadow of a doubt that you can define what needs to be defined.

I am however very interested to see that I2RS WG members will agree on
those things seamlessly :)

R.

---

From: Russ White <[email-masked]>
Date: Thu, 14 Mar 2013 11:14:15 -0400

I wouldn't frame the question in terms of the packet header but the routing table... I don't know that the answer comes out different, but... :-)

That said, I think a good base set would be:

- Dest IP Address
- Next hop IP address
- Outbound interface
- Admin distance
- Some form of tags
- Table ID

We've talked about the ad,in distance being more like a community string than an integer (having multiple parts so you can have several types of metrics here), but I don't know how useful that would be. I'm all for thinking past the immediate need and leaving doors open for unthought of things, though.

There's also the back channel out of the rib to consider -- specifically, things like, "your route was just overwritten by another process," "a route was just redistributed to you," "the next hop for this route just went away," "this connected route just failed," and other related stuff.

But I think we might need to get the use cases to give us what information they need, and work build a good list from that. Then we can ask the question, "is there a model that fits already?"

:-)

Russ

<><
[email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Mar 2013 11:15:02 -0400

> inet.X tables and ACLs. Not to protocol local RIBs.

Right, but JUNOS documentation calls these inet.X routing tables while in Cisco IOS terms a routing table already contains only active routes.

Lada

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 16:17:32 +0100

Hi Russ ...

For me the base set is completely not sufficient for any of the
application I would use I2RS for.

As example: it is missing match on VLAN, set MPLS VPN label, set MPLS
transport label.

r.

> On Thu, Mar 14, 2013 at 4:14 PM, Russ White <[email-masked]> wrote:
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 14 Mar 2013 15:20:08 +0000

In some use cases, Interface to Routing System can be safely interpreted as "interface to RIB (Routing Information Base)". However,  for the VPLS use case, such interpretation is not much accurate. For example, a controller needs to create a VPLS instance and bound a given port to that VPLS instance, can this write operation be interpreted as a write operation to the "RIB"? In addition, an ACL table w/r operation can not be interpreted as w/r an operation to RIB as well. 

Best regards,
Xiaohu 

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2013年3月14日 23:02
到: Scott Whyte
Cc: [email-masked]
主题: Re: [i2rs] RIB definition ...

Best,
R,.

---

From: Russ White <[email-masked]>
Date: Thu, 14 Mar 2013 11:20:52 -0400

Vlan, I think, might fit into a table ID... ??

MPLS tag I would include under next hop in general (take out IP)... ?

:-)

Russ

<><
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 16:24:11 +0100

> Vlan, I think, might fit into a table ID... ??

Well it depends who binds this VLAN to a table ID on the network element.

> MPLS tag I would include under next hop in general (take out IP)... ?

Well for transport MPLS analogy yes, but for application MPLS label
(example VPN label) this is not really a next hop property.

r.

---

From: Russ White <[email-masked]>
Date: Thu, 14 Mar 2013 12:47:49 -0400

Actually, several folks talked at lunch, and defining the data model first might be precisely the wrong thing to do... Let me just throw it out for discussion--

Is it better to define the information needed to forward a packet as a data model, so we simply leave the problem of defining a "rib," etc., as something we can ignore? In other words, if we start from the packet end, do we simplify our problem in a major way?

:-)

Russ

<><
[email-masked]

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 14 Mar 2013 17:34:55 +0000

and then associate the right label blocks ( BGP Flavor ) which is derived by other info as to the definition of the context.... I think it may be better to have the controller inform the distributed protocol as to the action to be taken..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, March 14, 2013 11:20 AM
To: Robert Raszuk; Scott Whyte
Cc: [email-masked]
Subject: Re: [i2rs] RIB definition ...

Best regards,
Xiaohu 

Best,
R,.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 13:43:02 -0400

Rob,

Yes - there is lots of work to do.  Exactly what is needed in the
information models is something I'm hoping the use-cases will help
with.

The framework gives a first concept of the type of data that I thought
would describe a route for the RIB (also RIB layer - not just
IPv4/IPv6 RIB).

The case of routing on destination IP address plus an L4 port is
different, of course - that is asking for NEW functionality in the
forwarding plane from what is commonly there beyond support via
ACLs/PBRs.   I don't personally see i2rs as providing the necessary
translation mechanism - but that's with the WG chair hat off.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 13:46:35 -0400

I do see setting an MPLS label as a characteristic of a next-hop.  The
concern will be describing capabilities reasonably without a rat-hole.

This is doing L3 routing - so VLAN matching seems out; while there may
be PWE3 or L2VPN type use-cases eventually, I've not seen them yet.

Alia

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 18:50:20 +0100

> concern will be describing capabilities reasonably without a rat-hole.

As I said transport label yes .. VPN label no. Also how about IP GRE
/IPv6 and other encapsulations ? This is prerequisite for any service
or application today.

> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet.

I think you have missed my point. I am talking about L3. Imagine L3VPN
PE ... I want to configure the service using I2RS ... you have had use
case for this even presented today. So I must match on the incoming
interface (physical or logical) to make sure propor RIB table is used
for packet lookup.

Best regards,
R.

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 14 Mar 2013 13:53:49 -0400

I think it depends if and/or how we decouple traffic-bearing interfaces 
from the RIB... Do we want the information model to represent 
ingress/egress labels, VLANs, etc as fields in the RIB, attributes of 
the RIB (or of various tables), or attributes of interfaces? Is the 
information model the same for ingress vs egress traffic?

I have opinions, of course. But I'm open-minded.

Cheers,
-Benson

---

From: Dave Israel <[email-masked]>
Date: Thu, 14 Mar 2013 13:58:44 -0400

> interface (physical or logical) to make sure propor RIB table is used

Well, arguably, the routing table you're in is already determined by the 
inbound interface.  Your inbound interface is already part of a 
vrf/logical system/etc.  You might be able to use i2rs to request that 
your interface be moved from one routing table to another, but that 
sounds more like a job for NetCONF-style configuration than I2RS-style 
ephemeral routing table manipulation.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 19:00:00 +0100

Hi Benson,

I think this is excellent point.

And as said I also think this is extremely important to move forward.

In other words I am just afraid that when junisco is talking about RIB
they are talking about current global RIB model which obviously is
completely not sufficient to realize/provision network wide services
by I2RS protocol alone.

So I just hope that we define base interface to network element which
will allow to address all use cases (even those already documented by
the drafts on the table).

Best,
R.

> On Thu, Mar 14, 2013 at 6:53 PM, Benson Schliesser <[email-masked]> wrote:
> I think it depends if and/or how we decouple traffic-bearing interfaces from
> the RIB... Do we want the information model to represent ingress/egress
> labels, VLANs, etc as fields in the RIB, attributes of the RIB (or of
> various tables), or attributes of interfaces? Is the information model the
> same for ingress vs egress traffic?
>
>>>> I wouldn't frame the question in terms of the packet header but the
>>>> routing table... I don't know that the answer comes out different, but...
>>>> :-)
>>>>
>>>> We've talked about the ad,in distance being more like a community string
>>>> than an integer (having multiple parts so you can have several types of
>>>> metrics here), but I don't know how useful that would be. I'm all for
>>>> thinking past the immediate need and leaving doors open for unthought of
>>>> things, though.
>>>>
>>>> There's also the back channel out of the rib to consider --
>>>> specifically, things like, "your route was just overwritten by another
>>>> process," "a route was just redistributed to you," "the next hop for this
>>>> route just went away," "this connected route just failed," and other related
>>>> stuff.
>>>>
>>>> But I think we might need to get the use cases to give us what
>>>> information they need, and work build a good list from that. Then we can ask
>>>> the question, "is there a model that fits already?"
>>>>
>>>> :-)
>>>>
>>>> Russ
>>>>
>>>>
>>>> <><
>>>> [email-masked]
>>>>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 14:00:52 -0400

In-line

> /IPv6 and other encapsulations ? This is prerequisite for any service

[Alia] For the VPN label, I think that depends - I could see a
VPN-specific RIB that outputs the VPN label and transport label.  And
YES, of course, other encapsulations are needed and of interest.
There's capability negotiation.

In the Framework draft Sec 4.1.1:
"      Encapsulation:   Associated with each primary next-hop can be
         details on the type of encapsulation for the packet.  Such
         encapsulation could be MPLS, GRE, etc. as supported by the
         router.
"

WRITE UP YOUR USE-CASES and DESCRIBE what functionality you need!

> interface (physical or logical) to make sure propor RIB table is used

[Alia] Sure - you need to be able to write to different tables in the
RIB - of course.  Look in the framework draft - in Sec 4.1.1
"   Route Table Context:   There can be different route table contexts in
      the RIB.  Examples include multiple protocols (e.g.  IPv4, IPv6),
      multiple topologies, different uses, and multiple networks (e.g.
      VRF tables for VPNs).  Appropriate application-level abstractions
      are required to describe the desired route table context.
"

Best Regards,
Alia

P.S.  How was the remote participation?

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 19:02:58 +0100

Ahhh so you are stating that to provision services on the network in
vendor neutral way I will not be able to use I2RS by design ?

Is this already agreed point that NETCONF (or any other form of
configuration) will be required anyway in addition to I2RS for any
complete service provisioning ?

Thx,
R.

> On Thu, Mar 14, 2013 at 6:58 PM, Dave Israel <[email-masked]> wrote:
>
> inbound interface.  Your inbound interface is already part of a vrf/logical
> system/etc.  You might be able to use i2rs to request that your interface be
> moved from one routing table to another, but that sounds more like a job for
> NetCONF-style configuration than I2RS-style ephemeral routing table
> manipulation.
>
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 14:03:43 -0400

On the matching, I was specifically talking about matching on VLAN; of
course, if a VLAN defines an L3 interface that feeds into a particular
RIB specific to that interface, that is - to my mind/abstractions -
different from matching on a VLAN tag.

YES - the results might be similar, but less generality.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 14:03:58 -0400

Of course not

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 14:05:35 -0400

I should add

if we don't have WRITTEN USE-CASES that describe the needs in terms of
information and functionality and the purpose and so on, then YES -
you are likely to see a much narrower scope that may not meet your
specific use-cases.

Alia

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 19:06:30 +0100

Which one is the "Of course not" ?

Thx,
R.

PS. Remote participation in I2RS was just great. Pity that only Ed's
slides were posted timely before the meeting.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 14 Mar 2013 14:12:08 -0400

> Which one is the "Of course not" ?

[Alia] The idea that it is somehow pre-decided that configuration via
Netconf or a different protocol will be required.

> slides were posted timely before the meeting.

[Alia] I'm glad that the remote participation went well.  I was a bit
concerned since we had no jabber comments during the discussions.
We'll do better on slides availability next time.  I did send out the
functional analysis as email to the list well in advance to try and
kickstart the conversation.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 19:12:36 +0100

I think L3VPN PE application I am referring too is already contained
in http://tools.ietf.org/html/draft-hu-i2rs-overlay-use-case-00

Thx,
R.

---

From: t.petch <[email-masked]>
Date: Thu, 14 Mar 2013 18:09:53 +0000

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: <[email-masked]>; "Scott Whyte" <[email-masked]>
Sent: Thursday, March 14, 2013 2:58 PM

> inet.X tables and ACLs. Not to protocol local RIBs.

In which case, perhaps that is interacting with the FIB and not the
RIBs, that is a RIB is the database of information that an instance of a
routing protocol needs to do what it does, such as calculating the best
route for some meaning of the word best.  For OSPF, that would be a
database of LSAs, for BGP it would include MED, LOCAL_PREF and so on, as
well s AFI/SAFI, next hop etc.

So, not to protocol local RIBs, because RIBs are protocol local:-)

Tom Petch

> > Well, according to RFC 4271, RIB (i.e., Adj-RIBs, Loc_RIB and
Adj-RIBs-Out) are data structures internal to a BGP speaker. I suspect
that what I2RS aims at interacting with is what 4271 calls "Routing
Table".
interface?

---

From: Dave Israel <[email-masked]>
Date: Thu, 14 Mar 2013 14:26:06 -0400

> complete service provisioning ?

I don't think there are many already agreed points anywhere outside the 
charter itself.  So don't worry if I think something you don't like; I'm 
at least as likely to be wrong as anybody else.

Still, I am inclined to think that RIB manipulation is separate from 
permanent configuration.  And while you could run a service by 
hand-configuring your RIBs everywhere with I2RS (with either a 
persistent I2RB state or reconfiguration on reboot from the controller), 
it doesn't seem like the *right* way to do it.  It makes more sense to 
establish your normal behavior through the existing configuration 
mechanisms (CLI, NETCONF, etc), and then use I2RS to manipulate it.

-Dave

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 19:34:17 +0100

Actually I am not arguing against permanent vs ephemeral states on
network element in fact I agree it is needed.

The only worry is that once you talk about two sort of provisioning
channels for a given service - perhaps independent from each other -
there will always be need for synchronization.

Example: I can not modify/add/delete entries in RIB context X if this
context X was not yet provisioned .. those classic sort of issues.

Thx,
R.

> On Thu, Mar 14, 2013 at 7:26 PM, Dave Israel <[email-masked]> wrote:
>
> charter itself.  So don't worry if I think something you don't like; I'm at
> least as likely to be wrong as anybody else.
>
> hand-configuring your RIBs everywhere with I2RS (with either a persistent
> I2RB state or reconfiguration on reboot from the controller), it doesn't
> seem like the *right* way to do it.  It makes more sense to establish your
> normal behavior through the existing configuration mechanisms (CLI, NETCONF,
> etc), and then use I2RS to manipulate it.
>
> -Dave
>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 14 Mar 2013 20:10:59 +0000

Is i2rs intended to be an API between provisioning system and a router/network? If yes, then why wouldn't it include the interface-to-routing table association?

Maria

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave Israel
> Sent: Thursday, March 14, 2013 2:26 PM
> To: Robert Raszuk
> Cc: [email-masked]

---

From: Dave Israel <[email-masked]>
Date: Thu, 14 Mar 2013 16:16:26 -0400

> Is i2rs intended to be an API between provisioning system and a router/network? If yes, then why wouldn't it include the interface-to-routing table association?

I'd disagree with your first statement. I don't believe that I2RS is 
intended to be an API to connect a provisioning system to a 
router/network.  It is intended to be an interface through which the RIB 
of a router can be directly manipulated.  A provisioning system might be 
one use case of such an interface, but I would not call it the intent of 
I2RS.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 14 Mar 2013 20:31:32 +0000

Dave,

What are the intended use cases for i2rs? 

Maria

> Sent: Thursday, March 14, 2013 4:16 PM
> To: [email-masked]
> > Is i2rs intended to be an API between provisioning system and a
> router/network? If yes, then why wouldn't it include the interface-to-
> routing table association?
>

---

From: Mach Chen <[email-masked]>
Date: Thu, 14 Mar 2013 20:54:38 +0000

Here is another draft that intends to cover the VN (VLAN, L2VPN, L3VPN, etc.) and VC (TE LSP, PW, etc.) applications

http://tools.ietf.org/html/draft-hares-use-case-vn-vc-00

Best regards,
Mach

________________________________________
From: [email-masked] [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Friday, March 15, 2013 2:12
To: Alia Atlas
Cc: Dave Israel; [email-masked]
Subject: Re: [i2rs] RIB definition ...

Thx,
R.

---

From: Dave Israel <[email-masked]>
Date: Thu, 14 Mar 2013 17:01:05 -0400

> What are the intended use cases for i2rs?

I think we're all here to come up with those.  The charter lists the 
following:

    o Interactions with the Routing Information Base (RIB). Allowing read
    and write access to the RIB, but no direct access to the Forwarding
    Information Base (FIB).

    o Control and analysis of the operation of the Border Gateway Protocol
    (BGP) including the setting and activation of policies related to
    the protocol.

    o Control, optimization, and choice of traffic exit points from
    networks based on more information than provided by the dynamic
    control plane.

    o Distributed reaction to network-based attacks through rapid
    modification of the control plane behavior to reroute traffic for
    one destination while leaving standard mechanisms (filters, metrics,
    and policy) in place for other routes.

    o Service layer routing to improve on existing hub-and-spoke traffic.

    o The ability to extract information about topology from the network.

    Injection and creation of topology will not be considered as an
    initial work item.

Some use cases I can come up with for such a system include:

* Polling the state of the network to determine the exact path the RIB 
believes a packet should take, edge to edge.

* Traffic engineering by identifying an overloaded link and overriding 
the next hop for some subset of traffic.  Or even more generalized 
traffic engineering: an autonomous controller that uses analytics to 
determine what endpoints currently need the most bandwidth and 
automatically allocate bandwidth to those applications, whether across 
the backbone or across the datacenter.

* Setting up policy routing for traffic matching a particular 
application to optimize performance; for example, pulling best-effort 
traffic to a longer path when load on a link is causing jitter in real 
time media.

* Finding routes that are not active in the RIB, due to higher 
administrative distance, and overriding that decision.  For example, 
imagine a situation where you are running OSPF and RIP on a router. 
Among other things, you receive a default route and another network, say 
192.0.2.0/24, via both protocols.  You want to believe the RIP route for 
192.0.2.0/24 and OSPF for default.  Using I2RS, you set a lower distance 
for only the RIP route.  (There's lots of mechanics with this one, 
including I2RS telling you when the table has changed, so you can 
intercede again if you have to.)

* Attack mitigation by routing traffic to a victim IP to either the bit 
bucket or a middlebox that can filter bad traffic from good.

* Modifying preference on BGP routes in real time to balance traffic 
ratios, prefer financially less expensive links, manipulate your 95th 
percentile traffic rate, etc.

* Tracking a route oscillation or similar event as it happens to help 
determine the source.

I'm sure there are plenty more...

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 18 Mar 2013 13:12:23 -0700

Hi Alia,

> translation mechanism - but that's with the WG chair hat off.

What makes IPDA+L4 port any different in terms of forwarding plane
than what is offered by ACLs/PBRs.  Isn't that just a subset of what
is already offered in the forwarding plane?

Anoop

---

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Mar 2013 05:00:16 -0400

Robert specifically asked about this capability NOT via PBR/ACL.

Alia

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Mar 2013 10:51:26 +0100

> Robert specifically asked about this capability NOT via PBR/ACL.

Any comments about the approach of draft-ietf-netmod-routing-cfg-09?

A route is defined there as an extensible container, and future modules (e.g., those defining data models for routing protocols) are expected to augment this container with new attributes. This augmentation is described in sec. 4.4.2 (Defining New Routing Protocols), and and example is shown in Appendix B for RIP.

It means that the definion of route is not fixed but depends on the modules supported by the device. 

Thanks, Lada

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 09:03:02 -0400

> Any comments about the approach of draft-ietf-netmod-routing-cfg-09?

I've commented on this draft in the past...

IMHO:

- It's not well enough defined for what we really want to get to here.
- It doesn't seem to be well organized

For instance --why is there a difference between "rw
main-routing-tables," and "rw routing-tables?" When would I choose to
use one or the other?

Where are the routing filters mentioned as a separate "thing" applied,
and how are they applied? What are the elements of the filter object?

What's the point of the "recipient routing table," piece of this model
(since we're talking about data, not an action)?

Why should "connected routes," and "static routes," be explicitly called
out as different "types" of routing protocols? How are they special?

> It means that the definion of route is not fixed but depends on the modules supported by the device. 

Which isn't going to work if you're actually trying to insert routes to
a number of different devices across a diverse network...

All of which is what went into my thinking about moving to a different
sort of model --

Rather than asking how to model a RIB, what if we tried to model the
information needed to actually forward a packet at layer 3? In other words:

- These are the tuples needed to build a solid routing table entry from
which the device can build forwarding table entries
- Add in the pieces we need for "policy," particularly the idea of
preference (called admin distance in cisco, for instance)

Is there anything else we would need?

The other option is to simply realize there's no "right" model here.
Just choose one that works, and move on with life.

Otherwise, we're going to bog down in arguing about models, rather than
getting real work done... And I'd really like to move to the "get real
work done" phase of things, rather than chatting about different models
for the next several years. :-)

:-)

Russ

---

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Mar 2013 09:55:01 -0400

First, while it is interesting to look at YANG models, what we need to be
thinking about in i2rs is information models - and how well different data
modeling languages meet those needs.

More comments in-line (ruthlessly cut)

> preference (called admin distance in cisco, for instance)

[Alia] I don't think that the forwarding info is quite the set we need, but
I would really like to see even a minimal information model for what the
RIB service info model should look like.  For instance, in addition to
admin-preference, we need the multiple route-tables, ways of putting
traffic in other than by just dest IP address, what events can be
registered for, etc.

> Just choose one that works, and move on with life.

[Alia] yes, get a small set of sufficient info to meet a basic set of
use-cases and define & use it.  It can always be extended later if and as
necessary.

Alia

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 20 Mar 2013 17:17:27 +0100

Hi Russ,

thanks for reading the draft (again). My responses are inline.

> - It's not well enough defined for what we really want to get to here.

There are certainly (intentional) gaps that will have to be filled, but IMO the data model could serve as a basis for I2RS, too. Unless, of course, you think something is wrong with it, in which case I'd like to hear the details so that we can improve it. I do believe though that we should eventually work, as much as possible, with the same data models - after all, the underlying router will be the same for both NETCONF and I2RS.  

> main-routing-tables," and "rw routing-tables?" When would I choose to

Unfortunately, it is not sufficient to look just at the graphical representation of the data tree in sec. 4. In the "ietf-routing" YANG module (sec. 6), you can see that "main-routing-table" is essentially only a *pointer* to a routing table. Its purpose is the following: There must be at least one routing table per address family, but there may be more, either built-in or user-defined. Each router instance then uses the "main-routing-table" pointers for designating the main routing table for each AF. Main routing tables are special in that
- direct routes are always installed in them,
- by default, all routing protocols instances are connected to them (this can be reconfigured).

Incidentally, until rev. -05 of the draft, the main routing tables were distinguished from the others by special prescribed names such as "main-ipv4-unicast", but then Wes Hardaker in his review objected (see http://www.ietf.org/mail-archive/web/netmod/current/msg07106.html, item 3) that using magic names was a bad idea. So we finally agreed to use an explicit pointer. 

> and how are they applied? What are the elements of the filter object?

The draft doesn't include any data model for specifying route filters. When the NETMOD WG was discussing the current charter, I actually proposed that the routing model would also include route filtering, but the prevailing opinion was that this task was too complicated and better left to experts. And indeed, it will IMO be pretty difficult to come up with a vendor-neutral filter specification that can be mapped somehow to the existing route filtering frameworks.

So yes, the "route-filter" entries in the current data model are mere placeholders, and the plan is that one or more route filtering data models will be developed and plugged into the prepared slots via augmentation (which IMO is one of YANG's killer features).

What the existing data model does specify are the places where route filters can be applied. It is
- between a routing protocol and its connected routing table, and
- between a routing table and its recipient routing tables.

I had the impression from the previous discussion in this ML that this might suffice for I2RS purposes.  

> (since we're talking about data, not an action)?

Some implementations (Cisco IOS) use the concept of "redistributing" routes directly between routing protocol instances while others (JUNOS, BIRD routing daemon) let each protocol first put its routes into a routing table and then pass it form there to other protocols, routing tables or the forwarding table. I believe the latter approach is more general. 

So, using this data model, the standard redistribution of routes from "proto A" to "proto B" will be configured like this:

	       +---------+          +---------+
	       | proto A |          | proto B |
	       +---------+          +---------+
		   | ^                  | ^
		   v |                  v |
	       +---------+          +---------+
	       | table A |--------->| table B |
	       +---------+          +---------+

Here, table A/B is the connected routing table for proto A/B, respectively, and table B is a recipient routing table for table A. A route filter can be applied at every edge in the above graph.

> out as different "types" of routing protocols? How are they special?

It is not our invention, JUNOS and BIRD deal with direct and static routes in terms of routing (pseudo-)protocols. As for the "direct" pseudo-protocol, it requires no configuration and can actually appear only in the "source-protocol" attribute of routes. On the other hand, "static" instances have to be configured - their configuration inlcudes the list of static routes that will then appear in routing tables with source protocol set to "static".

> a number of different devices across a diverse network...

If the network is heterogeneous, it it IMO quite appropriate to make use of specific capabilities of each type of device. In NETCONF this can be easily done because each device starts the session with advertising its capabilities to the manager. Why this isn't going to work in I2RS?

Thanks, Lada

---

From: Russ White <[email-masked]>
Date: Sat, 23 Mar 2013 10:33:07 -0400

> There are certainly (intentional) gaps that will have to be filled, but IMO the data model could serve as a basis for I2RS, too. Unless, of course, you think something is wrong with it, in which ca…

Well, what I would prefer is something that is smaller and lighter, and
definite in what it touches, but leaves room for development in later
iterations. In other words, I would probably prefer a bottom up
approach, rather than a top down one.

> Some implementations (Cisco IOS) use the concept of "redistributing" routes directly between routing protocol instances while others (JUNOS, BIRD routing daemon) let each protocol first put its rou…

Actually, no. Cisco IOS doesn't redistribute directly between routing
instance, it only redistributes from the routing table into a protocol.
I don't want to get into a lot of mechanics, but while the user
interface implies direct redistribution, this simply isn't how it's done
in the code.

Redistribution is, in all the implementations I know of, effectively a
filter the receiving protocol puts into the RIB/protocol interface to
say, "when you get a new route matching these criteria (with the source
protocol being a criteria), send the route information as well." I could
be wrong about this -- I don't know every implementation as well as I
should -- but I'm pretty sure this is how it's always coded.

Even in the case of import/export, what happens is normal redistribution
followed by an inter protocol callback to get the information the
routing table doesn't have (to fill in metrics and the like).

So... I think we can model all of these as a part of the policy between
the RIB and each protocol -- we don't need a separate and special
"channel."

> It is not our invention, JUNOS and BIRD deal with direct and static routes in terms of routing (pseudo-)protocols. As for the "direct" pseudo-protocol, it requires no configuration and can actually…

But if they're both just another flavor of a protocol, why not just call
them a protocol with some special bits, rather than calling them a
different "kind" of protocol process? That's one of the points, to me,
of working from the bottom up -- don't make distinctions at the model
level that can be made more simply by flipping some property bits at a
lower level.

> If the network is heterogeneous, it it IMO quite appropriate to make use of specific capabilities of each type of device. In NETCONF this can be easily done because each device starts the session w…

But it means we're back to square one --any off box process that wants
to work with the local RIB on a wide variety of boxes must poke through
the documentation (almost never complete, by intention) of each of those
boxes, and build an internal data model that can be used for that
individual box. This lays the problem of data modeling squarely on the
shoulders of the application developer.

I'd prefer a least common denominator set of things we know we need to
build a RIB (not a forwarding table a RIB), from the start, and then
build where we see more stuff we can do in the future.

Start small and grow up, don't start big and try to fill out the details
--IMHO.

:-)

Russ

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 23 Mar 2013 17:08:03 +0100

> approach, rather than a top down one.

The decision between top-down and bottom-up is always difficult, but in this case we hardly had any choice. One reason is technical: YANG is essentially designed for the top-down approach. One module defines the top-level skeleton and other modules can then fill in details via augmentation.

Another reason is that the initial (core) YANG modules have been developed by the NETMOD WG, in order to break the chicken-and-egg problem. And we couldn't start with a very specialized stuff such as routing protocols, this should be left to experts in other WGs.

Most of the complexity is a consequence of the stated objective that vendors should be able to map this data model to their proprietary models and/or CLI logic.
 
> interface implies direct redistribution, this simply isn't how it's done

Either way, it can be represented using the data model.
 
> should -- but I'm pretty sure this is how it's always coded.

An implementation is free to stick to just one routing table (per address family) and then it is exactly as you write: all protocol have no choice but to connect to this table and most of the complexity goes away.

> the RIB and each protocol -- we don't need a separate and special

The data model allows for multiple routing tables per address family, because this is what some implementations support. As I said, you are free to limit yourself to a single RIB/routing table and then there is no such channel, and what remains are only import and export filters between the single RIB and each routing protocol.

> level that can be made more simply by flipping some property bits at a

I am not sure I understand what you mean but, as a matter of fact, the two pseudo-protocols are *not* modelled as a different kind of protocol. For instance, configurations of "static" and "bgp" protocol instances will be entries of the same "routing-protocol" list.

> shoulders of the application developer.

If the off-box process uses NETCONF/YANG, it can learn the capabilities of each box from their hello packets, and then peruse the machine-readable representation of their data models. 

> build where we see more stuff we can do in the future.

Nothing prevents you from using the common denominator if it is sufficient.

Cheers, Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 23 Mar 2013 14:16:34 -0700

On Sat, Mar 23, 2013 at 7:33 AM, Russ White <[email-masked]> wrote:
>.....

This is an important point.
Do you want a framework that is filled in by vendors
(and possibly SDOs) that may be different on each platform,
or do you want a common API that provides basic functionality
that all vendors must implement? Or both?

It's too early to be reviewing YANG modules for I2RS
but it would be good to know the direction the API is headed.

> Russ

Andy

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Mar 2013 17:30:32 -0400

> that all vendors must implement? Or both?

[Alia] A common API that provides basic functionality that all vendors must
implement.   Having it extensible for different features is desirable.

> but it would be good to know the direction the API is headed.

[Alia]  Absolutely too early, but not for information models.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 23 Mar 2013 22:49:01 +0100

Hi Andy,

> that all vendors must implement? Or both?

FWIW it seems neither to me.

If I2RS interface is to become significant in the industry it must
support most common applications which are required by actual
operators - both for WAN, MAN, LAN, access and DCs.

If it will lack basic primitives which folks expect it to have I am
afraid it's use will be limited to bits and pieces demos at various
conferences and NOGs which I think is not what I2RG WG is aiming for.

So the approach to go by use cases seems wise provided all interested
parties will or can submit their use cases. Especially "can" is
important here as number of operators are at the design or development
phase of number of new services which are competitive and can not be
shared in public. With that one could observe that OF does offer much
lower level of interface to data plane and could be used or worked on
without exposing your future services.

That's why I have started this thread asking for RIB interface
definition to be able to sense if what is currently on the table has
potential of being useful for projects I am involved with or not.

Best,
R.