Subject: Re: Some comments on LDP MIB

From: Jim Sullivan <[email-masked]>
Date: Tue, 07 Sep 1999 15:58:03 -0400

At 09:23 AM 08/31/1999 +0200, Hans Sjöstrand wrote:
>We are still working on an 02 of the mib, comments are always welcome.
>Answers on your issues are embedded below. 

Do you have a date on when we can expect an updated version of the LDP MIB ? 

>> 
>> Page 11, MplsLdpEntityEntry
>> Would it not be useful to add an admin status per LDP entity ? Thus, LDP
>> could be enabled separately on each interface.
>> For the ATM case, I think we need to know if the peer LSR is directly or
>> indirectly connected (i.e. via an ATM VP). This must be configured
either as
>> part of the MPLS interface configuration or as part of the LDP entity for
>> ATM. Currently, there is no such parameter in the MIB.
>
>I would agree about the admin state, it could prove useful. Also in the
>case where some of the parameters can't be changed on an active session. 
>

It seems to me that the LDP MIB was written for LDP working with 
LC-ATM interfaces only.  For example notice that the index into the 
LDP entity table is the MplsLdpEntityID, and that this value can be 
the same for several different peers. (e.g. SHIM encoded ATM on 
several unnumbered interfaces to different LSRs, all using 
platform wide label space).  When you have this
situation then there may be just one MplsLdpEntityID representing all
the mentioned interfaces. In this case then it would not be possible 
to configure different label distribution methods for each peer. 
Let me know if I am missing something here, but the current LDP mib
seems broken. 

>> Finally, I would like to suggest to move all interface-specific objects
away
>> from the protocol-specific part of the MIB. Configurable parameters like
>> label ranges, VC directionality, merge capability etc. should appear only
>> once inside the MPLS MIB, in an interface-specific section (as long as they
>> are really protocol-independent).
>
>This is one solution to the problem to make the LDP mib bearer
>independant (i.e less ATM centric) as we said in Oslo. Sounds like you
>have some more specific proposal on how to do it, please cheer your
>ideas with us. 
>
>Regards
>/// Hasse
>

---

From: Theimer Thomas <[email-masked]>
Date: Thu, 9 Sep 1999 11:27:17 +0200

> > 	[Theimer Thomas]  
> > 	The consequence of that would be to associate the mplsLdpEntityEntry
> > with the interface, rather than the label space. So, even with a single
> > per-platform label space, you could have one mplsLdpEntityEntry per
> > interface. Would that solve your problem ? 
> > 	  
> > 	Regards, Thomas
> 
> 
> Per-interface may not be a good way to think about this since
> multiple LDP peers may be accessible via a single multi-access interface.
> 
> 
> Bob
	[Theimer Thomas]  Bob,

	I did not mean this association to be restricted to a one-one
relation between interface and LDP entity. What about the following MIB
structure:

	1. multiple LDP entities can exist with the same label space (LDP
ID); each entity refers to exactly one label space (LDP ID), but several
entities may refer to the same LDP ID.
	2. multiple LDP entities can exist on a single interface (typically
a multi-access interface such as ethernet); that means we need to introduce
an LDP interface level of MIB objects, to which the LDP entity can then
point to.
	3. there should also be media-specific interface tables containing
e.g. ATM-specific configuration parameters for LDP. These tables would then
point to the LDP interface objects in 2. above.
	4. there should also be media-specific label range tables (for ATM,
FR, 802.3, Generic labels) that define the label space for each LDP ID.

	Would that cover all practical cases ?

	Thomas

---

From: Jim Sullivan <[email-masked]>
Date: Thu, 09 Sep 1999 09:42:58 -0400

Thomas, 

I think this looks pretty good. 
Have you thought about what each 
table contains ? 

A general solution should cover 
LCATM(Direct, VP, SVC), ATM-SHIM(pt-pt, NBMA),
Ethernet, ...etc.

I have a few questions below.

1. For NBMA interfaces, do we need to allow entity
configuration per connection on the NBMA interface ? 
(e.g. to configure the label distribution mode differently
for each connnection, or to allow interface specific 
label space per connection) 
If so then there would be an entry in LDP Entity table
for each such connection, probably located based on 
interface, and IP address. Maybe there would also 
be a default that could be specified for all connections
not explicitely configured.

2. Similar question applies to Ethernet, if one would want 
to configure the label allocation mode per LSR reachable 
on an interface. Label space here would always be per 
platform.  

3. From a practicle standpoint would the capability
described in 1, and 2 above be useful ?  

4. I think the interface table needs to contain an interface
name field that can be used to locate the LDP ID.
For example in order to run the Hello 
protocol it is required to know which LDP ID to insert 
in the Hello packet, so from the interface name we 
need to be able to locate the LDP ID.    

Jim

---

From: Theimer Thomas <[email-masked]>
Date: Fri, 10 Sep 1999 11:05:48 +0200

Jim,

	here is a rough sketch of the tables. I didn't really work out all
the details. Also, I am not really a MIB expert, so don't expect too much.

	The tables are designed so that multiple LDP entities may exist on a
single interface (e.g. ethernet). I could not imagine that you would have a
single LDP entity control multiple interfaces. So, the LDP entity can refer
directly to the IfIndex of the interface it relates to. Note that interface
is used in a wide sense, it can be LC ATM,  LC FR, ATM PVC using generic
encaps, any other interface using generic encsapsulation. I'm not quite sure
about MPLS running on ATM NBMA, but in principle that seems to be similar to
the Ethernet case, as long as generic labels are used.

	I am also not sure about the IP address of the interface. Is there a
