The MPLS WG Archive

["Nagarajan, Ramesh (Ramesh)" <rameshn@lucent.com>]

Hi,

To add to akber's comments, certain soft failures are not only hard to
detect but also local bypass schemes may exhibit some undesirable behaviours
when (and if) these types of failures are detected. Let us consider the case
of a) MPLS forwarding tables are corrupted for a given LSP and packets are
being incorrectly forwarded or b) a LSR is dropping packets of a LSP for
reasons other than congestion. Note that our proposal provides protection 
against these soft failures as long as the soft failure effects only one
(single failure case) of the two LSPs. 
Also, we do not require any explicit detection of such a failure since
packets would be arriving fine from the working LSP. 

Now, let us consider, how one would detect such a soft failure. This would
be needed to activate the bypass in a path or a local reroute scheme. The
only means of detecting such a failure is by insertion of some kind of 
periodic keep alive in the data path of the LSP (Note that keep alives such
as OSPF hello, RSVP refresh etc., do not use the data forwarding path of the
LSP) and monitoring the presence of these keep alives at downstream nodes.
All this needs extra processing as akber has noted. Further, it takes time
since one has to damp immediate reaction to lack of keep alives (they may be
missing due to congestion rather than failure). Finally, failures are
detected at multiple downstream nodes. Note that in a sequence of LSRs
A->B->C->D with a soft failure (such as above) at B, both C and D would
detect a failure due to missing keep alives. In fact, in general, all nodes
downstream of the soft failure will detect the failure and will try to
signal to the next-next upstream hop (C->A and D->B in above example). So,
there is a lot of notification traffic as well as many upstream nodes trying
to switch. Eventually of course, the A->C (around B) switch will dominate
but all this signaling and switching is not very desirable. So, probably it
is best to not detect such failures in local bypass schemes because of
complexity and cost.

To put all of above in proper perspective, what we are proposing is a scheme
with the broadest failure coverage (so very high service
availability/reliability) and instantaneous recovery as some of the key
features. There is a price tag of course due to the bandwidth consumption on
both paths. That is why we believe it is complimentary to existing
approaches rather than replacing any particular approach. Together with
existing excellent approaches such as IGP reroute and MPLS FRR, we believe
our proposal provides service-providers and their end customers a richer set
of choices to better match their application needs.

ramesh.


----------------------------------------------------------------------------
--------------------------------------------------
Room 3M-335, Bell labs
Tel: 732-949-2761
101 Crawfords Corner Road
Fax: 732-834-5906
Holmdel, NJ 07733.
e-mail: rameshn@lucent.com.
----------------------------------------------------------------------------
---------------------------------------------------

> ----------
> From: 	Qureshi, Muhammad A (Akber)
> Sent: 	Thursday, March 21, 2002 5:56 PM
> To: 	'Jean Philippe Vasseur'; Qureshi, Muhammad A (Akber)
> Cc: 	'Metz, Eduard'; Nagarajan, Ramesh (Ramesh); 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
> 
> I assume that by proposing other detection mechanisms you are trying to
> approach
> the failure coverage of an end-to-end path protection scheme. Use of other
> detection mechanisms at higher layers will negatively affect (increase)
> the 
> recovery times. This will also increase complexity in terms of processing,
> etc.
> 
> Again, packet 1+1 provides maximum possible failure coverage with
> instantaneous
> recovery. It is extremely simple to operate. And only end nodes have to be
> service aware.
> 
> Akber.
> 
> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:jvasseur@cisco.com]
> Sent: Thursday, March 21, 2002 5:20 PM
> To: Qureshi, Muhammad A (Akber)
> Cc: 'Metz, Eduard'; Nagarajan, Ramesh (Ramesh); 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,
> 
> 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.
> > >
>