Subject: Re: [netmod] NetMod routing cfg

From: "Jmh.direct" <[email-masked]>
Date: Wed, 25 Jul 2012 06:15:37 -0700

Yes, that is what I meant.  Those ate used often to carty informstion brtween routing protocols.  A management station needs at leadt to be able to reaf thst information.  The simplest example of why is when that info is in error and causes problems.
Yours,
Joel

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: Re: [netmod] NetMod routing cfg 
From: Ladislav Lhotka <[email-masked]> 
To: Joel Halpern <[email-masked]>,NETMOD Working Group <[email-masked]> 
CC:  

Joel Halpern <[email-masked]> writes:

> In looking at the spec, and comparing with MIBs in the space, one thing 
> appeared to be missing.  I could not see an equivalent of the route-info

Do you mean this (from RFC 1213)?

  ipRouteInfo OBJECT-TYPE
      SYNTAX  OBJECT IDENTIFIER
      ACCESS  read-only
      STATUS  mandatory
      DESCRIPTION
              "A reference to MIB definitions specific to the
              particular routing protocol which is responsible
              for this route, as determined by the value
              specified in the route's ipRouteProto value.  If
              this information is not present, its value should
              be set to the OBJECT IDENTIFIER { 0 0 }, which is
              a syntatically valid object identifier, and any
              conformant implementation of ASN.1 and BER must be
              able to generate and recognize this value."
      ::= { ipRouteEntry 13 }

I thought it wasn't relevant to a YANG data model. How could it be used in our context?

> field used to represent tagging that is carried between routing 
> protocols by the RIB.

As I understand it, route tags are specific to protocols, e.g., OSPF has the 32-bit "External Route Tag" while RIP uses a 16-bit "Route Tag".

Thanks, Lada

>
> Yours,
> Joel
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jul 2012 16:06:07 +0200

> Yes, that is what I meant.  Those ate used often to carty informstion brtween routing protocols.  A management station needs at leadt to be able to reaf thst information.  The simplest example of w…

I am not able to find any examples of how this mechanism is used in practice and what value that field may contain - other than the default zeroDotZero. What can be a typical non-default value? 

In YANG terms, the "route-info" leaf would have the "instance-identifier" type, right? 

Lada

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Jul 2012 11:44:19 -0400

The basic model is that routing protocol one, when adding information to 
the RIB includes tag.  Routing protocol 2 carries that route 
information, with the tag.  In another router, the process is reversed 
so that the tag is preserved across the domain.  There are also other cases.

The point is that there were good reasons why the MIB included 
visibility to this information.  As such, it seems to me pretty odd for 
NetMod to unilaterally decide that it is NOT useful information.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jul 2012 23:21:43 +0200

On Jul 25, 2012, at 5:44 PM, Joel M. Halpern wrote:

> The basic model is that routing protocol one, when adding information to the RIB includes tag.  Routing protocol 2 carries that route information, with the tag.  In another router, the process is reversed so that the tag is preserved across the domain.  There are also other cases.

In my opinion, this is the role for route tags that are defined by some routing protocols and carried in their PDUs. I assume data models for such routing protocols will augment the set of route attributes with these tags and define means for configuring them, and data models for route filters will define means for using the tags when manipulating routes.

I must admit I don't get the connection between route tags and "a reference to MIB definitions specific to the particular routing protocol". Anyway, RFC 1213 also says in Sec. 3.7 that "ipRouteInfo" is IP routing protocol-specific.
 
> 
> The point is that there were good reasons why the MIB included visibility to this information.  As such, it seems to me pretty odd for NetMod to unilaterally decide that it is NOT useful information.

There was no such decision, the truth is that this issue has never been raised before. In my personal view, this parameter can be left to be defined by routing protocol data models, analogically to the five route metrics that are also defined by RFC1213-MIB, essentially as placeholders to be adopted by individual routing protocols.

I believe these generic placeholders are not needed in YANG.

Thanks, Lada

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Jul 2012 17:28:39 -0400

The whole point is that this RIB information is used to carry 
information between two instances of routing protocols (usually distinct 
protocols).  If there are problems with the information not being 
propagated properly, the network administrator will need to be able to 
check each step of the process.  That requires the ability to read this 
information from the RIB.

If you have specific evidence that this management information is no 
longer needed, I am willing to listen.  The information I have seen 
suggests it is still useful.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jul 2012 09:59:14 +0200

> information from the RIB.

