Subject: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Jul 2013 17:55:15 -0400

Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whether it
should be adopted by I2RS.  Detailed technical conversation is also most
welcome.

Authors: Are you aware of any IPR that applies
to draft-nitinb-i2rs-rib-info-model-01  Is so, has this IPR been disclosed
in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 18:08:58 -0400

Looking again at this document, I have to reluctantly say taht I do not 
support adoption of this document at this time.

The base definition of RIB is still very unclear.  A RIB is some 
collection of routing instances?  First, this seems upside-down to me. 
A routing instance would seem to contain a RIB, not the other way 
around.  Secondly, what defines, describes, or otherwise helps decide 
what set of routing instances go in the same RIB.

If this issue were clarified, I believe the rest of the material is in 
sufficiently good shape for working group adoption.

Yours,
Joel M. Halpern

On 7/24/13 5:55 PM, Alia Atlas wrote:
> Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whether
> it should be adopted by I2RS.  Detailed technical conversation is also
> most welcome.
>
> to draft-nitinb-i2rs-rib-info-model-01  Is so, has this IPR been
> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
> and 5378 for more details).
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 24 Jul 2013 18:11:50 -0400

I have reviewed the document in detail.  As Joel mentioned, there are some bumps and warts that need to be fleshed out, but I feel it is sufficiently well put together as a starting point for the WG to satisfy part of the chartered items of producing an information model. 

	--Tom

On Jul 24, 2013:5:55 PM, at 5:55 PM, Alia Atlas <[email-masked]> wrote:

> Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whether it should be adopted by I2RS.  Detailed technical conversation is also most welcome.
> 
> Authors: Are you aware of any IPR that applies to draft-nitinb-i2rs-rib-info-model-01  Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Jul 2013 18:16:53 -0400

Joel,

I understand your concern.  Do you have text to suggest to Nitin and
co-authors?
I think part of this is figuring out how to pull out the RIB bits (routing
tables) and what traffic they apply to - as well as the policy of how to
create associated containers.  Nitin's called that a routing instance...

What set of objects would you create?

I personally would like to see the info-model described in something other
than rBNF - but I view that as a piece that can happen in a future version.

Alia

On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern <[email-masked]>wrote:

> collection of routing instances?  First, this seems upside-down to me. A
> routing instance would seem to contain a RIB, not the other way around.
>  Secondly, what defines, describes, or otherwise helps decide what set of
> routing instances go in the same RIB.
>
>> Please review draft-nitinb-i2rs-rib-info-**model-01 and comment on
>> whether
>> to draft-nitinb-i2rs-rib-info-**model-01  Is so, has this IPR been
>> ______________________________**_________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 18:19:52 -0400

Asking for a text proposal is quite reasonable.
Unfortunately, since my oncern is taht I can not understand what is 
meant by RIB in this definition, it is really ahrd to propose an 
alternative set of definitions that do what the authors wanted.

Yours,
Joel

On 7/24/13 6:16 PM, Alia Atlas wrote:
> I think part of this is figuring out how to pull out the RIB bits
> (routing tables) and what traffic they apply to - as well as the policy
> of how to create associated containers.  Nitin's called that a routing
> instance...
>
> I personally would like to see the info-model described in something
> other than rBNF - but I view that as a piece that can happen in a future
> version.
>
> Alia
>
>
>
> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Looking again at this document, I have to reluctantly say taht I do
>     not support adoption of this document at this time.
>
>     collection of routing instances?  First, this seems upside-down to
>     me. A routing instance would seem to contain a RIB, not the other
>     way around.  Secondly, what defines, describes, or otherwise helps
>     decide what set of routing instances go in the same RIB.
>
>     If this issue were clarified, I believe the rest of the material is
>     in sufficiently good shape for working group adoption.
>
>     Yours,
>     Joel M. Halpern
>
>
>         Please review draft-nitinb-i2rs-rib-info-__model-01 and comment
>         on whether
>         to draft-nitinb-i2rs-rib-info-__model-01  Is so, has this IPR been
>         _________________________________________________
>         i2rs mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
>
>

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 25 Jul 2013 02:21:06 +0000

Hi Joel,

   Maybe this can help clarify what we meant by the RIB.

The RIB is the totality of all routing-information in a router. The
routing information itself can be sub-divided into multiple objects called
routing-instances. 

Routing-instances allow us to partition the physical router into domains
that can operate independently from one another in terms of routing and
forwarding. 

The rest of that section describes what objects are contained in a RIB,
like routing tables, routes and nexthops.

HTH as a starting point.
Nitin Bahadur

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jul 2013 22:43:34 -0400

This seems a different use of the term RIB than most of the work I am 
familiar with.  Even without dealing with things like protocol specific 
RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally 
discuss them as using separate RIBs.  This is why the terminology seems 
upside-down to me.

Yours,
Joel

---

From: Acee Lindem <[email-masked]>
Date: Thu, 25 Jul 2013 11:25:07 +0000

I agree with Joel. 

On 7/24/13 7:43 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>>>          it should be adopted by I2RS.  Detailed technical
>>>>conversation
>>>>          is also
>>>>          most welcome.
>>>>

---

From: Sri <[email-masked]>
Date: Thu, 25 Jul 2013 16:57:12 -0700

Hi Joel,

You seem to be pointing to two issues that need a better definition -
1) The RIB whose IM is being described in this doc (as opposed to all other
XXX-RIBs in a router)
2) The routing-instance that is defined in this doc as part of the RIB as
opposed to a more general understanding of a routing-instance.

