Re: Draft response to OIF on 1:n protection

["Adrian Farrel" <adrian@olddog.co.uk>]

OK, Thanks.

I can fold that in with a bit more clarity on the master/slave thing.

Adrian
----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <julien.meuric@francetelecom.com>
To: <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Tuesday, May 23, 2006 2:35 PM
Subject: RE: Draft response to OIF on 1:n protection


Hi Adrian, hi all.

I have the feeling that the OIF may have prefered to ask CCAMP instead of 
taking into account the mentioned 
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and 
draft-ietf-ccamp-gmpls-segment-recovery-02 -- which seem to answer several 
of their questions. That might be due to the fact they are not RFCs yet, so 
it may be useful to inform the OIF of the current status of these and 
reassure about their significance.

A few more comments in line.


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf 
Of Adrian Farrel

[...]

> 5.) RFC 4426 refers to three abstract messages involved in the
> reversion sequence:
>
> - A Bridge and Switch Request message from the source node after it
> has bridged traffic back to both working and protection links.
>
> - A Bridge and Switch Response message from the destination node after
> it has bridged traffic back to both working and protection links and
> changed its selector to the working link.
>
> - A Bridge and Switch Completed message from the source node after it
> has changed its selector to the working link and stopped sending traffic
> on the protection link (so the destination can stop transmitting on
> protection).
>
> Since RFC 4426 covers these Bridge and Switch messages briefly, more
> details should be specified on the operation and behavior in this
> reversion process.

If you have specific questions, we would be happy to answer them. If you
believe that additional documentation is required, we would welcome your
contributions as an Internet-Draft.

[JM] This could be a good place to pinpoint the IDs named above.


> Further, it would be helpful to understand why the actions are
> performed by source and destination nodes rather than master and
> slave nodes. It may be appropriate to reuse the master/slave roles
> in the reversion process just as is done in the switchover process.

There is a distinction between the node that invokes a switchover
process (the master) and a node that performs the process. For
example, a Bridge and Switch Request message is sent by the source
node after it has bridged traffic back to both working and protection
links simply because the source node has performed the bridging and
is the only node that can know this fact.

[JM] I may not really get the intial issue here but I'm also confused by the 
answer. My understanding was about the wording "source/destination" vs 
"master/slave"; in that case we should rather restate why "source" and 
"destination" are relevant here. But maybe I need a coffee... ;-)

[...]


Regards,

Julien