The MPLS WG Archive

["Cucchiara, Joan" <JCucchiara@Brixnet.com>]

> > * mplsInSegmentXCIndex description is incorrect.  A value
> >   of zero could certainly indicates a valid cross connect.
> >   The XC table does model XCs even for terminating InSegments
> >   and Originating OutSegments.
> > 
> >   The syntax clause should be changed in either this
> >   table or in the XC table since the syntax should be
> >   the same in both places.
> 
> We meant it to be this way, that is, 0 is not a valid
> XC index. 0 is used to indicate that the XC entries
> have exhausted.


Currently, mplsInSegmentXCIndex has:

SYNTAX  Integer32(1..2147483647)
DESCRIPTION  
   "The index into mplsXCTable is used to identify which
   cross-connect entry this segment is part of.  Note
   that a value of zero indicates that it is not being
   referred to by any cross-connect entry."
DEFVAL {0}

Could this object be made a RowPointer? 

        Why do you want this to be a RowPointer? I think 
that doing so would unnecessarily complicate the indexing 
for the agent, so we would like to leave it as is.

Joan's questions are in ():
(The object is not correct as it appears in the MIB. 
SYNTAX should start at 0 (OR get rid of the DEFVAL {0}).

It is not clear from the above description what
the value of this object represents.  Does this
object take on the same value as 'mplsXCIndex' in 
the mplsXCTable'?

Is the value of 'mplsXCIndex' unique within the table?
Also, the value of 'mplsXCIndex' should have range which 
starts at 1, currently it is not specified so this means
zero would be an acceptable value.  Since mplsInSegmentXCIndex
uses zero to mean that there is no corresponding entry
in the mplsXCTable, this needs to be changed.)



> > * mplsInSegmentTSpecIndex -- this object needs to be made
> >   optional for LDP.
> 
> Is already optional. A value of zero to indicate best effort.
> See description.

Why is it necessary for an LDP only implementation to
support this?

        It is not necessary. Although an implementation 
must implement this value, it can certainly return 0.

Joan's comments are in ():
(But this really makes no sense for LDP, there is
no Tspec or Traffic Engineering, that is why we
also have CR-LDP, right?  So having an LDP only implementations
support objects which have no meaning for LDP is not acceptable.
Thus, it should be made optional in the conformance statements.

I thought we reached agreement that the TSpec table would
also be made optional for LDP.  Is this not the case?)


> > * mplsInSegmentOwner -- could this be removed from the
> >   table.  
> > 
> >   These object are of little value in my opinion because
> >   who really cares how the row got created?
> > 
> >   Also, if you have snmp and policyAgent, then you should
> >   add cli, config file, web, etc....
> > 
> >   Just seems to be a big rat hole in my opinion.
> 
> If you don't want to identify yourself, you can choose the
> 'other' option ;-)
> 
> It is there because folks asked for it. It provides
> tracking for usage information, for troubleshooting,
> and erroneous deletion by somebody how did not create
> it in the first place.

Are you planning on specifying in the enum the
other possibilities (cli, config file, web, etc...)?

        No.

Joan's question in ():
(why? don't you think you need these other 
ways of configuring for completeness of this object?)

Also, why is policyAgent one of the choices, this is 
a MIB and it was my understanding that policyAgent's used
PIBs.  PolicyAgents can't support RowStatus, so I believe
that choice should be removed.

        The PIB may not support RowStatus, but the agent which
interacts with the PIB/PolicyAgent may create an entry. It 
is our intent for this enumeration to note this case.

Joan's comments in (): 
(This may or may not be the case, it is not yet
defined what the interactions between the Policy Agent and
the SNMP Agent are going to be.  You have no way to know
if the Policy Agent will be able to inform the SNMP Agent
to create a Row or any other MIB entries for that matter.
Besides, if this was already defined, why would there even
be a need for a PIB?  we could just use MIB, right?

I would also like to understand what the heck difference
this makes for the LSR MIB.  It is putting many restrictions
on what the agent does and is of no relevance to the LSR MIB.
Could we compromise and have this object made optional in
the conformance section?)


> > * mplsOutSegmentIndexNext object range should start at 0 (zero).
> 
> No. 0 is bad index; is used to identify terminating connections
> in the cross-connect.

The description for this object says:
"If the number of unassigned entries is exhausted, 
this object will take on the value of 0...."

But the SYNTAX starts at 1, I believe that the SYNTAX should
start at 0.

        Good catch. Fixed.


> A label swapping is modelled as a pop followed by a push.
> See mplsInSegmentNPop. The description also talks about
> the ATM case.
> 
> > 
> >   Could you rephrase this section to specifically
> >   call out that for Version 1 of LDP using ATM or FR this should
> >   be set to true and Reference Section 5. of the LDP Spec?
> 
> I don't think we need to specially qualify LDP for this. This
> is common to any protocol on ATM.

