Subject: PWE3 Charter Update

From: Danny McPherson <[email-masked]>
Date: Fri, 4 Mar 2005 09:08:34 -0700

Folks,
Here's a proposed update to the PWE3 charter.  Once
we complete this we'll work on getting the goals and
milestones updated accordingly.  Stewart and I will also
provide a complete draft status report in MSP.

If you've got input we'd like to receive it within the next
two weeks.  Comments and discussion welcome!

Thanks!

-danny & Stewart

-----
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, TDM and SONET

Specify the control and management of the PW types
identified above.

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 deploys equal cost multiple path packet (ECMP)
switching.

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
mechanisms are therefore needed to protect the Internet
from the unconstrained deployment of PWs.

Define requirements for and mechanisms to provide interconnection
of PWs.

Define requirements for and mechanisms to provide inter-domain
operation of PWs.

Define the reqiurements for and mechanisms needed to allow the
operation of switched virtual circuits over a PSN.

---

From: "Florin Balus" <[email-masked]>
Date: Fri, 4 Mar 2005 13:27:26 -0500

> Define requirements for and mechanisms to provide 
> interconnection of PWs.
> 
> Define requirements for and mechanisms to provide 
> inter-domain operation of PWs.
> 
> Define the reqiurements for and mechanisms needed to allow 
> the operation of switched virtual circuits over a PSN.

Do you consider Signaling a mechanism to be considered part of the PWE3
Charter? It was in the past but could we be more specific here.  More
specifically is MH PW Signaling part of the PWE3 charter or not?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Danny McPherson
> Sent: Friday, March 04, 2005 11:09 AM
> To: pwe3
> Subject: [PWE3] PWE3 Charter Update
> 
> 
> 
> Folks,
> 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.
> 
> encapsulation, transport, control, management, interworking 
> and security of services emulated over IETF specified PSNs.
> 
> service which is perceived by its user as an unshared link or 
> circuit of the chosen service.
> 
> 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 
> unless there are technical reasons why the existing 
> mechanisms are insufficient or unnecessary.
> 
> recovery and other real-time signaling functions.  This work 
> will be coordinated with the AVT WG and RTP will be used 
> where appropriate.
> 
> 
> a PSN that deploys equal cost multiple path packet (ECMP) switching.
> 
> 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.
> 
> congestion, a PW deployed by an end-user may cause congestion 
> of the underlying PSN. Suitable congestion mechanisms are 
> therefore needed to protect the Internet from the 
> unconstrained deployment of PWs.
> 
> Define requirements for and mechanisms to provide 
> interconnection of PWs.
> 
> Define requirements for and mechanisms to provide 
> inter-domain operation of 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: Stewart Bryant <[email-masked]>
Date: Fri, 04 Mar 2005 21:05:59 +0000

> specifically is MH PW Signaling part of the PWE3 charter or not?

PWE3 sets up pt-pt links.

L2VPN figures our what needs to be connected using its own
protocols, and then uses PWE3 protocols to set them up.

The last bullet is really about SVCs such as you find
with ATM.

Stewart

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 4 Mar 2005 16:33:41 -0500

In a round about way YES.

It is clear enough for me from this text - 

- Define requirements for and mechanisms to provide interconnection of PWs.
- Define requirements for and mechanisms to provide inter-domain operation of PWs.

"mechanisms to provide interconnection of PWs" means at setup & control
as well as data aspects of interconnected PW segments. The setup
mechanisms then include static & dynamic.

/himanshu

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stewart Bryant
> Sent: Friday, March 04, 2005 4:06 PM
> To: Florin Balus
> Cc: pwe3; Danny McPherson
> Subject: Re: [PWE3] PWE3 Charter Update
> 
> 
> 
> 
> Florin Balus wrote:
> 
> >

---

From: [email-masked]
Date: Sat, 5 Mar 2005 14:43:57 -0000

Hi Stewart, 
> PWE3 sets up pt-pt links.

