The MPLS WG Archive

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>]

Hi Alia

You say that an advantage of the path specific method 
is less bandwidth reservation, thanks to detour merging.

I'm not sure that detour merging  always reduce bandwidth reservation.
Indeed, when you merge many detours, the final detour protects many
entities (links, nodes, SRLGs).
and thus you reduce the possibility to share bandwith with other
detours.

Regards 

JL 

-----Message d'origine-----
De : Alia Atlas [mailto:aatlas@avici.com]
Envoye : samedi 12 octobre 2002 01:50
A : Pan, Ping
Cc : Shahram Davari; 'Thomas D. Nadeau'; mpls@UU.NET
Objet : Re: what's the status ofdraft-ietf-mpls-rsvp-lsp-fastreroute-00.
txt


Absolutely.  The real requirement has been for inter-operability.  It is

important that what is out there be inter-operable and provide the 
functionality required.

While I would not have chosen the trade-offs made for the path-specific 
method, there are advantages to it (earlier merging of detours so less 
bandwidth reserved) as  well as disadvantages.  Let those who plan to 
deploy it decide what they want.

The draft says how to sit down and actually implement this feature.  As 
Ping says, the code for it is rather complicated.   One has to keep
track 
of merging states, keeping state around even though the relevant
interface 
is down, propagating or not propagating messages, etc.

That said, much as Ping had the need to inter-operate with Cisco's
bypass 
tunnels, we've had the requirement to inter-operate with both.  Much
like 
Ping, I sat down and figured out what would be possible and logical to
do; 
we did so.  That's why I did the draft suggesting how to deal in a
network 
with both cases.

Certainly, we've implemented both the Path-specific method as well as
the 
sender-specific method, because of the requirement to interoperate.
That's 
what standardization is about - the need to interoperate.

We're keeping the old Class-type for FAST_REROUTE, without the
include-any 
administrative-color, in the draft for the same reason.  It describes
what 
is done.

Clearly the issue of the path-specific method is contentious.  Are there

others with opinions on this one?  Perhaps we could/should put in some 
applicability words about the advantages and disadvantages of each
approach 
to aid those deciding which to implement and/or deploy?

Alia

At 04:23 PM 10/11/2002 -0700, Pan, Ping wrote:
>Hmmm... let me see who have done what in this space...
>
>Path-specific one-to-one method:
>   Juniper, several routers (cannot tell the names)
>
>Sender-specific one-to-one method:
>   Avici. ?
>
>Many-to-one method:
>   Cisco (both node and link protection), Juniper (link protection for
now).
>
>We never said that every vendor has to support everything in the draft 
>right away right now. Since each method has its own merits, we let the 
>developers and carriers to decide.
>
>To talk about lack of consensus based on some people's comment is quite

>amazing and disturbing.
>
>People have been asking why we glued two approaches together in the
first 
>place. It looks like we are here for some rubber-stamping. But you guys

>gotta ask yourself this: Cisco and Juniper are not the best friends in
the 
>first place, so why in the world do they get together to do this? The 
>answer is that marketing people tried to kill each other, but didn't
work. 
>:-) The customers seem to know more than we do on the advantages and 
>disadvantages of both methods...
>
>... It's been a slow Friday afternoon. Let me tell the whole story
behind 
>this fast reroute crap:
>
>About one year ago, Der-Hwa Gan got one-to-one fast reroute working on 
>Juniper routers. The original idea came from Tony Li (while in Juniper)

>and Der-Hwa. It was by far the most complex code in RSVP (you guys
ought 
>to try it someday). It worked, and shipped. At the same time, Cisco got
a 
>MPLS fast-reroute working as well. Both methods didn't work together.
So 
>one day, Dave Cooper of Global Crossing came to us and told us that he 
>needed fast reroute to be compatible with each other, and didn't care
how 
>to achieve it.
>
>I got the assignment, found a copy of draft-swallow, and started the 
>coding. When I thought it was done, I hooked up a Cisco router. Nothing

>worked! There was no sender-specific stuff in sight. All I got was the 
>original Path messages tunneled through the bypass LSP. After talking
to 
>George Swallow and JP directly over the phone, I was told that the new 
>code was still in beta, and has not been released yet. To me, being
upset 
>was an understatement! But Cisco folks were kind enough to send a copy
of 
>their new draft that actually told me how it supposes to work. As my 
>release date slipping fast, I had to rewrite the darn thing from
scratch.
>
>More disturbing discovery was that since Cisco used Shared-explicit
style, 
>while Juniper used Fixed-Filter, there was no way we could turn on both

>Juniper and Cisco fast reroute to protect a single LSP. We could not
ship 
>this fast-reroute feature this way to the customers. Around this time, 
>Alia from Avici told us that they had been reverse engineering Juniper 
>fast reroute, and had found several serious problems (including merging

>rules and sender-specific vs. path-specific). So Der-Hwa and I started
to 
>changed our code while changing the spec. That merging rule in the
draft 
>was actually a line-by-line pseudo code at one point. It was kinda fun 
>thinking back. :-)
>
>When I was done with the facility fast reroute proposed by Cisco, there

>were a lot of implementation issues. So I merged both drafts together,
and 
>sent it to George and JP for correction along with a bunch of
questions. 
>Avici folks came on board also. So we had several rounds of discussion
and 
>disagreement, but came up a draft that developers knew how to
implement. 
>That was what you have seen.
>
>The final outcome of the draft would allow both one-to-one and
many-to-one 
>fast reroute to be turned on to protect a single LSP. Both
sender-specific 
>and path-specific would work together too. That's what you have in
Junos 
>5.4. The implementation of facility fast-reroute was limited to link 
>protection in Juniper so far, because that was what Dave Cooper wanted 
>anyway. Dave was kind enough that we actually interop'ed the facility 
>fast-reroute with Cisco developers (Rob and Carol) in Global Crossing
lab 
>(this is bud to you, Brook!).
>
>The reason for telling you all this is that this draft came directly
from 
>engineers with the help from providers. No vendor politics, no IETF 
>politics, it was a lot of pain and fun at the end! If you are a
developer, 
>you can really implement this by reading spec.
>
>So before you question our motives again, please reconsider.
>
>Thanks!
>
>- Ping