Subject: RE: Last call on MPLS TE MIB

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Jan 2001 11:37:15 -0500

Yes, sorry we overlooked it during our most
recent editing session. The object looks fine.
Lets just blame Arun for that one. ;)

         --Tom

>I would like to see Manikantan's suggestions
>added to the MPLS-TE MIB.  This is also for
>CR-LDP support.  Is this object and description
>going to be added?
>
>    Thanks, Joan
>
> > -----Original Message-----
> > From: Manikantan S [mailto:[email-masked]]
> > Sent: Wednesday, January 17, 2001 11:33 PM
> > To: 'Cucchiara, Joan'
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: Last call on MPLS TE MIB
> >
> >
> > Hello Joan
> >
> > #> Hello
> > #>
> > #> It would help, as suggested in the mail to include
> > #> the CRLDP-Specific MIB objects in the TE MIB.
> > #>
> > #> Currently we have them as Enterprise MIB objects
> > #> in our implementation and we can move to the
> > #> standard MIB if they are available there.
> > #>
> > #> I have the following question/doubt for Joan.
> > #>
> > #> 1) We have a field "flags" in the CRLDP Traffic
> > #> Parameters TLV. This helps in conveying the
> > #> set of negotiable parameters. The value of "Flags"
> > #> being added as a configurable object will provide
> > #> added flexibility. what do you suggest?
> > #
> > #I agree with you that an ActiveFlags object would
> > #be useful for CR-LDP.  If possible, would you
> > #be able to email what this object looked like in
> > #your enterprise MIB?
> > #
> > #Having actual implementation feedback is very useful
> > #for MIB objects.
> >
> > I currently have the following definition in
> > the Enterprises MIB.
> >
> >      fsMplsLdpCrlspTnlFlags INTEGER
> >
> >      fsMplsLdpCrlspTnlFlags OBJECT-TYPE
> >         SYNTAX        INTEGER (0..63)
> >         MAX-ACCESS    read-create
> >         STATUS        current
> >         DESCRIPTION
> >             "The value of Flags conveyed as part of the
> > Traffic Parameters
> >              during the establishment of the CRLSP. The Bit value
> >              indicates the set of Traffic parameters that are
> >              negotiable during the CRLSP setup."
> >         REFERENCE
> >             "Section 4.3, Constraint-Based LSP Setup using
> > LDP, Jamoussi,
> > et.
> >              al, <draft-ietf-mpls-crldp-04.txt>, July 2000."
> >         DEFVAL        { 0 } -- Parameters not negotiable.
> >
> > #>
> > #> 2) Do we need to use the value of the MIB object
> > #> "mplsTunnelIncludeAnyAffinity" for the
> > #> "RsCls" field in Resource Class TLV?
> > #
> > #This seems like a reasonable approach.  Are you
> > #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity"
> > #object be enhanced to include CR-LDP's Resource Class TLV?
> >
> > Yes. I feel it will be clear and very helpful.
> >
> > Thanks and best regards
> > mani
> > -----------------------------------------
> > S.Manikantan
> > Future Software Limited
> > 480-481, Anna Salai,
> > Nandanam, Chennai, India.
> > Zip (PIN CODE) : 600 035
> > Phone          : 91-44-4330550
> > Fax            : 91-44-4344157
> > email          : [email-masked]
> > -----------------------------------------
> >

---

From: "Manikantan S" <[email-masked]>
Date: Thu, 25 Jan 2001 10:50:28 +0530

Hello Joan, Thomas

I have an another observation/suggestion with respect to the
CRLSP support. 

This is with respect to the ER Hop that is configured to be of
type LSPID. Currently we have support to configure the LSPID
value via the MIB object "mplsTunnelHopLspId" and the
have the MIB object "mplsTunnelHopAddrType" set to value "lspid".

For a ER Hop Type of LSPID, the Ingress LSR Router ID value is
also required. 

Can we add an object to facilitate this configuration?
(We have added this to our enterprises MIB to support LSPID ER hop
types).

The SMI for the object can be as follows.

mplsTunnelHopIngressRouterId MplsLsrId

mplsTunnelHopIngressRouterId OBJECT-TYPE
   SYNTAX        MplsLsrId
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
          "If mplsTunnelHopAddrType is set to lspid(4), then
           this value will contain the IPv4 address of the
           Ingress Router ID of the Tunnel. This object is 
           otherwise insignificant and should contain a 
           value of 0."
  
NOTE: The suggestion made is for IPv4 Address alone here, since
the LSPID TLV currently supports IPv4 address type only.

Thanks in advance
with best regards
mani

---

From: "Manikantan S" <[email-masked]>
Date: Thu, 25 Jan 2001 11:24:35 +0530

Hello Joan, Thomas

  

Thanks in advance
with best regards
mani

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 25 Jan 2001 07:55:33 -0500

What is wrong with just using the mplsTunnelHopIpv4Addr
or mplsTunnelHopIpv6Addr which are on the Hop entry already?
I would prefer not to add another object if there are
others which you can reuse.

         --Tom