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

From: Danny McPherson <[email-masked]>
Date: Fri, 2 May 2008 07:50:33 -0600

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.

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 <[email-masked]>
Stewart Bryant <[email-masked]>

Internet Area Director(s):
Jari Arkko <[email-masked]>
Mark Townsley <[email-masked]>

Internet Area Advisor:
Mark Townsley <[email-masked]>

Technical Advisor(s):
Allison Mankin <[email-masked]>

Secretary(ies):
Matthew Bocci <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Danny McPherson <[email-masked]>
Date: Fri, 2 May 2008 12:45:43 -0600

> got comments, send'm along, as we'd like to get this off to the

s/IAB/IESG/, of course :-)

-danny

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 5 May 2008 14:34:11 +0300

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

1. The draft says:

<quote>
<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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Danny McPherson
> Sent: Friday, May 02, 2008 9:46 PM
> To: [email-masked]
> Subject: Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**
>
>

---

From: Danny McPherson <[email-masked]>
Date: Mon, 5 May 2008 08:47:29 -0600

>        RFC 4929 for the MPLS/GMPLS change.

I think your recommendation here is reasonable, let's see
what other folks think about it.

>    could be used as the template.

Just as the WG delineation and charter scopes the area of
work, PWE3 *specific* work will be done in PWE3, while it's
only natural that general MPLS-related work will be done in
the MPLS WG.  If there's overlap or ambiguity, then we'll have
to address those issues as they arise.

If there's specific text along these lines you or others would
like to see in the charter, I welcome proposals.

>     IMHO this makes coordination with AVT somewhat problematic.

If we have any issues with PWE3 we'll address them at that
time.  I do not see any obvious issue here, nor do I believe we
have experienced any in the past.

> Hopefully these notes will be useful.

Yes, thanks for your review!

-danny

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 11 May 2008 09:23:37 +0300

Danny and Sasha, 

I will comment both on the charter and Sasha's comments.

s/Frame Realy/Frame Relay/ and please add TDM to that line.
Also s/pseudo-wire/pseudowire/ (I saw one left).

What does "Switching ... ON the traditional service ..." mean today ?
It obviously should not rule choosing the correct PW at a VPLS ingress
PE
(although not defined in PWE3).
I don't care if it rules out an ECMP mechanism peaking at the first
nibble,
since this is only referenced in PWE3, not defined.
Does it rule out an S-PE choosing a path based on a label chosen by the
T-PE
after looking at the native header ?
Does it rule out a PW protection mechanism that emulates the native
service's mechanism ?

"PWE3 will specify requirements for clock recovery ..."
Actually, TICTOC is specifying requirements. What I think PWE needs to
do
is to support TICTOC efforts on the protocol side.

I agree with Sasha that we should be the design authority for PW over
MPLS issues.
In particular, we should be able to block redefinition of PW
functionality,
such as the popping of the PW label while leaving the tunnel label that
has been proposed.
If this requires another logistics RFC, then we should write one.

Regarding PWE security, the MPLS security document intentionally did not
go into
data plane issues for non-IP clients. This was left for PWE to handle.
(I really should refresh the PWE-security drafts ...)

"Publish requirements and specification for PW load-balancing
mechanisms."
Can we add "inverse multiplexing" to "load balancing" ?
I am writing a draft on this now.

"to support the applications of MPLS to transport networks"
did you mean "the application (no s) of MPLS" ?
If so, perhaps "to support MPLS-based transport networks" ?

Did the group ever agree that P2MP PWs are a good idea ?
I seem to recall that at the mike people agreed that there could be the
need
to transport P2MP services over MPLS, but that it was unsure how this
mapped onto the PWE3 architecture. PWs are emulations of "wires" not
"trees".
It may be a better idea to define a non-IP MPLS client that is not a PW.

Y(J)S

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 12 May 2008 12:13:11 +0100

>         RFC 4929 for the MPLS/GMPLS change.
My understanding of the intent of RFC4929 was that it applied with equal 
force to the other WGs.

How about:

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 who will address then using the RFC 4929 change 
process.

>      IMHO this makes coordination with AVT somewhat problematic.
That should be addressed at the the next AVT charter revision, but I 
don't see why this affects the PWE3 charter revision.
- Stewart
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 May 2008 13:22:59 +0200

All,

> My understanding of the intent of RFC4929 was that it applied with equal 

as one of the original authors of the change process that is my
understanding also - actually wg have an opt in possibility and when
it comes to the (G)MPLS technology this is much prefered

/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]
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 May 2008 14:28:26 +0300

Stewart and all,
Please see inline below (marked [Sasha]).

Regards,
         Sasha

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, May 12, 2008 2:13 PM
> To: Alexander Vainshtein
> Cc: Danny McPherson; [email-masked]
> My understanding of the intent of RFC4929 was that it applied
> with equal force to the other WGs.
>
[Sasha] The intent of RFC 4929 could well be as you say, but, if so,
it did not make it, IMHO, to the published text. This text
nominates just two WGs as the design authorities on MPLS, and
PWE3 is not one of them.
> proposals to the PWE3 WG who will address then using the RFC
> 4929 change process.
>
[Sasha] Please see above.
> don't see why this affects the PWE3 charter revision.
[Sasha] OK with me.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 12 May 2008 12:33:17 +0100