Link (connections) are fixed entities in a given layer network topology.
Flexibility (of connectivity) comes from the subnetwork connections (I
mean subnetwork in a formal G.805 sense here).  Subnetworks are
recursive structures within a given layer network, with the largest
subnetwork being the 'network' and the smallest subnetwork (of practical
value to an operator) being a 'node'.

A trail is a sequence of concatenated link connections and subnetwork
connections across a layer network. Of course the smallest trail can
indeed be just a single link-connection in length.....which is what a SH
PW is, however MH PWs are the more general case of a sequence of
concatanated link and subnetwork connections.

So PWE3 sets up trails (if we are considering MPLS) or connectionless
trails (if we are considering IP)......one cannot set-up 'links'.

Note - the allowed connectivity topology of a trail is a seperate issue.
Valid constructions in the co-ps and co-cs modes are p2p and p2mp.

regards, Neil

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Mar 2005 16:35:47 +0200

> Flexibility (of connectivity) comes from the subnetwork 
> connections (I mean subnetwork in a formal G.805 sense here). 
>  Subnetworks are recursive structures within a given layer 
> network, with the largest subnetwork being the 'network' and 
> the smallest subnetwork (of practical value to an operator) 
> being a 'node'.

Neil, 

No reason to be overly pedantic here.

A link connection of the client 
is supported by a trail in the server layer.

What Stewart was saying (translated into ITU speak)
is that one sets up a trail to support the link
that the PW client sees.

Y(J)S

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 8 Mar 2005 09:48:49 -0500

[snipped]
> >  > the operation of switched virtual circuits over a PSN.
[snipped]
> The last bullet is really about SVCs such as you find

How to setup ATM SVCs or SPVCs over an MPLS core is more an ATM issue than an MPLS or PWE issue. In the past, the IETF has always considered this to be out of scope.

Furthermore, the MPLS Frame Relay Alliance and ATM Forum have started (and to some extent, completed) work on this a while ago.

Why is this now added to the PWE3 charter?

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Mar 2005 16:50:48 +0200

I have a few comments :

1) You say 

  Switching  ... unless required as part of the emulation, is out of the
scope of the PWE3 WG.

and afterwards you talk of interconnection of PWs (PW stitching),
inter-domain PWs (ditto)
and SVCs. Is this what you mean by "required as part of the emulation" ?
What precisely is required by the emulation? Do you mean required by the
applications
using the PW, or part of the service to be emulated?

2)  I like the wording "AVT ... and RTP will be used where appropriate"
and any other de-emphasis
    of RTP mechanisms as compared with the original charter.

3) please write "low-rate TDM and SONET/SDH" instead of "TDM and SONET".

4) what is included control in "control and management of the PW types"
?
    Is it limited to set-up/teardown signaling ? If so, why don't we say
so?

5) Wording suggestion "by retention of FCS" (remove to "the"s)

6) Suggestion "(ECMP) switching mechanisms" (the problem isn't with ECMP
per se ...)

7) Wording suggestion "in some cases this may be satisfactory ..."
instead of "is satisfactory" .

8) I assume you mean "Suitable congestion avoidance/amelioration/control
mechanisms", 
    (we have far too many mechanisms for congestion generation already
...)

9) Why are Define requirements for ...interconnection of PWs,   and
                 Define requirements for ...interdomain PWs separate
items?
    Isn't the latter a specific application of the former (and thus
could be a parenthetical remark)?

Y(J)S

---

From: Danny McPherson <[email-masked]>
Date: Thu, 10 Mar 2005 05:58:02 -0700

On Mar 8, 2005, at 7:50 AM, Yaakov Stein wrote:

> inter-domain PWs (ditto) and SVCs. Is this what you mean by
> "required as part of the emulation" ?
> What precisely is required by the emulation? Do you mean required
> by the applications using the PW, or part of the service to be
> emulated?

