The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

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