First let me try to clarify some statements to see if there is agreement
and then we can cobble together some wording around it for the draft -
0. A router can be thought of as an I2RS agent endpoint. This definition is
outside the scope of this document, but it may help to understand the RIB
IM in relation to I2RS.
1. There is a single RIB in a router. When referred to in the context of a
router, this RIB is unqualified. The IM in this draft is describing this
RIB.
2. A router has zero or more routing instances. Each routing instance will
have its own RIB. This RIB is unqualified in the context of that routing
instance, but is qualified by the routing-instance name when in the context
of the router (e.g. core.RIB or VPN_X.RIB). We can further qualify by the
type i.e. the routing-instance (e.g. routing_instance.core.RIB) if there
are separate namespaces for routing-instance names and say protocols, but
this is a minor point.
3. The collection of the RIBs of all the routing-instances in the router is
the RIB (i.e., the RIB defined in 1.)
4. Other RIBs e.g. the BGP RIB-in of a routing instance has to be qualified
further within the routing instance and hence is not part of the RIB (i.e.
the RIB defined in 1.). So you will have routing_instance.core.bgp-in.RIB
to describe BGPs RIB-in for that instance. All such XXX-RIB IMs are outside
the scope of this draft.
5. To summarize, the RIB in 1. in words - This document describes the IM of
the RIB of a router. A router has a single RIB. A router consists of
multiple routing instances and each routing-instance has a RIB. The
router's RIB consists of the collection of RIBs of all the
routing-instances of the router. A routing-instance's RIB consists of
routes added by zero or more routing/signaling/static protocols of that
routing instance. Routes added by one instance can be resolved via routes
in other instances and this relationship is reflected in the RIB. The
RIB-manager manages all the routes in the RIB and executes the policies to
recursively resolve the routes according to the capabilities of the
forwarding hardware. It also downloads the routes to the FIB. The
RIB-manager also executes policies to re-distribute routes across protocols.

Let me know if this helps.

On Wed, Jul 24, 2013 at 7:43 PM, Joel M. Halpern <[email-masked]>wrote:

>>>>          Please review draft-nitinb-i2rs-rib-info-__**model-01 and
>>>> comment
>>>>          on whether
>>>>          to draft-nitinb-i2rs-rib-info-__**model-01  Is so, has this
>>>> IPR
>>>> been
>>>>          ______________________________**___________________
>>>>          i2rs mailing list
>>>>          https://www.ietf.org/mailman/_**_listinfo/i2rs<https://www.ietf.org/mailman/__listinfo/i2rs>
>>>>          <https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>>>> >
>>>>
>>>>

---

From: t.petch <[email-masked]>
Date: Fri, 26 Jul 2013 16:39:30 +0100

I oppose adoption of this I-D.  The use of terminology seems
incompatible with the use of the same terminology elsewhere and,
arguably, contradicts the charter.

For example, this I-D says

" A RIB
   contains one or more routing instances.
   A routing instance, in the context of the RIB
   information model, is a collection of routing tables, interfaces, and
   routing parameters.
  The routing tables specify how incoming
   traffic is to be forwarded."

whereas the charter clearly differentiates the RIB, which is the subject
of this WG, from the FIB, which is not.  The reference here to routing
tables sounds rather like a FIB.  (Of course, the charter fails to
define RIB and FIB which is likely to be a recurrent problem for all the
work of this WG unless and until rough consensus is achieved thereon.)

And the I-D places heavy emphasis on interfaces which again seems to
have
nothing to do with the charter.

This topic has surfaced several times on several WG lists, none of which
has produced an agreed document, but the best one would appear to me to
agree that there are processes, not just data, and that these processes
are tied to routing protocols, and that the data thereof needs to be
split into three
 - a RIB (in the sense that I most often see it used) containing the
data used by a protocol process instance
- a central database of consolidated routes, sometime referred to as
RIB2
- what gets used in forwarding, usually by the silicon.

Routing table and FIB I see used arbitrarily and so confusingly used for
the second and third data structures.  (I have no idea what the charter
means in this regard).

Tom Petch

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
To: "Nitin Bahadur" <[email-masked]>
Cc: <[email-masked]>; "Alia Atlas" <[email-masked]>
Sent: Thursday, July 25, 2013 3:43 AM
Subject: Re: [i2rs] Call for WG Adoption:
draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

conversation
> >>>          to draft-nitinb-i2rs-rib-info-__model-01  Is so, has this
IPR
> >>> been
> >>>          disclosed in compliance with IETF IPR rules (see RFCs
3979,
> >>>          4879, 3669

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 26 Jul 2013 14:10:33 -0400

I also oppose WG adoption for some of the same reasons that Joel
stated earlier.  That said, there is some useful content in this
document but I had some additional questions or concerns that could
just be mis-reading of intent:

Thanks,

-Jon

Section 2.1:

paragraph 2 - "if the intersection MUST be the null set, then an
interface MUST NOT be present in", current text using "should" seems
inconsistent.

fields -

1. If INSTANCE_NAME is required and the distinguisher by which you
keep these tables seperate, why is INSTANCE_DISTINGUISHER also a
required field?  I could understand if you said INSTANCE_DISTINGUISHER
actually was exactly the BGP RD instead of could be mapped "well" to
it.  However even then it's not clear this is required outside of a
L3VPN context.  On the other hand if INSTANCE_NAME is NOT required and
is really meant to be an optional user friendly name, then perhaps you
mean INSTANCE_DISTINGUISHER MUST be unique rather than SHOULD be.

2. A paragraph break seperating mandatory and optional fields
would be really helpful, I thought this was one bullet list on first
pass.

3. ROUTER_ID seems protocol specific (although many implementations
allow you to set one globally to apply to multiple protocols).  Does
it make sense to expose this to the data model if protocol
manipulation and configuration are out of scope?  Also the mention of
virtual routers here seems odd in that one could also imagine virtual
routers would have seperate i2rs interfaces.  ISO_SYSTEM_ID seems even
more circumspect, if that, why not BGP ASN and all kinds of other
protocol details?

4. as_data doesn't make any sense to me here, can you elaborate?  If
the goal is to apply some sort of generic tag to routes in this
routing instance maybe a local implementation tag/color/blah is what
you meant here?   Unless i2rs is focused on BGP protocol manipulation
it doesn't seem that RIB manager is likely to use AS length as a
determining factor for route selection (later in the doc it appears
route preference and metric are the deciding factor which seems more
consistent with my understanding of a RIB).

Section 2.3:

1. LOCAL_ONLY - I wonder if the word RIB in this description is used
in the common meaning rather than the document's definition?

2. as-path - This makes me wonder if this draft is optimized around
specific vendor implementations that export BGP attributes to the RIB
(common definition) rather than keeping them in the bRIB.  Even if
this is the case, does this imply we should include other BGP
attributes as well, why limit it to as-path?

Section 2.4.1:

A large portion of this section seems to suggest things that are FIB,
not RIB manipulation, for instance recursive next hops and the mention
of multiple headers.  Multiple headers may have to be installed in the
FIB as a router consults a RIB and finds a nexthop that also leads to
the RIB (and not a local interface of some kind) but this wording
seems to suggest it can be programmed directly in one entry rather
than by consulting the RIB again when it's non-local.  This seems to
be out of scope for i2rs?

Section 2.4.2:

I'm a bit unclear if this is in scope for RIB or FIB either, but
assuming it is in scope, should LOAD_BALANCE_WEIGHT mention that
PROTECTION_PREFERENCE must be equal?  In other words, these two items
don't appear to be mutually exclusive to me, however it doesn't
explicitely state if they are in this model or if they aren't, how to
deal a set of nexthops with both attributes.

Section 2.4.3:

Is writing destination MAC in scope for this WG?  Or is this mean to
be a specified nexthop IP like you may have for a static route in
traditioanl CLI config?  If it's an IPv4 entry and only a MAC is
specified what is written in the destination IP address?

Section 2.4.4.1:

These seem MPLS specific and typically is a
signalling function? 

> >>>>          disclosed in compliance with IETF IPR rules (see R

> D"_blank">https://www.ietf.org/mailman/<u></u>lis=
> tinfo/i2rs</a>&gt;<br>
> <br>
> <br>
> </blockquote>
> _________________________

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 27 Jul 2013 16:52:30 -0400

Jon, Nitin, and Joel: 

I too agree this draft is not ready for WG adoption.  

To move this forward, I would suggest that the draft get broken into two
pieces:

1) What is a RIB and how i2rs will deal with it, and 
2) RIB information model based on the first part. 