I'm not sure I understand where you're going with this Yaakov?
Obviously, if they're inter-domain or multi-hop PWs associated
encapsulation, setup and maintenance functions will be part of the
emulation function.

> 3) please write "low-rate TDM and SONET/SDH" instead of "TDM and 

I'm OK with this.

> ? Is it limited to set-up/teardown signaling ? If so, why don't we say
> so?

It's more than that, as it could include OAM functions as well.
If you've got some alternative wording you'd like to see here
please pass it along.

> 6) Suggestion "(ECMP) switching mechanisms" (the problem isn't with 

Do you have an alternative text recommendation?

> mechanisms",  (we have far too many mechanisms for congestion 
> generation already
> ...)

Heh, fixed!

> Define requirements for ...interdomain PWs separate items?

OK, I think I've cleaned this up sufficiently.

Thanks for the review Yaakov!

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 10 Mar 2005 03:57:41 -0700

On Mar 8, 2005, at 7:48 AM, Busschbach, Peter B (Peter) wrote:
>
> How to setup ATM SVCs or SPVCs over an MPLS core is more an ATM issue 
> than an MPLS or PWE issue. In the past, the IETF has always considered 
> this to be out of scope.

Not when IP/MPLS-related codepoints and protocol interactions are
concerned.

> Furthermore, the MPLS Frame Relay Alliance and ATM Forum have started 
> (and to some extent, completed) work on this a while ago.
>

Because interest has been expressed by a number of folks in
defining these mechanisms in the IETF.  As usual, we welcome
contributions from folks active in other SDOs that have worked
on these problems already.

-danny

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Mar 2005 15:26:57 +0200

> 1) You say
>   Switching  ... unless required as part of the emulation, is out of 
> the scope of the PWE3 WG.
> inter-domain PWs (ditto) and SVCs. Is this what you mean by "required 
> as part of the emulation" ?
> What precisely is required by the emulation? Do you mean 
> required by the applications using the PW, or part of the service to
be 
> Obviously, if they're inter-domain or multi-hop PWs 
> associated encapsulation, setup and maintenance functions 
> will be part of the emulation function.

That's what I meant.

So the language in the first section has to be cleaned
up to indicate that setup and maintenance signaling
is in-scope.

> ? Is it limited to set-up/teardown signaling ? If so, why 
> don't we say so?
> 

How about
 all mechanisms necessary for setup, configuration, maintenance,
 and tear-down of PWs
?

> 6) Suggestion "(ECMP) switching mechanisms" (the problem isn't with 
> ECMP per se ...)
> 

Yes - I proposed one (I added the word "mechanisms")

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 14 Mar 2005 18:38:28 +0200

Danny and all,
A  brief comment:

The proposed text refers once to "IETF specified PSNs" 
once to "IP and MPLS PSNs" and once to "IP or MPLS" PSNs.

IMHO it would be nice to explicitly spell the (presumably
quite short) list of the PSNs PWE3 is going to deal with.

Regards,
                                  Sasha Vainshtein
email:                         [email-masked] <mailto:[email-masked]> 
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

> From: Danny McPherson [mailto:[email-masked]]
> Sent: Monday, March 14, 2005 6:27 PM
> To: pwe3
> Cc: Mark Townsley
> Yaakov, I think I've incorporated your comments to date, thanks
> for the review.
> 
> We plan to WG Last Call the charter below later this week, please
> send comments ASAP.
> 
> Thanks!
> 
> -danny
> 
> [snip]
> 
> 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.
> 
> a PSN that employs equal cost multiple path (ECMP) packet
> switching mechanism.
> 
> avoidance mechanisms are therefore needed to protect the
> Internet from the unconstrained deployment of PWs.
> 
> interconnection of PWs (to include inter-domain PWs).
>

---

From: [email-masked]
Date: Mon, 14 Mar 2005 16:38:34 +0000

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

