Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt

From: "t.petch" <[email-masked]>
Date: Thu, 2 Jun 2011 14:19:01 +0200

I said that I had a different terminology for routers (as well as a
classification by size).  I was reminded of a post to the IDR list which asked
if there could be more than one BGP process in a router, to which the answer was
that IDR was not a suitable forum for that discusion; but it did prompt me to
investigate and I could not find a router that had this capability, whereas it
is a commonplace for OSPF (I did not look at IGRP or EIGRP).

So a router is an engine with multiple processes running routing protocols -
BGP, OSPFs, EIRGP, RIP, ... - with, crucially, the ability to bring together
information from different sources - routing protocols, configuration - to form
a single, coherent table which is used for forwarding packets.  For me, each
routing protocol instance has a RIB, the form of which is routing protocol
dependent, so that the RIP RIB and the OSPF RIB have nothing in common.  The
single table I call a FIB (whereas Joel seems to be using RIB2 for this).  If
the information cannot be brought together, then I call that multiple routers,
perhaps virtual routers sharing the hardware platform.

But as I said before, at the top end they become (MPLS) switches and stop being
routers at all.

I see a lot of activity in MPLS and CCAMP (GMPLS) on MIB modules, but not the
same support for an updated BGP MIB module.  Which is why I wonder if the most
useful netmod router module would be targetted at Windows and CPE routers, ie
entry level.

I am also surprised that this I-D does not have RFC4292 as a normative
reference; that for me would be a starting point.

Tom Petch

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Ladislav Lhotka" <[email-masked]>; "NETMOD Working Group"
<[email-masked]>
Sent: Friday, May 27, 2011 3:21 AM
Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt

> It would be hard for the discussion to be premature.  Waiting until the
> working group finished with the document, and then raising these issues,
> when I noticed them early, would be rather rude of me.
> As for whether it is the right list, this working group is working on
> the document.  Unless the chairs and ADs decide to move it, this is the
> place to discuss it.  (Yes, normally, MIB and other kinds of modeling is
> done in the subject matter working group.  The RTGWG does not have the
> time to take this as its primary work item :-)
>
> As for the view of modeling, I can well believe that there is a better
> model.  Lada reasonably asked me to put a starting alternative on the
> table.  That seemed a fair request, and putting the alternative forward
> might help folks understand my objection to the WG document.  So I
> sketched something.  I tried to make it match the range of routers,
> routing protocols, and protocol implementations I have worked with over
> the years.  A cleaner model than I suggested would be very helpful.
>
> Yours,
> Joel
>
> On 5/26/2011 12:09 PM, t.petch wrote:
> > Joel
> >
> > I think that this discussion is premature and on the wrong list:-(
> >
> > I would like to see a routing list, eg routing area WG, discuss
> > what the model of a router should be, and then have this list turn that
> > into Yang (or whatever).  I think that the experience of people like
> > Curtis is needed to come up with something that lasts.  RFC1213
> > has not stood the test of time and I would not expect this to.
> >
> > In passing, I do not share your view of routers and routing terminology, and
> > nor do I share Lada's, but do not know if any of us are right.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Joel M. Halpern"<[email-masked]>
> > To: "Ladislav Lhotka"<[email-masked]>
> > Cc: "NETMOD Working Group"<[email-masked]>
> > Sent: Wednesday, May 25, 2011 2:41 AM
> > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt
> >
> >
> >> Two comments, brought to the front for clarity.  I have retained the
> >> whole note for context, although we should probably trim it soon.
> >>
> >> 1) The difference between virtual router, virtual routing protocol,
> >> routing process or routing protocol instance as you intended it is not a
> >> big deal.  However, you should understand that vendors have used those
> >> terms in different ways to represent very different things.
> >>
> >> 1') More importantly, if you are talking about configuring a routing
> >> protocol, you have to get teh granularity right.  It is not possible, in
> >> BGP, to have different hold times for different address families.  The
> >> different address families are all using the same TCP exchange over the
> >> same ports, managed by the same protocol machinery.  So when one tries
> >> to configure a routing protocol, if you define that to be a single
> >> address family, and to be separate for unicast and multicast, you make
> >> it MORE complicated to represent the realities.
> >>
> >> With regard to the RIBs, what I would recommend is NOT to try to model
> >> the per-protocol RIB.  Rather, model
> >> 1) The central, protocol independent, RIB, ala RIB2
> >> 2) The policies and priorities by which things get into the RIB, which
> >> can be configured.
> >> 3) The individual routing instances.  This model should allow for
> >> multiple instances of different protocols, but not require it
> >> 3a) For each routing protocol instance, the policies by which it
> >> extracts information from the common RIB, and the policies by which it
> >> adds information to the common RIB
> >> 3b) The routing data structure specific to the protocol.  For most
> >> protocols, these are NOT modifiable.  Modification is generally done by
> >> policies, not by manipulating the data. For IS-IS and OSPF, we would
> >> want to model the link state database.  For BGP, we would want to
> >> advertise the RIB-IN, the BGP decision RIB, and the RIB out.  The BGP
> >> structure needs to include the BGP attributes, like the path, and has to
> >> be organized in terms of the NLRI.  It has to represent the fact that
> >> several NLRI can share the same properties.  (This may change in the
> >> future, but is currently the case.)  I would NOT recommend trying to
> >> represent the IS-IS Link State Database using the same parent structure
> >> as the BGP RIB.  (It is probably not even worth trying to create a
> >> common parent for the OSPF and IS-IS LSDB.)   And I would not use the
> >> same structure for the BGP RIB as for the central RIB.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote:
> >>> Joel,
> >>>
> >>> I have to apologize, you didn't miss anything. Your comments are quite
> > far-reaching, so I had no quick answer and then had to work on other things.
> >>>
> >>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote:
> >>>
> >>>> I sent a question about this several weeks ago.  I apologize if there was
a
> > clear answer which I missed.
> >>>>
> >>>> The document seems to have a major problem of mixing the notions of RIB
and
> > routing process.  The reality is quite different from the document in
several
> > regards.  Conceptually, RIB and Routing Process are orthogonal concepts.  A
> > routing process may maintain several RIBs.  it may manitain only one.  It
also
> > may pull information from
> >>>
> >>> There may be a terminological confusion, as Phil already pointed out. A
> > routing process is essentially a "virtual router", so, by definition, its
> > routing information is not shared with other virtual routers. I think that
what
> > you call "routing process" is a "routing-protocol-instance" in my
terminology.
> >>>
> >>> On the other hand, each routing-process (= virtual router) is limited to a
> > single address family (AFI+SAFI), in order to make the data model extensible
and
> > manageable. From a practical point of view, is it a serious limitation?
> >>>
> >>>> RIBs beyond the one or ones it maintains.  It may work with one address
> > family, or several.  It may handle only unicast, only multicast, or both.
> >>>> And, conversely, some routing protocols do not operate in terms of
> > maintaining a RIB (although they still have to interact with one or more
RIBs at
> > the edge.
> >>>>
> >>>> I get further confused by the placement of operations like one for
deleting
> > routes in the routing protocols.  If a routing protocol learns a route, you
> > generally MUST NOT delete it.  Depending upon the routing protocol, you may
or
> > may not have knobs to
> >>>
> >>> I think this "MUST NOT" only applies to link-state protocols, otherwise
> > routes learned by other routing protocols can be filtered before they are
> > imported to a routing table.
> >>>
> >>> In any case, the "delete-route" operation can be removed and other
> > operations/knobs added, this area is open to further discussion. I just
wanted
> > to include at least one rpc statement in the module to make people that are
not
> > very familiar with YANG aware of the possibility to define new operations.
> >>>
> >>>> control whether it is used.
> >>>> (And there may be separate knobs affecting the way the system uses the
RIB
> > output from the routing protocol, but that is a different matter.)
> >>>>
> >>>> Normally, modeling has concentrated on the central RIB, with its policy
and
> > data.  Routing protocol configuration has focussed on the individual knobs
for
> > the routing protocols.  And instances are handled on a case by case basis.
> >>>> Better commonality is good.
> >>>> Mixing the concepts of RIB and Routing protocol instance is at best VERY
> > confusing, and possibly worse.
> >>>
> >>> Could you sketch how the data model should be organized? I am not sure
that
> > the concept of a central RIB fits existing implementations with policy
routing,
> > where sets of routes can be filtered, manipulated and redistributed between
> > routing protocols in many different ways.
> >>>
> >>> Thanks, Lada
> >>>
> >>>>
> >>>> Yours,
> >>>> Joel M. Halpern
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> --
> >>> Ladislav Lhotka, CESNET
> >>> PGP Key ID: E74E8C0C
> >
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 2 Jun 2011 16:25:18 +0200

> is a commonplace for OSPF (I did not look at IGRP or EIGRP).

In JUNOS documentation I found this:
"You can create multiple instances of BGP, IS-IS, LDP, Multicast Source Discovery Protocol (MSDP), OSPF version 2 (usually referred to simply as OSPF) ..."

> a single, coherent table which is used for forwarding packets.  For me, each

Some implementations allow for creating additional routing tables, and their connections to routing protocols, as well as the exchange of information between routing tables, are configurable. This is what the I-D tries to emulate.

> reference; that for me would be a starting point.

I think it's much more important that the YANG framework for routing be an acceptable common ground, or lingua franca, for the existing popular router configuration languages (CLIs). My preliminary research involved three of them.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 02 Jun 2011 11:40:06 -0400

I think we mostly agree Tom.  The reason I use RIB2 rather than FIB is 
that the structure that brings the information together is often 
organized so as to allow conflicts, which the central process resolves 
in building the actual FIBs which are sent to / used by the individual 
line/forwarding cards.  (Trying to cover all the archtiectures in a 
single sentence produces awkwardness.  Sorry.)

Yours,
Joel

On 6/2/2011 8:19 AM, t.petch wrote:
> To: "t.petch"<[email-masked]>
> Cc: "Ladislav Lhotka"<[email-masked]>; "NETMOD Working Group"
> <[email-masked]>