The difficulty with the merging of the two is that the work is that the WG
needs to confirm #1 in order to get clarity with #2.  Does this help? 

Sue  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon
Mitchell
Sent: Friday, July 26, 2013 2:11 PM
To: Sri
Cc: [email-masked]; Nitin Bahadur; Joel M. Halpern; Alia Atlas
Subject: Re: [i2rs] Call for WG Adoption:
draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

I also oppose WG adoption for some of the same reasons that Joel stated
earlier.  That said, there is some useful content in this document but I had
some additional questions or concerns that could just be mis-reading of
intent:

Thanks,

-Jon

Section 2.1:

paragraph 2 - "if the intersection MUST be the null set, then an interface
MUST NOT be present in", current text using "should" seems inconsistent.

fields -

1. If INSTANCE_NAME is required and the distinguisher by which you keep
these tables seperate, why is INSTANCE_DISTINGUISHER also a required field?
I could understand if you said INSTANCE_DISTINGUISHER actually was exactly
the BGP RD instead of could be mapped "well" to it.  However even then it's
not clear this is required outside of a L3VPN context.  On the other hand if
INSTANCE_NAME is NOT required and is really meant to be an optional user
friendly name, then perhaps you mean INSTANCE_DISTINGUISHER MUST be unique
rather than SHOULD be.

2. A paragraph break seperating mandatory and optional fields would be
really helpful, I thought this was one bullet list on first pass.

3. ROUTER_ID seems protocol specific (although many implementations allow
you to set one globally to apply to multiple protocols).  Does it make sense
to expose this to the data model if protocol manipulation and configuration
are out of scope?  Also the mention of virtual routers here seems odd in
that one could also imagine virtual routers would have seperate i2rs
interfaces.  ISO_SYSTEM_ID seems even more circumspect, if that, why not BGP
ASN and all kinds of other protocol details?

4. as_data doesn't make any sense to me here, can you elaborate?  If the
goal is to apply some sort of generic tag to routes in this routing instance
maybe a local implementation tag/color/blah is what
you meant here?   Unless i2rs is focused on BGP protocol manipulation
it doesn't seem that RIB manager is likely to use AS length as a determining
factor for route selection (later in the doc it appears route preference and
metric are the deciding factor which seems more consistent with my
understanding of a RIB).

Section 2.3:

1. LOCAL_ONLY - I wonder if the word RIB in this description is used in the
common meaning rather than the document's definition?

2. as-path - This makes me wonder if this draft is optimized around specific
vendor implementations that export BGP attributes to the RIB (common
definition) rather than keeping them in the bRIB.  Even if this is the case,
does this imply we should include other BGP attributes as well, why limit it
to as-path?

Section 2.4.1:

A large portion of this section seems to suggest things that are FIB, not
RIB manipulation, for instance recursive next hops and the mention of
multiple headers.  Multiple headers may have to be installed in the FIB as a
router consults a RIB and finds a nexthop that also leads to the RIB (and
not a local interface of some kind) but this wording seems to suggest it can
be programmed directly in one entry rather than by consulting the RIB again
when it's non-local.  This seems to be out of scope for i2rs?

Section 2.4.2:

I'm a bit unclear if this is in scope for RIB or FIB either, but assuming it
is in scope, should LOAD_BALANCE_WEIGHT mention that PROTECTION_PREFERENCE
must be equal?  In other words, these two items don't appear to be mutually
exclusive to me, however it doesn't explicitely state if they are in this
model or if they aren't, how to deal a set of nexthops with both attributes.

Section 2.4.3:

Is writing destination MAC in scope for this WG?  Or is this mean to be a
specified nexthop IP like you may have for a static route in traditioanl CLI
config?  If it's an IPv4 entry and only a MAC is specified what is written
in the destination IP address?

Section 2.4.4.1:

These seem MPLS specific and typically is a signalling function? 

On 25/07/13 16:57 -0700, Sri wrote:
> 1) The RIB whose IM is being described in this doc (as opposed to all 
> other XXX-RIBs in a router)