|---------+--------------------------->
|         |           Danny McPherson |
|         |           <[email-masked]> |
|         |           Sent by:        |
|         |           pwe3-bounces@iet|
|         |           f.org           |
|         |                           |
|         |                           |
|         |           14/03/2005 16:27|
|         |                           |
|---------+--------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                |
  |        To:      pwe3 <[email-masked]>                                                                                           |
  |        cc:      Mark Townsley <[email-masked]>                                                                             |
  |        Subject: Re: [PWE3] PWE3 Charter Update                                                                                 |
  >--------------------------------------------------------------------------------------------------------------------------------|

Thanks!

-danny

[snip]

---

From: [email-masked]
Date: Mon, 14 Mar 2005 21:11:46 -0000

Is it possible to say what PWE3 are going to do about IP L2tpv3 and MPLS
RSVP-TE (or modified LDP) signalling i/w wrt MH PWs?

regards, Neil

> Behalf Of Andrew G. Malis
> Sent: 14 March 2005 19:02
> To: [email-masked]
> Cc: [email-masked]; Mark Townsley; pwe3; Danny McPherson
> 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,
> >
> >" Define the reqiurements for and mechanisms needed to allow the
> >operation of switched virtual circuits over a PSN."
> >
> >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).
> >
> >switched network (PSN). This migration requires 
> communications services
> >that can emulate the essential properties of traditional
> communications
> >links over a PSN.
> >
> >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.
> >
> 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 
> >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
> 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.
> >
> >
> additional
> >PW types contingent on WG consensus and AD approval:
> >
> 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.
> >
> >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
> 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).
> >

---

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

> quite short) list of the PSNs PWE3 is going to deal with.

While it appears to me that all of the above are indeed the
same (barring a conjunction or two) , I'll try to make the text
more consistent with "IP and MPLS PSNs", assuming no one
objects?

Thanks for the feedback Sasha!

-danny

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 14 Mar 2005 17:15:33 -0500

Danny, et al...

	The charter item is to -

"Define the requirements for and mechanisms needed to allow
 the operation of switched virtual circuits over a PSN."

I believe that this should be qualified rather than removed,
though the effect may be the same.  Instead of what it says
now, it should say something like this - 

"Define any requirements of IETF specific mechanisms and/or
 protocols, including additional mechanism, definition or
 extension requirements - if any - necessary for operation
 of switched virtual circuits over a IP PSN."

I am concerned that some work that may need to be done in
the IETF - to support whatever activities may exist in an
external forum in this problem domain - may become hard to
do as a result of removing this charter item and creating 
an impediment to the continuing efforts of those outside 
fora.

As a specific example, it is exceptionally difficult to get
an IETF consensus assigned code point without a WG with the
particular activity on its charter.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> Danny McPherson
--> Sent: Monday, March 14, 2005 4:54 PM
--> To: Andrew G. Malis
--> Cc: Mark Townsley; pwe3
--> Subject: Re: [PWE3] PWE3 Charter Update
--> 
--> 
--> 
--> On Mar 14, 2005, at 12:01 PM, Andrew G. Malis wrote:
--> 
--> > 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.
--> 
--> 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
--> 
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Walsh, Thomas D (Tom)" <[email-masked]>
Date: Mon, 14 Mar 2005 18:19:29 -0500

Danny,

I support your proposal to remove it.  Should a future need for modification or extension to an IETF protocol arise, I am sure someone will bring the appropriate requirement to your wg and others as needed.

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Danny McPherson
Sent: Monday, March 14, 2005 4:54 PM
To: Andrew G. Malis
Cc: Mark Townsley; pwe3
Subject: Re: [PWE3] PWE3 Charter Update

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

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 14 Mar 2005 18:28:33 -0500

Tom,

	An interesting ramification of removing this item from
the charter is that it may very well prevent this WG from being
able to do anything about any requirement brought to them.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Walsh, Thomas D (Tom)
Sent: Monday, March 14, 2005 6:19 PM
To: 'Danny McPherson'; Andrew G. Malis
Cc: Mark Townsley; pwe3
Subject: RE: [PWE3] PWE3 Charter Update

