The MPLS WG Archive

["Qureshi, Muhammad A (Akber)" <mqureshi@lucent.com>]

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).

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. 
>