RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt
<roman.krzanowski@verizon.com> Fri, 04 January 2008 21:08 UTC
Return-path: <pwe3-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAtmA-0001pV-U1; Fri, 04 Jan 2008 16:08:22 -0500
Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1JAtm9-0001pP-Uh for pwe3-confirm+ok@megatron.ietf.org; Fri, 04 Jan 2008 16:08:21 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAtm9-0001oX-Gt for pwe3@ietf.org; Fri, 04 Jan 2008 16:08:21 -0500
Received: from irvmail2.verizon.com ([192.76.80.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAtm8-0001mH-8y for pwe3@ietf.org; Fri, 04 Jan 2008 16:08:21 -0500
Received: from smtptpa4.verizon.com (smtptpa4.verizon.com [138.83.71.177]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id m04L8Ea7002956; Fri, 4 Jan 2008 15:08:15 -0600 (CST)
Received: from ftwintrmemf2.verizon.com (ftwintrmemf2.verizon.com [138.83.131.184]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id m04L8EWl004561; Fri, 4 Jan 2008 16:08:14 -0500 (EST)
Received: from ftwintrmemf2.verizon.com (unknown [127.0.0.1]) by ftwintrmemf2.verizon.com (Symantec Mail Security) with ESMTP id 21EA1528002; Fri, 4 Jan 2008 16:08:14 -0500 (EST)
X-AuditID: 8a5383b8-aeb04bb000000632-72-477ea03b37b6
Received: from coregate1.verizon.com (unknown [138.83.34.22]) by ftwintrmemf2.verizon.com (EMF) with ESMTP id AD1FD4E4002; Fri, 4 Jan 2008 16:08:11 -0500 (EST)
Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id m04L85Zx011218; Fri, 4 Jan 2008 15:08:10 -0600 (CST)
Received: from FHDP1CCMXCV01.us.one.verizon.com ([166.68.240.11]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jan 2008 16:07:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt
Date: Fri, 04 Jan 2008 16:07:26 -0500
Message-ID: <029583E37562274699DC24FB7663A5FC25BFBE@FHDP1CCMXCV01.us.one.verizon.com>
In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B03C7D40E@USDALSMBS03.ad3.ad.alcatel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt
thread-index: AchO94VvGWOISObISp+v8yJpAIlKSwAA7YuQAAWv94A=
From: roman.krzanowski@verizon.com
To: Mustapha.Aissaoui@alcatel-lucent.com, pwe3@ietf.org
X-OriginalArrivalTime: 04 Jan 2008 21:07:31.0710 (UTC) FILETIME=[D20E01E0:01C84F15]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b
Cc:
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2046691959=="
Errors-To: pwe3-bounces@ietf.org
Mustapha thank you for the response... On the first issue, let me tell you where it is coming from - when provisioning redundant PWEs in the topology as below [RT0]---------[RT1] | |---------------[RT2] with one end of both PWEs on RT0 and other ends terminating on separate RTs [RT1] and [RT2] - from the provisioning perspective it is advantageous to designate one PWe as primary and another as secondary. This maybe rather specific to having PWE ends on separate physical systems - but not necessarily so. It may be the case that the route taken by the primary PWE is more optimal -performance and capacity wise- than the secondary or backup and you would rather keep the traffic on the primary if possible all the time. I do not want to involve TE at this point. On the second issue Yes, there is an OAM mapping draft. But what I wanted to say that in this particular case .. will this draft cover the stand by/ active status for the PWE specifically on the RT1 and RT2 and not on the RT0. So this would be one-sided signaling on RT1/2 on switchover, as I see it, and signaling on RT0 only if both PWEs fail. For the RT1 RT2 CPE in my view it is critical to be able to know the status of PWEs asap. The customer may have his own status e2e hellos ( this would require lets say something like BFD-kind with nx hello missed giving us nx delay in notification ) and this maybe may be good enough, but he may not have it and the notofication mechanism from the RT1/RT2 would be nice to have - I guess it would lead to faster notofication of the status of PWEs. please let me know if I should elaborate further Thx roman ________________________________ From: AISSAOUI Mustapha [mailto:Mustapha.Aissaoui@alcatel-lucent.com] Sent: Friday, January 04, 2008 3:37 PM To: Krzanowski, Roman; pwe3@ietf.org Subject: RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt Roman, thank you for the suggestions. See my comments below. Regards, Mustapha. ________________________________ From: roman.krzanowski@verizon.com [mailto:roman.krzanowski@verizon.com] Sent: Friday, January 04, 2008 12:29 PM To: pwe3@ietf.org Subject: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.txt I am thinking about the operationalizing of the PWE ACTIVE/passive stand-by function. Without mandating specific mechanisms the draft should state the need for certain functionalities to be considered in the implementation of the draft. I propose to include the following sections or similar: 5.4 Permanent active PWE designation. The system COULD provide for the permanent designation of one PWe as Active. After the switch over to stand-by and the recovery of the active the traffic would switch over to the active again. The "flapping prevention mechanism- algorithm" should be implemented. This function is OPTIONAL. MA> What you may be suggesting is the concept of Primary PW and Secondary PW rather than an Active/Standby designation. Active and Standby are states which change over time. However, a Primary PW is a PW that is activated in preference to all other PWs when it is UP and shows "Active" status at both endpoints. This also means that the system should revert to the Primary PW when it comes back up from a failure. The draft refers to the concept of Primary and Secondary PWs and we could expand as required. Let me know if my understanding is incorrect. 5.5 AC PWE status signaling A system COULD signal to the AC side the status of the PWE - Active, down. The existing OAM signaling mechanisms could used for this function. The signaling should be done on the non-switching END -PE ONLY. This function is OPTIONAL. MA> I assume you are referring to the ability of a PE/T-PE to translate a fault notification received in a PW status bit to the AC specific fault notification. This applies mostly to the operational status bits, i.e., AC up/down, PW up/down, and PW not forwarding. This is covered in draft-ietf-pwe3-oam-msg-map-05 and implementations should support it independently of the PW redundancy capability. I am not sure I see the application for passing the "active/standby" status to the AC. I appreciate if you could elaborate.
_______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3
- [PWE3] draft-muley-dutta-pwe3-redundancy-bit-02.t… roman.krzanowski
- RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-… AISSAOUI Mustapha
- RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-… roman.krzanowski
- RE: [PWE3] draft-muley-dutta-pwe3-redundancy-bit-… AISSAOUI Mustapha