Danny,

I support your proposal to remove it.  Should a future need for modification
or extension to an IETF protocol arise, I am sure someone will bring the
appropriate requirement to your wg and others as needed.

Tom

-----Original Message-----

Any objections?

Thanks!

-danny

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 15 Mar 2005 08:18:11 -0500

Eric,

If that's a worry, then I would prefer an item in the charter like:

"Review, respond to, and advise IANA on incoming liaisons and internet 
drafts from external organizations on requirements, extensions, and 
requests for code point assignments related to PWE3 chartered activities 
and work items."

Cheers,
Andy

-----------

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 15 Mar 2005 08:55:26 -0500

Andy,

	Review, respond to and advise _IANA_ would address the
specific example I gave. It would not address _extensions_ -
should any be required - without requiring a charter change 
as part of the _response_.

	However, the wording you suggest is getting close and
- perhaps - the need to re-charter would not be such a BAD
THING.  Is there a succinct way to say "IANA, IESG or IAB"?

--
Eric

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, March 15, 2005 8:18 AM
To: Gray, Eric
Cc: 'Walsh, Thomas D (Tom)'; Mark Townsley; pwe3
Subject: RE: [PWE3] PWE3 Charter Update

Eric,

Cheers,
Andy

-----------

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 15 Mar 2005 09:59:45 -0500

Stewart,

	Works for me.

--
Eric

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Tuesday, March 15, 2005 9:58 AM
To: Gray, Eric
Cc: 'Andrew G. Malis'; Mark Townsley; pwe3
Subject: Re: [PWE3] PWE3 Charter Update

> THING.  Is there a succinct way to say "IANA, IESG or IAB"?

"IETF" ?

i.e.

"Review, respond to, and advise IETF on incoming liaisons and internet
drafts from external organizations on requirements, extensions, and
requests for code point assignments related to PWE3 chartered activities
and work items."

Stewart

>>I support your proposal to remove it.  Should a future need for
> 
> modification
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 15 Mar 2005 14:58:27 +0000

"IETF" ?

i.e.

Stewart

---

From: Scott W Brim <[email-masked]>
Date: Tue, 15 Mar 2005 10:05:48 -0500

I think I agree with Eric, but I don't know if we need all the
extra words.  I don't believe that "allowing" SVCs to run over a PSN
requires control protocol interworking, so Andy's concern is
satisfied.  However one of the main motivators for PWE3 has been to
support virtual connections, so it makes little sense to me to
delete mention of them.  We can add Andy's paragraph about advising on
incoming liaisons as well (since we do), but the two are not mutually
exclusive and both are good to have in the charter (not control
signaling).

Scott

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 16 Mar 2005 08:43:28 -0500

Me too.

Thanks, Stewart.

Cheers,
Andy

----------

---

From: [email-masked]
Date: Wed, 16 Mar 2005 14:07:24 +0000

Looks good to me.

Best regards,

Matthew

|         |           "Andrew G.      |
|         |           Malis"          |
|         |           <andymalis@comca|
|         |           st.net>         |
|         |           16/03/2005 13:43|
  |                                                                                                                                |
  |        To:      "Gray, Eric" <[email-masked]>                                                                           |
  |        cc:      Mark Townsley <[email-masked]>, pwe3 <[email-masked]>, "'Stewart Bryant'" <[email-masked]>              |
  |        Subject: RE: [PWE3] PWE3 Charter Update                                                                                 |

Me too.

Thanks, Stewart.

Cheers,
Andy

----------

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 16 Mar 2005 17:15:04 +0200

Danny and all,
Thank you for a prompt response.

> be coordinated with the AVT WG and RTP will be used where

I wonder if this topic attracts sufficient interest within the PWE3. 
I do not have to remind you how lack of such interest in the TDM PWs 
have affected development of the corresponding standards in the
(not so remote) past.