> 2) The routing-instance that is defined in this doc as part of the RIB 
> as opposed to a more general understanding of a routing-instance.
> 
> First let me try to clarify some statements to see if there is 
> agreement and then we can cobble together some wording around it for 
> the draft - 0. A router can be thought of as an I2RS agent endpoint. 
> This definition is outside the scope of this document, but it may help 
> to understand the RIB IM in relation to I2RS.
> 1. There is a single RIB in a router. When referred to in the context 
> of a router, this RIB is unqualified. The IM in this draft is 
> describing this RIB.
> 2. A router has zero or more routing instances. Each routing instance 
> will have its own RIB. This RIB is unqualified in the context of that 
> routing instance, but is qualified by the routing-instance name when 
> in the context of the router (e.g. core.RIB or VPN_X.RIB). We can 
> further qualify by the type i.e. the routing-instance (e.g. 
> routing_instance.core.RIB) if there are separate namespaces for 
> routing-instance names and say protocols, but this is a minor point.
> 3. The collection of the RIBs of all the routing-instances in the 
> router is the RIB (i.e., the RIB defined in 1.) 4. Other RIBs e.g. the 
> BGP RIB-in of a routing instance has to be qualified further within 
> the routing instance and hence is not part of the RIB (i.e.
> the RIB defined in 1.). So you will have 
> routing_instance.core.bgp-in.RIB to describe BGPs RIB-in for that 
> instance. All such XXX-RIB IMs are outside the scope of this draft.
> 5. To summarize, the RIB in 1. in words - This document describes the 
> IM of the RIB of a router. A router has a single RIB. A router 
> consists of multiple routing instances and each routing-instance has a 
> RIB. The router's RIB consists of the collection of RIBs of all the 
> routes added by zero or more routing/signaling/static protocols of 
> that routing instance. Routes added by one instance can be resolved 
> via routes in other instances and this relationship is reflected in 
> the RIB. The RIB-manager manages all the routes in the RIB and 
> executes the policies to recursively resolve the routes according to 
> the capabilities of the forwarding hardware. It also downloads the 
> routes to the FIB. The RIB-manager also executes policies to re-distribute
routes across protocols.
> > This seems a different use of the term RIB than most of the work I 
> > am familiar with.  Even without dealing with things like protocol 
> > specific RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs 
> > we normally discuss them as using separate RIBs.  This is why the 
> > terminology seems upside-down to me.
> >
> > Yours,
> > Joel
> >
> >
> >> routing information itself can be sub-divided into multiple objects 
> >> called routing-instances.
> >>
> >> Routing-instances allow us to partition the physical router into 
> >> domains that can operate independently from one another in terms of 
> >> routing and forwarding.
> >>
> >>
> >> The rest of that section describes what objects are contained in a 
> >> RIB, like routing tables, routes and nexthops.
> >>
> >>
> >> HTH as a starting point.
> >> Nitin Bahadur
> >>
> >>
> >>
> >>
> >>
> >>> Unfortunately, since my oncern is taht I can not understand what 
> >>> is meant by RIB in this definition, it is really ahrd to propose 
> >>> an alternative set of definitions that do what the authors wanted.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>>> I understand your concern.  Do you have text to suggest to Nitin 
> >>>> and co-authors?
> >>>> (routing tables) and what traffic they apply to - as well as the 
> >>>> policy of how to create associated containers.  Nitin's called 
> >>>> that a routing instance...
> >>>>
> >>>> I personally would like to see the info-model described in 
> >>>> something other than rBNF - but I view that as a piece that can 
> >>>> happen in a future version.
> >>>>
> >>>> Alia
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern 
> >>>> <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>
> >>>>          Please review draft-nitinb-i2rs-rib-info-__**model-01 
> >>>> and comment
> >>>>          on whether
conversation
> >>>>          to draft-nitinb-i2rs-rib-info-__**model-01  Is so, has 
> >>>> this IPR been

---

From: Nitin Bahadur <[email-masked]>
Date: Sun, 28 Jul 2013 18:15:01 +0000

My original intent here was to provide "a name" to something that
aggregated all the routing-instances.
Obviously as many have pointed out, giving it the name of "rib" was a bad
choice.

So we have 2 choices:
- Remove the top-level object in the grammar (rib) completelyŠand instead
start off with routing-instance.
- Rename "rib" (in the grammar) to something better :)

Thanks
Nitin Bahadur

On 7/25/13 4:25 AM, "Acee Lindem" <[email-masked]> wrote:

>>>called
>>>domains
>>>>>policy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 28 Jul 2013 22:05:21 +0000

Hi,

I have concerns with adopting this document.

As others have mentioned on the list, the concepts of RIB and routing instance seem to be inverted. But in addition to that, there seem to be two other issues with the document in its current shape:
1. It's not clear the scope of what's within the Routing Information Base information model. Specifically, elements defined seem to belong in the FIB and not the RIB.
2. The document structure seems to have gaps and overlaps, and lacks a compiled set of definitions of RIB elements.

Please find below some additional questions and observations on the document, marked with "CMP". 

I hope these are clear and useful.

                  Routing Information Base Info Model
                  draft-nitinb-i2rs-rib-info-model-01

1.  Introduction

   The rest of this document is organized as follows.  Section 2.1 goes
   into the details of what constitutes and can be programmed in a RIB.
   Section 5 provides a high-level view of the events and notifications
   going from a network device to an external entity, to update the
   external entity on asynchronous events.  The RIB grammar is specified
   in Section 6.  Examples of using the RIB grammar are shown in
   Section 7.

CMP: What about other Sections? From 2.1 it jumps to Section 5

   and not proactive push (from the router) mechanisms.  Screen scraping
   is error prone (since output can change) and vendor dependent.

CMP: A nit -- the output will change. I think "since the output format can change" is what's meant.

2.1.  RIB definition

   A RIB is a logical construct controlled by an external entity.  A RIB
   contains one or more routing instances.  On a network device, a RIB
   is uniquely identified by its name.  A routing instance can be in
   only 1 RIB.  A routing instance, in the context of the RIB
   information model, is a collection of routing tables, interfaces, and
   routing parameters.  A routing instance creates a logical slice of
   the router and allows different logical slices; across a set of
   routers; to communicate with other each.

CMP: I think these set of definitions could use a visual to describe what's a RIB, routing instance, routing tables and their high-level elements, in addition to itemized definitions.

   Layer 3 Virtual Private
   Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service
   (VPLS) can be modeled as routing instances. 

CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as routing instances. Which L3 elements are there in an L2VPN?

   Note that modeling a
   Layer 2 VPN using a routing instance only models the Layer-3 (RIB)
   aspect and does not model any layer-2 information (like ARP) that
   might be associated with the L2VPN.

CMP: DOes this mean that ARP should be out of the RIB model?

2.2.  Routing tables

   A routing table is an entity that contains routes.  A routing table
   is identified by its name.  The name MUST be unique within a RIB.
   All routes in a given routing table MUST be of the same type (e.g.
   IPv4).  Each routing table MUST belong to some routing instance.

CMP: Should you also differentiate, in addition to the AF, by unicast versus multicast?

   Each route table can be optionally associated with a
   ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding
   (RPF) checks on all IP routes in that table.  Reverse path forwarding

CMP: Is RPF an attribute of the routing table?

2.3.  Route

   A route is essentially a match condition and an action following the
   match.  The match condition specifies the kind of route (IPv4, MPLS,
   etc.) and the set of fields to match on.  This document specifies the
   following match types:

CMP: What is an "MPLS Route" in the context of a routing table?

   o  IPv4: Match on destination IP in IPv4 header
   o  IPv6: Match on destination IP in IPv6 header
   o  MPLS: Match on a MPLS tag
   o  MAC: Match on ethernet destination addresses

CMP: Is the MAC address a match element within routing? Or what types of address families and identifiers are input to defining the elements included?

2.4.1.  Nexthop types

   o  Special nexthops - for performing specific well-defined functions

CMP: Are things like the drop/null route fitting here? Are there many different kinds of specials, or should they be listed explicitly?

6.  RIB grammar

   <table-family> ::= <IPV4_TABLE_FAMILY> | <IPV6_TABLE_FAMILY> |
                      <MPLS_TABLE_FAMILY> | <IEEE_MAC_TABLE_FAMILY>

CMP: Why these families? 
CMP: Do you need to separate IPv4 in unicast versus multicast? Or are you modeling a single table with attributes for the uni/multicast?

   <ipv4-route> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>

CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"?

Thanks,

-- Carlos.

---

From: "Russ White" <[email-masked]>
Date: Sun, 28 Jul 2013 21:10:54 -0400

> - Rename "rib" (in the grammar) to something better :)

Let me ask this: Is there some point to the top level "rib" object? IE,
would you ever use an object that encompasses every routing table entry
across the box, no matter which specific VRF the route is in? To put it
another way --is there any time when you might want to say, "hand me every
route you have to 10.1.1.0/24, no matter what the routing context?"

I can't think of any reason you'd ever ask this type of question --the
context of the route is something you must have to make sense of the route
itself. In response to that, I'd say it's best to simply remove the top
level object itself.

:-)

Russ

---

From: Sriganesh Kini <[email-masked]>
Date: Sun, 28 Jul 2013 23:56:49 -0700

Carlos, good point. But we also need to ask the question of where we
express relationships between routing-contexts. E.g. If VPN-1 is being
transported over Backbone-1 and VPN-2 over Backbone-2. Would these be
inside the routing context or in a top level object ?

- Sri

---

From: Acee Lindem <[email-masked]>
Date: Mon, 29 Jul 2013 07:51:40 +0000

I vote for #1.  
Acee

On 7/28/13 11:15 AM, "Nitin Bahadur" <[email-masked]> wrote:

>>>>RIB,
>>>>>>      Looking again at this document, I have to reluctantly say taht
>>>>>>I
>>>>>>do
>>>>>>      If this issue were clarified, I believe the rest of the
>>>>>>material
>>>>>>is

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Jul 2013 10:27:37 +0200

> discuss them as using separate RIBs.  This is why the terminology seems 

It was not without a reason that I proposed to start with agreeing on and writing down definition of these important terms and acronyms:

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

We have gone through similar discussions in the NETMOD WG regarding the document draft-ietf-netmod-routing-cfg. In short, IETF standards and various vendors (plus their customers) use these terms with different meanings.

Lada

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

---

From: t.petch <[email-masked]>
Date: Mon, 29 Jul 2013 14:58:03 +0100

----- Original Message -----
From: "Russ White" <[email-masked]>
To: "'Nitin Bahadur'" <[email-masked]>; "'Acee Lindem'"
<[email-masked]>; "'Joel M. Halpern'" <[email-masked]>
Cc: <[email-masked]>; "'Alia Atlas'" <[email-masked]>
Sent: Monday, July 29, 2013 2:10 AM

another way --is there any time when you might want to say, "hand me
every

<tp>
Russ

After decades of working with router models in the IETF, my ideas are
probably rather fossilised, but I think I see some agreement that at one
end of the router, there are data structures that are passed to the
silicon to use in deciding where to forward packets; while at the other
end, there are instances of routing protocols sending and receiving
data, maintaining protocol specific data structures as a BGP RIB or OSPF
link state database, and processing it in order to derive one or more
best routes within the purview of that protocol instance:-)

Then there is Something In The Middle, on which I do not see agreement,
that takes some or all of the output of the other and passes it to the
one.  You could regard SITM as being a process with no data; or it might
be useful to conceive of it as a data structure, listing all possible
routes, or at least all those seen as acceptable to the individual
protocol instance.

If you are going to apply rules of selection, operational parameters,
policy and so on, then regarding SITM as data is one way to do it.  I
rather expected this to be the approach of i2rs.

So I am happy to see an all embracing SITM data structure, as long as
its definition makes clear its relationship to the other and the one (as
described above).

I avoid the use of the usual terminology here for reasons that are
probably obvious.

Tom Petch

</tp>
I can't think of any reason you'd ever ask this type of question --the
context of the route is something you must have to make sense of the
route
itself. In response to that, I'd say it's best to simply remove the top
level object itself.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 29 Jul 2013 16:26:38 -0400

> probably rather fossilised, but I think I see some agreement that at one
end
> of the router, there are data structures that are passed to the silicon to
use in
> deciding where to forward packets; while at the other end, there are
> instances of routing protocols sending and receiving data, maintaining
> protocol specific data structures as a BGP RIB or OSPF link state
database, and
> processing it in order to derive one or more best routes within the
purview
> of that protocol instance:-)

