The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

Der-Hwa, Ping, Arthi, Kireeti,

Please consider merging this capability with the bandwdith sharing
capability described in draft-kini-*.  This would allow the bandwidth
on backup paths to be shared where possible.  See additional comments
on this below.

Comments mixed with some text from your draft.

Curtis


> 3.2 DETOUR Object
>  
>        DETOUR Object
>  
>        Class = 63  (to conform 0bbbbbbb format for compatibility)
>        C-Type = 7
>  
>              0             1              2             3
>         +-------------+-------------+-------------+-------------+
>         |       Length (bytes)      |  Class-Num  |   C-Type    |
>         +-------------+-------------+-------------+-------------+
>         |                   Source ID                           |
>         +-------------+-------------+-------------+-------------+
>         |                   Downstream Node ID                  |
>         +-------------+-------------+-------------+-------------+
>  
>  
>       Source ID
>  
>         IPv4 address identifying the beginning point of detour.
>         Any address on the branching node can be used.
>  
>       Downstream Node ID
>  
>         IP address identifying the downstream node that source
>         is trying to avoid. Router ID of downstream node is preferred.


This seems to assume node disjoint paths.  A more general approach
would be to provide a list of SRLG that the detour need to avoid.

A special case is one where an SRLG contains all links terminated at a
given node, which covers the node disjoint case above.

Another special case is link disjoint, in which the link is the only
member of an SRLG.  One would use this if it was thought that the
nodes were sufficiently reliable but the links were not.

It should be fine to provide a object that names a specific node as a
special case of the detour object, and may be (is) needed to
accommodate existing code.  It might be useful to have a form of the
detour object that covered the link disjoint special case.  There
should also be a form of the detour object that allows the more
general list of SRLG.

SRLG should also be considered in the "Detour Path Computation
Algorithm" section.

Note that the draft does not say what intermediate nodes are supposed
to do with the "Downstream Node ID".  I can see that one potential use
would be in allowing loose hops in the backup path or hops across
areas where incomplete topology information is exchanged and
constraints must be provided.

Another potential use that was discussed on the MPLS mailing list a
very long time ago was to put the link, node, or SRLG that you were
trying to protect in an object in the backup path, and use that
information to determine if bandwidth could be shared.

If you also can flood information about the bandwidth being used for
backup and what SRLG are being backed up, this is referred to as
"having complete information" in the papers listed below.

   Lakshman, T.V., Kodialam, M., "Dynamic Routing of Bandwidth
   Guaranteed Tunnels with Restoration", Proceedings of INFOCOM 2000,
   April 2000.

   Lakshman, T.V., Kodialam, M., "Dynamic Routing of Bandwidth
   Guaranteed Tunnels Using Aggregated Link Usage Information", To be
   published in Proceedings of INFOCOM 2001.

The draft-kini-* simply provides a means to exchange the information
described in the above papers, draft-kini-restoration-shared-backup-00
providing the overview of the technique and the other providing the
TLVs needed for isis, ospf, and objects needed for rsvp.

The approach in draft-kini-* provides for limited flooding that is
capable of bandwidth sharing for backup tunnels almost as efficiently
as having complete information.

> 6 Intellectual Property Considerations
>  
>    Juniper Networks, Inc. is seeking patent protection on technology
>    described in this Internet-Draft. If technology in this Internet-
>    Draft is adopted as a standard, Juniper Networks agrees to license,
>    on reasonable and non-discriminatory terms, any patent rights it
>    obtains covering such technology to the extent necessary to comply
>    with the standard.

Could you please point out exactly what you think is new and unique
about this proposal?