The MPLS WG Archive

[Francois Le Faucheur <flefauch@cisco.com>]

Ramesh,

At 14:22 20/03/2002 -0500, Nagarajan, Ramesh (Ramesh) wrote:
>         First, Thanks for all your comments (including some other e-mails i
>have received in this thread). I think we have some good discussions going.
>
>         my comments interspersed below:
>
> > Nagarajan,
> >
> > If I understand correctly, this approach fundamentally does not achieve
> > protection at the MPLS layer (ie it does not rely on MPLS forwarding to
> > achieve protection) but rather achieves protection through a "thin"
> > additional protection layer on top of MPLS. In other words, the LSPs are
> > really used as pure pipes and you rely on an additional layer (aka
> > sequence
> > number in terms of protocol + some module in the data path to do packet
> > selection).
> > Is this not right?
> >
> > I sort of look at that as re-building a kind of SDH-lite on top of MPLS
> > (which seems a little odd to me since one objective of MPLS protection is
> > to be able to take advantage of MPLS forwarding so as not to have to rely
> > on underlying SDH protection).
> >
>         [Ramesh] I think the view of a thin layer on top of MPLS is one way
>of looking at it and a reasonable one.
>       However, all MPLS protection approaches that i am aware of require
>support outside of the MPLS *forwarding*             layer. This typically
>includes functions such as failure detection, failure notification and LSP
>switching (none                         of which we need for our proposal).
>What  we are requiring is a different kind of thin function  outside of
>basic MPLS forwarding. .

Yes, the other MPLS protection approaches make use of "mechanisms" in 
addition to MPLS forwarding, but all these mechanisms are in the control 
plane (e.g. failure detection, LFIB update). In terms of data path, the 
other protection approaches rely purely on existing forwarding mechanisms 
(e.g. label stacking).

A protection approach which cannot be supported by MPLS hardware strikes me 
as a pretty unattractive MPLS protection approach.

Also, this approach is very bandwidth wasteful when compared to the other 
approaches. First, the backup capacity is entirely wasted in the absence of 
failure (while other approaches allow complete reuse of it for traffic 
which can tolerate being squeezed out during failure). Secondly, the backup 
capacity is used on a path which should be SRLG disjoint end-to-end and 
thus may be much "longer" than back up paths used by local protection. 
You'd really have to be assuming an environment where bandwidth is of no 
concern at all.

You have similar inefficiencies in the terminating box in the cases 
discussed below where packets have to go to/fro inside the terminating LSR 
(BTW, I can't see the "protection in the box" argument since you still have 
a single point of failure in the card which actually does the packet selection)

The only thing this approach buys you is a slightly improved recovery time 
which is equal to the local failure detection time (note that failure 
notification is not required with bypass approaches).

I pesonnally can't see that such a small improvement (aka in the 10s of 
millisec) justifies a complete change in MPLS forwarding and MPLS hardware 
as well as the other drawbacks. Let's hear other opinions.

Francois


> > You may argue that this additional "SDH-lite" protection layer is really
> > really "thin" and should not be considered as an additional layer (it only
> >
> > needs a sequence number after all), but I have the impression that it is
> > affecting the data path so significantly that MPLS hardware could not cope
> >
> > with that (ie before doing forwarding of any packet I need to select the
> > copy of the packet - which BTW appears particularly interesting on egress
> > LSRs with distributed architecture when the two LSPs terminate on
> > different
> > input cards).
> >
>         [Ramesh] Selecting is done wherever the above thin layer is
>terminated. This may
>         imply that the duplicated packets are carried to a different line
>card than where
>         the LSPs are terminated. By the way, this provides additional
>protection (in the box) and is more
>         end-to-end from a service standpoint. Also, even for a single LSP
>one needs to carry
>         packets to a different line card if the service the LSP is carrying
>does not originate/terminate
>         at the card the LSP terminates.
>
> > So, am I wrong in assuming that this requires specific hardware support?
> > or
> > are you proposing that we adopt as MPLS protection an appraoch which
> > cannot
> > be achieved with existing MPLS hardware?
> >
>       [Ramesh] Hardware support is probably needed to implement the
>selection function
>       at high speeds. But it can also be done in software if speed is not an
>issue (also
>       someone may very well figure out/choose to do this simple/thin
>function extremely fast
>       in software).
>
> > If the latter, that would be an interesting element to add to your
> > comparison between your approach and pure MPLS protection schemes.
> >
> > Thanks
> >
> > Francois
> >
> > At 16:04 19/03/2002 -0500, Nagarajan, Ramesh (Ramesh) wrote:
> > >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.
> >


_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 19 98 50 90
Fax:                   +33 4 97 23 26 26
Email:                 flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________