Subject: [mpls] New draft Submission: draft-kumar-mpls-fec-to-nhlfe-mib-01.txt

From: Subodh Kumar <[email-masked]>
Date: Thu, 23 Jul 2009 11:39:40 +0530

Hi All, 

  I have submitted the draft with below link which defines an alternate
for RFC 3814. Pls share you comments on this:

http://www3.ietf.org/proceedings/staging/draft-kumar-mpls-fec-to-nhlfe-m
ib-01.txt

Also, I request for adoption it as a WG item.

Thanks

Subodh

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 23 Jul 2009 07:32:04 -0400

It doesn't appear in the repository as of this morning.

	Anyways, it might be useful for you to explain why we need to redo  
RFC3814.

	--Tom

> Hi All,
>   I have submitted the draft with below link which defines an  
> alternate for RFC 3814. Pls share you comments on this:
>
>    http://www3.ietf.org/proceedings/staging/draft-kumar-mpls-fec-to-nhlfe-mib-01.txt
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Subodh Kumar <[email-masked]>
Date: Thu, 23 Jul 2009 17:44:37 +0530

>	It doesn't appear in the repository as of this morning. 

Pls use the following url:
     http://www.ietf.org/id/draft-kumar-mpls-fec-to-nhlfe-mib-01.txt

>
>	Anyways, it might be useful for you to explain why we need to 
> redo RFC3814.

There are some reasons that are suggested in section 5 of the proposed draft:
  - Each entry in the mplsFTNTable table corresponds to a FIB entry. Unfortunately, the indexing structure appears complex and is not easy to implement. And even if it were implementable, given the indexing structure, the only way to retrieve data from the MIB would be to walk the entire table. The proposed document simplifies the indexing structure by using a structure similar to the forwarding table (ipCidrRouteTable).

  - The mplsFTNMapTable maps mplsFTNTable entries to the interfaces upon which they are applied. This would make sense if a router maintained a separate forwarding table for each incoming interface. I doubt if any routers do this.
 
  - The mplsFTNPerfTable maintains per route performance statistics. It is highly unlikely that anybody maintains such statistics.

Pls share on your valuable inputs.

Thanks
Subodh

________________________________________
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, July 23, 2009 5:02 PM
To: Subodh Kumar
Cc: [email-masked]
Subject: Re: [mpls] New draft Submission: draft-kumar-mpls-fec-to-nhlfe-mib-01.txt

	Anyways, it might be useful for you to explain why we need to redo RFC3814.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 23 Jul 2009 10:12:05 -0400

>     http://www.ietf.org/id/draft-kumar-mpls-fec-to-nhlfe-mib-01.txt

	Got it. Thanks.

>  - Each entry in the mplsFTNTable table corresponds to a FIB entry.  
> Unfortunately, the indexing structure appears complex and is not  
> easy to implement. And even if it were implementable,

	It is implementable; I've implemented it as have a number of vendors  
over the years. 8)
In fact, an informal poll I took about 4 or 5 years ago showed that  
the core set of MIBs (RFC3811,
12, 13, 14 and 15) had been implemented at least in part, by about 20  
vendors and NMS vendors.

> given the indexing structure, the only way to retrieve data from the  
> MIB would be to walk the entire table. The proposed document  
> simplifies the indexing structure by using a structure similar to  
> the forwarding table (ipCidrRouteTable).

	I guess that depends on how your FIB is indexed. I will be the first  
to admit that the indexing structure
isn't perfect, but it was designed to be flexible enough to  
accommodate the many implementations that contributed
to the design when we built the MIB many years ago.  It was also  
designed to handle the many different
contingencies afforded by RFC3031 as well as follow-ons to this such  
as multicast.

>  - The mplsFTNMapTable maps mplsFTNTable entries to the interfaces  
> upon which they are applied. This would make sense if a router  
> maintained a separate forwarding table for each incoming interface.  
> I doubt if any routers do this.
>
>  - The mplsFTNPerfTable maintains per route performance statistics.

	Yes.

> It is highly unlikely that anybody maintains such statistics.

	Guess again, some do/did for sure. *)  Again, the MIB wasn't designed  
to work in theory;
it was designed originally with inputs from many vendors.

	Speaking as an operator now, what I want to avoid here is the fiasco  
we had with the
TE-TE-MIB where we designed a separate TE MIB and standardized what  
ultimately was a proprietary MIB from
one vendor -- and you know who you are Kireeti *) -- supported by  
operators that used that vendor's equipment
only.  What we at BT want are MIBs that are interoperable and multi- 
vendor. My OSS is so expensive to
design and run already that I don't want to have to have any more  
special management per-vendor than I
have already. However, if other vendors and operators support  
modifying/augmenting RFC3814 let us do it,
but if this is just an effort as it seems you said above -- to support  
your particular FIB design -- I
am not for that.

	--Tom

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 Jul 2009 17:41:23 -0400

Tom,

While RFC 3814 may not be totally unimplementable, I think that it does
deserve a bis-version. The following are rationale:

In RFC 3814, mplsFTNEntry is indexed by mplsFTNIndex. mplsFTNIndex is an
unsigned integer representing the entry's relative position in the table
(1,2,3,4).

If someone wanted to walk the entire table, this would be all well and
good. However, sometimes you might want to look for a particular entry
in the table. In that case, indexing becomes much more important.

The current indexing structure allows you to perform a GET by relative
position in the table (e.g., Get me the 102nd entry in the routing
table). I think that Subodh proposes a much more useful indexing
structure, mimicking ipCidrRouteTable, which has proven very useful over
the years.

Since we need to open the draft to address indexing problems, now would
be a very good time to also revisit the issue of per route statistics.
With the operational experience we have behind us today, would we still
include the mplsFTNPerfTable in the standard?

                                      Ron

Thomas Nadeau wrote:
> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Jul 2009 10:08:15 +0100

[Individual contributor mode]

Revising a MIB module is extremely disruptive to implementations.

Aren't there ways of handling the indexing problem without requiring to 
respin the entire MIB module?
For example, one could define a new table, indexed as you want that allows 
you to read the (numeric) index to the new table.

So, the "while we have the draft open" explanation does not hold. Instead, 
can we pick through the issues and decide whether a revision or an extension 
is more appropriate?

(Oh, and avoiding emotive language describing other people's work)

Cheers,
Adrian

----- Original Message ----- 
From: "Ron Bonica" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>
Cc: "Subodh Kumar" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 23, 2009 10:41 PM
Subject: Re: [mpls] New draft 
Submission:draft-kumar-mpls-fec-to-nhlfe-mib-01.txt