Subject: Re: draft-ietf-mpls-lsr-mib-10.txt

From: Curtis Villamizar <[email-masked]>
Date: Thu, 19 Jun 2003 14:38:08 -0400

See below.  A new table is proposed to make it efficient to do an SNMP
traceroute using the LSR MIB.  What is needed is a way to find the
index (mplsInSegmentIndex) for a given interface and label that is
determined from the outsegment on the prior LSR.  The interface MIB on
both routers may be needed to get the ifindex of the other router.

Note that even with this change the LSR MIB does not have enough
information by itself to do the traceroute.

Curtis

In message <[email-masked]>, "Thomas D. Nadeau" 
writes:
> 
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[email-masked]] 
> > Sent: Thursday, June 19, 2003 12:00 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: draft-ietf-mpls-lsr-mib-10.txt 
> > 
> > 
> > 
> > In message <[email-masked]>, 
> > "Thomas D. Nadeau" 
> > writes:
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:[email-masked]]
> > > > Sent: Wednesday, June 18, 2003 11:05 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: draft-ietf-mpls-lsr-mib-10.txt
> > > > 
> > > > 
> > > > 
> > > > In message <[email-masked]>,
> > > > "Thomas D. Nadeau" 
> > > > writes:
> > > > > 
> > > > >  
> > > > > > For the traceroute capabiility to work, there has to 
> > be a way to 
> > > > > > take the outgoing label out of the 
> > mplsOutSegmentTopLabel on the 
> > > > > > previous LSR and find the MplsInSegmentEntry on the 
> > next LSR.  
> > > > > > Have we broken this?  If so that would be a problem.
> > > > > 
> > > > > 	No, this still works the same way with an octet string.
> > > > Remember, an
> > > > > octet string is just a series of bytes. If you make it 4
> > > > bytes, then
> > > > > it behaves the same as the unsigned32 did, if you make 
> > it more you
> > > > > have the same interactions.
> > > > > 
> > > > > 	--Tom
> > > > 
> > > > 
> > > > If I wanted to find a specific interface and label (that I
> > > > got from the outsegment on the prior router) I'd use:
> > > > 
> > > > We don't know the mplsInSegmentIndex.  We just know the
> > > > mplsInSegmentLabel and mplsInSegmentInterface.  It may be a 
> > > > per platform label or per interface label (we don't know)>
> > > > 
> > > > What do we put in a get or getnext to quickly get the
> > > > mplsInSegmentEntry?  Walking the table won't do.
> > > 
> > > 	Reading the original question again, I see that I
> > > missed the question's point in my response. Thanks Curtis.
> > > So to answer the original question, yes, the tracing capability 
> > > is altered and broken by the new indexing, and now I see that we 
> > > may have gone overboard with the octet string as an index in the 
> > > InSegment table. It seems that for only the inSegmentTable, it 
> > > will be useful to use (ifIndex, inSegmentLabel). The big issue
> > > for me personally is to be able to have extended indexing
> > > available for originating segments, which is why I feel
> > > strongly that we still need the octet string index on the
> > > XC and outSegment tables. I have discussed this in private
> > > with the co-authors and a few others and they agree that
> > > the following indexing should now handle all fo the
> > > cases.
> > > 
> > > 	MplsInSegmentTable
> > > 		INDEX { mplsInterfaceIndex, -- InterfaceIndexOrZero
> > > 		        mplsInSegmentLabel  -- MplsLabel 
> > > 			}
> > > 
> > > 	MplsXCTable
> > > 		INDEX { mplsXCIndex,        -- MplsIndexType
> > > 			  mplsInterfaceIndex, -- InterfaceIndexOrZero 
> > > 		 	  mplsInSegmentLabel, -- MplsLabel
> > > 			  mplsOutSegmentIndex -- MplsIndexType
> > > 			}
> > > 
> > > 	MplsOutSegmentTable
> > > 		INDEX { mplsOutSegmentIndex -- MplsIndexType
> > > 			}
> > > 
> > > 	--tom
> > 
> > 
> > Tom,
> > 
> > I suggest you keep the index as you now have it and add a table:
> > 
> >   mplsInSegmentLocate
> >     SYNTAX	MplsInSegmentLocate
> >     [...]
> > 	INDEX { mplsInterfaceLocate,  -- InterfaceIndexOrZero
> > 		mplsInSegLabelLocate  -- MplsLabel
> > 	        }
> >   ::= [...]
> > 
> >   MplsInSegmentLocate ::= SEQUENCE {
> >     mplsInterfaceLocate			InterfaceIndexOrZero,
> >     mplsInSegLabelLocate		MplsLabel,
> >     mplsInSegmentLocate			MplsIndexType
> >   }
> > 
> > This table would just return the mplsInSegmentIndex.
> 
> 	I am okay with this, as it keeps things simpler
> from my perspective at least.  Please reply to my posting 
> to the MPLS mailing list and propose that.
> 
> 	--Tom
> 
> > 
> > Curtis

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 19 Jun 2003 15:58:05 -0400

> See below.  A new table is proposed to make it efficient to 
> do an SNMP traceroute using the LSR MIB.  What is needed is a 
> way to find the index (mplsInSegmentIndex) for a given 
> interface and label that is determined from the outsegment on 
> the prior LSR.  The interface MIB on both routers may be 
> needed to get the ifindex of the other router.

	Being one who advocated the original change
to the indexing, I can live with the addition of a
mapping table and the indexing currently in v10 of 
the MIB.
 
> Note that even with this change the LSR MIB does not have 
> enough information by itself to do the traceroute.

	Yes, there is a need to use the application-
specific MIBs to know where to start (i.e.: VPN,
or FTN).

	--Tom

> > > > > If I wanted to find a specific interface and label 
> (that I got 
> > > > > from the outsegment on the prior router) I'd use:
> > > > > 
> > > > > mplsInSegmentLabel and mplsInSegmentInterface.  It 
> may be a per 
> > > > > platform label or per interface label (we don't know)>
> > > > > 
> > > > missed the question's point in my response. Thanks 
> Curtis. So to 
> > > > answer the original question, yes, the tracing capability is 
> > > > altered and broken by the new indexing, and now I see 
> that we may 
> > > > have gone overboard with the octet string as an index in the 
> > > > will be useful to use (ifIndex, inSegmentLabel). The 
> big issue for 
> > > > me personally is to be able to have extended indexing available 
> > > > for originating segments, which is why I feel strongly that we 
> > > > still need the octet string index on the XC and 
> outSegment tables. 
> > > > I have discussed this in private with the co-authors and a few 
> > > > others and they agree that the following indexing should now 
> > > > handle all fo the cases.
> > > > 
> > > > 	MplsInSegmentTable

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 20 Jun 2003 09:53:07 -0400

In message <[email-masked]>, "Thomas D. Nadeau" 

Tom,

I wasn't clear in my second comment.

The LSR MIB is used for RSVP/TE as well as LDP.  For both getting the
ifindex of the next hop interface requires using the interface MIB.

For TE you'd want to trace an LSP from ingress to egress starting with
the outgoing interface, label, and any other information available at
the ingress.  One peice of information that is not available to the
ingress is the ifindex of the next-hop interface (unless the interface
is unnumbered).  The NMS can't get from the ingress any information
the ingress does not have.  It can get the IP address of the next hop
and all next hops from the RRO (via the MIB).  Using the interface
addresses the ifindex can be determined.

If you are tracing a given FEC I think the same is true, the ifindex
is not normally known by the downstream node but the interface IP
address is.  The outsegment ifindex in the LDP MIB is for the current
LSR just as the LSR MIB outsegment ifindex is for the current LSR.
There is no direct way to get the ifindex of the next-hop other than
looking at the mplsLdpPeerTransportAddr and looking that up that
address in the interface MIB on the peer.

I don't percieve this as a serious problem, however it is worth noting
and a possible manageability improvement for either RSVP/TE or LDP
would be to provide the ifindex in the signaling just for management
purposes.  For example, an optional suboject in the RRO could contain
the ifindex of the prior IPv4 or IPv6 address subobject or new
subobjects could be introduced which give both the address and
ifindex.  A similar change could be made to LDP.  The other side
ifindex could then be populated in the LSR MIB if known and the LSR
MIB alone could support a traceroute.

It is also worth noting that it is impossible to trace an LSP
backwards but it could be a worthwhile capability.  For example, if
inseg on a given LSR had a consistent zero traffic and no apparent
purpose it might be worth bein able to trace it back to see if it was
the remnant of a software problem (or errant MIB set if someone were
foolish enough to configure routers with MIB sets :^).

Curtis

[...trimmed...]