Subject: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-00.txt

From: Nitin Bahadur <[email-masked]>
Date: Tue, 25 Jun 2013 18:55:03 +0000

Folks,

  We have just posted an initial version of the RIB information model.
Looking for feedback and collaborators who can help improve/add-to the
draft.

Thanks
Nitin

On 6/25/13 11:47 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-nitinb-i2rs-rib-info-model-00.txt
>has been successfully submitted by Nitin Bahadur and posted to the
>IETF repository.
>
>Filename:	 draft-nitinb-i2rs-rib-info-model
>Revision:	 00
>Title:		 Routing Information Base Info Model
>Creation date:	 2013-06-25
>Group:		 Individual Submission
>Number of pages: 21
>URL:             
>http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-00.tx
>t
>Status:          
>http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model
>Htmlized:        
>http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-00
>
>
>Abstract:
>   Routing and routing functions in enterprise and carrier networks are
>   typically performed by network devices (routers and switches) using a
>   routing information base (RIB).  Protocols and configuration push
>   data into the RIB and the RIB manager install state into the
>   hardware; for packet forwarding.  This draft specifies an information
>   model for the RIB, to build a standardized RIB model, using which an
>   external entity (external to the network device) can read and write
>   information from/to the RIB.
>
>                  
>        
>
>
>The IETF Secretariat
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 25 Jun 2013 15:05:46 -0400

Thanks for posting this!  I look forward to lively discussion :-)

Alia

On Tue, Jun 25, 2013 at 2:55 PM, Nitin Bahadur <[email-masked]> wrote:

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Jun 2013 14:42:43 +0200

Hi,

this work, or at least its general parts, is closely related to the following work item of the NETMOD WG:

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

I tried to compare these two documents, and IMO the match is pretty good. Paradoxically, the match would be even better if we take one of the previous revisions of the routing-cfg documents because some constraints that were originally present have been relaxed in the meantime (details follow).

I think it would make a good sense to coordinate these two efforts, and it should't be difficult.

Specific comments:

1. What you call "routing instance" is very similar to "router (instance)" in routing-cfg. Interfaces are also assigned to each router instance, but we don't require (since rev. -03) that the sets of interfaces assigned to different router instances be disjoint. One use case is that two router instances may be used for different address families, e.g., instance A for IPv4 and B for IPv6. Then the same interface may be used in A for IPv4 traffic and in B for IPv6. Perhaps this also depends on the definition of "interface".

2. Until rev. -05, each routing table was also confined to one router instance. This was relaxed based on the following comment of a Routing Directorate reviewer (Thomas Morin):

"Allowing multiple "routers" is a good starting point for using these specs in the context of RFC4364
(MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the way the filters are defined would
not work in the context of RFC4364, where a BGP routing instance in the master "router" exports selected
routes in each of the routing table of each VPN (VRF).  The VRF also export routes to the master
instance."

3. Route attributes, nexthops etc., as specified in draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG data model via augmentation. We expect this will be done by future YANG modules defining data models for routing protocols, such as BGP. For example, an entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module.

4. The data model in routing-cfg doesn't define any event notifications yet, though I think there have already been some proposal. I think we can add the two that you mention in sec. 5.

5. Routing tables can be inspected in the same way as other operational state data, i.e., via the standard NETCONF operation <get>. However, we also have two special RPC operations:

   o  active-route: query the routing system for the active route(s)
      that are currently used for sending datagrams to a destination
      host whose address is passed as an input parameter.

   o  route-count: retrieve the total number of entries in a routing
      table.

Cheers, Lada

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Jun 2013 09:01:46 -0400

Hi Lada,

The draft you mention is certainly of interest - particularly if I2RS
requirements for a data modeling language result in selecting YANG.

A couple quick points on your comments though.

The next-hops are largely the POINT of this info-model.   The organization
into route-tables and then route-instances allow different ones to be
applied to different interfaces and such.  So, saying that the nexthops can
be easily added via augmentation is saying that a very key feature is not
yet there.  Similarly, the event notifications are also a key point of the
info-model ; that is how different i2rs clients can learn dynamic
information.

Having a comparison and thinking about how to extend the existing YANG
model is certainly interesting - but I think it's important to get and
agree on the info-model first.

It's also clear that there are large critical aspects that are missing and
needed (from the I2RS perspective).

Alia

On Wed, Jun 26, 2013 at 8:42 AM, Ladislav Lhotka <[email-masked]> wrote:

> I tried to compare these two documents, and IMO the match is pretty good.
> Paradoxically, the match would be even better if we take one of the
> previous revisions of the routing-cfg documents because some constraints
> that were originally present have been relaxed in the meantime (details
> follow).
>
> 1. What you call "routing instance" is very similar to "router (instance)"
> in routing-cfg. Interfaces are also assigned to each router instance, but
> we don't require (since rev. -03) that the sets of interfaces assigned to
> different router instances be disjoint. One use case is that two router
> instances may be used for different address families, e.g., instance A for
> IPv4 and B for IPv6. Then the same interface may be used in A for IPv4
> traffic and in B for IPv6. Perhaps this also depends on the definition of
> "interface".
>
> 2. Until rev. -05, each routing table was also confined to one router
> instance. This was relaxed based on the following comment of a Routing
> Directorate reviewer (Thomas Morin):
>
> 3. Route attributes, nexthops etc., as specified in
> draft-nitinb-i2rs-rib-info-model-00, can be easily added into the YANG data
> model via augmentation. We expect this will be done by future YANG modules
> defining data models for routing protocols, such as BGP. For example, an
> entry like your ISO_SYSTEM_ID can be augmented by an IS-IS module.
>
> 4. The data model in routing-cfg doesn't define any event notifications
> yet, though I think there have already been some proposal. I think we can
> add the two that you mention in sec. 5.
>
> 5. Routing tables can be inspected in the same way as other operational
> state data, i.e., via the standard NETCONF operation <get>. However, we
> also have two special RPC operations:
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Jun 2013 16:20:13 +0200

Hi Alia,

> info-model ; that is how different i2rs clients can learn dynamic

As I said, the two notifications will be added in the next revision. However, it is important to note that, by design, the data model in routing-cfg is mainly a skeleton or framework providing placeholders for real stuff (routing protocol or route filter data) to be filled in. As a proof of concept, I can certainly try to write a YANG module that augments the specific items defined in i2rs-rib-info-model, should you find this exercise useful.

> agree on the info-model first.

The text of the routing-cfg draft in fact presents an information model, and in a very similar structure as the present draft (routing/router instances, routing tables, routes, but in addition also routing protocol instances and route filters). I think we should be able to agree on a common information model, even if the I2RS WG decides to use something else than YANG for data modelling.

>From the NETMOD perspective, these critical aspects are eagerly waiting to be augmented into the existing YANG data model. :-)