The problem is there is no longer "one" database that's passed to the
silicon to make an actual forwarding decision --with virtualization,
specifically, there's (potentially) a different set per interface, and hence
there's a different "RIB" per topology behind these different forwarding
table entries (though I hate to use the term "RIB" here). So when you look
up a specific destination, you must not only specify the destination, but
also the context within which that destination lives.

The question becomes --do you want to have something like this:

(Context1,10.1.1.0/24)
(Context2,10.1.1.0/24)

And call that the "RIB," which lives at the top level of the hierarchy? If
so, then what do you call the table that lives exclusively in context 1 (or
2), and has a route to 10.1.1.0/24, but is not even aware of other routes to
that same destination address because it has no access to the tables in
other contexts? This second table is what's traditionally called "the RIB,"
in my experience. While different people have different experiences, I don't
know of anyone who would call the combination of all forwarding table entry
contexts into one large table the "RIB."

A second way to look at this, I think, is in asking what question you want
to be able to ask. Do you want to say: "Find me the route in context 1 that
leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select context 1.
Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find every route
to every possible 10.1.1.0/24 no matter what the context is?"

The third question makes no sense to me, as I don't see anything useful you
can do with that information. I'm open to suggestions, I just can't think of
anything off the top of my head I'd ever want to use that information for,
because  (Context1,10.1.1.0/24) is actually a completely different
destination than (Context2,10.1.1.0/24) --they're only related by their
destination address, not by the physical or logical topology in any way. 

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 29 Jul 2013 16:30:18 -0400

> inside the routing context or in a top level object ?

So you're saying, "what if 10.1.1.0/24 in context 1 is reachable via 10.1.1.1 in context 2?" The primary way we describe this today is through tunneling, not through multiple VRF contexts... And I would never expect to have, "(10.1.1.0/24,context1) is reachable via (10.1.1.1,context2), and (192.168.1.0/24,context2) is reachable via (10.1.1.1,context1)." In fact, I think all such situations are probably really dangerous in the real world, and operators would avoid them like the plague.

But, again, I'm not saying this is a completely nonuseful construct, I'm just trying to figure out a specific use case for doing such a thing.

:-)

Russ

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 29 Jul 2013 23:09:29 +0000

I don't know about the global RIB, but one thing that

should be modeled is the box within which all the RIBs exist.

All the RIBs share various resources/objects within the box.

Examples are:

1. power supply: if it dies, all the RIBs die.

2. Physical ports. Any RIB can bind to any of them or any VLANs on them.

3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) over a single BGP session.

4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to all of them.

The RIBs in a box, but not RIBs in a different box have access to all the resources in the box.

--

Jakob Heitz.

________________________________
From: [email-masked] [[email-masked]] on behalf of Russ White [[email-masked]]
Sent: Monday, 29 July 2013 1:26 PM
To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern'
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

end
use in
database, and
purview

(Context1,10.1.1.0/24)
(Context2,10.1.1.0/24)

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Mon, 29 Jul 2013 19:20:53 -0400

> should be modeled is the box within which all the RIBs exist.

I would prefer not to get into modeling the physical box, or anything else
that reaches outside the routing system. IMHO, we're already trying to boil
the ocean... We should leave management of the box to the management folks,
as much as possible (IMHO), and attack the points where there are truly
unique, interactive, "things," we can do that the management folks haven't
already done.

:-)

Russ

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 29 Jul 2013 23:24:36 +0000

> 2. Physical ports. Any RIB can bind to any of them or any VLANs on them.

+1 to Russ's comments in prior email.

> 3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) over a single BGP session.

BGP L3VPN is a specific use-case. The RIB modeling avoid protocol specific modeling. Also we are not trying to replicate BGP here. So what is modeled here is the ability to inject routes into a bunch of tables (and the tables can be contained in routing-instances…aka VRFs).

> 4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to all of them.

These should be modeled as part of topology. Tunnels are nothing but virtual links in a topology.

Thanks

Nitin

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 30 Jul 2013 02:20:57 +0200

On Jul 30, 2013, at 1:20 AM, "Russ White" <[email-masked]> wrote:

> unique, interactive, "things," 

+1, the only reason the top level context might exist is as a root for i2rs clients to interact with (some basic info such as hostname could be provided to ensure you are talking to the right device...)

-Jon

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Jul 2013 23:37:19 -0700

+1 to Russ' comments.

Management context, top-level context, local-context, backbone-context, ...
etc should not influence whether this information should be at the
top-level of the modeling hierarchy.

- Sri

On Mon, Jul 29, 2013 at 5:20 PM, Jon Mitchell <[email-masked]>wrote:

> +1, the only reason the top level context might exist is as a root for
> i2rs clients to interact with (some basic info such as hostname could be
> provided to ensure you are talking to the right device...)
>
> -Jon
>

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 29 Jul 2013 23:52:54 -0700

Russ,

I am not not talking about the resolution of nexthops in another context.
BTW we have not modeled a "context", so there is every possibility we are
talking different things.

I am considering the case where there is more than one backbone to provide
BGP/MPLS IP VPNs. The use-case could be purely for administrative purposes.

If we put the restriction that there is a single backbone, then it is clear
as to how the VRF routing-instance traffic is tunneled over. So RIB could
be below the routing-instance in the hierarchy. If there can be multiple
backbones, then the relationship has to be expressed as to which backbone
the VRF is tunneled over. This information could be in a structure that is
not below the routing-instance in the hierarchy.

- Sri

On Mon, Jul 29, 2013 at 1:30 PM, Russ White <[email-masked]> wrote:

> So you're saying, "what if 10.1.1.0/24 in context 1 is reachable via
> 10.1.1.1 in context 2?" The primary way we describe this today is through
> tunneling, not through multiple VRF contexts... And I would never expect to
> have, "(10.1.1.0/24,context1) is reachable via (10.1.1.1,context2), and (
> 192.168.1.0/24,context2) is reachable via (10.1.1.1,context1)." In fact,
> I think all such situations are probably really dangerous in the real
> world, and operators would avoid them like the plague.
>
> But, again, I'm not saying this is a completely nonuseful construct, I'm
> just trying to figure out a specific use case for doing such a thing.
>
> :-)
>
> Russ
>
>

---

