Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks

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

On Jul 26, 2005, at 7:06 AM, [email-masked] wrote:

> danny - i agree on Loa's recommendation -

OK folks, I've made the recommended changes..

The current draft revision of the charter is available here:

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

and inline below..

-danny

--------------------------
Pseudo Wire Emulation Edge to Edge (PWE3) WG

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 networks (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 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 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 and L2TPEXT WG to
ensure a clear demarcation is defined for where PWE3 stops
and L2VPN starts.  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.

WG Objectives (in order of priority):

Specify the following PW types and consider specifying
additional PW types contingent on WG consensus:

Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM and SONET.

PWE3 may also specify a PW type which can be used for
carrying a user's MPLS packets from one end of the PW to
the other.

In general, PWE3 will not specify mechanisms by which a PW may
connect two different access services.  However, PWE3 may specify
such mechanisms for the special case where the access service
payloads at both ends are known to consist entirely of IP packets.

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

Define requirements for and mechanisms to provide
interconnection of PWs (to include inter-domain PWs).

Define the requirements 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

---

From: Luca Martini <[email-masked]>
Date: Tue, 26 Jul 2005 12:00:33 -0600

Danny,

Comments inline.

> http://pwe3.tcb.net/pwe3-charter-2005072601.txt
This statement need to be changed to either say :

PWE3 will work closely with the L2VPN and L2TPEXT  WG. PWE3 WG is not 
concerned with how PW are placed , or provisioned in a network, but only 
with the encapsulation and maintenance of the PWs.

Or something along these lines ...
The point is to draw the line , no just leave it open ended to the WG to 
fight over it .

> additional PW types contingent on WG consensus:
No this is open ended. The WG could go on forever defining an infinite 
amount of PWs ...
If the AD think that we need more then we should get a charter revision.
By now you should know where this WG work needs to end.

It should change to:

> payloads at both ends are known to consist entirely of IP packets.
excellent , this is much better then the previous version...

> types, to include PW setup, configuration, maintenance and
This is fine with me , but in the initial charter "Setup" was taken to 
mean placement.
So that would be the L2VPN WG job..

> for example by the retention of the FCS across the PW.
This seems to be a contradiction to the above statement:
" It is not intended that
an emulated service will be indistinguishable from the service
that is being emulated. "

I'm not sure that the FCS retention draft needs anything in the charter 
specific to it .
What other work is this paragraph intended for ?

I think that this should be made clear or removed.

> a PSN that employs equal cost multiple path (ECMP) packet
I take this to mean that we will define methods to operate PW in a 
network containing ECMP ...
This means finding a way to load share a PW across multiple links ....
Are you sure this is the intention ?
( disabling load sharing for PW would actually break the ECMP network ... )

I think you should take this section out unless the intention is as above.

Luca

---

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

On Jul 26, 2005, at 12:00 PM, Luca Martini wrote:
> concerned with how PW are placed , or provisioned in a network, but 
> only with the encapsulation and maintenance of the PWs.

> The point is to draw the line , no just leave it open ended to the WG 
> to fight over it .

If everyone weren't screaming conspiracy it wouldn't be an issue.
The fact of the matter is that things are going to change and
simply calling out a few WGs explicitly - by request of several
folks, was done.  The charter already explicitly says that exerting
control on the underlying PSN is out of scope.

> If the AD think that we need more then we should get a charter 

The ADs don't think this, they gauge consensus of new work
from the working group.  It's crazy to think a recharter should
be required every time a PW type is defined.

> By now you should know where this WG work needs to end.

I'm not sure about that..  What about FC, for example?  Just
because your interests have been served doesn't mean that the
same underlying architectures can't/shouldn't be used to enable
additional PW types that other WG members are interested in..

> I'm not sure that the FCS retention draft needs anything in the 
> charter specific to it .

I'd be happy removing it as I believe it was just meant to cover
the FCS work.  There's no contradiction though, and I've never
liked to word transparent, but for lack of a better..

Does anyone see a need to keep that paragraph?

> I take this to mean that we will define methods to operate PW
> in a network containing ECMP ...

Yes, i.e., not break as a result of ECMP...

> Are you sure this is the intention ?

Or not load-share, depending on how you look at it..

> I think you should take this section out unless the intention is as 

That section was meant to place the MPLS ECMP (draft*bcp) & the CW
in scope..  We could potentially remove it at this point as well.

-danny

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 26 Jul 2005 14:30:25 -0400

On Jul 26, 2005, at 2:11 PM, Danny McPherson wrote:

>> PWE3 will work closely with the L2VPN and L2TPEXT  WG. PWE3 WG is  
>> not concerned with how PW are placed , or provisioned in a  
>> network, but only with the encapsulation and maintenance of the PWs.
>>
>
>
>> The point is to draw the line , no just leave it open ended to the  
>> WG to fight over it .
>>
>
>> No this is open ended. The WG could go on forever defining an  
>> infinite amount of PWs ...

     Well, maybe not so crazy. *)  IMHO, it just focuses
the scope of the work a little more than leaving it
open-ended.  In my mind adding new PW types is
a potentially big deal in that it has possible
ramifications on all of the existing work done
to-date, so it should be considered carefully.

     --Tom

---

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

> control on the underlying PSN is out of scope.
yes but it does not say anything about automatic provisioning of the PWs 
or automatic placement of the PWs.
That is not "exerting control on the underlying PSN".
It should be explicit. Included or excluded.

> be required every time a PW type is defined.
That was the initial intention. When we created PWE3 the PW types to 
work on where explicitly mentioned for this reason.
New PW types require a re-charter.