Every protocol may create such information on its own (and in its own namespace), be it metrics, tags or whatever. If this information is passed between two instances of different protocols (more precisely between routing tables connected to either instance), then a reasonable default behaviour is to leave this information untouched.

> suggests it is still useful.

I am not saying this information is not needed, only that it is not necessary to pre-allocate the slot in the generic routing module, if the contents is to be generated in a specific way by routing protocols.

Maybe the difference lies in the fact that "ipRouteTable" is modelled as a table (one size fits all) in the MIB while the contents of each "route" entry in the YANG data model may be (partly) protocol-specific.

The "ipRouteInfo" field is intended (I assume) as a pointer to an additional object containing the protocol-specific information. In YANG, this information can be put directly to the particular "route" entry. The example RIP module in Appendix A adds its own "metric" and "tag" nodes, which are however valid only if "source-protocol" equals to "rip".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Jul 2012 10:11:20 +0200

> The "ipRouteInfo" field is intended (I assume) as a pointer to an additional object containing the protocol-specific information. In YANG, this information can be put directly to the particular "ro…

A few comments from the SNMP MIB side. The current IP routing table
MIB is in the IP-FORWARD-MIB published as part of RFC 4292. The
various ipCidrRouteInfo object is actually deprecated (and RFC 1213
routing tables can't do CIDR, thus are pretty much de factor historic
for a long time). The latest set of routing table MIB objects do not
have a *Info object anymore but only inetCidrRouteProto. In other
words, the routing table records information which routing protocol
provided the routing table entry and assume that a management
application knows how to retrieve further information if needed.

This brings me to my main question: Are we discussing how to expose
and track the information where a routing entry originates from or are
we discussing how information attached to a routing entry can be
passed between protocol instances? These are two different things and
I am not sure we keep them separated. (But perhaps I am also just a
bit confused. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jul 2012 14:11:06 +0200

> A few comments from the SNMP MIB side. The current IP routing table

Yes, thanks. ;-)

> application knows how to retrieve further information if needed.

It is certainly possible with our YANG data model because each route contains mandatory "source-protocol". But in YANG we have the option to put the additional protocol-specific information straight into route entries via augmentation, and make the new nodes conditionally valid only for a particular protocol type. The advantage of this approach is that all route information is nicely packed, hence easily available to route filters.

> I am not sure we keep them separated. (But perhaps I am also just a

Every single route must contain the information about the source protocol instance so the former is not an issue.

All information encapsulated in a route, including protocol-specific stuff, can be passed between routing tables (i.e. also between routing protocol instances), subject to route filters. I don't see any limitation here either.

Lada

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Jul 2012 10:05:57 -0400

It appears that I have confused myself by mixing information I thought 
was still visibly modeled. Apologies to Lada and the working group. 
Given that it appears to have been dropped from the MIBs, I don't have a 
leg to stand on to ask for it to be in the generic table.  (The 
information I was looking for was generic, not protocol specific, and 
could not be handled by protocol specific extensions.)  I am surprised 
the information is gone, but that is not this WGs problem at this point.

I presume that fields like nextHopAS would be handled in protocol 
specific extension, since that would apply only to  routes inserted by BGP?

I also presume that metric information, being specific to the individual 
routing protocols, would go in those extensions, rather than in the main 
table as done in RFC 4292?

The ability to modularize the information seems powerful.  To be useful 
for management, we are going to need those other pieces.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Jul 2012 17:28:18 +0200

On Jul 26, 2012, at 4:05 PM, Joel M. Halpern wrote:

> It appears that I have confused myself by mixing information I thought was still visibly modeled. Apologies to Lada and the working group. Given that it appears to have been dropped from the MIBs, I don't have a leg to stand on to ask for it to be in the generic table.  (The information I was looking for was generic, not protocol specific, and could not be handled by protocol specific extensions.)  I am surprised the information is gone, but that is not this WGs problem at this point.

I am glad it's been clarified - thanks, Juergen!

> 
> I presume that fields like nextHopAS would be handled in protocol specific extension, since that would apply only to  routes inserted by BGP?

Yes.

> 
> I also presume that metric information, being specific to the individual routing protocols, would go in those extensions, rather than in the main table as done in RFC 4292?

Yes.

> 
> The ability to modularize the information seems powerful.  To be useful for management, we are going to need those other pieces.

Right. I actually expect that data models for the more complicated stuff (protocols, filter) will reveal some shortcomings of the core routing model, so I guess we have to be prepared for some iterations.

Thanks, Lada