Lada

---

From: Alia Atlas <[email-masked]>
Date: Wed, 26 Jun 2013 10:57:03 -0400

Lada,

Your enthusiasm is awesome - and I totally agree on trying for a common
info-model!  I just don't want to assume that everything has to be
expressed in the hierarchy of YANG.  I think that Joel had some opinions on
the different expressiveness in different data-models.   It's likely that
the RIB info-model is a good place to start exploring that and helping to
derive requirements.

I do think that the RIB info-model isn't expecting the "real-stuff" to come
from elsewhere - but rather is expressing this particular layer fully.

Before you start trying to write a YANG module to do the augmentation, you
probably want to touch base with Nitin and see where he is on that (other
than on Pacific Time).

Regards,
Alia

On Wed, Jun 26, 2013 at 10:20 AM, Ladislav Lhotka <[email-masked]> wrote:

> As I said, the two notifications will be added in the next revision.
> However, it is important to note that, by design, the data model in
> routing-cfg is mainly a skeleton or framework providing placeholders for
> real stuff (routing protocol or route filter data) to be filled in. As a
> proof of concept, I can certainly try to write a YANG module that augments
> the specific items defined in i2rs-rib-info-model, should you find this
> exercise useful.
>
> >
> The text of the routing-cfg draft in fact presents an information model,
> and in a very similar structure as the present draft (routing/router
> instances, routing tables, routes, but in addition also routing protocol
> instances and route filters). I think we should be able to agree on a
> common information model, even if the I2RS WG decides to use something else
> than YANG for data modelling.
>
> >
> From the NETMOD perspective, these critical aspects are eagerly waiting to
> be augmented into the existing YANG data model. :-)
>
> Lada
>
> >
> > Alia
> >
> >
> >> I think it would make a good sense to coordinate these two efforts, and
> it
> >> should't be difficult.
> >>
> >> Specific comments:
> >>

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 26 Jun 2013 18:10:29 +0000

Hi Ladislav,

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

Yes. I agree and I've been aware of this document all along.

>it should't be difficult.

Agree again.

>
>Specific comments:
>
>1. What you call "routing instance" is very similar to "router
>(instance)" in routing-cfg. Interfaces are also assigned to each router
>instance, but we don't require (since rev. -03) that the sets of
>interfaces assigned to different router instances be disjoint. One use
>case is that two router instances may be used for different address
>families, e.g., instance A for IPv4 and B for IPv6. Then the same
>interface may be used in A for IPv4 traffic and in B for IPv6. Perhaps
>this also depends on the definition of "interface".

Interface is not address family specific. It's not clear why one would
need 2 router instances, one per address type. The way I've been modeling
this is how I've seen customers use interfaces. They associate all
features with a given interface as part of one domain. So everything
related to a given GigE interface (like routes, VPNs, etc) are managed in
a wholesome way.

>export routes to the master

IMO this is the export-import policy stuff (that I left out on purpose in
rev -00). IMO, import-export between tables in different router instances
should be supported/allowed. But that does not mean the tables need to be
in multiple router instances. Based on your knowledge of Yang, do you
think it's not possible to define import-export of routes between tables
in different instances?

Rest of your comments were data-model specific, which I will defer for now
(we'll take that up on a separate thread).

Thanks
Nitin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Jun 2013 11:39:37 +0200

> the RIB info-model is a good place to start exploring that and helping to

Yes, absolutely. It is actually important for our work in NETMOD to make sure that the I2RS info model can be expressed in our YANG framework, because otherwise it won't most likely be useful for anything else.
 
> probably want to touch base with Nitin and see where he is on that (other

Yes, this is already taking place.

Thanks, Lada

>> (instance)"

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Jun 2013 14:33:28 +0200

Hi Nitin,

...

> need 2 router instances, one per address type. The way I've been modeling

One use case, though perhaps not very typical, is the BIRD routing software, which uses separate daemons for IPv4 and IPv6. 

> related to a given GigE interface (like routes, VPNs, etc) are managed in

Right, I guess it's just a matter of definition. And it's fine either way because the routing-cfg I-D also states:

   Implementations MAY specify additional rules for the assignment of
   interfaces to logical routers.  For example, it may be required that
   the sets of interfaces assigned to different logical routers be
   disjoint.

> should be supported/allowed. But that does not mean the tables need to be

OK, then I misunderstood the following sentence in sec. 2.2: "Each routing table MUST belong to some routing instance." I thought this meant that such exports/imports between different router instances are imposible.

> (we'll take that up on a separate thread).

OK.

Thanks, Lada