Subject: RE: MPLS TE MIB

From: Adrian Farrel <[email-masked]>
Date: Wed, 5 Jan 2000 15:07:41 -0000

Good news, Tom!

Here are some thoughts on the current draft.

Regards,
Adrian

1. Control of Notifications.
It would be nice to be able to control the notifications so that they do not
flood the Management Application.  

Can I suggest adding to mplsTeObjects as follows.

mplsTunnelUpNotificationEnable     OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
            "Allows the generation of notifications in when the
             mplsTunnelOperStatus object of a configured tunnel
             moves from the down state to any state other than
             notPresent."
      DEFVAL        { true }
      ::= { mplsTeObjects 4 }

mplsTunnelDownNotificationEnable     OBJECT-TYPE
      SYNTAX      TruthValue
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
            "Allows the generation of notifications in when the
             mplsTunnelOperStatus object of a configured tunnel
             moves into the down state from any state other than
             notPresent."
      DEFVAL        { true }
      ::= { mplsTeObjects 5 }

2. Cannot Read the Actual Route Used 

Although this feature does not (currently) exist for CR-LDP the RRO is
present and useful in Labels RSVP.  It offers the potential to examine the
actual route in use which might be particularly nice in some TE applications
and where a loose explicit route has been used.

The TE MIB does not offer the possibility of examining the RRO.  Should we
add it?

3. Bit Rates etc.

In a previous thread, Andy Baker ([email-masked]) wrote...

> In the MPLS Traffic Engineering MIBs, bit rates
> and burst sizes in the mplsTspecTable and mplsTunnelTable are inherited
> from the Integrated Services MIB where they are defined as SNMP INTEGERs
> with a valid range of 0 - 0x7FFFFFFF. 
> 
> However, the underlying traffic parameter quantities for both CR-LDP and
> RSVP are IEEE 32-bit floating point numbers.  (For example, see section
> 4.3 of draft-ietf-mpls-crldp-03.txt.)
> 
> This means that the data rates which it is possible to reserve on an LSP
> are limited to 2Gbit/s, while as the underlying protocols will support
> data rates up around 10^39 bytes/second (note the differing units too).
> 
> To be able to configure and manage an LSP using SNMP, it seems to me that
> we need to modify the object type for the bit rates and burst sizes to be
> a 64 bit quantity, which at least will allow data rates up to about 10^18.

draft-kzm-hcdata-types-02.txt suggests an approach using 64 bits, but
perhaps we should bite the bullet and use/define full floating point support
(I haven't checked whether MIB-II SMI has floating point support).

4. Support for draft-ietf-mpls-diff-ext-02.txt

When defining an MPLS Tunnel to support Diff-Serv according to this spec
(and in particular L-LSPs) it will be necessary to supply the information to
be encoded in the new objects/TLVs (e.g. RSVP DIFFSERV_PSC Object).

To avoid having extensions to the MIB at a later date, it would be as well
to add this to the current MIB (in such a way that implementations that do
not support draft-ietf-mpls-diff-ext-02.txt will not be handicapped).

Can I suggest the following ASN.1.  You might want to run it past Francois
Le Faucher.

mplsTunnelDiffServLspType OBJECT-TYPE
   SYNTAX        INTEGER {
         no-diff-serv(1)  -- Diff-Serv not supported
         e-lsp(2)         -- EXP-Inferred-PSC LSP
         exp-e-lsp(3)     -- EXP-Inferred-PSC LSP set up
                          -- explicitly using the method
                          -- used for L-LSPs.
         l-lsp(4)         -- Label-Inferred-PSC LSP
      } 
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Determines the support for diff-Serv provided by this
        LSP Tunnel.  If this field is set to no-diff-serv, then
        mplsTunnelDiffServPscNum and mplsTunnelDiffServPsc have
        no meaning."
   REFERENCE
       "MPLS Support of Differentiated Services, Le Faucheur, 
        et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999."
   DEFVAL        { 1 }
   ::= { mplsTunnelEntry xx }

mplsTunnelDiffServPscNum OBJECT-TYPE
   SYNTAX        INTEGER 
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates the number of PSC values included in 
        mplsTunnelDiffServPsc.  This object has no meaning if 
        mplsTunnelDiffServLspType is set to no-diff-serv."
   REFERENCE
       "MPLS Support of Differentiated Services, Le Faucheur, 
        et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999."
   DEFVAL        { 1 }
   ::= { mplsTunnelEntry xx }

mplsTunnelDiffServPsc OBJECT-TYPE
   SYNTAX        INTEGER (0..65535)
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates the PSC value to use for this LSP.  This object
        has no meaning if mplsTunnelDiffServLspType is set to
        no-diff-serv.
        If mplsTunnelDiffServLspType indicates exp-e-lsp, this 
        object must only represent a single Ordered Aggregate."
   REFERENCE
       "MPLS Support of Differentiated Services, Le Faucheur, 
        et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999."
   ::= { mplsTunnelEntry xx }

mplsTunnelDiffServExpELsp OBJECT-TYPE
   SYNTAX        TruthValue
   MAX-ACCESS    read-create
   STATUS        current
   DESCRIPTION
       "Indicates whether the number PSC value to use for this LSP.  This
        object has no meaning if mplsTunnelDiffServLspType is set
        to no-diff-serv."
   REFERENCE
       "MPLS Support of Differentiated Services, Le Faucheur, 
        et. al, draft-ietf-mpls-diff-ext-02.txt, October 1999."
   DEFVAL        { false }
   ::= { mplsTunnelEntry xx }

--
Adrian Farrel  mailto:[email-masked]
ATM, MPLS and Telecoms Development Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>-----Original Message-----
>From: Thomas D. Nadeau [mailto:[email-masked]]
>Sent: Wednesday, January 05, 2000 12:47 PM
>To: Adrian Farrel; [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: MPLS TE MIB
>
>
>
>         Yes, the TE MIB is alive and well. I am currently working
>on the final edits for the next revision with Cheenu. The new revision
>should be out in a few weeks.
>
>         --Tom
>
>
>>I have some issues with the current draft of the TE MIB, but 
>before I raise
>>them I want to check that the MIB is alive and well.  The 
>current version,
>>draft-ietf-mpls-te-mib-01.txt, is marked as expiring in December 1999.
>>
>>Can anyone tell me what the plans are for further progress?
>>
>>TIA
>>Adrian
>>--
>>Adrian Farrel  mailto:[email-masked]
>>ATM, MPLS and Telecoms Development Group
>>Data Connection Ltd., Chester, UK
>>http://www.datcon.co.uk/
>>Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>