The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 07:53 PM 6/27/2001 -0400, Irfan Lateef wrote:
>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".

         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.

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

         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.

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

         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