Subject: Questions on draft-ietf-mpls-lsr-mib-00.txt

From: Nick Weeds <[email-masked]>
Date: Fri, 29 Oct 1999 13:53:11 +0100

Hi,

I have some questions and suggestions regarding the LSR MIB, and would be
grateful if you would provide clarification.

1) mplsInterfaceConfTable and interfaces using the global label space

How does mplsInterfaceConfTable represent interfaces using the global
(per-platform) label space?

Section 6.1 states that mplsInterfaceConfTable contains an entry for each
MPLS-capable interface.  This suggests that there should be an entry for
each MPLS-capable interface, even if the interface uses the global label
space rather than a per-interface label space.

The description of mplsInterfaceConfTable says
       "An  entry  in this table is created by  an  LSR  for
        every  interface  capable  of  supporting  MPLS  and
        represents the label space of that interface.  A row
        with index 0 represents the global label space."
This seems to tie interfaces to per-interface label spaces.

Does the LSR MIB allow interfaces to use the global label space rather than
per-interface label spaces?
If so, what does the table entry for such an interface look like?
If not, should we add support for interfaces using the global label space?
This could be done using 2 tables:
*	MPLS interface table
*	MPLS label space table.
The former would contain adminStatus, operStatus, and the index of the label
space table entry.
The latter would contain the label ranges for the label space.
Note that if this approach is used then we would also need to clarify
whether the mplsInSegmentIfIndex used to index other MIB tables is an
interface index or a label space index.

If you think we should change the MIB to use separate tables for MPLS
interfaces and MPLS label spaces, we would be happy to draft suitable MIB
text.

2) Bi-directional LSP setup in section 7

Section 7 claims to describe the MIB operations to set up a
__bidirectional__ LSP, but only sets up a single incoming segment and a
single outgoing segment.  Presumably section 7 is really describing the MIB
operations to set up a __unidirectional__ LSP.  Is this correct?

3) Cross-connect entries and cross-connect model

There appear to be 2 different ways of setting up cross-connect entries,
corresponding to 2 different cross-connect models.  Clearly only 1 of these
cross-connect models is intended!
The 2 possibilities are...

(A) Each incoming segment is associated with a cross-connect by a
cross-connect entry, and each outgoing segment is associated with a
cross-connect by a separate cross-connect entry.  Each cross-connect entry
refers to either an incoming segment or an outgoing segment but not both.
All incoming segments and outgoing segments referring to the same
cross-connect are cross-connected.

(B) Each incoming segment and outgoing segment to be cross-connected are
cross-connected by a single cross-connect entry referring to both the
incoming segment and the outgoing segment.
For point-to-point, point-to-multipoint and multipoint-to-point LSPs this
requires fewer cross-connect entries than (A).
However, when generalized to multipoint-to-multipoint LSPs it requires far
more cross-connect entries than (A) and becomes much more complicated to set
up.

Section 7 describes model (A).  However, reading MIB description in section
8 alone I would conclude that the MIB uses model (B).

Is model (A) the intended model?

If model (A) is intended, it would be helpful to clarify the description for
mplsXCEntry.  In particular, it would be helpful to state that each
cross-connect entry refers to either an incoming segment or an outgoing
segment but not both (ie disallow entries with mplsInSegmentIfIndex != 0 and
mplsOutSegmentIndex != 0).
(Alternatively, it might be possible to use a different MIB structure which
eliminates the possibility of confusion, but this might complicate the MIB
rather than simplify it.)

4) LSP termination

(Note: this point assumes model (A) above.)

How does the LSR MIB represent LSP termination at the LSP egress LSR?

This is particularly important when the previous hop of the LSP doesn't
support penultimate hop popping (eg ATM), so that the egress LSR is required
to
*	pop the top label
*	either pass the packet to the local IP stack (if label stack empty)
or look up the next label (if label stack not empty).
When the previous hop doesn't support penultimate hop popping then the 2nd
step is essential.
However, it is important not to perform the 2nd step unless certain that the
LSP terminates at this LSR - otherwise the next label will be misunderstood
(because allocated by a different LSR) or the IP address might be
misunderstood (if core LSRs have incomplete routing information or if the IP
address belongs to a VPN).

I believe that the LSR MIB represents an LSP termination at the LSP egress
LSR as a cross-connect with an incoming segment but no outgoing segment.  Is
this correct?

This approach certainly works and has the merit of simplicity.  However, it
requires care to avoid windows during cross-connect programming where the
LSP appears to terminate.  For example, the MIB operations described in
section 7 leave a window after setting the mplsXCEntry for the incoming
segment where the LSP appears to terminate.  Only after setting the
mplsXCEntry for the outgoing segment does it become clear that the LSP
doesn't terminate after all.  Between these 2 MIB SETs there is a risk of
packets received on the incoming segment being erroneously passed to the
local IP stack.

An alternative might be to use a special interface for LSP termination.  An
LSP termination would then be represented in the MIB as a cross-connect with
an incoming segment and with an outgoing segment specifying the special
interface.  The special interface could be viewed as a loopback interface,
or it could be viewed as the local IP stack's interface to the label switch.

Using a special interface for LSP termination also allows
point-to-multipoint LSPs with the local IP stack as one of the destinations.
Without a convention such as this it is difficult to see how such
point-to-multipoint LSPs can be represented or programmed using the MIB.

Do you think that the MIB should specify a special interface for LSP
termination?
Or do you see this as an implementation choice?  (Obviously such a choice
would have to be understood by the network manager in order to use the MIB
correctly.)

5) Enabling and disabling MIB traps

The LSR MIB specifies a comprehensive set of useful MIB traps
(mplsInterfaceUp/Down, mplsInSegmentUp/Down, mplsOutSegmentUp/Down,
mplsXCUp/Down).  However, it is likely that large numbers of these traps
will be generated is some scenarios.  It would be desirable to be able to
enable and disable trap generation.

Should we add MIB variables to enable and disable these traps?

Such MIB variables could be modelled on the ifLinkUpDownTrapEnable variable
in the interfaces MIB (RFC 2233).  We would probably want a single MIB
variable for each pair of traps (mplsInterfaceUp/Down, mplsInSegmentUp/Down,
mplsOutSegmentUp/Down, mplsXCUp/Down).  These MIB variables could be added
to mplsInterfaceConfTable, or they could be added to a new MIB group
referring to the LSR as a whole.

If you think we should add MIB variables to enable and disable traps, we
would be happy to draft suitable MIB text.