Subject: Re: LDP MIB-03: Can FEC have only one LSP.

From: Geetha Brown <[email-masked]>
Date: Tue, 16 Nov 1999 16:52:36 -0500

Hi,

In this mplsLdpFecEntry context I have a question, do we need a separate
FEC table in LDP mib?  If the LSP to FEC
mapping is required it can be maintained in the mplsLdpLibTable.  On an
LSR at any one point we can have topology
driven LSPs and traffic engineered LSPs.  In such a case we will have
two sets of FEC to LSP mapping tables existing on the LSR.  

Geetha

---

From: Joan Cucchiara <[email-masked]>
Date: Wed, 17 Nov 1999 11:10:59 -0500

Hi Geetha,

> two sets of FEC to LSP mapping tables existing on the LSR.

The FEC table, perhaps should be renamed to FecElement Table, but
yes, I believe that two tables are needed.  Multiple FecElements can
be related to an LSP, or a single FEC element could be related to
more than one LSP, so two tables are more flexible, as opposed to 
one table.  (ASIDE: as previously stated there will be changes to
the LIB table for the addition of learned labels, and the indexing
to the FEC table will also need to be changed, so these tables
will change in the next rev.)

Combining the FEC Element information in the LIB table may make it
more difficult to get a clear picture of the number of LSPs because
the indexing would need to be combined with some of the FEC Table's
indexing.

As for the nature of an LSP's creation (TE, topology-driven), I'm not
sure I understand what the issue is, the LDP MIB contains information
on LDP and the LIB is for LDP related information.  I think (just my
own opinion here) that it would be straightforward 
to extend/augment these tables to carry more information (which may
including pointing to other table rows in other MIBs).  
The same goes for other MIBs, where the tables could 
be extended/augmented to point to rows in say, for example the LDP MIB.

    -Joan