IETF Logo Mail Archive

[CCAMP] Clarification on RFC4202

Ben Wright <Ben.Wright@metaswitch.com> Fri, 22 February 2013 10:24 UTC

Return-Path: <Ben.Wright@metaswitch.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714BE21F8E74 for <ccamp@ietfa.amsl.com>; Fri, 22 Feb 2013 02:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4znHznS8HPB for <ccamp@ietfa.amsl.com>; Fri, 22 Feb 2013 02:24:36 -0800 (PST)
Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3145F21F8E19 for <ccamp@ietf.org>; Fri, 22 Feb 2013 02:24:36 -0800 (PST)
Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 22 Feb 2013 10:23:37 +0000
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0342.003; Fri, 22 Feb 2013 10:24:35 +0000
From: Ben Wright <Ben.Wright@metaswitch.com>
To: Ccamp <ccamp@ietf.org>
Thread-Topic: Clarification on RFC4202
Thread-Index: Ac4Q5s81LskWzfLOQhWp+oD2HVpJjA==
Date: Fri, 22 Feb 2013 10:24:34 +0000
Message-ID: <B3B6FD81D3159A45B5421AF9DD500F88D6CBF764@ENFICSMBX1.datcon.co.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.72.114]
Content-Type: multipart/alternative; boundary="_000_B3B6FD81D3159A45B5421AF9DD500F88D6CBF764ENFICSMBX1datco_"
MIME-Version: 1.0
Subject: [CCAMP] Clarification on RFC4202
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 10:24:37 -0000

Hi,

I have a question on the text in RFC4202.

A 1+1 protected link may be configured between two nodes, but 1+1 protection may be temporarily unavailable (e.g. because of a failure on one of the constituent lower-layer links which provide the 1+1 protection).   In this case, should implementations advertised the link as having the currently supported link protection type (i.e. unprotected) or the intended / configured link protection type (1+1 protected)?

http://tools.ietf.org/html/rfc4202#section-2.2 describes the Link Protection Type as "the protection capability that exists for a link".    My reading is that this means the currently supported protection type should be advertised (i.e. unprotected in the case above) not the intended / configured link protection type.   Do you agree?

Thanks,

Ben

v2.35.0 | Report a Bug | By Email | System Status