The MPLS WG Archive

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

In message <3AD618F9.56BC0655@juniper.net>, Ping Pan writes:
> Curtis Villamizar wrote:
> > 
> > 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.
> > 
> 
> 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?

Not quite yet but RSN.

> > > 3.2 DETOUR Object
> > >
> > >              0             1              2             3
> > >         +-------------+-------------+-------------+-------------+
> > >         |       Length (bytes)      |  Class-Num  |   C-Type    |
> > >         +-------------+-------------+-------------+-------------+
> > >         |                   Source ID                           |
> > >         +-------------+-------------+-------------+-------------+
> > >         |                   Downstream Node ID                  |
> > >         +-------------+-------------+-------------+-------------+
> > >
> > 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.
> 
> 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.

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.

> > 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.
> 
> Sure. Thanks!

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

> > 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?
> 
> 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? ;-)

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.

> Take care and thanks!
> 
> - Ping

Good to hear from you again,

Curtis