Subject: RE: Last call on MPLS TE MIB

From: "Manikantan S" <[email-masked]>
Date: Thu, 25 Jan 2001 19:02:48 +0530

Hello Thomas, Joan

I have placed the SMI for the object in alignment 
with the other objects in the TE MIB.

If this is fine, or please modify as required and can be
added to the MIB.

---------------------------------------------------------
      mplsTunnelResourceFlags INTEGER

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

--------------------------------------------------------------

thanks in advance
with best regards
mani

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, 25 January 2001 1:21 AM
To: Cucchiara, Joan; [email-masked]
Cc: [email-masked]
Subject: RE: Last call on MPLS TE MIB

         Hi,

         Can someone provide us with the appropriate
SMI for this object?

         --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 20:09:32 +0530

Hello Tom

#-----Original Message-----
#From: Thomas D. Nadeau [mailto:[email-masked]]
#Sent: Thursday, 25 January 2001 7:33 PM
#To: [email-masked]; 'Cucchiara, Joan'
#Cc: [email-masked]; [email-masked]
#Subject: RE: Last call on MPLS TE MIB
#
#
#
#         I would just add to that at the end, "The
#syntax and semantics of this value must coincide with
#those defined in the CRLDP specification."  I think that
#we need this to ensure inter-operability.
#
#         I would also change the SYNTAX to Unsigned32.
#The use of "INTEGER" is appropriate for enumerations.
#Will Unsigned32(0..63) satisfy the definition from
#the CRLDP specification? I think that we want to just
#leave this as Unsigned32 without the range.

Mani> The range was specified since only 6 bits of
the 1 byte Flags can be set. The 2 Most significant Bits
are reserved, set to zero on transmission. (Ignored on
reception).

If range is not specified, in the implementation we
need to take care of the value being set with the
appropriate values.

best regards
mani

#
#
#    Traffic Parameters
#
#         Each Traffic Parameter is encoded as a 32-bit IEEE single-
#         precision floating-point number.  A value of positive infinity
#         is represented as an IEEE single-precision floating-point
#         number with an exponent of all ones (255) and a sign and
#         mantissa of all zeros. The values PDR and CDR are in units of
#         bytes per second. The values PBS, CBS and EBS are in units of
#         bytes.
#
#         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 25 Jan 2001 10:01:47 -0500

>need to take care of the value being set with the

         Okay, then we can leave it as an Unsigned32
value with the range. You should also include the above
textual description in the suggested description I
requested.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 25 Jan 2001 09:02:56 -0500

I would just add to that at the end, "The
syntax and semantics of this value must coincide with
those defined in the CRLDP specification."  I think that
we need this to ensure inter-operability.

         I would also change the SYNTAX to Unsigned32.
The use of "INTEGER" is appropriate for enumerations.
Will Unsigned32(0..63) satisfy the definition from
the CRLDP specification? I think that we want to just
leave this as Unsigned32 without the range.

    Traffic Parameters

         Each Traffic Parameter is encoded as a 32-bit IEEE single-
         precision floating-point number.  A value of positive infinity
         is represented as an IEEE single-precision floating-point
         number with an exponent of all ones (255) and a sign and
         mantissa of all zeros. The values PDR and CDR are in units of
         bytes per second. The values PBS, CBS and EBS are in units of
         bytes.

         --Tom