Subject: Re: PWE3 Charter Update

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 14 Mar 2005 14:01:57 -0500

Danny,

The IESG has said numerous times that layer 2 SVC signaling protocol 
interworking is not in the IETF charter.  Agreeing with Matthew and others 
on this list, this work is addressed elsewhere, and doing it here as well 
would be (at best) an unnecessary duplication of effort.  In addition, the 
rough consensus on the list from those that have spoken up is to remove 
this from the charter.  I don't think I've seen anyone else supporting 
leaving it in.

Thanks,
Andy

At 3/14/2005 04:38 PM +0000, [email-masked] wrote:

>Danny,
>
>I have a question about the final statement:
>
>" Define the reqiurements for and mechanisms needed to allow
>the operation of switched virtual circuits over a PSN."
>
>Please can you clarify the meaning of this? Do you mean interworking
>between, say ATM or FR SVCs and Pseudo-wires? If so, there are already a
>number of existing specifications either in existence (e.g. in the ITU-T
>and the ATM Forum), or in an advanced state of development (e.g. MPLS/FR
>Alliance).
>
>Are you proposing that this work also be taken up by PWE3?
>
>Thanks,
>
>Matthew
>
>
>[snip]
>
>Pseudo Wire Emulation Edge to Edge (PWE3) WG
>
>Description of Working Group:
>
>Network operators and their subscribers are seeking to rationalize
>their networks by migrating to a single, IP or MPLS based packet
>switched network (PSN). This migration requires communications
>services that can emulate the essential properties of traditional
>communications links over a PSN.
>
>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 link, and provides a
>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 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 will 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 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 two endpoints of the PW.
>
>PWE3 will investigate mechanisms necessary to perform clock
>recovery and other real-time signaling functions.  This work will
>be coordinated with the AVT WG and RTP will be used where
>appropriate.
>
>
>WG Objectives (in order of priority):
>
>Specify the following PW types and consider specification of
>additional PW types contingent on WG consensus and AD approval:
>
>Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET
>
>Specify the control and management functions of chartered PW
>types, to include PW setup, configuration, maintenance and
>tear-down.
>
>Specify OAM mechanisms for all PW types, suitable for
>operation over both IP and MPLS PSNs, and capable of
>providing the necessary interworking with the OAM mechanisms
>of the emulated service.
>
>Enhance packet-based PW specifications as necessary to
>allow the emulated service to be carried transparently
>over the PSN, for example by the retention of the FCS
>across the PW.
>
>Define mechanisms to permit the operation of a PW over
>a PSN that employs equal cost multiple path (ECMP) packet
>switching mechanism.
>
>A PW operating over a shared PSN does not 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.
>
>Whilst a service provider may traffic engineer their network
>is 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.
>
>Define requirements for and mechanisms to provide
>interconnection of PWs (to include inter-domain PWs).
>
>Define the reqiurements for and mechanisms needed to allow
>the operation of switched virtual circuits over a PSN.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Mar 2005 14:53:52 -0700

On Mar 14, 2005, at 12:01 PM, Andrew G. Malis wrote:

> interworking is not in the IETF charter.  Agreeing with Matthew and 
> others on this list, this work is addressed elsewhere, and doing it 
> here as well would be (at best) an unnecessary duplication of effort.  
> In addition, the rough consensus on the list from those that have 
> spoken up is to remove this from the charter.  I don't think I've seen 
> anyone else supporting leaving it in.

I'm fine with removing it, but should it result at some point
in modifications and/or extensions to IETF protocols (e.g., BGP
AFI/SAFI specification) we'll need to reconsider as a WG.

Any objections?

I should also note that there was at one point seemingly much
more interest for some aspects of this within the PWE3 WG,
and the IESG in my recollection wasn't quite as adamant as your
message suggests about this particular issue - though it certainly
wasn't within PWE3's immediate scope or charter - as we hadn't
yet completed any of the initially chartered items.

Of course, it seems that those interested in doing it here initially
have found more welcoming homes for their agendas, as is more
and more commonly becoming the case.  With my WG chair hat
on, I would caution folks to remember that simply because we're
not the first to draft/approve/publish a specification, that won't deter
us from doing what's in the best interest of the IETF and the
Internet (note that this is a very broad statement here and not
regarding this particular issue).  [Please avoid replying to this
particular issue in this thread.  If you must comment - which I
sure someone will, please start a new thread.]

I'll remove this item from the charter assuming no objections from
the WG?

Thanks!

-danny