The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi,

At 11:15 21/03/2002 -0500, Qureshi, Muhammad A (Akber) wrote:
>Hi,
>
>Packet 1+1 is providing fast end-to-end protection. I think end-to-end
>protection has better failure coverage than any fast restoration scheme
>based on local reroute. Reason is the dependence of fast local reroute
>scheme on physical layer detection which may not be available all the time.
>Also there can be failures at the above layers which can affect the LSP
>forwarding but cannot be detected at the physical layer. So packet 1+1 fills
>a gap that cannot be covered by either IGP-reroute (which is slow) or MPLS
>FRR (which does not provide end-to-end protection).

I won't reiterate the same arguments as before (avoiding duplication ;-) )
Coming back to your statement "FRR does not provide end to end protection": 
every section along the path is being protected. Related to failure 
detection, various failure detection schemes may be used for different 
failure types: layer 2, RSVP hellos, ...

JP.

>1+1 protection in the transport world does duplicate traffic on two paths.
>It exists because it is simple to manage and provides fast end-to-end
>protection. Similarly, proposed packet 1+1 is also very simple to operate
>and provides fast packet 1+1 protection.
>
>Akber.
>
>-----Original Message-----
>From: Metz, Eduard [mailto:Eduard.Metz@KPNQwest.com]
>Sent: Wednesday, March 20, 2002 5:27 AM
>To: 'Nagarajan, Ramesh (Ramesh)'; 'Jean Philippe Vasseur'
>Cc: mpls@UU.NET; Qureshi, Muhammad A (Akber); Wang, Yung-Terng (Y T)
>Subject: RE: Comments on
>draft-nagarajan-ccamp-mpls-packet-protection-00.t xt
>
>
>
>Which applications / traffic types require this type of protection? (and why
>would existing methods not be sufficient? -IGP re-route, MPLS FRR-)
>
>How do you ensure that in case of a link / node failure the affected LSP it
>taken 'out-of-service'? Otherwise, it is very likely that both LSPs will end
>up sharing resources on at least a part of the path between ingress and
>egress LSR. Which is a waste of resources, but also could lead to congestion
>of the available path between ingress and egress. So potentially the
>protection mechanism could cause degradation of service (for those
>situations it should solve some problems).
>
>As the solution cannot cope with packet reordering between ingress and
>egress, qos/scheduling on the path between ingress and egress LSR could
>result in packet drop at the egress due to window-check failure.
>
>Side note: In general I feel more comfortable with solutions that stick to
>forwarding packets just once.
>
> > -----Original Message-----
> > From: Nagarajan, Ramesh (Ramesh) [mailto:rameshn@lucent.com]
> > Sent: Tuesday, 19 March, 2002 22:05
> > To: 'Jean Philippe Vasseur'
> > Cc: mpls@UU.NET; Qureshi, Muhammad A (Akber); Wang, Yung-Terng (Y T)
> > Subject: RE: Comments on
> > draft-nagarajan-ccamp-mpls-packet-protection-00.t xt
> >
> >
> > Hi,
> >
> > I have attached some viewgraphs which we plan to present to
> > MPLS WG. It
> > highlights features of our proposal and also compares to
> > other recovery
> > schemes like you have mentioned. Please take a look and we
> > can discuss more.
> > Fyi, the proposed approach is in field trail with a major
> > service-provider.
> >
> > ramesh.
> >
> >  <<ietf_0302.pdf>>
> >
> > > -----Original Message-----
> > > From:       Jean Philippe Vasseur [SMTP:jvasseur@cisco.com]
> > > Sent:       Tuesday, March 19, 2002 12:00 PM
> > > To: Nagarajan, Ramesh (Ramesh)
> > > Cc: mpls@uu.net
> > > Subject:    Comments on
> > > draft-nagarajan-ccamp-mpls-packet-protection-00.txt
> > >
> > > Hi,
> > >
> > > A few comments about your proposal:
> > >
> > > I personally do not see the clear advantages compared to
> > local protection
> > > (FRR) especially in term of efficiency (local => <50ms
> > convergence time ;
> > > protection => control on the QOS for the rerouted LSPs)
> > while allowing
> > > protection bandwidth sharing.
> > >
> > > while
> > >
> > > I clearly see serious disadvantages/showstopper:
> > > - bandwidth consumption as you bridge the traffic onto the
> > two LSPs. You
> > > just double the bandwidth consumption for every protected LSP.
> > > - requires Hardware modification on every ingress and egress LSR,
> > > - ...
> > >
> > > Let's have the comments from SPs ...
> > >
> > > JP.
> >