Subject: Re: MIBs for GMPLS

From: "Irfan Lateef" <[email-masked]>
Date: Wed, 27 Jun 2001 19:53:39 -0400

Tom,

I may be missing something here but let try to make it
more explicit using a hypothetical example.

Let us extend the example given in the draft
draft-nadeau-mpls-gmpls-te-mib-00.txt section.8 from two hops
to N hops and from loosely routed to explicitly routed and assume
that this has to be done automatically from a management application.

Further assume the application needs to find a list of ERHOPs
satisfying a condition like "find unprotected lambdas with OC-48
worth of bandwidth and setup an LSP  from A to B".

My understanding is, the information gathered by the extensions
specified in draft-kompella-ospf-gmpls-extensions-01.txt section.5
namely LinkProtectionType,LinkDescriptor (in fact most of the
sub-TLVs of TE-link TLV) may be necessary to do this.

I do not see this data incorporated in any MIB.

Now in the absence of such data, how can the management application
compute the explicit hops satisfying the criteria mentioned above.

If I am totally in the wrong direction would appreciate any pointers
in the right direction.

Thanks for your attention and appreciate your response.

Irfan Lateef

>From: "Thomas D. Nadeau" <[email-masked]>
>To: "Irfan Lateef" <[email-masked]>, [email-masked]
>Subject: Re: MIBs for GMPLS
>Date: Wed, 27 Jun 2001 09:15:44 -0400
>
>
>         Hi,
>
>>In order to use the MIB defined by the draft
>>draft-nadeau-mpls-gmpls-te-mib-00.txt a MIB similar
>>to RFC 1850 OSPF-v2 MIB with extensions derived from
>>ideas given in the following drafts
>>draft-kompella-ospf-gmpls-extensions-01.txt
>>AND/OR
>>draft-kompella-isis-gmpls-extensions-02.txt
>>AND/OR
>>draft-katz-yeung-ospf-traffic-05.txt
>>AND/OR
>>draft-srisuresh-ospf-te-00.txt
>>AND/OR others ....
>>may be required to exchange topology data with the management
>>interface. This data can then be used by the administrator to
>>setup TE-tunnels.
>
>         I don't think that this is necessary for GMPLS-TE
>tunnels to be set up. The aforementioned drafts are
>necessary insofar as to facilitate the exchange
>of that information. That is, that functionality
>must be supported by the devices in the GMPLS
>network.
>
>>I have the following two questions,
>>
>>1. Whether such a MIB is being written/developed?
>
>         Yes, GMPLS-TE-MIB.
>
>         --Tom
>
>
>
>
>>2.  If yes, which draft(s) is being used as a base and
>>    when is it likely to be available.
>>
>>2a. If no,which draft is the most likely candidate to be used
>>    for drafting a MIB like, say, gmpls-ospf-te-mib.txt
>>
>>Appreciate your guidance.
>>
>>If this is not the forum, I would like to find an interest
>>group to discuss this subject.
>>
>>Thanks
>>Irfan Lateef
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 27 Jun 2001 21:12:21 -0400

>worth of bandwidth and setup an LSP  from A to B".

         Then you go to LSR A and specify the tunnel bandwidth to
be that of an OC-48 link and specify B as the destination.

>sub-TLVs of TE-link TLV) may be necessary to do this.

         If you feel that the GMPLS-TE-MIB is missing some
constrains, please let us know. At present, we feel that
the MIB is nearly adequate for specifying GMPLS te tunnels,
but we could be wrong and for this reason always welcome
input from others.

         It is my understanding that the tunnel will be signaled
as any other MPLS tunnel, just using additional or replacement
GMPLS-specifics. Therefore, the number of hops in the tunnel
or the constraints those links fit into are not necessary for
this to work. That is, the head-end should be able to signal
the tunnel based on the information specified in the tunnel record.
If you want to calculate explicit paths and want to check out what
bandwidth/afinity/etc... is available, there are several
ways of determining this. Depending on what configuration you
are using, the MPLS link bundling or MPLS-DS-TE MIBs might
help you, as they provide specific TE link information. These
might be more appropriate places to find that information
anyway.  Please take a look at these and see if they
meet (or not) your requirements. Second, there are proprietary
MIBs that various vendors have that show this information
as well.

>compute the explicit hops satisfying the criteria mentioned above.

         The management application should not be required to
compute the explicit hops. There are several reasons why this
is very difficult, but basically they are the same as any
off-line TE application would experience, just worse because
the information needs to be up-to-date all the time. If it
somehow does, it needs all of the information provided by the
CSPF in every LSR, perhaps across multiple (G)MPLS domains.
What is typical in such cases is the use of loose routes.
These are specified at the head-end LSR, which then does the
path computation between the points specified. This is much
easier to do there because it already has this up-to-date
information. In cases where specific paths are to
be taken, then entire path (or most of it) is specified, and the
LSR optionally fills-in the gaps. Some off-line tool may be
used to assist the operator in this choice, but it is not
mandatory, and as mentioned, is a difficult process to
get right especially in a multi-vendor network.

         --Tom