RE: Draft response to OIF on 1:n protection

"MEURIC Julien RD-CORE-LAN" <julien.meuric@francetelecom.com> Tue, 23 May 2006 13:48 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXFd-0008WC-8G for ccamp-archive@ietf.org; Tue, 23 May 2006 09:48:45 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXFd-0000B9-6M for ccamp-archive@ietf.org; Tue, 23 May 2006 09:48:45 -0400
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiXCe-0007Et-FC for ccamp-archive@ietf.org; Tue, 23 May 2006 09:45:42 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FiX2y-0003Oe-Dk for ccamp-data@psg.com; Tue, 23 May 2006 13:35:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1
Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <julien.meuric@francetelecom.com>) id 1FiX2x-0003OP-3Z for ccamp@ops.ietf.org; Tue, 23 May 2006 13:35:39 +0000
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 15:35:37 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Draft response to OIF on 1:n protection
Date: Tue, 23 May 2006 15:35:35 +0200
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603745C0C@FTRDMEL2.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Draft response to OIF on 1:n protection
Thread-Index: AcZ92rrllH3TeHH8SvuO3kjZPhyXFwAgseFg
From: MEURIC Julien RD-CORE-LAN <julien.meuric@francetelecom.com>
To: adrian@olddog.co.uk, ccamp@ops.ietf.org
X-OriginalArrivalTime: 23 May 2006 13:35:37.0159 (UTC) FILETIME=[C6639D70:01C67E6D]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17

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