The MPLS WG Archive

[stefaan.de_cnodder@alcatel.be]

JL,

When a PLR (in case of one-to-one protection) receives
a ResvTear, it may also do a switchover to the detour.
So a detour is used not only when the immediate
downstream link or router fails, but it can also be
triggered by failures further downstream and the
downstream nodes do not have a detour (the last
paragraph of section 5.2 of the fast-reroute draft
suggests this behavior although it is not clear). So
sharing bandwidth between detours protecting different
primary LSPs becomes difficult, i.e. in the worst case,
a detour can protect the whole primary LSP downstream
of the PLR and merging another detour with it will not
necessarily increase the number of protected entities.
This looks like a good property because you have fast
protection (although somewhat slower) even in case the
local PLR upstream the failure was not able to
establish a detour. So merging detours (for both types
of detours) looks like a good solution to save
bandwidth.

regards,

Stefaan


Alia Atlas wrote:
> 
> 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