In addition I would like to understand the intended scope of 
the clock recovery investigations in PWE3. 

Clock recovey for TDM pseudo-wires does NOT, IMHO, justify
such an investigation because:

- the "bits on the wire" issue has been already addressed 
  in the PWE3 drafts (e.g., by including optional RTP header
  in the SAToP, CESoPSN and TDMoIP encapsulations or by
  carrying the Pointer Justification events in the CEP
  encapsulation)
- specific clock recovery algorithms (utilising these
  bits) do not require standardization.

A more generic question of distributing high quality timing 
over the PSN is important, but I do not see how it fits into
the PWE3 framework: the latter is point-to-point, while
clock distribution is natively point-to-multipoint 
(the number of points where you have access to the primary 
reference clock (PRC) is limited). Under this assumption:

- one option for timing distribution would be client-server 
  with the server having access to the PRC and distributing 
  it to multiple clients, possibly using some enhancements to NTP
- yet another option would be using IP multicast from the
  node having access to the PRC and the receivers joining
  an appropriate multicast group.

Hopefully these notes will be useful.

Regards,
                                  Sasha Vainshtein

> Sent: Monday, March 14, 2005 11:43 PM
> To: Sasha Vainshtein
> Cc: Mark Townsley; pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 Mar 2005 16:59:46 +0000

Sasha

It's a placeholder.

We know that a precision frequency distribution mechanism
is needed, and we know that PWE3, by encouraging the
retirement of PDH networks is part of the cause. Whether
the work is an NTP task or a PWE3 task is not yet clear.

I have agreed to help pull together a requirements list
and hopefully we can use that to drive things. If you
wish to contribute, your thoughts are welcome.

If the solution is essentially a TDM stream with no payload
that belongs to us.

If the solution is a derivative of NTP it belongs there
although their first task is to write up NTP as it
currently exists in the network, and is not new work.

If it is some other approach then we will see where the
best fit is.

Stewart

---

From: "Florin Balus" <[email-masked]>
Date: Thu, 17 Mar 2005 10:26:36 -0500

Danny, Luca,
See in-line

> Behalf Of Luca Martini
> Sent: Wednesday, March 16, 2005 3:13 PM
> To: Danny McPherson
> Cc: pwe3
> The three point below will need some careful consideration:
> 
[clip] 

> 
> "Define requirements for and mechanisms to provide 
> inter-domain operation of PWs. "

Minor point - we should change Inter-domain PWs to whatever terminology the
requirements draft is proposing: Multi-hop PWs was the first term used which
evolved currently into Multi-segment PWs.

>
> This is a little tricky. I believe that if we do this here , we will 
> need to pull in VPWS service from L2VPN.
> L2VPN already has WG drafts defining this item. So I think this 
> duplicates the work here.
> 
> For example : are we going to deal with VPN security at the 
> border of a 
> domain/AS ? or just worry about PW security ?
> 
> I believe that unless VPWS is moved here, there is too much overlap , 
> with L2VPN , and it is better to add this item to L2VPN WG.
> 

I agree with Luca: we do require further clarifications although I am not
sure we have enough information at this point to be very specific. I listed
below some suggestions.

I liked the comment Stewart made in a previous email to the PWE3 list:
"L2VPN figures our what needs to be connected using its own protocols, and
then uses PWE3 protocols to set them up." 

A good example of applying this strategy in the past is the way L2VPN
Signaling draft complemented the PW drafts: describing the provisioning and
discovery models for various VPN constructs, while re-using the PW modules
(signaling, encapsulation etc) defined in PWE3 drafts. 

Same will apply to Inter-domain PWs (or Multi-hop/segment PWs): i.e.
provisioning and discovery models (for endpoints, topology etc), security
aspects are one piece (e.g. "what needs to be connected") which will end up
in L2VPN; the basic components (e.g. Signaling/"how to set them up") are the
other piece which seem like a good fit in PWE3. 