From: "Russ White" <[email-masked]>
Date: Tue, 30 Jul 2013 08:26:09 -0400

> BGP/MPLS IP VPNs. The use-case could be purely for administrative

If there are multiple backbones (I think you mean multiple VRFs across a single set of physical links here), then there wouldn't be one "RIB" at the "top of the hierarchy." There would be multiple "RIBs," with each one (possibly) bearing the same set of destinations IP address wise, while actually reaching different topological destinations in the network. The only way to make these multiple "RIBs" into a single "RIB," would be to include some form of context identifier, such as a VRF number or RD, to distinguish between the different destinations. 

Your argument actually argues against a single "RIB" at the top of the hierarchy, rather than for it. 

:-)

Russ

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 30 Jul 2013 12:40:12 +0000

Hi Carlos,

  Thanks for the detailed review. Please see inline below.

On 7/29/13 12:05 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

>As others have mentioned on the list, the concepts of RIB and routing
>instance seem to be inverted.

Yes, I have removed "RIB" as a top-level container to avoid the
confusion/inversion-issue.

>But in addition to that, there seem to be two other issues with the
>document in its current shape:
>1. It's not clear the scope of what's within the Routing Information Base
>information model. Specifically, elements defined seem to belong in the
>FIB and not the RIB.

Besides the routing table, which other elements did you have in mind.

Regarding "routing tables" as an element of the FIB, then I think it's a
terminology mis-understanding. A routing-table (as per this draft) is
something that is local to the control plane and has nothing to do with
the forwarding plane. A routing-table (as per this draft) is a database
containing route information. Now if this terminology conflicts/confuses
with how hardware vendors use the same term, I would be happy to change
the name to something else (maybe call it a RIB). I hope you now
understand why I did not think of it as a FIB construct.

>2. The document structure seems to have gaps and overlaps, and lacks a
>compiled set of definitions of RIB elements.

Compiled set of definitions of the elements is on my TODO list. I'll
likely add an Appendix at the end.

>CMP: What about other Sections? From 2.1 it jumps to Section 5

Will be cleaned up in next rev.

>can change" is what's meant.

Will fix.

>CMP: I think these set of definitions could use a visual to describe
>what's a RIB, routing instance, routing tables and their high-level
>elements, in addition to itemized definitions.

I have a UML diagram representing this, but there is no way to imbed
images in IETF drafts (maybe time to change IETF draft format?). I'll add
a text form of a diagram for readability.

>CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as
>routing instances. Which L3 elements are there in an L2VPN?

There are no L3 elements in a L2VPN. However, one can (if one really
wants) setup a static PW through the RIB model and then map MAC routes to
that PW. You can argue that MAC routes shouldn't be a part of this draft
and I'll be happy to remove it if there is consensus.

>CMP: DOes this mean that ARP should be out of the RIB model?

ARP should be out of the RIB model. ARP is a network-device local function.

>CMP: Should you also differentiate, in addition to the AF, by unicast

It would be good if someone kept unicast & mcast in different tables, but
the model does not enforce
that.

>CMP: Is RPF an attribute of the routing table?

In reality, RPF is an attribute of the route. But it's simpler if it is
associated with the entire table..so you do an RPF check for all routes in
that table. It is possible to move this as an attribute of the route and
if folks prefer that, it's an easy change.

>CMP: What is an "MPLS Route" in the context of a routing table?

MPLS route is nothing but a mpls label match.

>CMP: Is the MAC address a match element within routing?

MAC address is really not a routing concept. But given that we have mac
addresses being passed around in E-VPN and that VPLS deals with MAC
addresses, there was sufficient motive to add MAC address match.

>Or what types of address families and identifiers are input to defining
>the elements included?

I'm not sure if I understand the above question. AF_IP, AF_IPV6, AF_MPLS?

>CMP: Are things like the drop/null route fitting here? Are there many
>different kinds of specials, or should they be listed explicitly?

They should be called out explicitly someplace but not here. This is more
of an overview of the info model and putting in all the details in this
section would disturb the overall flow.

>                      <MPLS_TABLE_FAMILY> | <IEEE_MAC_TABLE_FAMILY>

It doesn't make sense to put IPv4 routes and IPv6 routes together.
Currently, routing vendors have well-defined table names that implicitly
identify the address family of routes in a given table. Intent here is to
remove that implicit assumption.

> 
>CMP: Do you need to separate IPv4 in unicast versus multicast? Or are you
>modeling a single table with attributes for the uni/multicast?

As I said before, it's up to the I2RS server (controller) to create
multiple tables (one for unicast and one for mcast). If the WG feel
strongly, we can enforce that in the model.

>CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"?

I don't know. Last I remember, in rBNF, all terminal stuff should be all
CAPS.

Thanks
Nitin

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 30 Jul 2013 12:57:48 +0000

Hi Tom,

Thanks for your comments. Please see inline below.

On 7/26/13 5:39 PM, "t.petch" <[email-masked]> wrote:

>tables sounds rather like a FIB.

with how some hardware vendors use the same term, I would be happy to
change

>nothing to do with the charter.

It's unclear to me how you program a route without an associated interface
where the data gets sent out. For example in OSPF, if one learns a route
via OSPF, you know from which neighbor you learnt it from and you know the
interface associated with it as well. That's how the router is able to
send the packets out to the destination.

In the case of DDOS mitigation, you might want to add a route that drops
packets from most offending prefixes. But for some of the offending
prefixes, you might want to forward the packets to a monitoring station (a
station that is directly connected to the router and does not speak IGP).
So the only way is to add a route pointing to an interface. This is very
similar to how static routes are configured on routers today. AFAIK, a lot
of operators use static routes and if we get rid of the "interface"
object, then a whole class of static routes cannot be programmed using the
RIB IM model. Similarly, you won't be able perform things like RPF
checkŠwithout which multicast will be crippled.

>data used by a protocol process instance

This is what is contained in the contents of the "routing table".

>- a central database of consolidated routes, sometime referred to as

This is not necessarily exposed to the external controller. At least it's
not easily possible in the current information model. The RIB IM draft
basically calls for programming routes in tables (say RIBs) and if a route
gets selected as the best route (Eg. For a given IP prefix), then the
external controller is informed that the route it programmed is now
installed and will be used by silicon for forwarding).

