Re: RPR protection with MPLS

I would to add some comments at this time. I apologize for getting in a
little late in the conversation.

First of all, MPLS path protection and RPR protection are completely
independent. In fact, when RPR runs on SONET, you have a additional layer of
protection. I would layer it as follows

1) L1 or Physical link protection (for instance if RPR were running on top
of SONET)
2) L2 or Mac layer protection provided by RPR
3) L2.5  MPLS protection
4) L3 protection

RPR ring is viewed as a broadcast media (for a lack of a better term) as
opposed to NBMA network. When the MAC is given the packet to send, it can
make a choice of going either west or east or mac client indicates the
direction. Again, there are two ways to handle the L3 interface. The L3
interface can be a stacked interface over the spans (physical port
interfaces). Meaning, as far as L3 is concerned, it can be made agnostic of
the fiber chops and protection events and the interface does not go up or
down and we let the mac take care of the default direction (remember the RPR
mac has access to the topology DB). For this kind of behavior, I don't need
MPLS re-route or L3 protection (meaning no need to withdraw and add routes).
However, there is another way of looking at the interfaces wherein the east
and west span are exposed to L3 and it ends up seeing two separate
interfaces. This becomes a littl tricky and we need to work through all the
cases.

I have written up some text on the handling of the L3 interfaces and would
be more than glad to put on the reflector for more review and incorporation
into the proposed draft.

I have tried to limit my discussion to a single ring only. MPLS reroute and
FRR takes on a whole new meaning for interconnected rings and subtending
rings (like the SONET subtend rings).

Thanks
Vinay




----- Original Message -----
From: "Helen Butcher" <[email protected]>
To: "nitin panjwani" <[email protected]>; "David Zelig"
<[email protected]>; "'Frank Kastenholz'" <[email protected]>; <ipo
[email protected]>
Sent: Tuesday, November 12, 2002 3:36 PM
Subject: RE: [IPORPR] RPR protection with MPLS


> My understanding as to which layer will respond first to a failure is
> dependent on what trigger and protocol timer expires first. If RPR
> takes more than some amount of time to respond to a failure
> and FRR is configured and optimized, MPLS could respond first
> before the ring. If anyone knows this cannot happen then please
> speak up. Since both RPR and FRR are capable of responding
> to a failure within a small amount of milliseconds, plus FRR is
> usually planned with consideration of layer 1 topology and properties
> such as latency, it seems to me that we need to understand the
> coupling effect when there is a failure.
>
> Thanks,
> Helen.
>
> At 12:09 PM 11/12/2002 -0800, nitin panjwani wrote:
>
> >Hi David and all,
> > > > >However if RPR protection fails, MPLS should be
> > > triggered to
> > > > protect. The exact method of doing it could be an
> > > IPORPR
> > > > discussion topic, with timeouts being one of the
> > > options (so
> > > > MPLS could be configured to ignore failures unless
> > > they
> > > > persist for more than say 100ms, which would
> > > indicate a
> > > > failure of the underlying RPR layer)
> > > >
> > > > Two questions
> > > > 1. When the 802.17 ring has a failure and invokes
> > > its protection
> > > >    procedure, do the higher layers see it as a
> > > brief failure in
> > > >    the link (i.e. there is an "interface down"
> > > event followed a
> > > >    few ms later by an "interface up" event) or
> > > does it happen
> > > >    transparently, with no interface failure (i.e.
> > > it would appear
> > > >    to the higher layers as just a brief moment of
> > > packet loss)
> > > >
> > > It is the later as the RPR will steer/wrap in less
> > > than 50msec.
> > >
> > > > 2 If an 802.17 ring fails and can not go into
> > > single-ring-mode
> > > >   for some reason, wouldn't it appear as a link
> > > failure to MPLS
> > > >   causing MPLS mechanisms to invoke fast reroute,
> > > just as if, say,
> > > >   a PPP link went kablooey or an ethernet lost its
> > > ether?
> > > >
> > > RPR failure is segment failure (not sure what you
> > > mean by single-ring-mode)
> > > i.e. you loose a segment between two nodes. If you
> > > have more than one
> > > failure any connection that cannot access the
> > > isolated nodes in the middle
> > > between those failures is lost. I believe it is
> > > implementation specific
> > > whether to wait for the MPLS timeout to detect it or
> > > report immediately back
> > > to the MPLS to invoke backward that re-route is
> > > required. This is something
> > > we can work out in the WG.
> >Shouldn't it be something like: either RPR or MPLS
> >protection will take charge of rerouteing the traffic;
> >and one which assures minimum packate loss and delay
> >will win and take charge.
> >On this, usually upper layer(MPLS) depends on the
> >lower layer(RPR)(as it simplifies the implementation
> >and serves the perfect goal of layering approach)and
> >shouldn't it be upto MPLS to decide wheathet to take
> >charge of protection or wait for RPR, depending on how
> >critical network and the passing traffic is(this
> >should be configurable).
> >Please correct me.
> >
> >Tahnks,
> >Nitin
> >
> >
> >
> >
> >
> >
> >__________________________________________________
> >Do you Yahoo!?
> >U2 on LAUNCH - Exclusive greatest hits videos
> >http://launch.yahoo.com/u2
> >_______________________________________________
> >IPORPR mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/iporpr
>
> _______________________________________________
> IPORPR mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/iporpr