Subject: RE: LSR MIB comments and questions

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 05 Apr 2000 15:22:32 -0400

Hi,

         Sorry about the delay in response. It was  a
long flight back from Adelaide! ;)

> > >I also question why this extra variable is required to
> > >convey the label space membership attributes.
> > >
> > >If  mplsInterfaceConfIndex is zero, then it uneqivocally
> > >has the attributes 'in global label space' and 'not in
> > >local label space'.
> > >
> > >If mplsInterfaceConfIndex is non-zero, that it uneqivocally
> > >has the attribute 'in local label space' and the 'in
> > >global label space' variable arbitrates that (optional)
> > >attribute.
> >
> >          Yes, but there are cases in ATM where an interface needs
> > to be part of both label spaces. This is why we have
> > provided two separate variables here.
>
>The combination of the index and ONE of these
>objects would (I think) allow all combinations.  For example,

         Yes, that is true, although it implicitly notes
which interfaces are per-interface and which are per-platform.
Our intention was to be explicit about this. The reason is
that if you use the implicit version, it is unclear as to
how the implementation should note the label ranges. We do
agree however, that changing the names to IsPerPlatformLabelSpace
and IsPerIfLabelSpace is a great idea as it makes this consistent
with the architecture.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 05 Apr 2000 16:48:14 -0400

Hi,

> > > * 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.

> > > * 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.

> > > * 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.

>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.

> > > * 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.

> > > * 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.

>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.

> > > * 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.

> > > *  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.

         --Tom

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Wed, 5 Apr 2000 16:57:29 -0400

-----Original Message-----
>From: Thomas D. Nadeau [mailto:[email-masked]]
>Sent: Wednesday, April 05, 2000 3:23 PM
>To: Cucchiara, Joan
>Cc: [email-masked]'
>Subject: RE: LSR MIB comments and questions
>
>        Hi,
>

> how the implementation should note the label ranges. We do

Tom,

Could I suggest combining these two boolean objects into
one enum object, mplsInterfaceLabelParticipationType, 
with values ( perPlatformOnly, perInterfaceOnly, both)??

DESCRIPTION:
   "If the value of the mplsInterfaceConfIndex for this
   entry is zero, then this object MUST be perPlatformOnly.  
   
   If the value of the mplsInterfaceConfIndex for this entry
   is non-zero, then this object may be either 'perInterfaceOnly'
   or 'both'.  If the value is perInterfaceOnly then this means that
   the value of the MIN/MAX IN/OUT Label Range objects for
   this entry contain valid values.  If the value is both, then
   the value of the MIN/MAX IN/OUT label Range objects do not contain
   valid values  (???? OR maybe  need to contain the same values as
   the MIN/MAX IN/OUT Label Range objects for the
   entry which has the mplsInterfaceConfIndex of zero????)"

[NOTE:  The description needs work because it needs to be
co-ordinated with the MIN/MAX IN/OUT Label objects.]

I think this enum would be explicit enough (and also combines
the two boolean objects into one enum object -- so one less object!).  
What do you think?

   Thanks, 
     Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 05 Apr 2000 17:07:46 -0400

Hi,

         This sounds like a reasonable thing to us. I
will make the change.

         --Tom

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Wed, 5 Apr 2000 21:51:38 -0400

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.)

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?)

        No.

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

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?)

        Good catch. Fixed.

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.

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).

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.)

        Good catch. Fixed.

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.)

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

---

From: Arun Viswanathan <[email-masked]>
Date: Thu, 6 Apr 2000 10:09:20 -0700

> the NMS understand that this is a real XC and not an originating

There is no ambiguity here. Label 0 cannot have an outgoing segment.
See label encap draft for explicit NULL label.

-arun

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 06 Apr 2000 13:51:58 -0400

Hi Joan,

>SYNTAX should start at 0 (OR get rid of the DEFVAL {0}).

         Yes, this value has been fixed to have the correct
range.

>object take on the same value as 'mplsXCIndex' in

         Yes. We will add a sentence indicating this. I
think that it was our assumption that the name indicated
this.

>Is the value of 'mplsXCIndex' unique within the table?

         No. In cases of multipoint/multicast connections,
it is possible to have several segments "point at" the
same XC.

>in the mplsXCTable, this needs to be changed.)

         Yes, this has been fixed.

>Thus, it should be made optional in the conformance statements.

         Is it really a big deal for an implementation to support