I think that if you expect that people support this MIB
for LDP then you should be more accomodating.  I'm only
asking for a clarifying description and reference to be
added.

        Sure. How does this sound:

The number of labels to pop from the incoming packet.  Normally only the top
label is popped from the packet and used for all switching decisions for
that packet. Note that technologies which do not support label popping
should set this value to its default value of 1.           

Joan:  Good.


> > * mplsOutSegmentTopLabel
> >  
> >   Could this object be changed to contain the value of
> >   the top label on egress?  I think it would be
> >   much more interesting to point to the egress label
> >   especially since the prior object (mplsOutSegmentPushTopLabel)
> >   tells whether or not this was pushed.
> 
> 
> Hmm..I guess I don't understand the comment. 
> It already is what you are asking it to be.

Sorry, my mistake.  I think the name confused me,
would you consider a name change to mplsOutSegmentLabel?

        I think that mpslOutSegmentTopLabel is more
specific. I modified the description a bit to make it (hopefully)
be more explicit:

If mplsOutSegmentPushTopLabel is true then this represents the label that
should be pushed onto the top of the outgoing packet's label stack. Note
that the contents of the label field can be interpreted in an outgoing
interface-specific fashion.  For example, the label carried in the MPLS shim
header is 20 bits wide and the top 12 bits must be zero. The Frame Relay
label is 24 bits wide and the top 8 bits must be zero.  For ATM interfaces
the lowermost 16 bits are interpreted as the VCI, the next 8 bits as the VPI
and the remaining bits must be zero.

Joan(): (it was pointed out to us that there is a type in the MplsLabel
TC -- the vpi should be 12 bits.  Okay, adding the "the top" seemed to
help).


I know that we discussed this before and the reason
that you gave was that the MIB had been this way since
Feb 1999, but I am still confused as to why you
believe the indexing of this table to be better
than (mplsOutSegmentIfIndex, mplsOutSegmentLabel)

This won't work for the case where we want to pop the top label and 
forward the packet with whatever label is underneath, without knowing 
or wanting to know the underlying labels.

Joan():  (I'm a little confused because the LIB (or XC) is supposed
to be a ingress, egress pairing and other info, right?
If you don't keep the egress label used in forwarding, then
not sure that I understand what you are saying here.

Anyway, if you say that you can't change it then I so be it.)
 

> > * mplsXCIndexNext object's range should start at 0.
> 
> It is alright the way it is. 0 is reserved to indicate
> "no more cross-connect entries available".

I agree but the SYNTAX clause starts at 1 and should
start at 0. 

        Good catch. Fixed.


> > * INDEX clause and description of the entry:
> > 
> >   The description redefines what a values of zero means
> >   for the mplsInSegmentIfIndex and mplsInSegmentLabel;
> >   in the mplsInSegmentTable they mean one thing, 
> >   and yet, they mean something  else in the XC table.  
> > 
> 
> Yes, they are different tables.
> Index zero is valid only for the InSegemntTable.

They may be different tables but they are the same indices,
so they should be used the same everywhere they are referenced.
It is not acceptable to redefine what a value means just because
they are in different tables. 

        The index's definition is meaningful within the
context of each table. We went to great lengths to 
make the meaning within each context explicit.

Joan():  (What if there is an entry in the InSegment table
with values of MplsInSegmentLabel == 0 and mplsInSegmentIfIndex == 0,
which is an actual InSegment and is cross connecting to
an actual outsegment.  How is this InSegment and its
associated OutSegment represented in the XC table, such that
the NMS understand that this is a real XC and not an originating
LSP? 

This is exactly the reason that you cannot redefine the SAME
object to mean different things just because it is a different
table.  That is not accepted MIB practice.)


> > *  What do the AdminStatus and OperStatus objects mean when
> >    the LSP is terminating or Originating for this entry?
> > 
> 
> Admin status is provided to control the cross-connect from
> passing data. Oper status may reflect the overall health of 
> the cross-connect, for example, if the outgoing interface is
> down, then the cross-connect oper status may reflect that.

But what do they mean in the case of a terminating or originating
LSP which is in the XC table?
If AdminStatus is down, what does this imply for a terminating LSP?
Could the description be clarified to call this out, because this
is something which could be interpretted differently by different
vendors and needs to be clarified.

        This means that the LSP should not forward packets. 
We have updated section 7.0 Brief Description of MIB Objects,
to add some additional text explaining this more explicitly.

Joan: (I realize that perhaps I wasn't very clear, to put it
another way, does AdminStatus in the XC table differ from
the AdminStatus in the InSegment table?  If not, could you
just say so, or otherwise say how these are different?)

Thanks, Joan

        --Tom