RE: 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