this just by setting the value to 0? The DEFVAL specifies 0 as
a default value, so most implementations will not have to do anything
here, and can support it as read-only, so it will never be
changed.

>also be made optional for LDP.  Is this not the case?)

         Yes, the Tspec table is optional (i.e.: not included in
the module conformance statement).

>ways of configuring for completeness of this object?)

         What the intent was with this object was to
identify either the signaling protocol, policy agent
(i.e.: COPS), agent (SNMP) or "other" configuration of this
object. The point here was to let external sources know
that if they did not create an object, that they may not
be allowed to delete/modify it depending on the implementation.
We distinguished SNMP since it seemed obvious. We also provided
"other" for managers who did not want to use "SNMP", but wanted
to note that something else configured the object (i.e.: cli,
web, etc...).

>to create a Row or any other MIB entries for that matter.

         As you pointed out, it may or may not be the case. We
are focusing on the "may" case. I believe the original request
for this object came from one of the reference implementations.

>the conformance section?)

         I think that this is reasonable, since I believe that
we have stated already that the implementation of this object
is implementation-specific. Certainly implementation of this
object at all. How about leaving the object there, but adding
another option called "unknown" and making this the DEFVAL?

>just say so, or otherwise say how these are different?)

         Yes, their values *may* differ. I think that the distinction
should be clear from the definitions of admin and oper status. It may
be the case that some implementations do not allow modification of
these values, and hence might want different admin/operStatus
values just like in any other MIB. However, in other cases, where
they do not allow modification of these values, then they will
be the same thing: whatever the agent has set them to.

         --Tom

---

From: Cheenu Srinivasan <[email-masked]>
Date: Thu, 6 Apr 2000 20:41:50 -0400

> It is not acceptable to put enums like this in a standard mib
> which "may" be defined.  If the interaction between a policyAgent
> and an SNMP Agent for row-creation is ever defined, it is a long
> long way off (YEARS).  By then this MIB will be on its 57th 
> revision :)

Let me try to clarify before we drift too far afield (if we haven't
already).

The intent of this object is to indicate the owner/creator of this 
conceptual row. Just because we expose something via an SNMP interface
does not mean that these are/should be manipulated via SNMP. This is
true of all the standard MIBs we have out there. The
interaction/interface between the owner of the object and the LSR is
irrelevant here. This applies equally to any of the signaling protocols,
a policy agent etc. Any of them can and probably will use a proprietary
interface to create objects inside the LSR. Do you imagine that
LDP or RSVP is going to issue SNMP protocol requests to create/configure
anything? The concept of a PIB is also irrelevant here for the same reason
and only governs the interaction between the policy server and policy
agent. 

Cheenu

---

From: Arun Viswanathan <[email-masked]>
Date: Thu, 6 Apr 2000 19:07:41 -0700

Joan,

> long way off (YEARS).

For some it may be years away, perhaps not so for others.
Besides, the policy agent doesn't have to go through SNMP agent
to create entries in the table. There is no need for a standard
on how policy agent creates entries in the LIB.

>   By then this MIB will be on its 57th 
> revision :)

At this rate even version 1 looks remote to me :-)

> 
> There is not one other standard's track MIB which indicates whether a
> row was created by a policyAgent/PIB vs. a snmpAgent/MIB.
> If someone really wants this enum then it belongs in their enterprise
> MIB and NOT in a standard MIB.
> 
> Could you take this policyAgent enum out now and put it in
> when someone describes how a Policy Agent instructs an SNMP agent
> to create a row? 
> 
> If you could remove the policyAgent enum and the SNMP enum and
> just use a generic "mgmt" enum, that would be an acceptable
> alternative.

What your are suggesting is useless and doesn't serve any purpose.
Just defining one enum defeats the whole purpose of this object.
How do you suggest we track which entity created a row in this
table?

> 
> Also, I disagree with the premise that the row needs to be destroyed
> by the same protocol which created it.

This is a non-issue. This is an implementation choice.

>  If a human being wants to
> take down an LSP which was created via signalling what is the problem
> with that?

Same as above.

>  I would also like to understand what the agent is supposed
> to return for an error code in this situation?
> 

I think you are laboring a rather innocuous but useful object.
The ONLY purpose of the object is to track which entity created
an entry in the table for the purpose of trouble-shooting and
reporting. The object's purpose is NOT to allow or disallow an
entity from creating entries into LIB. So, even if we choose
to remove some of the enum doesn't mean those entities cannot
create rows in the LIB. 

-arun