The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

Hi JL,

Remember that today one can only merge detours for the same protected 
LSP.  Currently, there's no idea that one could share bandwidth between 
detours protecting different primary LSPs (though the DETOUR object is 
there, so it would be possible...).

Alia

At 02:51 PM 10/14/2002 +0200, LE ROUX Jean-Louis FTRD/DAC/LAN wrote:
>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