>- what gets used in forwarding, usually by the silicon.

This should not be exposed to the controllerŠsince it contains forwarding
details as well.

Thanks
Nitin

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Jul 2013 07:42:10 -0700

As Nitin already pointed out in another email we have removed RIB from the
top-level of the hierarchy. I wasn't arguing to make a single RIB at the
top of hierarchy, but rather seeing if by moving the RIB tables to under
routing-instance there would still be any information that would still make
sense at the top-level. It doesn't seem there is such information. Having
some context identifier is a given in any case.

On Tue, Jul 30, 2013 at 5:26 AM, Russ White <[email-masked]> wrote:

> If there are multiple backbones (I think you mean multiple VRFs across a
> single set of physical links here), then there wouldn't be one "RIB" at the
> "top of the hierarchy." There would be multiple "RIBs," with each one
> (possibly) bearing the same set of destinations IP address wise, while
> actually reaching different topological destinations in the network. The
> only way to make these multiple "RIBs" into a single "RIB," would be to
> include some form of context identifier, such as a VRF number or RD, to
> distinguish between the different destinations.
>

---

From: "Russ White" <[email-masked]>
Date: Tue, 30 Jul 2013 10:53:47 -0400

> >have nothing to do with the charter.
> 
via
> OSPF, you know from which neighbor you learnt it from and you know the
send the
> packets out to the destination.

Actually, it isn't... Routing protocols install routes to a next hop, which
is then recursed to find the best interface (or set of interfaces) by which
the local forwarding plane can reach that next hop. I would avoid telling
the RIB which specific interface to use, as this could have very negative
effects on load sharing and fast failover solutions --unless the specific
intent is to provide for load sharing on a per interface level in I2RS. I
would argue that's more of a job for OpenFlow than I2RS, though.

> station that is directly connected to the router and does not speak IGP).

You can do this with the full tuple in the IP header --you don't need the
interface for this specific use case (unless you're programming a switch,
which isn't where I2RS should be, IMHO).

> So the only way is to add a route pointing to an interface. This is very
similar
> to how static routes are configured on routers today. AFAIK, a lot of
> operators use static routes and if we get rid of the "interface"

I assume you're talking about a static to an interface. For this specific
case, I would argue that we should wait and see if that's really a
requirement --statics to interface aren't (normally) in operational best
practices, so I don't know the value of supporting them. For
point-to-points, just use the other end of the link, and for broadcast, a
static to an interface is generally not a really good idea (ARP cache). 

For uRPF and OILs, I'm not certain you need the interface... uRPF, for
instance, doesn't rely on direct programming of the expected inbound
interface, but rather the "previous hop" being examined recursively in the
routing table to figure out what the correct inbound interface is. You don't
want uRPF to break because the route to you from some specific source
changes... 

> This is not necessarily exposed to the external controller. At least it's
not
> easily possible in the current information model. The RIB IM draft
basically
> calls for programming routes in tables (say RIBs) and if a route gets
selected
> as the best route (Eg. For a given IP prefix), then the external
controller is
> informed that the route it programmed is now installed and will be used by
> silicon for forwarding).

Which is all only useful within the virtual context. It's been a long long
time since routers only had one "RIB."

:-)

Russ

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 30 Jul 2013 11:06:45 -0400

> static to an interface is generally not a really good idea (ARP cache). 

I'm not sure I agree with this... specifying interface + IPv4/v6 NH on
some platforms can be useful specifically to stop recursion when the
interface goes down by for a nexthop that otherwise may recurse (often
to an aggregate or default).  Whether it's required to program static
routes in i2rs I don't know, but if we plan to support it, a way to
stop undesired recursion would be useful.

Jon

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 30 Jul 2013 08:54:55 -0700

> intent is to provide for load sharing on a per interface level in I2RS. I

Even today routes can be added with nexthop as an interface. Consider a
static route with nexthop as a point-to-point unnumbered interface.

> would argue that's more of a job for OpenFlow than I2RS, though.

Great. Now we have another use-case for I2RS ;-)

- Sri

---

From: "Russ White" <[email-masked]>
Date: Wed, 31 Jul 2013 08:36:15 -0400

> I'm not sure I agree with this... specifying interface + IPv4/v6 NH on some
> platforms can be useful specifically to stop recursion when the interface goes
> down by for a nexthop that otherwise may recurse (often to an aggregate or
> default).  Whether it's required to program static routes in i2rs I don't know,
> but if we plan to support it, a way to stop undesired recursion would be
> useful.

Aha! Good point... This is a useful case, so I'm happy with leaving it in. 

:-)

Russ

---

From: Ken Gray <[email-masked]>
Date: Wed, 31 Jul 2013 14:31:00 +0000

The idea here/now is the model for programmability via I2RS, namely the RIB object(s) …the intent isn't to modify envmon or inventory from a programmability perspective (or anything else).

>From a "topology" extraction PoV, which we are not covering quite yet, interfaces/inventory are an adjunct bit of information that we'll probably have to deal with in that model (as "inactive topology")… Again as a topology model and not as a monitoring mechanism per-se.

>From a monitoring perspective -  as someone else said, let's leave the monitoring of these envmon/inventory objects to existing mechanisms.   If we start venturing into a generic programmatic interface for monitoring as a replacement for the existing mechanisms (because now we've got REST potentially abetted by Yang/NETCONF/?) we will bit off way more than we can chew … even if maybe one day we may get to that point.

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Mon, 29 Jul 2013 23:09:29 +0000
To: Russ White <[email-masked]<mailto:[email-masked]>>, "'t.petch'" <[email-masked]<mailto:[email-masked]>>, 'Nitin Bahadur' <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, "'Joel M. Halpern'" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Alia Atlas' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

Examples are:

--

Jakob Heitz.

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Russ White [[email-masked]<mailto:[email-masked]>]
Sent: Monday, 29 July 2013 1:26 PM
To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern'
Cc: [email-masked]<mailto:[email-masked]>; 'Alia Atlas'
Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

end
use in
database, and
purview

(Context1,10.1.1.0/24)
(Context2,10.1.1.0/24)

:-)

Russ

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