Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Mon, 05 May 2008 11:34 UTC

Return-Path: <pwe3-bounces@ietf.org>
X-Original-To: pwe3-archive@megatron.ietf.org
Delivered-To: ietfarch-pwe3-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A099628C32D; Mon, 5 May 2008 04:34:43 -0700 (PDT)
X-Original-To: pwe3@core3.amsl.com
Delivered-To: pwe3@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AAD28C36A for <pwe3@core3.amsl.com>; Mon, 5 May 2008 04:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_41=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he9RjuQPUQ1F for <pwe3@core3.amsl.com>; Mon, 5 May 2008 04:34:40 -0700 (PDT)
Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id A0E0C28C3C2 for <pwe3@ietf.org>; Mon, 5 May 2008 04:34:13 -0700 (PDT)
Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 05 May 2008 14:37:39 +0300
Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 14:34:11 +0300
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 5 May 2008 14:34:11 +0300
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Danny McPherson <danny@tcb.net>
Date: Mon, 05 May 2008 14:34:11 +0300
Thread-Topic: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**
Thread-Index: AcishNdiI9bZOgivQBWJR9pNH1nIVwCBiyyA
Message-ID: <A3C5DF08D38B6049839A6F553B331C766B14D41E27@ILPTMAIL02.ecitele.com>
References: <3EBA4713-4631-4148-8DD6-B108A8BC5519@tcb.net> <AD91AFAC-26CF-47BA-951A-5AEC977DB538@tcb.net>
In-Reply-To: <AD91AFAC-26CF-47BA-951A-5AEC977DB538@tcb.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-OriginalArrivalTime: 05 May 2008 11:34:11.0370 (UTC) FILETIME=[F04030A0:01C8AEA3]
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org

Danny and all,
I have a couple of comments regarding the proposed draft charter.

1. The draft says:

<quote>
        The IETF PWE3 WG is the design authority for pseudo-wire
        over IP/MPLS PSN technology.  Extensions to this work by other
        SDOs needs to invoke the MPLS Change Process, as provided in
        RFC 4929.
<end quote>

    I've looked up RFC 4929 and, to the best of my understanding, it treats
    the PWE3 WG as one of the "other" IETF WGs when it comes to the
    MPLS/GMPLS change process, i.e. it is NOT a valid address for the external
    SDO to bring its proposals for the MPLS/GMPLS change, this function is
    reserved for the MPLS and CCAMP WGs.

    Hence the following re-wording looks to me more accurate (even if
    it sounds too much legalese:-)

<proposed text>
        The IETF PWE3 WG is the design authority for pseudo-wire
        over IP/MPLS PSN technology.  An entity or individual that
        wishes to propose extensions or changes to this technology
        must bring the corresponding proposals to the PWE3 WG that
        would treat them via a process similar to one described in
        RFC 4929 for the MPLS/GMPLS change.
<end of proposed text>

2. PWE3 security: I have been under the impression that the MPLS WG
    is working on the "common" MPLS security document that would cover,
    among others, the PWE3-specific security issues. The draft, however,
    proposes to deal with the PWE3 security issues separately. Is such
    separation justified, and, if so, how do we see the partitioning between
    the two efforts? I think that such partitioning should be mentioned in
    the draft, the text used for partitioning between PWE3 and L2VPN
    could be used as the template.

3. Timing. The draft proposes coordination with TICTOC and AVT.
    The (minor) point I'd like to raise is that while TICTOC charter
     indeed mentions coordination with PWE3, the AVT one doesn't.
     IMHO this makes coordination with AVT somewhat problematic.

Hopefully these notes will be useful.

Regards,
            Sasha

> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On
> Behalf Of Danny McPherson
> Sent: Friday, May 02, 2008 9:46 PM
> To: pwe3@ietf.org
> Subject: Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**
>
>
> On May 2, 2008, at 7:50 AM, Danny McPherson wrote:
>
> > Folks,
> > Time for that periodic charter refresh and update.  If you've
> > got comments, send'm along, as we'd like to get this off to the
> > IAB for approval.
>
> s/IAB/IESG/, of course :-)
>
> -danny
>
> >
> >
> > Please consider this a 2 week call for input, ending on 5/16.
> >
> > Thanks much!
> >
> > -danny
> >
> > ----
> > v0.1
> > Pseudowire Emulation Edge to Edge (pwe3)
> > Additional information is available at http://tools.ietf.org/wg/pwe3
> >
> > Chair(s):
> >
> > Danny McPherson <danny@arbor.net>
> > Stewart Bryant <stbryant@cisco.com>
> >
> > Internet Area Director(s):
> > Jari Arkko <jari.arkko@piuha.net>
> > Mark Townsley <townsley@cisco.com>
> >
> > Internet Area Advisor:
> > Mark Townsley <townsley@cisco.com>
> >
> > Technical Advisor(s):
> > Allison Mankin <mankin@psg.com>
> >
> > Secretary(ies):
> > Matthew Bocci <matthew.bocci@alcatel-lucent.co.uk>
> >
> > Mailing Lists:
> > General Discussion: pwe3@ietf.org
> > To Subscribe: pwe3-request@ietf.org
> > In Body: subscribe your_email_address
> > Archive: http://www.ietf.org/mail-archive/web/pwe3/index.html
> >
> > Description of Working Group:
> >
> > Network transport service providers and their users are
> > seeking to rationalize their networks by migrating their
> > existing services and platforms onto IP or MPLS enabled
> > IP packet switched networks (PSN). This migration requires
> > communications services that can emulate the essential
> > properties of traditional communications links over a PSN.
> > Some service providers wish to use MPLS technology to
> > replace existing transport network infrastructure, relying
> > upon pseudowire technology is an integral component of
> > these network convergence architectures.
> >
> > Pseudowire Emulation Edge to Edge (PWE3) will specify the
> > encapsulation, transport, control, management, interworking
> > and security of services emulated over IETF-specified PSNs.
> >
> > A pseudowire emulates a point-to-point or point-to-multipoint
> > link, and provides a single service which is perceived by
> > its user as an unshared link or circuit of the chosen
> > service.  It is not intended that an emulated service will
> > be indistinguishable from the service that is being emulated.
> > The emulation need only be sufficient for the satisfactory
> > operation of the service. Emulation necessarily involves a
> > degree of cost-performance trade-off.  In some cases it may
> > be necessary to design more than one emulation mechanism in
> > order to resolve these design conflicts. All emulated service
> > definitions must include an applicability statement describing
> > the faithfulness of the emulation.
> >
> > Switching, multiplexing, modification or other operation on
> > the traditional service, unless required as part of the
> > emulation, is out of the scope of the PWE3 WG.
> >
> > PWE3 will make use of existing IETF-specified mechanisms
> > unless there are technical reasons why the existing mechanisms
> > are insufficient or unnecessary.
> >
> > PWE3 operates "edge to edge" and will not exert control on
> > the underlying PSN, other than to use any existing QoS or
> > path control mechanism to provide the required connectivity
> > between the endpoints of the PW.
> >
> > PWE3 will specify requirements for clock recovery and other
> > real-time signaling functions needed by PW types that it
> > is designing. It will co-ordinate this with the AVT and
> > TICTOC WGs. Where AVT or TICTOC require extensions to
> > PWs to support time or frequency transfer this work will be
> > undertaken by the PWE3 WG in co-ordination with the these
> > WGs.
> >
> > A PW operating over a shared PSN does not necessarily have
> > the same intrinsic security as a dedicated, purpose built,
> > network. In some cases this is satisfactory, while in other
> > cases it will be necessary to enhance the security of the PW
> > to emulate the intrinsic security of the emulated service.
> > PW specifications MUST include a description of how they
> > are to be operated over a shared PSN with adequate security.
> > PWE3 will work with the MPLS, L2VPN and other relevant WGs
> > for definitions of common solutions for the secure operation
> > of pseudowires.
> >
> > Whilst a service provider may traffic engineer their network
> > in such a way that PW traffic will not cause significant
> > congestion, a PW deployed by an end-user may cause
> > congestion of the underlying PSN. Suitable congestion
> > avoidance mechanisms are therefore needed to protect the
> > Internet from the unconstrained deployment of PWs.
> >
> > PWE3 will work closely with the L2VPN WG to ensure a clear
> > demarcation is defined for where PWE3 stops and L2VPN starts,
> > in particular in defining point-multipoint (P2MP) PWs.
> >
> > PWE3 will work with MPLS and L2VPN to enhance the OAM suite
> > for transport applications.  PWE3 will coordinate very closely
> > with any WG that is responsible for protocols which PWE3
> > intends to extend (e.g., the MPLS WG for LDP), as well as
> > foster interaction with WGs that intend to extend PWE3
> > protocols.
> >
> > The IETF PWE3 WG is the design authority for pseudo-wire
> > over IP/MPLS PSN technology.  Extensions to this work by other
> > SDOs needs to invoke the MPLS Change Process, as provided in
> > RFC 4929.
> >
> > WG Objectives:
> >
> > Specify the following PW types:
> >
> > Most of the initial specific PW types have been specified
> > (e.g., Frame Realy, Ethernet, ATM).  Investigation into
> > and specification of a "generic PW" type and/or MPLS PW
> > should be undertaken.
> >
> > PWE3 will specify a PW type for the special case where the
> > access service payloads at both ends are known to consist
> > entirely of IP packets. PWE3 will not specify mechanisms
> > by which a PW connects two different access services
> > unless the Network Layer protocol is IP.
> >
> > Specify the control and management functions of chartered PW
> > types, to include PW setup, configuration, maintenance and
> > tear-down. The PWE3 WG will do this in its entirety for
> > MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics
> > for L2TPv3-based PWs.
> >
> > Specify Operations and Management (OAM) mechanisms for all
> > PW types, suitable for operation over both IP/L2TPv3 and
> > MPLS PSNs, and capable of providing the necessary
> > interworking with the OAM mechanisms of the emulated
> > service.
> >
> > Define requirements for and mechanisms to provide
> > interconnection of PWs (to include inter-domain PWs).
> >
> > Define requirements for and mechanisms to provide
> > protection and restoration of PWs.
> >
> > Publish document outlining PW-specific congestion avoidance
> > and response guidelines.
> >
> > Publish document outlining PW-specific security considerations.
> >
> > Publish specification for enabling P2MP PWs.
> >
> > Publish requirements and specification for PW load-balancing
> > mechanisms.
> >
> > Publish requirements and specification for enhanced OAM.
> >
> > Publish requirements and specifications to provide the
> > necessary extensions to PWs to support the applications
> > of MPLS to transport networks.
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3