The MPLS WG Archive

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

I suppose MPLS cloud cosnists of many hops. In this case end-to-end
path protection requires detection+notification which would be hard to
achieve in 10s of millliseconds unless network provides stringent QoS
requirements.
I don't think IGP reroute can achieve 10s of milliseconds recovery in a
reasonable size network. (We are targetting for restoration times in order
of
10s of milliseconds)

Below in your example you are assuming a specific policy of what
happens after failure of an LSP. No where in the draft we are advocating
that
policy. When computing the failed route one can always put a constraint to
avoid SRLGs being used in the working path. It can be done easily through
configuration as done in the transport network as well as signalling (if one
wants to use it).

Akber.

-----Original Message-----
From: Metz, Eduard [mailto:Eduard.Metz@kpnqwest.com]
Sent: Thursday, March 21, 2002 12:41 PM
To: 'Qureshi, Muhammad A (Akber)'; Metz, Eduard; Nagarajan, Ramesh
(Ramesh); 'Jean Philippe Vasseur'
Cc: mpls@UU.NET; Wang, Yung-Terng (Y T)
Subject: RE: Comments on
draft-nagarajan-ccamp-mpls-packet-protection-00.t xt


I'm not so sure about some of the statements below.

Why does MPLS FRR not provide end-to-end protection? It has the same scope
as 1+1 packet protection, which is the MPLS cloud. (btw also IGP reroute can
be fast (enough)).

I doubt that packet 1+1 is as 'simple' as SONET/SDH 1+1. It is simple in
transport networks because these (and the equipment) are built for it. Many
packet networks (and routers) are not like that. For one, transport networks
do not have dynamic routing which is one of the main ingredients of packet
networks. And also one of the strenghts, e.g. it allows recovery of 2+
failures.

Consider the following:
- LSP-A is setup with bandwidth constraint X.
- Now LSP-B should be the mated one of LSP-A. In an automated setup probably
LSP-B will be setup with bandwidth constraint X, and the additional
constraint to avoid SRLG used by LSP-A.

If a failure occurs on the path of LSP-A it will be re-routed. Assume it now
shares part of the path of LSP-B. Since the SRLG of LSP-A has changed (and
overlaps with LSP-B), LSP-B will be re-routed as well. Such a sequence of
events would probably result in packet loss on the egress, and minimise the
potential gain of this solution. Unless you nail down the LSP statically
-which has other downsides-, how would you avoid the above? 

cheers,
	Eduard

ps how do you plan to handle traffic like traceroute? as the intermediate
LSR are not aware of the special status of the traffic they carry, probably
one would get interesting reponses (of course this could be considered a
feature).

> -----Original Message-----
> From: Qureshi, Muhammad A (Akber) [mailto:mqureshi@lucent.com]
> Sent: Thursday, 21 March, 2002 17:16
> To: 'Metz, Eduard'; 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
> 
> 
> 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. 
> > 
>