> because your interests have been served doesn't mean that the

My interests ? you make it sound like a personal WG !
I actually supported including the FC in this charter ...
If we know about it , and there is interest , then we should include it .
( X.25 PW maybe ? I do not think that there is interest in that ;-) )
WG work has to be specific , and focused. Otherwise we get nowhere.
The WG  has to have a start , chartered work  and an end. If more work 
is needed after the WG shuts down then a new WG is created like the 
L2TPEXT one...

Luca

[cut]

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Jul 2005 13:03:54 -0600

> to-date, so it should be considered carefully.

Yeah, you're right..  I'm not sure what the best way to go
about this is.  I've asked the ADs for some guidance...

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Jul 2005 13:08:53 -0600

On Jul 26, 2005, at 12:57 PM, Luca Martini wrote:
> yes but it does not say anything about automatic provisioning of
> the PWs or automatic placement of the PWs.  That is not "exerting
> control on the underlying PSN".  It should be explicit. Included or
> excluded.

Wouldn't provisioning or placement of the PWs require some interaction
(i.e., exerting control) on the underlying PSN?  If you've got some
proposed text that's reasonable I'd be happy to incorporate.

> That was the initial intention. When we created PWE3 the PW types
> to work on where explicitly mentioned for this reason.

Running this by the ADs now, I suspect you're right..  I've got
it tagged as an open issue.

> My interests ? you make it sound like a personal WG !

I thought that might catch your attention :-)

> The WG  has to have a start , chartered work  and an end. If more
> work is needed after the WG shuts down then a new WG is created like
> the L2TPEXT one...

See above point about consulting with ADs on this..

Thanks for the feedback!

-danny

---

From: David McDysan <[email-masked]>
Date: Tue, 26 Jul 2005 15:23:37 -0400

Comment in line below on FCS retention.

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Danny McPherson
> Sent: Tuesday, July 26, 2005 2:12 PM
> To: Luca Martini
> Cc: pwe3
> Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP networks
> 
> 

Snipped

>> 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.
> >>
> > an emulated service will be indistinguishable from the 
> service that is 
> > being emulated. "
> >
> I'd be happy removing it as I believe it was just meant to 
> cover the FCS work.  There's no contradiction though, and 
> I've never liked to word transparent, but for lack of a better..
> 

I would like to see a specific mention of FCS retained in the charter. Here
I agree with sentiment several people have expressed that the charter should
be specific and closed ended.

Since FCS retention is a specific fault detection mechanism, mention could
be added as another sentence to the OAM paragraph above the paragraph in
question. 

Proposed text for this new sentence: "Specify an OAM mechanism for detecting
faults in PW-based Ethernet forwarding using an FCS retention mechanism."

Snipped

---

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

> faults in PW-based Ethernet forwarding using an FCS retention mechanism."

It's not just Ethernet, it's also FR and HDLC/PPP

- Stewart

---

From: David McDysan <[email-masked]>
Date: Tue, 26 Jul 2005 16:13:37 -0400

OK, proposed revised sentence for Draft charter.

"Specify OAM means for detecting faults in PW-based Ethernet, FR, and
HDLC/PP forwarding using an FCS retention mechanism."

Dave

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Tuesday, July 26, 2005 3:51 PM
> To: David McDysan
> Cc: 'pwe3'
> Subject: Re: [PWE3] Draft Charter - IP and MPLS enabled IP 
> networks - FCS Retention
> 
> 
> > Proposed text for this new sentence: "Specify an OAM mechanism for 
> > detecting faults in PW-based Ethernet forwarding using an 
> FCS retention mechanism."
>

---

From: Danny McPherson <[email-masked]>
Date: Tue, 26 Jul 2005 14:22:47 -0600

> be added as another sentence to the OAM paragraph above the paragraph 

Yeah, I've been asked by a couple folks to leave it and
the ECMP text as is, given that we've got current WG drafts
that address these topics..  For now, I plan to leave the
current text surrounding these items in the charter.

Thanks Dave!

-danny

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 26 Jul 2005 21:54:18 -0400

>> detecting

     How about just "Specify OAM mechanisms for
all supported PW types." ?

     --Tom

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 27 Jul 2005 17:58:12 -0400

Needless to say, I'm in favor of the text below.

Thanks,
Andy

---------

---

From: Luca Martini <[email-masked]>
Date: Wed, 27 Jul 2005 16:56:36 -0600

David,

The problem here is that you are putting a solution in the charter....
There maybe many ways of solving this issue , one of with is FCS retention.
I know we have a solution already , but a more general item is more 
likely to get approved, and we still use the FCS retention:

"Specify OAM means for detecting data plane faults in PW forwarding."

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 27 Jul 2005 17:06:14 -0600

Can you point out the e-mails on this list that discuss the ECMP?

Need I remind you that this is not a secret society .... we work 
together on this e-mail list.

Thanks.
Luca

---

From: Danny McPherson <[email-masked]>
Date: Thu, 28 Jul 2005 11:14:41 -0600

> Can you point out the e-mails on this list that discuss the ECMP?

I received a direct email from Stewart, and Dave's emails to the
list regarding the FCS.

It really doesn't make sense to remove these items from the
charter given that we've got active working group items for
both FCS (FCS draft) & ECMP (CW & corresponding mpls-bcp)
both of which seem to be nearly done but neither of which
is complete.

If you've got some underlying concern regarding these already
chartered WG items then let me know and we can perhaps
scope or wrap some additional text around these items in the
charter.

> together on this e-mail list.\

Cute Luca..  No need to remind me, but I do encourage you
to keep this in mind :-)

-danny