Subject: Last call on MPLS TE MIB

From: George Swallow <[email-masked]>
Date: Fri, 05 Jan 2001 17:17:58 -0500

This message begins a workgroup last call on
draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management
Information Base Using SMIv2".

The last call ends Jan 19, 5pm est.
                               
...George

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: "Korchemny, Elena" <[email-masked]>
Date: Wed, 10 Jan 2001 16:38:19 +0200

Greetings,

MPLS-TE-MIB has been implemented for Virata MPLS software packet.
This implementation is based on draft-ietf-mpls-te-mib-05 document.

A few points arose during our work on MPLS-TE-MIB. I think these
points might clarify MPLS TE MIB draft before it become standard.

 1. There is mplsTunnelLocalProtectInUse object in the Tunnel table 
    Can you add reference to a document (draft, RFC, standard) explaining
    what is "Local protection mechanism".
    Is there any relation between mplsTunnelLocalProtectInUse object and
    "isPersistent" flag of mplsTunnelSessionAttributes object.

 2. mplsTunnelOwner objects currently has 5 values: 
       admin(1), rsvp(2), ldp(3), policyAgent(4) and other(5).
    It seems to me that tunnel owner should be defined as:
       admin, signaling, policyAgent, other. And in order to know which type
of
   signaling was used for tunnel creating object mplsTunnelSignallingProto  
   should be used. 
   Existing definition causes doubling of information on transit hops 
   (for example, a tunnel owner is rsvp(2) and signProtocol is rsvp(2)). 

 3. mplsTunnelIndex and mplsTunnelInstance objects
    How do you see mapping between TE MIB tunnel index/instance and 
    the signaling protocol concepts?
    In Virata TE MIB implementation we interpreted these objects as:
      for RSVP signaling -
        mplsTunnelIndex corresponds to TunnelId of the rsvp session object,
        mplsTunnelInstance corresponds to LSPID of the sender template.

     for LDP signaling - 
         mplsTunnelIndex corresponds to LSPId TLV in label
request/mapping/...
                                                             messages,
         for mplsTunnelInstance we don't see appropriate object in CR-LDP
           (CR-LDP does not support "multi-path tunnel").
           We set TE MIB TunnelInstance value to 1 in this case.  

    Does this approach correct? Or you didn't mean any relation between
    the Tunnel table indices and the signal protocol objects?

 4. One more little note.
    mplsTunnelTotalUpTime and mplsTunnelInstanceUpTime objects are defined
with
    MAX-ACCESS "read-create". I think they should be "read-only". Am I
right?
    mplsTunnelAdminStatus is defined as read-create, it should be
read-write.  

 I think the above points might clarify the MPLS-TE_MIB draft.
 (And your answers to the above questions should help us to improve our
MPLS-TE MIB implementation.)

Regards,
Elena Korchemny

Senior software engineer
VIRATA
Tel: +972-9-7663288 (Ext. 211)
[email-masked] 

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Saturday, January 06, 2001 12:18 AM
To: [email-masked]
Subject: Last call on MPLS TE MIB

                               
...George

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 17 Jan 2001 11:42:20 -0500

Hi Joan and Shobhan,

         Thanks for the comments.

>Shobhan Lakkapragada was involved in an implementation of
>CR-LDP and found that the following objects are needed
>to fully support the CR-LDP protocol using the
>MPLS TE MIB (draft-ietf-mpls-te-mib-05.txt).
>
>Also, I have reviewed these objects and would like to
>see these added to MPLS TE MIB.  That way, the MPLS TE
>MIB could be used for both MPLS-RSVP and CR-LDP which
>is, we believe, the intent of the MIB, i.e. one MIB for
>both of the TE MPLS protocols, namely, MPLS-RSVP and
>CR-LDP.

         Agreed. It was and still is, one of our goals
for this MIB to have a single MIB used for TE, regardless
of signaling protocol or implementation.

>The following objects would fit in the mplsTunnelResourceEntry.
>These objects are important in order to fully utilize the
>Traffic Parameters offered by CR-LDP.

         These all look okay to me. As long as there are no
other objections from the WG, I think that we can add
these. Would anyone object to these objects being
made mandatory in the conformance statement for only
those implementations utilizing CR-LDP for signaling?

         --Tom

