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

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 May 2011 10:32:16 -0400

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 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 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.

Yours,
Joel M. Halpern

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 May 2011 18:27:35 +0200

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.
> 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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 May 2011 20:41:32 -0400

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

---

From: "t.petch" <[email-masked]>
Date: Thu, 26 May 2011 18:09:43 +0200

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

> > 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.
> >> 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.
> >> (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.
> >
> > 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.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 May 2011 11:04:58 -0700

> I think that this discussion is premature and on the wrong list:-(

You have identified one of the key reasons why standard configuration
has been so difficult to achieve.

The domain experts don't really know the data modeling stuff,
and the data modeling experts don't really know the domain stuff.

I think our AD already looked into getting us a routing expert to help
with early review the YANG models. So that should be the next step.

> nor do I share Lada's, but do not know if any of us are right.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 May 2011 21:21:21 -0400

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:
> From: "Joel M. Halpern"<[email-masked]>
> To: "Ladislav Lhotka"<[email-masked]>
> Cc: "NETMOD Working Group"<[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 May 2011 10:02:26 +0200

Tom,

I absolutely agree. In order to get the generic framework right, one has to know quite precisely the needs of all the various routing protocols and address families that will be supported, including things like multicast and MPLS.

Routing experts should be heard now, and I hope that by criticizing my initial data model, they will be able to come up with something better.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "t.petch" <[email-masked]>
Date: Fri, 27 May 2011 18:07:35 +0200

----- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>; "NETMOD Working Group"
<[email-masked]>
Sent: Friday, May 27, 2011 10:02 AM

Tom,

I absolutely agree. In order to get the generic framework right, one has to know
quite precisely the needs of all the various routing protocols and address
families that will be supported, including things like multicast and MPLS.

Routing experts should be heard now, and I hope that by criticizing my initial
data model, they will be able to come up with something better.

Lada

My starting point is that there are four kinds of routers with different,
perhaps incompatible, requirements.
- DFZ Gbps routers, with (almost) everything on the line card and most of that
is MPLS switching, not routing
- CPE routers, probably the most numerous in the world, the simplest (what's a
routing protocol?) but because they are CPE in the most need of management
- middle of the road, blades in chassis, alongside switch, hub, management etc
blades (which is what I am most familiar with)
 - the host I am using to create this:-)

You make mention of MPLS which makes me think you are focussing on the first and
while its needs are great, it also has the most skilled staff and support, will
be most manufacturer dependent and perhaps with the least need of
standardisation by us since the proprietary modules will do everything so much
better.  I remember well when first I looked at the CISCO MIB for an entry level
router; the proprietary modules had 10 times as many objects as the standard MIB
would have had and had everything I needed; perhaps it is the last we should
focus on.

Tom

PS my PC says that your e-mail is 'secure' but that the security is faulty:-(

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 May 2011 11:26:26 +0200

Hi, 

Speaking from the perspective of the AD and answering different comments
made about the placement of this work and the participants. 

I agree in principle with the point that specialized YANG models should
be standardized in the WGs that are responsible with the technology.
However, as YANG modelling is at its first steps (and RFCs) we decided
to have this first routing module standardized in NETMOD, where all the
experts in YANG are, while inviting experts from the routing area to
participate in the process. Joel was the first who engaged, now Tom
joined the discussions, we hope to have more routing people
participating in the discussions - and I am copying the routing ADs with
the hope that another plea on this respect will result into a broader
participation. 

Later, as we did with MIBs we want the WGs in the other areas of the
IETF and out of the IETF to take over. Now what is important is to get
YANG experts and routing experts together to work on this module. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joel M. Halpern
> Sent: Friday, May 27, 2011 4:21 AM
> To: t.petch
> Cc: NETMOD Working Group
> >> protocols, these are NOT modifiable.  Modification is generally
done
> by
> >>>> I sent a question about this several weeks ago.  I apologize if
> there was a
> > clear answer which I missed.
> >>>>
> > routing process.  The reality is quite different from the document
in
> several
> > routing process may maintain several RIBs.  it may manitain only
one.
> It also
> > routing process is essentially a "virtual router", so, by
definition,
> its
> > routing information is not shared with other virtual routers. I
think
> that what
> deleting
> > routes learned by other routing protocols can be filtered before
they
> are
> >>>> (And there may be separate knobs affecting the way the system
uses
> the RIB