Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt

From: [email-masked]
Date: Thu, 05 May 2011 11:00:01 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

    Title         : A YANG Data Model for Routing Configuration
    Author(s)     : L. Lhotka
    Filename      : draft-ietf-netmod-routing-cfg-00.txt
    Pages         : 44
    Date          : 2011-04-27
    
   This document contains a specification of two YANG modules that
   together provide a data model for essential configuration of a
   routing subsystem.  It is expected that this module will serve as a
   basis for further development of data models for individual routing
   protocols and other related functions.  The present data model
   defines the building blocks for such configurations - routing
   processes, routes and routing tables, routing protocol instances and
   route filters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 5 May 2011 20:12:06 +0200

Hi,

this is a new version of the core routing data model. It now consists of two YANG modules, one of them just defines top-level containers and the other provides a basic framework for IPv4 unicast routing, and could serve as a model for other address families. Please send your comments to this mailing list.

Thanks, Lada 

Begin forwarded message:

> From: [email-masked]
> Date: May 5, 2011 8:00:01 PM GMT+02:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Thu, 5 May 2011 15:37:08 -0400

>    Title         : A YANG Data Model for Routing Configuration

There are a number of modern routing features that we should ensure
are incorporated.  I've not read the draft, but a quick skim found
no mention of logical routers, chained next-hops, etc.  I'm not
sure if these are add-ons that will be layered on top of the model
in later modules, but the picture with one FIB at the top makes me
nervous.  Do we have engagement from the routing community to ensure
our model reflects today's needs?

Also the use of the word "process" is confusing, since there should
be minimal implementation constraints placed on the system.  Even
the word "process" is heavily overloaded, with unix geeks thinking
you mean one thing and IOS users think another.  I'd avoid the word.

FWIW, in JUNOS, we call these "routing instances" and they run in
the single JUNOS routing protocol daemon (RPD) (where logical routers
get distinct daemons).  However any such internal processes mappings
are not visible to the user.

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 May 2011 17:23:44 -0400

Can you please elaborate a bit on the purpose of the model?
Is it to enable configuring static routes?
Is to to enable fetching the current forwarding behavior of the device?
is it to give access to the common RIB, which consolidates the effect of 
different routing protocols?
Is it ostensibly generic enough to serve as a bse, from whcih to 
subclass models for RIBs for different routing protocols?

Before I try to evaluate the proposed model, I need to know what purpose 
it is intended to fulfill.
(We have made the mistake before of building models for the sake of 
models.  That proves not to be useful.)

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 May 2011 13:38:17 +0200

> no mention of logical routers, chained next-hops, etc.  I'm not

The routing process is intended to represent a virtual router. I am not sure what "chained next-hop" exactly means but probably it requires a list of next hops instead of one? If it is not practical to achieve it via augmenting, we can change the model.

> in later modules, but the picture with one FIB at the top makes me

It's one FIB per routing process (virtual router).

> our model reflects today's needs?

Yes, we need to involve the routing community, Dan has already tried but I haven't seen any response yet.

> you mean one thing and IOS users think another.  I'd avoid the word.

I agree, but so is the word "virtual".

> are not visible to the user.

I was thinkink about "routing instances" but as there are also routing protocol instances, I thought it could be confusing.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 6 May 2011 13:54:20 +0200

On May 5, 2011, at 11:23 PM, Joel M. Halpern wrote:

> is it to give access to the common RIB, which consolidates the effect of different routing protocols?
> Is it ostensibly generic enough to serve as a bse, from whcih to subclass models for RIBs for different routing protocols?

I think it's mainly the last one, i.e. to provide a generic framework on which real data models for routing subsystems can be built (by other WGs). It's not that much about subclassing but rather about augmenting the framework.
 
> 
> Before I try to evaluate the proposed model, I need to know what purpose it is intended to fulfill.
> (We have made the mistake before of building models for the sake of models.  That proves not to be useful.)

The purpose is stated in the WG charter. I sort of expect that my initial concepts will prove to be somewhat naive but we have to start somewhere.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 May 2011 10:35:03 -0400

The largest problem I see is the confusion between RIB and routing process.
For example, BGP is normally run as a single routing process, exchanging 
multiple protocols with multiple neighbors.  It conceptually maintains a 
separate RIB-IN for the information it receives from each neighbor, a 
consolidate RIB for what it has concluded, and a RIB-Out for each 
neighbor for what it will send to each neighbor.

An additional item that confused me is that the routing process seems to 
have a mandatory operation for deleting routes.
 From a system perspective, you can create, delete, and modify static 
routes.
On some systems there are ways to prevent the system as a whole from 
learning a route from some routing protocol.  But you may not reach in 
and delete the routes that a given routing protocol is learning / using. 
  That would break the routing protocol.

There is an additional reason that most modeling efforts have tried to 
model only the central rib where the system decides what to make of all 
the information it gathers.  That can be meaningfully represented 
independently of the routing protocol.
In contrast, for example, OSPF does not represent a RIB.  Rather, it 
represents the link state information.

And if you try to represent each RIB, then you are inviting the problem 
of how to represent the interaction between the RIBs.  If you actually 
know a common abstraction across the vendors for how we look at that, it 
would be very powerful.

Yours,
Joel