>         mplsTunnelResourceMeanBurstSize        MplsBurstSize,
>         mplsTunnelResourceExcessBurstSize      MplsBurstSize,
>         mplsTunnelResourceFrequency            Integer32,
>         mplsTunnelResourceWeight               Unsigned32
>
>         mplsTunnelResourceMeanBurstSize OBJECT-TYPE
>              SYNTAX        MplsBurstSize
>              UNITS         "bytes"
>              MAX-ACCESS    read-create
>              STATUS        current
>              DESCRIPTION
>                  "The mean burst size in bytes."
>
>         mplsTunnelResourceExcessBurstSize OBJECT-TYPE
>              SYNTAX        MplsBurstSize
>              UNITS         "bytes"
>              MAX-ACCESS    read-create
>              STATUS        current
>              DESCRIPTION
>                  "The Excess burst size in bytes."
>              REFERENCE
>                  "CR-LDP Specification, Section 4.3."
>
>         mplsTunnelResourceFrequency  OBJECT-TYPE
>              SYNTAX        INTEGER {
>                                unspecified(0),
>                                frequent(1),
>                                veryFrequent(2),
>                            }
>              MAX-ACCESS    read-create
>              STATUS        current
>              DESCRIPTION
>                  "The granularity of the availability of committed rate. "
>              REFERENCE
>                  "CR-LDP Specification, Section 4.3."
>
>         mplsTunnelResourceWeight    OBJECT-TYPE
>              SYNTAX        Unsigned32(0..255)
>              MAX-ACCESS    read-create
>              STATUS        current
>              DESCRIPTION
>                  "The relative weight for using excess bandwidth
>                    above its committed rate.  The value of 0 means
>                    that weight is not applicable for the CR-LSP."
>              REFERENCE
>                  "CR-LDP Specification, Section 4.3."
>
>
>
>
> > Sent: Friday, January 05, 2001 5:18 PM
> > To: [email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 17 Jan 2001 16:21:06 -0500

Hi,

>     what is "Local protection mechanism".

         Certainly. I believe there is mention of this in the
mpls framework document.

>     "isPersistent" flag of mplsTunnelSessionAttributes object.

         Not necessarily. LocalProtect equates to a local path
repair (perhaps temporary) having taken place. The 'isPersistent'
bit indicates whether this tunnel should be restored automatically
after a link/LSR failure occurs.

>    (for example, a tunnel owner is rsvp(2) and signProtocol is rsvp(2)).

         Although it is a duplication in one or two cases,
I don't think that a change is necessary, as there is really
no operational impact or confusion if it is left the way it
is.

>         mplsTunnelInstance corresponds to LSPID of the sender template.

         Yes.

>            We set TE MIB TunnelInstance value to 1 in this case.

         I believe that this is true.

>     MAX-ACCESS "read-create". I think they should be "read-only". Am I

         Yes, that is a typo on our part.

>     mplsTunnelAdminStatus is defined as read-create, it should be

         Yes; typo.

         --Tom

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Wed, 24 Jan 2001 10:42:21 -0500

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

> 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: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 26 Jan 2001 13:51:41 -0500

Hi! The current version of the MPLS-TE MIB does
	not capture the QoS scheme (Int-Serv / DiffServ) 
	and the associated parameters being used by a
	MPLS tunnel. Should the MPLS-TE be extended to 
	handle this ?

	Per MPLS Tunnel information I was looking for:
	---------------
	1. QoS scheme being used by the tunnel 
	   (At least at the originating LER.)

	2. If QoS scheme is Diff-Serv
		2.1 Type  of the LSP (L-LSP/E-LSP)
		2.2 If L-LSP (with signaled EXP<->PHB)
			2.2.1 The PSC associated with the
				L-LSP
			2.2.2 With or without bandwidth reservation.
				(Assume: If mplsTunnelResourcePointer	
				==ZeroDotZero then no bandwidth
				reservation needed)
				
		2.3 If E-LSP (with signaled EXP<->PHB)
			2.3.1 The set of PSCs being carried 
				by this E-LSP (EXP<->PHB
				mapping that was signaled 
				for this LSP)
			2.2.2 With or Without bandwidth reservation.
				(Assume: If mplsTunnelResourcePointer	
				==ZeroDotZero then no bandwidth
				reservation needed)		

	Some specific examples:
	-----------------------
	1. Assume that user configured a MPLS tunnel on
	a Diff-Serv aware LER. How will the LSR know 
	what kind of LSP (L-LSP / E-LSP) to setup ?

	2. How can the user determine what type of 
	PSC is being carried on a specific L-LSP ?
	(Alternatively, how can a user request the LSR
	to establish a L-LSP for a specific PSC?)

	3. How can user determine the details related to
	signaled EXP<->PHB mapping for a specific 
	E-LSP ?

	If this issues has been already addressed, I
	will appreciate if you can help me with the 
	answer to the above questions.

	Thanks,
	sanjay

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 27 Jan 2001 08:51:22 -0500

Hi,

>         MPLS tunnel. Should the MPLS-TE be extended to

         No. The traffic parameters which are there were
agreed upon a while ago, and are appropriate for what
we were chartered to do. The MPLS-TE-MIB will not
directly support DiffServ-aware TE  because it is so new.
We have been directed to finish up  the MIB now, so waiting
for the D-A-TE work to be completed  by the WG(s) is
not an option.

         I am preparing an extension to the TE MIB as a
companion to the other DiffServ-aware TE documents I am
working on with Francois et al. I will have it ready for
the next IETF meeting.

         --Tom