Subject: RE: [IPORPR] RPR protection with MPLS

From: David Zelig <[email-masked]>
Date: Tue, 12 Nov 2002 16:19:46 +0200

Frank,
See below

> -----Original Message-----
> From: Frank Kastenholz [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 3:43 PM
> To: [email-masked]
> Subject: RE: [IPORPR] RPR protection with MPLS
> 
> 
> At 06:09 PM 11/11/2002 -0800, George Suwala wrote:
> >Indeed successful RPR protection should not trigger MPLS 
> protection (should have no impact on the MPLS protection).
> >
> >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.

David

> Frank Kastenholz
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: nitin panjwani <[email-masked]>
Date: Tue, 12 Nov 2002 12:09:46 -0800 (PST)

Hi David and all,
> 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-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: Helen Butcher <[email-masked]>
Date: Tue, 12 Nov 2002 18:36:20 -0500

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.

---

From: "A.Herrera" <[email-masked]>
Date: Tue, 12 Nov 2002 19:17:29 -0500

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

> critical network and the passing traffic is(this
Both MPLS FRR and RPR steer/wrap are localized
reactions to divert within ms. to a pre-determined
detour path or alternate ring direction. So I'll
assume that operator preferences to fault scenarios
are pre-determined and pre-configured as per network
planning based on critical flows.

In this case, I would think, that sufficient feedback from
RPR as to the nature of the faults (i.e. multiple or
combinations of Signal Fail/Degrade, etc.) will allow MPLS
to choose to divert even before RPR protection settles.
For single occurrances of SF, etc, RPR is more than
sufficient protection for critical flows.

These mechanisms and scenarios should be discussed
and further clarified within the WG.

Albert

---

From: "Vinay Bannai" <[email-masked]>
Date: Tue, 12 Nov 2002 17:12:01 -0800

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-masked]>
To: "nitin panjwani" <[email-masked]>; "David Zelig"
<[email-masked]>; "'Frank Kastenholz'" <[email-masked]>; <ipo
[email-masked]>
Sent: Tuesday, November 12, 2002 3:36 PM
Subject: RE: [IPORPR] RPR protection with MPLS

---

From: raj sharma <[email-masked]>
Date: Tue, 12 Nov 2002 19:41:41 -0800 (PST)

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-masked]> wrote:
> > > > >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
> > > > 1. When the 802.17 ring has a failure and
> invokes
> > > its protection
> > > >    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.
> > >
> > > >   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
> > > whether to wait for the MPLS timeout to detect
> it or
> > > report immediately back