> It obviously should not rule choosing the correct PW at a VPLS ingress

This is from the original charter and was meant to rule out PWE3 
specifying things like ATM switches. I suggest that we leave it in and 
if we ever need to specify native service switching we can ask for a 
charter revision on a case by case basis.

> after looking at the native header ?
What we need is an abstract mapping between the native service that 
understands the structure of the service and provides information to the 
T-PE on how to map this to one or more PWs.
> Does it rule out a PW protection mechanism that emulates the native
So how would you word the restriction so as to permit the operations 
that we need without chartering native service switching which we must 
put out of scope?
> is to support TICTOC efforts on the protocol side.
The original point was to allow the TDM PE designers to feed 
requirements to TICTOC through the PWE3 WG, but I am sure that if they 
have anything to say they will turn up in TICTOC and say it :)

> If this requires another logistics RFC, then we should write one.
You mean the single label PW concept. That would need consensus in PWE3 
and MPLS WG before we could work on it.

> mapped onto the PWE3 architecture. PWs are emulations of "wires" not
Many wires are trees! Certainly pt-mp wires exist in the transport world 
and have done for many years.

Unless we specify pt-mp PWs we condemn our users  to  emulate pt-mp  
using a set of  pt-pt PWs. What is needed is  the ability to map a pt-mp 
service through a pt-mp PW and then onto a multicast PSN.
> It may be a better idea to define a non-IP MPLS client that is not a PW.
How do you see this mapping work?

- Stewart

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 12 May 2008 17:27:08 +0300

> This is from the original charter and was meant to rule out PWE3
specifying things like ATM switches. 

yes, I know. That is why I asked what it means "today" .

> What we need is an abstract mapping between the native service that
understands the structure of the service 
> and provides information to the T-PE on how to map this to one or more
PWs.

I agree. That sounds like it is ruled out by the present wording.

service's mechanism ?
> So how would you word the restriction so as to permit the operations
that we need without chartering 
> native service switching which we must put out of scope?

Something like "PWE will not redefine or recreate native switching
mechanisms,
but may define new switching mechanisms that are based on PW-specific
information.

> The original point was to allow the TDM PE designers to feed
requirements to TICTOC through the PWE3 WG, 

Yes, quite. but that work has been completed, and the requirement can be
removed from the new charter !

> Many wires are trees! Certainly pt-mp wires exist in the transport
world and have done for many years.

If this is automatic, then we needn't define anything for it.
The problem is when you start defining tree-specific mechanisms.

> Unless we specify pt-mp PWs we condemn our users  to  emulate pt-mp
using a set of  pt-pt PWs. 

No, we needn't define them. Others can - and will. VPLS was defined by
L2VPN quite nicely
based on the Ethernet PW, without PWE3 having to get involved.

> What is needed is  the ability to map a pt-mp service through a pt-mp
PW and then onto a multicast PSN.

Or to map a pt-mp service onto N pt-pt ones, and then map each pt-pt one
onto a PW.

> How do you see this mapping work?

Similar to a PW, that is based on an MPLS label stack plus a bottom
label or labels.
But the architecture (and signaling) would tailored for pt-mp. 

Y(J)S

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 12 May 2008 16:15:57 +0100

> The problem is when you start defining tree-specific mechanisms.

I'm not sure what you mean by automatic.

If I understand you correctly Yaakov - are you basically saying that we need
do nothing special at the PW layer as we would expect to map the PW into a
P2MP server layer (e.g. MPLS) construct (LSP)?

> Or to map a pt-mp service onto N pt-pt ones, and then map each pt-pt one

Hardly efficient using a bunch of Pt-Pt PWs to emulate a P2MP one (with
ingress replication I assume) though is it?

Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 May 2008 18:38:16 +0300

Yaakov and Ben,
Please see inline below.
I've snipped part of the original message that is not relevant to my comments.

Regards,
        Sasha

> Behalf Of Ben Niven-Jenkins
> Sent: Monday, May 12, 2008 6:16 PM
> To: Yaakov Stein; [email-masked]
> Cc: [email-masked]; Danny McPherson
... snipped ...
> Hardly efficient using a bunch of Pt-Pt PWs to emulate a P2MP
> one (with ingress replication I assume) though is it?
>
[Sasha] Especially if p2mp "transport" LSPs facilitate peer-to-peer delivery with minimal
replication in the branching points only... but, presumably, cannot be used by the PW layer.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 12 May 2008 17:07:01 +0100

> P2MP server layer (e.g. MPLS) construct (LSP)?
That cannot be just an automatic process. The PW needs to join, the 
correct multicast group.
The OAM will be different. The T-PE to x-PE signaling will be different.
> ingress replication I assume) though is it?
Exactly my point.

Stewart

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 12 May 2008 11:40:59 -0700 (PDT)