The MH PWs concepts are going to be re-used in all existing VPWS, VPLS
schemes, wherever interdomain operation is required between Virtual
Forwarders (e.g. VPWS with pools) or VSIs (e.g. distributed VPLS) so it
makes sense to proceed with their basic modules the same way we did with
regular PWs.

I propose we modify the text to read: "Define requirements for and
mechanisms to provide the Setup and Maintenance of Inter-domain PWs" 

This way we clarify we are just trying to address the same modules as for
regular PWs (i.e. setup and maintenance). I expect anyhow that in the
process, some of the concepts defined in one WG will be migrated to the
other one - see the case of the Generalized ID FEC.

[clip]
> Luca
> Danny McPherson wrote:
> > we complete this we'll work on getting the goals and milestones 
> > updated accordingly.  Stewart and I will also provide a 
> complete draft 
> > status report in MSP.
> >
> > 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
> recovery 
> > coordinated with the AVT WG and RTP will be used where appropriate.
> >
> >
> operation over 
> > Whilst a service provider may traffic engineer their 
> network is such a 
> > Suitable congestion mechanisms are therefore needed to protect the 
> interconnection of 
> > PWs.

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 17 Mar 2005 10:44:49 -0500

Tom,

	I think the restriction on overlap you are concerned 
about would be more appropriately mentioned in the L2VPN
charter than in this one.

	Given that the item deals very explicitly with pseudo
wire interconnection mechanisms, it makes more sense to do 
that sort of work here than anywhere else, doesn't it?

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Thomas D. Nadeau
Sent: Thursday, March 17, 2005 8:16 AM
To: Danny McPherson
Cc: Mark Townsley; pwe3
Subject: Re: [PWE3] PWE3 Charter Update

	Danny, some comments.

> [..]

	On this one, I think we need to be careful not to
overlap with L2VPN.  It might be worth coordinating
with the L2VPN charter on this to make sure that you both
are aligned on this (explicitly).

	--Tom

> [..]

---

From: "DELORD Simon RD-RESA-LAN" <[email-masked]>
Date: Thu, 17 Mar 2005 17:22:49 +0100

Luca and all,
We support the idea of having OAM requirements and mechanisms for all kind of PWs, including MH-PWs in the charter.
Regards,
		Simon

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Luca Martini
Envoyé : mercredi 16 mars 2005 21:13
À : Danny McPherson
Cc : pwe3
Objet : Re: [PWE3] PWE3 Charter Update

Danny,

"Define requirements for and mechanisms to provide interconnection of PWs. "

This is fine , as it does not create a service , nor does it necessarily 
put new requirements on the defines service.

"Define requirements for and mechanisms to provide inter-domain operation of PWs. "

For example : are we going to deal with VPN security at the border of a 
domain/AS ? or just worry about PW security ?

"Define the requirements for and mechanisms needed to allow the operation of switched virtual circuits over a PSN."

I believe that OAM is already in pwe3 , so this item is long overdue 
...  shouldn't it say "operation and management" ?

Luca

Danny McPherson wrote:

> updated accordingly.  Stewart and I will also provide a complete draft 
> status report in MSP.
>
> If you've got input we'd like to receive it within the next two weeks.  
> Comments and discussion welcome!
>
> Thanks!
>
> -danny & Stewart
>
> -----
> It is not intended that an emulated service will be indistinguishable 
> cases it may be necessary to design more than one emulation mechanism 
> 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.
>
> security as a dedicated, purpose built, network. In some cases this is 
> satisfactory, while in other cases it will be necessary to enhance the 
> Whilst a service provider may traffic engineer their network is such a

---

From: David McDysan <[email-masked]>
Date: Tue, 22 Mar 2005 08:37:29 -0500

> duplicates the work here.

