Subject: draft-gan-fast-reroute-00.txt

From: Curtis Villamizar <[email-masked]>
Date: Thu, 12 Apr 2001 15:33:47 -0400

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?

---

From: Ping Pan <[email-masked]>
Date: Thu, 12 Apr 2001 14:07:05 -0700

> on backup paths to be shared where possible.  See additional comments

Sure. I have read the INFOCOM papers before. Let me take a look at them
again. Just curious, has anyone implemented the proposed routing
(OSPF/ISIS) extensions?

> given node, which covers the node disjoint case above.

My editing goof: the downstream node ID is the first downstream router
to avoid. It is used in the CSPF computation, which is to provide the
shortest detour path between the current router to a downstream merging
router. We will consider your comment of having a list for protecting
nodes.

> SRLG should also be considered in the "Detour Path Computation

Sure. Thanks!

> Could you please point out exactly what you think is new and unique

It's up to the lawyers to decide. ;-) Look, it seems everyone has used
the similar paragraph for their restoration mechanism. We really have no
choice. BTW, what's the status of that restoration patent application
from Bell Labs which your drafts are based on? ;-)

Take care and thanks!

- Ping

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 12 Apr 2001 18:53:22 -0400

> again. Just curious, has anyone implemented the proposed routing

Not quite yet but RSN.

> router. We will consider your comment of having a list for protecting

That was clear in the document.  My point is that the "node disjoint
path" case is a subset of what can be expressed with SRLG.

> > SRLG should also be considered in the "Detour Path Computation

So you'll add one or two Objects to cover SRLG, and possible the link
disjoint special case.

> from Bell Labs which your drafts are based on? ;-)

I don't think it is up to the lawyers to decide what is original
unless they among the inventors.  I'm not a lawyer so its possible
that I can't say that.

I also wonder how many of these patent applications if awarded would
stand up if challenged.

Lets continue offline.

> - Ping

Good to hear from you again,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 12 Apr 2001 19:09:48 -0400

> from Bell Labs which your drafts are based on? ;-)

It is not up to the lawyers to decide.  The lawyers provide a service
to the inventors who must indicate to the lawyers what is original and
non-obvious that makes this a patentable invention.  Of course, the
law profession specifically disallows anyone who is not a lawyer from
giving legal advice, so don't consider this legal advice, and go
consult a lawyer.

In my legally unprofessional and uninformed opinion, a lot of the
patent claims we are seeing ar smoke screens and would not stand up on
appeals.  But you have to discount that comment too.

As far as any Lucent patents, they may be negligent in not disclosing
intellectual property claims if they are applying for a patent.  I
don't know of any patent application and I have been led to beleive
that there is none.  I will ask Lakshman.  If the application of their
algorithm to the problem of restoration becomes patented and is not
licensed for a nominal fee, then I'd abandon the work and use an
algorithm of my own design that I had considered prior to finding out
about their work.  It would involve more flooding, but anyone could
use it.

I wish we could get rid of this whole patent system.  It is enormously
counterproductive and hinders technical progress in so many fields.  I
hope networking isn't the next victim of the patent system choking
innovation.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 12 Apr 2001 19:12:20 -0400

People other that the Ping please ignore my last message.  It was
supposed to have the mailing lists trimmed off the Cc.

Oops.

Curtis

---

From: Ping Pan <[email-masked]>
Date: Thu, 12 Apr 2001 16:41:03 -0700

> So you'll add one or two Objects to cover SRLG, and possible the link

Let me check with other folks here. We have shipped the restoration
feature for a while, and providers have deployed it. So we have to be
careful. Please understand.

Thanks again!

- Ping