Subject: RE: draft-ietf-mpls-te-mib-04 clarifications

From: Adrian Farrel <[email-masked]>
Date: Mon, 13 Nov 2000 21:08:41 -0000

Tom,
This flag is already available in our MIB in our implementation, so I guess
I'd be happy to see it in the IETF MIB. :-)

How about...

mplsTunnelRecordARHops OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "This object permits actual route recording to be selected for
        a particular tunnel.  When set to 'true', the actual route of
        a tunnel whose mplsTunnelOperStatus is 'up' can be viewed by 
        examining the mplsTunnelARHopTable."
   ::= { mplsTunnelEntry 25 }

Regards,
Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>-----Original Message-----
>From: Cisco -Thomas Nadeau 
>Sent: Monday, November 13, 2000 8:14 PM
>To: Sowdambiga Karthikeyan
>Cc: [email-masked]
>Subject: Re: draft-ietf-mpls-te-mib-04 clarifications
>
>
>
>
>>         Can we have one more field in the mplsTunnelEntry, 
>to turn on/off 
>> the record
>>route option (for eg. in case of RSVP, the RRO option can be 
>turned on/off).
>>This can be interpreted as: if this is turned on, then the AR 
>Hop Table may be
>>populated by the signalling protocol and if it is turned off, 
>the table 
>>won't be
>>populated.
>
>         The ARTable should always contain the actual path being taken
>by the tunnel unless it is unavailable, so your interpretation of
>it not being populated if RRO is disabled is accurate. I can see
>that it might be an interesting nob to turn off/on, but I would want
>to hear from others before adding new stuff to the MIB at this point.
>
>>         By the way, when can we expect version -05 ?
>
>         As soon as Cheenu and Arun return from vacation and
>we can all have a conference call. ;)  Seriously, it is
>finished with only one minor issue that needs to be decided.
>After that it will go out. Hopefully this will be within the
>next day or so.
>
>         --Tom
>
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 13 Nov 2000 17:12:40 -0500

This flag is already available in my implementation
as well. Any objections to adding this variable to
the tunnel table?

         --Tom