I think that a particular type of VPWS is currently a WG document in L2VPN.
In the inter-AS case, this is based upon BGP. When we presented extensions
to LDP, the L2VPN working group chairs commented that this appears to belong
in PWE3. Then there is the RSVP based proposal, where would it belong?

---

From: David McDysan <[email-masked]>
Date: Tue, 22 Mar 2005 08:37:29 -0500

I agree with this sentiment, and would add QoS, interoperability and
resiliency to the OAM functions as things that need to be covered
consistently.

Dave

> Behalf Of Thomas D. Nadeau
> Sent: Thursday, March 17, 2005 11:04 AM
> To: Gray, Eric
> Cc: Mark Townsley; pwe3; Danny McPherson
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Tom,
> >
> about would be 
> > more appropriately mentioned in the L2VPN charter than in this one.
> >
> > 	Given that the item deals very explicitly with pseudo wire 
> > interconnection mechanisms, it makes more sense to do that sort of 
> > work here than anywhere else, doesn't it?
> 
> 	Frankly, I don't care where it is done, as long as 
> there are clear guidelines as to where it is done. 8) I also 
> have concerns about not only the protocol specifications, but 
> how the OAM for all of this gets divvied up between the 
> groups given that there are many potential overlaps. Again, I 
> don't care where it is done, as long as it does get done.
> 
> 	--Tom
> 
> 
> 
> 
> >
> > --
> > Eric
> >
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> > Thomas D. Nadeau
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > 	Danny, some comments.
> >
> >>
> >> Yaakov, I think I've incorporated your comments to date, 
> thanks for 
> >> the review.
> >>
> overlap with L2VPN.  
> > It might be worth coordinating with the L2VPN charter on 
> this to make 
> > sure that you both are aligned on this (explicitly).
> >
> > 	--Tom
> >
> >
> >> [..]
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFCOapxHwfkLUURkkwRAtZOAJ98BN/n47azQS071B5m8RlsNoU9PACfUtYO
> 4DEw2mdIlCgnEZcZLWV+JrA=
> =LKD8
> -----END PGP SIGNATURE-----
>

---

From: "Florin Balus" <[email-masked]>
Date: Tue, 22 Mar 2005 10:38:14 -0500

We actually need to clarify what we mean by domain.

In MH PW Requirements (draft-martini-pwe3-mh-pw-requirements-01.txt) a
MH/S-PW traverses different PW domains.  Each (PW) domain could be different
things depending on the use case: e.g. an autonomous system, an IGP area or
administratively established pseudo-wire domain (MAN/WAN) which does not
necessarily match a specific routing domain (area). If PW Domains is what we
mean then yes we will always have inter-domain operations. But then we need
to qualify what we mean by PW Domain.

If we mean routing domain then we need to be specific about different use
cases: Inter-domain, Intra-domain etc...

> Behalf Of David McDysan
> Sent: Tuesday, March 22, 2005 8:37 AM
> To: 'Rahul Aggarwal'; 'Danny McPherson'
> Cc: 'pwe3'
> Rahul,
> The MS-PW requirements document states several use cases that 
> are intra-domain (e.g., metro access, large number of nodes). 
> Therefore, I suggest that "inter-domain" be expanded to 
> "inter- and intra-domain" in the charter statement. Some 
> mention of scalability and interoperability could be used to 
> qualify the intra-domain applicaiton.
> 
> Dave
> 
> > Behalf Of Rahul Aggarwal
> > Sent: Friday, March 18, 2005 5:13 PM
> > To: Danny McPherson
> > Cc: pwe3
> > Hi Danny,
> > A comment inline.
> > I am not aware of any other application of interconnection of
> > PWs other than interdomain operation of PWs. Hence the real 
> > charter item is:
> > "requirements for and mechanisms to provide inter-domain 
> > operation of PWs".
> > 
> > Interconnection of PWs is one possible mechanism to build
> > inter-domain operation of PWs. Hence there is no need to 
> > mention it in the charter.
> > 
> > thanks,
> > rahul
> > 
> >