Subject: RE: [PWE3] Draft Charter

From: "Moran Roth" <[email-masked]>
Date: Sun, 24 Jul 2005 10:35:55 +0200

Danny,

The first objective of the WG states:
"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."

We would like to add Fibre Channel to the list of PW types, as we have
identified a requirement from network operators to carry Fibre Channel
over PW. This will allow the transparent transport of Fibre Channel
services over the PSN, along with the data and TDM services already
specified in the list. This will facilitate the extension of storage
area networks to support mission critical applications such as disaster
recovery and business continuity.

Thanks,
Moran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Danny McPherson
Sent: Tuesday, July 19, 2005 4:05 PM
To: pwe3
Subject: [PWE3] Draft Charter

Folks,
Please give the following charter a review and let Stewart and I (and/or
the entire mailing list) know if you have any comments.  The window for
comments will close July 29, 2005.

http://pwe3.tcb.net/pwe3-charter-2005071901.txt

Thanks!

-danny

---------
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.

PWE3 will work closely with the L2VPN WG to ensure a clear demarcation
is defined for where PWE3 stops and L2VPN starts.

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.

PWE3 will evaluate the use of PW mechanisms for an "MPLS Pseudowire"
to transparently carry an MPLS label stack and payload between two PE
routers.

Specify a PW type that supports transparent carriage of IP payloads
between disparate access services (e.g., ATM and Ethernet).

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.

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Danny McPherson <[email-masked]>
Date: Sun, 24 Jul 2005 14:58:05 -0600

> recovery and business continuity.

Are other folks interested in this becoming a WG
item?  We've heard this from Moran a bit in the
past, if there's additional support within the WG we
can add it to the charter now...

-danny

---

From: Luca Martini <[email-masked]>
Date: Mon, 25 Jul 2005 09:48:20 -0600

Danny McPherson wrote:

>
> l 24, 2005, at 2:35 AM, Moran Roth wrote:
>
>> Danny,
>>
I do not have any objections to having a Fibre Channel PW. If anything 
it's going to be an interesting topic , as I seem to remember lot's of 
timing requirements in the old fibre channel protocol.
Anyway if we are going to create a Fibre Channel PW, then pwe3 is the 
right place to do it.

Luca

---

From: "Robert Hines" <[email-masked]>
Date: Mon, 25 Jul 2005 11:55:39 -0400

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Jul 2005 17:46:56 +0100

> can add it to the charter now...

It seems a useful wire type to me, and IETF is in the SAN business.
 From what I have heard it will need a careful applicability statement.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Jul 2005 12:50:21 +0200

All,

I've one immediate reaction reading the charter - this is
quite a bit of work too take on. is it the intention that we
should do all this is one go? Wouldn't be better to focus?

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 26 Jul 2005 12:41:48 +0100

There are four core elements to the charter:

1) Finishing the work on simple pt-pt PWs that we started.
    Here the technology is agreed, we just need to turn the
    handle to get the RFCs done. The burdon here falls
    on the individual authors and WG chairs.

2) New PW types - this is essentially sustaining engineering
    that will continue for some time.

3) Management (OAM and MIBs). This needs to get some attention.

4) Multi-segment PWs, which is new work.

This seems a reasonable work programme.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Jul 2005 14:27:06 +0200

Stewart,

there are at least two things in the charter not covered in
this list, the security diffrences between native wires and
PWs, possibly quite a bit of work; and the congestions mechansisms,
that also could quite a bit of work.

Also I guess that "some attention" on MIBs and OAM is to put
it mildly, the experiences from the mpls wg group was that it
was a major effort (still to be completed).

/Loa

-- 
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Jul 2005 14:35:33 +0200

The current proposal for the pwe3 charter says:

Network transport service providers and their users are
seeking to rationalize their networks by migrating their
existing services and platforms onto IP or MPLS based
packet switched networks (PSN).  This migration requires
communications services that can emulate the essential
properties of traditional communications links over a
PSN.

I would like to change this to:

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 networks (PSN).  This migration requires
communications services that can emulate the essential
properties of traditional communications links over a
PSN.

This is to clearly say that mpls is part of the IP protocol
suite.

/Loa
-- 
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Jul 2005 14:51:49 +0200

Second paragraph of the proposed charter says:

"Pseudowire Emulation Edge to Edge (PWE3) will specify the
encapsulation, transport, control, management, interworking and
security of services emulated over IETF specified PSNs."

While I have a farily good idea what goes into encapsulation
and management, and understand the need for security. I've
issues with transport, control and interworking.

Do we use "trasnport" here as it used in e.g. "transport area"
or do we intend to talk about the technology over which the the
PW is "transported". If it is the latter what needs to be specified?

Control normally comprises signalling and routing protocols, should
these be specified by the pwe3 wg or by the wg that "owns the
protocol"? Shouldn't we say that we need to develop requirements
on signaling and routing prtocol extensions.

Interworking - I assume that this interworking where boths attachment
circuits carry IP packets? If so how much of this is addressed by
the L2VPN wg and the IPLS? In the best of worlds the PWs need not to
bother about interworking at all.

/Loa

-- 
Loa Andersson

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Jul 2005 06:59:06 -0600

> This is to clearly say that mpls is part of the IP protocol

I've already changed this paragraph twice and considering
it's simply meant to be introductory/background text I'm
not all that keen on changing it again.  I believe it's
implied that these mechanisms are enabled by an "IP
protocol suite", of which MPLS is a component.

With that said, do other folks have thoughts on Loa's
recommendation?  If so, I can fold it into the next
revision.

Thanks for the review Loa!

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Jul 2005 07:07:59 -0600

> Do we use "trasnport" here as it used in e.g. "transport area"

Nah, else I'd have use a capital 't' as in Transport :-)

> PW is "transported". If it is the latter what needs to be specified?

I thought "transport" seemed sufficient.  Would you prefer
"carriage" or something akin?

> on signaling and routing prtocol extensions.

All the control functions we provide to date were "extended"
in PWE3, and as much as the PWE3 architecture permits, this
is likely to remain the path going forward - as you well
know.  However, working with other working groups where
necessarily is of course required.

> bother about interworking at all.

That demarcation is just what needs to be defined, and
PWE3 and L2VPN need to work together to get there..

-danny

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Jul 2005 15:46:29 +0200

> "carriage" or something akin?

nope - understood that way "transport" is fine, more curious
on what needs to be specified?

/Loa

-- 
Loa Andersson

---

From: Luca Martini <[email-masked]>
Date: Tue, 26 Jul 2005 11:01:36 -0600

> recommendation?  If so, I can fold it into the next
I think that the "MPLS enabled IP networks" text fits in with the stile 
we put in the pwe3 control protocol draft.
It might make things more consistent..
Luca

---

From: Luca Martini <[email-masked]>
Date: Tue, 26 Jul 2005 11:09:23 -0600

> that also could quite a bit of work.
Actually there seems to be little or no interest to work on congestion 
mechanisms in this WG.
Since this WG does not deal with applications , it is quite difficult to 
build a congestion mechanism that will work properly.

Luca

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Jul 2005 11:28:00 -0600

> on what needs to be specified?

It's mainly concerned with the "PW Service Functionality",
as defined in the architecture document.  Otherwise
exerting control on the underlying PSN (be it IP or
IP/MPLS) is explicitly out of scope, which I hope would
satisfy any concerns you have here..

-danny