hi Stewart and Ben,

<snipped>

> > ingress replication I assume) though is it?

Agreed. And hence the need for P2MP PWs.

To provide some context, the VPLS work in L2VPN WG started
with ingress replication for multicast traffic and this was a limitation.
The VPLS multicast work (draft-ietf-l2vpn-vpls-multicast) specified the use
of P2MP LSPs in VPLS to overcome the ingress replication issue. The L2VPN
case for non-ethernet attachment-circuits is similar. We need a way to support
P2MP Layer 2 service without ingress replication.

rahul

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 13 May 2008 17:03:38 +0300

To all who responded on the p2mp issue.

I was not claiming that using many p2p PWs to emulate a p2mp service
was efficient.  I was only saying that this was ONE way of implementing
a p2mp service using pseudoWIREs.

This is precisely what we do with VPLS. The PW remains p2p,
and a layer above it provides the needed connectivity.
If we CAN relatively efficiently implement a mp2mp service
by using a mesh of p2p PWs, why do we need to extend the definition of a
PW?

Another way would be to define a pseudotree (PT).
This would be an inherently p2mp entity,
that would enable running p2mp applications over p2mp 
upstream label allocated MPLS.

Perhaps instead we should go all the way to a pseudomesh (PM),
that would run over a mesh of LSPs, or over PSNs capable of supporting
mp2mp traffic.

When such a radical extension is proposed
the alternatives should be weighed.

Y(J)S

---

From: "BOCCI Matthew" <[email-masked]>
Date: Tue, 13 May 2008 16:39:46 +0200

Yaakov,

Isn't weighing the alternatives part of the point of a requirements /
framework draft? I think there is a need to do this work, and that it is
clearly different from the L2VPN mechanisms, which are specific to each
L2VPN type.

I think the charter simply needs to state something like the following:

"Requirements and mechanisms for P2MP functionality for PWs. This work
will be coordinated with the L2VPN and MPLS working groups."

Matthew

> Behalf Of Yaakov Stein
> Sent: 13 May 2008 15:04
> To: Rahul Aggarwal; Stewart Bryant; Ben Niven-Jenkins; 
> Alexander Vainshtein
> Cc: pwe3; Danny McPherson
> I was not claiming that using many p2p PWs to emulate a p2mp 
> service was efficient.  I was only saying that this was ONE 
> way of implementing a p2mp service using pseudoWIREs.
> 
> If we CAN relatively efficiently implement a mp2mp service by 
> using a mesh of p2p PWs, why do we need to extend the 
> definition of a PW?
> 
> This would be an inherently p2mp entity, that would enable 
> running p2mp applications over p2mp upstream label allocated MPLS.
> 
> Perhaps instead we should go all the way to a pseudomesh 
> (PM), that would run over a mesh of LSPs, or over PSNs 
> capable of supporting mp2mp traffic.
> 
> When such a radical extension is proposed the alternatives 
> should be weighed.
> 
> Y(J)S

---

From: <[email-masked]>
Date: Tue, 13 May 2008 17:28:56 +0200

Yaakov,

Please see below
[FJ]

Regards,
Fred

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Yaakov Stein
Envoyé : mardi 13 mai 2008 16:04
À : [email-masked]; Stewart Bryant; Ben Niven-Jenkins; Alexander Vainshtein
Cc : pwe3; Danny McPherson
Objet : Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**

I was not claiming that using many p2p PWs to emulate a p2mp service was efficient.  I was only saying that this was ONE way of implementing a p2mp service using pseudoWIREs.

This is precisely what we do with VPLS. The PW remains p2p, and a layer above it provides the needed connectivity.
If we CAN relatively efficiently implement a mp2mp service by using a mesh of p2p PWs, why do we need to extend the definition of a PW?
[FJ] For the same reasons raised in L2VPN when comparing Ingress replication to P2MP LSP for VPLS (bandwidth savings, provisioning, replication burden...). The P2MP PW requirement draft mentions some possible use cases related to other PW types (comment on DVB-H: even if the MPEG-TS flow is supported over IP, a L2VPN offer still remains required for IP addressing plane purpose, e.g. wholesale offer...)

Another way would be to define a pseudotree (PT).
This would be an inherently p2mp entity, that would enable running p2mp applications over p2mp upstream label allocated MPLS.
[FJ] a P2MP MS-PW may rely on traffic replication only on S-PEs, each PW segment from the PW tree supported over P2P PSN tunnel. In that case the upstream PW label assignment is not required...

Perhaps instead we should go all the way to a pseudomesh (PM), that would run over a mesh of LSPs, or over PSNs capable of supporting mp2mp traffic.
[FJ] Introducing new terminologies may sometimes be confusing. Why not using the term "pseudowire" to define a common transport technology (data plane), and making the differentitation rather on the topology (P2P, P2MP, MP2MP) as it is proposed today for LSP?
On the other hand, a new terminology like VPMS (Virtual Private Multicast Service) may make sense in L2VPN to clarify the service topology.  

When such a radical extension is proposed the alternatives should be weighed.

Y(J)S