RE: RPR protection with MPLS

Helen, just wanted to point out that in RPR frames
carrying a specific LSP can be identified as 
either protected or unprotected. 
If unprotected than MPLS can either resort to
path or span restoration techniques as planned.

Couple of interesting points to note: 
1)if all node on
RPR are routers or LSRs. The current RPR standard
would make the RPR subnet behave such that each
router or LSR would be adjacent to each other 
regardless of their relative position on the ring.
There could be some LSPs between LSRs on the RPR ring
whose packets traverses other nodes.
The other interesting element is that upon
protection switching RPR would introduce the packet
on the opposite (East or West) interface. To the LSR
both
these physical interface should appear as a single
MPLS interface.

Raj Sharma
Luminous Networks
(408) 342 6460

--- Helen Butcher <[email protected]> wrote:
> 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


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2