RE: RPR protection with MPLS

David Zelig <[email protected]> Tue, 12 Nov 2002 16:19:46 +0200
Newsgroups gmane.ietf.iporpr
Message-ID <[email protected]>
Frank,
See below

> -----Original Message-----
> From: Frank Kastenholz [mailto:[email protected]]
> Sent: Tuesday, November 12, 2002 3:43 PM
> To: [email protected]
> 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
>