The MPLS WG Archive

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

Arun,

(bunch of stuff deleted...)


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


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

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

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.

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


> 
> > 
> > * mplsOutSegmentEntry is incorrect and should say 'outgoing'
> >   in place of incoming which I think someone else mentioned
> >   already.
> 
> Evils of cut-and-paste.
> 
> > 
> >   Also REF clause should be updated
> 
> Will be removed and description adjusted.
> 
> > 
> > * mplsOutSegmentIfIndex should be not-accessible
> 
> Hmmm..I guess so.
> 
> > 
> > * mplsOutSegmentPushTopLabel's description is 
> >   somewhat misleading with regard to the current
> >   version of LDP.  In the case of LDP using ATM, the
> >   idea of a label popping does not apply.  So it's
> >   misleading to say, it does not support pop-and-go.
> >   It does not support label popping at all.
> 
> 
> 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.


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

Also, this would imply a change to the XC table
as being (mplsInSegmentIfIndex, mplsInSegmentLabel, mplsOutSegmentIfIndex
and mplsOutSegmentLabel).

Something to keep in mind is that the above is more in
line with what is already being done in the internal XC tables,
so forcing another indexing on top of that is somewhat inefficient
for implementations to support.  

Could text be added as to why the present indexing is thought to be
more efficient?


> 
> > 
> > * mplsOutSegmentNextHopIpAddrType should use similar
> >   TC's as defined in draft-ops-endpoint-mib-07.txt
> 
> Done.
> 
> > 
> >   Also, I have a question on this description:  What is
> >   meant by the outgoing interface being point-to-point in
> >   the case of LDP using ATM?
> 
> That is, 'none' is not a valid choice for any multi-access network.
> 
> > 
> > * mplsOutSegmentNextHopIpv4Addr and mplsOutSegmentNextHopIpv6Addr
> >   these should be combined, and should also use the relevant
> >   TC in draft-ops-endpoint-mib-07.txt
> 
> Yes.
> 
> > 
> > * 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. 

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

> 
> > 
> > * mplsXCIndex should be not-accessible
> 
> Okay.
> 
> > 
> > * mplsXCCOS, should this object be made optional for
> >   LDP? 
> 
> Will remove this object based on comments on ML.
> 
> > 
> > * mplsXCIsPersistent should have SYNTAX of StorageType
> 
> Okay.
> 
> > 
> > * mplsXCOwner same comment as before, big rat hole, could
> >   we get rid of this object?
> 
> No, see comments above.

see my comments above also :)

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

Thanks, Joan



> 
> -arun
>