Re: RPR protection with MPLS

I think it's a good plan. Core spec to
rely on standard IP/MPLS timeouts and 
convergence to somehow find its way 
to an unreachable node. Extended features
will go into tighter feedback between IP/MPLS
and 802.17 to coordinate failure scenarios
and maintain millisecond recovery.

Albert

----- Original Message ----- 
From: "Frank Kastenholz" <[email protected]>
To: "David Zelig" <[email protected]>; <[email protected]>
Sent: Tuesday, November 12, 2002 10:07 AM
Subject: RE: [IPORPR] RPR protection with MPLS


> At 04:19 PM 11/12/2002 +0200, David Zelig wrote:
> >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.
> 
> That's what I suspected.
> This means that we can ignore 802.17 failures which are handled
> by 802.17's protection mechanisms. MPLS will not see the failure.
> The only thing to be concerned about is that the path used by
> MPLS has changed because the path through the 802.17 ring has
> changed. MPLS might need to know of this change in order to
> determine if the path still has the desired properties, etc.
> 
> [Speaking as WG cochair now]
>         I believe that this is work that we've elected to
>         put off until we develop the Extended protocol
>         which is to be done after the rechartering we've
>         proposed for roughly Q1 of next year.  I'll make a
>         note to put this in the new charter.
> 
>         That said, some discussion on this point now is fine, 
>         so long as it does not interfere with working on the
>         core protocol stuff
> [No longer speaking as WG cochair]
> 
> 
> >> 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.
> 
> Well, I see I phrased my question badly, but you ended up answering
> it anyway. I'll spit the important points back just to make sure
> I've got them
> 1. If an 802.17 ring fails in such a way that traffic can not go 
>    from A to B across the ring, then as far as A->B traffic is 
>    concerned, it's just the same as any other failure. 
> 2. If the A->B path fails, traffic might still flow from A->C, so it
>    might not seem as if it's a "lower layer failure" ("lower layer"
>    from the perspective of IP and MPLS). However, this would have
>    the same apparent behavior to IP/MPLS as the failure of a specific
>    node on a muli-access network.  Imagine a traditional Ethernet with
>    nodes A, B, and C -- if node B failed, the Ethernet would be up, but
>    B is not reachable. 
> 
> So, we really have a couple of options here.
> A. If the ring fails such that node B is no longer reachable, we
>    extract this failure data from the 802.17 ring's MAC (or whatever
>    part it is that knows this information), reflect that data up to
>    MPLS, and then MPLS can fail only those path(s) that go to node B 
>    and invoke its recovery mechanisms
> 
> B. We do nothing. the failure of the ring such that node B is no
>    longer reachable in the above scenario would appear to MPLS
>    just as if node B itself had failed. MPLS would eventually 
>    discover this through the mechanisms it has today and do a
>    recovery. This involves the least work. It's not the ideal
>    solution, but I think it's consistent with the goals for the
>    core specification and it does work.
> 
> 
> [Speaking as WG cochair now]
>         I believe that option A is work that we've elected to
>         put off until we develop the Extended protocol
>         which is to be done after the rechartering we've
>         proposed for roughly Q1 of next year.  I'll make a
>         note to put this in the new charter.
> 
>         That said, some discussion on this point now is fine, 
>         so long as it does not interfere with working on the
>         core protocol stuff
> [No longer speaking as WG cochair]
> 
> Frank Kastenholz
> _______________________________________________
> IPORPR mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/iporpr