The MPLS WG Archive

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

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