strong reason to put it into the LdpEntityTable ?

	Here are the tables:

MplsLdpConfAtmLabelRangeTable                (for label-controlled ATM
interfaces)
  mplsLdpConfAtmLabelRangeID                 LDP ID identifying the label
space
  mplsLdpConfAtmLabelSpaceType               per-interface or per platform
(do we need that ?
                                             I do not expect per platform
label space here)
  mplsLdpConfAtmLabelRangeLowerBoundVPI      AtmVpIdentifier,
  mplsLdpConfAtmLabelRangeLowerBoundVCI      AtmVcIdentifier,
  mplsLdpConfAtmLabelRangeUpperBoundVPI      AtmVpIdentifier,
  mplsLdpConfAtmLabelRangeUpperBoundVCI      AtmVcIdentifier,
  mplsLdpConfAtmLabelRangeRowStatus          RowStatus

MplsLdpConfFrLabelRangeTable                 (for label-controlled FR
interfaces)
  mplsLdpConfFrLabelRangeID                  LDP ID identifying the label
space
  mplsLdpConfFrLabelSpaceType                per-interface or per platform
(do we need that ?
                                             I do not expect per platform
label space here)
  mplsLdpConfFrLabelRangeLowerBoundDLCI      Minimum DLCI
  mplsLdpConfFrLabelRangeUpperBoundDLCI      Maximum DLCI
  mplsLdpConfFrLabelRangeRowStatus           RowStatus

MplsLdpConfGenericLabelRangeTable            (for all interfaces using the
shim header)
  mplsLdpConfGenericLabelRangeID             LDP ID identifying the label
space
  mplsLdpConfGenericLabelSpaceType           per-interface or per platform
  mplsLdpConfGenericLabelRangeMinOut         Minimum outgoing label
  mplsLdpConfGenericLabelRangeMaxOut         Maximum outgoing label
  mplsLdpConfGenericLabelRangeMinIn          Minimum incoming label
  mplsLdpConfGenericLabelRangeMaxIn          Maximum incoming label
  mplsLdpConfGenericLabelRangeRowStatus      RowStatus

MplsLdpEntityTable
  mplsLdpEntityIndex                         Unique index, used by
media-specific conf tables
  mplsLdpEntityID                            MplsLdpIdentifier of the label
space
  mplsLdpEntityIfIndex                       points to the interface in
IfTable
                                             Note: this may be a physical
interface,
                                             an ATM VP, or an IP interface
  mplsLdpEntityWellKnownDiscoveryPort        UDP port for neighbor discovery
  mplsLdpEntityMtu                           MTU (do we really need that ?
should be derived
                                             from IfTable via IfIndex)
  mplsLdpEntityKeepAliveHoldTimer            KeepAliveHoldTimer
  mplsLdpEntityFailedInitSessionThreshold    FailedInitSessionThreshold
  mplsLdpEntityLabelDistributionMethod       LabelDistributionMethod
  mplsLdpEntityRowStatus                     RowStatus

MplsLdpConfAtmTable                          (for label controlled ATM
interfaces)
  MplsLdpConfAtmEntity                       Index of corresponding LDP
entity
  mplsLdpConfAtmPeerLsrConnectivity          Direct, via ATM VP or via ATM
SVC
  mplsLdpConfAtmDefVpi                       VpIdentifier for default
traffic
  mplsLdpConfAtmDefVci                       VcIdentifier for default
traffic
  mplsLdpConfAtmUnlabTrafVpi                 VpIdentifier for unlabeled
traffic
  mplsLdpConfAtmUnlabTrafVci                 VcIdentifier for unlabeled
traffic
  mplsLdpConfAtmPeerAddress                  ATM address to be used for SVC
setup
  mplsLdpConfAtmMergeCapability              MergeCapability
  mplsLdpConfAtmVcDirectionality             VcDirectionality

MplsLdpConfFrTable                           (for label controlled FR
interfaces)
  MplsLdpConfFrEntity                        Index of corresponding LDP
entity
  mplsLdpConfFrDefDlci                       DLCI for default traffic
  mplsLdpConfFrUnlabTrafDlci                 DLCI for unlabeled traffic
  mplsLdpConfFrMergeCapability               MergeCapability
  mplsLdpConfFrVcDirectionality              VcDirectionality

Regards,

Thomas

---

From: Theimer Thomas <[email-masked]>
Date: Fri, 10 Sep 1999 11:22:16 +0200

> Jim Sullivan [SMTP:[email-masked]] wrote: 
	[Theimer Thomas]  For ATM PVCs using generic encaps,
	I think that would be quite useful. If that's what you meant.
	For ATM NBMA interfaces, there should be per-peer LDP
	entity configuration at least as an option. How that translates
	into connections is another matter.
> interface, and IP address. 
	[Theimer Thomas]  The LDP entity table should probably
	contain the IfIndex of the interface. I am not about the IP
	address. That may not be unique (for unnumbered interfaces).

> Maybe there would also 
	[Theimer Thomas]  Would it have to be per-platform ?

> described in 1, and 2 above be useful ?  
	[Theimer Thomas]  I think it would be very useful, do other
	people share that view ?

> need to be able to locate the LDP ID.    
	[Theimer Thomas]  Actually, a separate interface table
	may not be necessary at all, provided that the LdpEntityTable
	would refer directly to the interface via its IfIndex. Although that
	precludes cases where a single LDP entity controls multiple
	interfaces. Does anyone see a need for that ?

	Thomas