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

From: Nick Weeds <[email-masked]>
Date: Thu, 4 Nov 1999 18:56:34 -0000

James,

I haven't yet received any clarifications regarding my question on the
cross-connect model.  I think this is probably because everybody's busy with
the IETF meeting coming up next week, but I hope I'll receive clarification
later.

Regarding your question about mplsXCIndex, I can see two possible reasons
for including this index.  Either way it's important for each LSP to use a
different mplsXCIndex value.

1) First possible explanation

According to section 7 of the draft, two cross-connect table entries are
required to connect an input segment to an output segment:

   For the in-segment:
   {
      mplsXCIndex = x,
      mplsInSegmentIfIndex = i1,
      mplsInSegmentLabel = l1,
      mplsOutSegmentIndex = 0,
      mplsLabelStackIndex = 0,
      mplsXCRowStatus = createAndGo(3)
   }
   
   For the out-segment:
   {
      mplsXCIndex = x,
      mplsInSegmentIfIndex = 0,
      mplsInSegmentLabel = 0,
      mplsOutSegmentIndex = o,
      mplsXCLabelStackIndex = 0,
      mplsXCRowStatus = createAndGo(3)
   }
   
The only thing which relates these two cross-connect entries is the
mplsXCIndex, so mplsXCIndex is crucial in forming the cross-connect.

However, there is an alternative interpretation of how to set up the
cross-connect entries.  According to my personal interpretation, the MIB
text itself would allow a single mplsXCTable entry for the cross-connect:

   In mplsXCTable:
   {
      mplsXCIndex = x,
      mplsInSegmentIfIndex = i1,
      mplsInSegmentLabel = l1,
      mplsOutSegmentIndex = o,
      mplsXCLabelStackIndex = 0,
      mplsXCRowStatus = createAndGo(3)
   }
   
Here the single mplsXCTable entry explicitly identifies both the input
segment and the output segment, so it isn't necessary to use mplsXCIndex to
relate the two.

I suspect that I'm not the only person to have interpreted the MIB text in
this way, which is why I think clarification is important.

As you point out, the two models are very different when extended to the
multipoint-to-multipoint case.  The former requires far fewer cross-connect
table entries (number of input segments + number of output segments) than
the latter (number of input segments * number of output segments).

2) Second possible explanation

Even if the mplsXCIndex isn't necessary to relate input segments and output
segments, it still makes it easier the MIBs easier to browse.

For example, it's possible to start with an output segment in the output
segment table, look up it's mplsXCIndex, use the mplsXCIndex to look up all
the cross-connects in the cross-connect table and find all the input
segments, then look up all the input segments in the input segment table.
With the mplsXCIndex as the first index to the cross-connect table it's easy
to do this.  If we didn't have the mplsXCIndex it would be much harder to
find the input segments - you'd have to read the entire cross-connect table.
(I don't know of any specific reason why you'd want to browse the MIBs in
this way, but it's nice to be able to do it!)

	Nick.

-----Original Message-----
From: James Tsillas [mailto:[email-masked]]
Sent: 04 November 1999 18:25
To: Nick Weeds
Subject: RE: Questions on draft-ietf-mpls-lsr-mib-00.txt

Nick,

have you received any clarification regarding your question on
the model for cross-connects? I've also posted a question
but after reading your posting (item 3) I see that we are having
similar issues. What is particularly troublesome is that the
text doesn't mention multipoint-to-multipoint yet the model
seems to imply that this is a consideration.

-Jim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Nick
Weeds
Sent: Friday, October 29, 1999 8:53 AM
To: [email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Questions on draft-ietf-mpls-lsr-mib-00.txt

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.

---

From: "Tim Mancour" <[email-masked]>
Date: Mon, 8 Nov 1999 09:15:26 -0500

Nick,

After spending sometime looking at the LSR MIB, I've come to the following
conclusions/assumptions:

	1) The mplsXCTable table supports *unidirectional* point-to-point,
	point-to-multipoint and multipoint-to-point connections.

	2) Each row in the mplsXCTable completely specifies a single cross-connect.
Of
	course, the number of rows in the table for any given set of
cross-connections
	will be equal to the number of endpoints - 1.

	3) A cross-connect must be in one of the following forms:
		a) inSegment --> XC			-- terminating
		b) XC --> outSegment			-- originating
		c) inSegment --> XC --> outSegment	-- intermediate or penultimate

		Where:
			An inSegment can perform a pop(0..N) label operation.
			The XC can perform a push label stack operation.
			An outSegment can push the outbound label.

	4) The example in section 7 needs to be reworked. One obvious issue is
	that it suggests that traffic could flow from an outSegment to an
inSegment.

Any additional comments that help clarify the LSR MIB would be appreciate.

Thanks
TimM

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Nick
Weeds
Sent: Thursday, November 04, 1999 1:57 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: Questions on draft-ietf-mpls-lsr-mib-00.txt

James,

   For the in-segment:
   {
      mplsXCIndex = x,

   For the out-segment:
   {
      mplsXCIndex = x,

   In mplsXCTable:
   {
      mplsXCIndex = x,

	Nick.

-----Original Message-----
From: James Tsillas [mailto:[email-masked]]
Sent: 04 November 1999 18:25
To: Nick Weeds
Subject: RE: Questions on draft-ietf-mpls-lsr-mib-00.txt

Nick,

-Jim.

-----Original Message-----

Hi,

4) LSP termination