Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

From: <[email-masked]>
Date: Thu, 1 Mar 2007 17:34:47 -0000

> > If we want to take on the work proposed in the draft there 
> seems to be 
> > two possible routes open
> > 
> > - change the charter to talk about *publick switched networks* in
> >   general (I would have objections to this route)
> 
> I agree the IETF is the design authority for IP and MPLS 
> PSNs, it is not the design authority for Ethernet PSNs.
> 
> - Stewart
> 
I also agree, but I would also make the observation that if one is not
clear between client/server and peer-partition layer network
relationships then one can easily generate many self-inflicted problems.
Public services require a great deal of thought wrt to the services they
support...it's more than simply 'technology interconnects'...and this is
manifested in detailed UNI and E-NNI specifications.

regards, Neil

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

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 10:04:00 -0000

Yaakov,

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: 14 March 2007 05:55
To: Harrison,N,Neil,JCGA1 R; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

Neil, 
 
Thanks for your clear statement of why you don't like MPLS. 
Sorry, you misinterpet me.  I was simply pointing out facts......these
are things I cannot change.....so this has nothing to do with 'opinions'
of whether I like/dislike MPLS.
 
It is the possible consequences of those facts I am urging caution on.
 
regards, Neil
 
However, perhaps I can restate the facts in a somewhat more positive
way.
 
MPLS is a general server layer. It can handle all clients.
It is built to recursively carry itself with no overhead.
It has an optional feature to eliminate itself when not needed,
but no-one forces you to use that feature.
 
Since IP was its first, and remains its most important client,
there are special features to make carrying IP maximally efficient
from both bandwidth and router-processing points of view.
 
For all other payloads some extra bandwidth must be allowed.
However, this is a mere 4 bytes (most of which are empty
and just there in order to maintain efficient processing).
Most of the time it is only needed for internal MPLS reasons,
but other protocols have similar constructs 
(e.g. when you want to add priority bits to nontagged Ethernet 
you MUST use a VLAN tag, when you want to carry realtime traffic
over IP, you must use at least 12 bytes of RTP header).
 
If you only want to transport Ethernet, and you have Ethernet
infrastructure,
then don't bother using MPLS or any other server layer
(unless you want to benefit from other characteristics of MPLS).
If you already have an IP/MPLS infrastructure then you can use
it for arbitrary clients - you needn't build a new infrastructure
in order to provide legacy and Ethernet services.
 
Y(J)S

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 07:20
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

I want to try and inject a sanity check on this thread.
 
PWs are a direct consequence of the fact that MPLS does not treat all
it's client consistently, ie
IP=> null encaps OR peer PDU
MPLS=> digital wrapper, ie just stick on new header and pretend we can
create a server layer connection at will
Other=> PW encaps.
 
So PWs are an artificial construct for carrying XoverMPLS, and they only
exist because of the way MPLS has been specified in the 1st place.
Further, once the PWs entities become > 1 hop they have a step change in
behaviour from being some form of adaptation (mainly to suit the
vagaries of MPLS, and a wrong mind-set that client compression is a good
idea) to a full-blown co-ps mode layer network in its own right.......so
just where the heck are we going with this stuff?
 
At a minimum one will create a quite unnecessary common adaptation layer
for other technologies.  If I want to carry Ethernet over Ethernet (ie
MACinMAC) I for sure don't want a PW layer inserting in the stack thank
you very much!   Further, I'd take issue with anyone who tried to tell
me the functional fields in the CW are useful in a properly constructed
co-ps or co-cs mode server layer...... they look like they do purely to
serve issues created by MPLS. 
 
I think caution and careful consideration should be exercised before
spreading the PW remit wider than MPLS.
 
Aside=> the fact that PHP 'votes itself (ie MPLS) off the island' as I
once heard someone most tellingly remark does not justify the direction
being suggested IMO.....but hey, that's a consequential problem of
allowing PHP in the first place!
 
regards, Neil

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]]

Sent: 06 March 2007 00:00
To: Andrew G. Malis
Cc: Mark Townsley; pwe3; Shah,Himanshu; Stewart Bryant
Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

Andy,
 
The charter language does not apply in the case of adjacent PEs. You
can't mandate that there be an MPLS network between adjacent PEs,
because then they would not be adjacent.
 
That said, I agree that the text in RFC4447 was not meant to sanction
PWs over Ethernet. We should update the charter and allow PWs over any
packet switched network.
 
Peter

  _____  

From: Andrew G. Malis [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 6:50 PM
To: Busschbach, Peter B (Peter)
Cc: Mark Townsley; pwe3; Shah,Himanshu; Stewart Bryant
Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

Peter,

Thanks for pointing that out. However, that doesn't change the existing
charter language.

Cheers,
Andy

-------

At 3/5/2007 05:43 PM -0600, Busschbach, Peter B \(Peter\) wrote:

Andy,
 
I respectfully disagree. The text that I quoted says "... if the
pseudowire endpoints are immediately adjacent ...". Note the "s" at the
end of "endpoints". Therefore, the text is about adjacent PEs and it
says that in that case there is no need for an MPLS tunnel to carry the
PW. In other words, the PW can be carried directly over the link layer
between the adjacent PEs.
 
Peter

  _____  

From: Andrew G. Malis [  <mailto:[email-masked]>
mailto:[email-masked]] 

Sent: Monday, March 05, 2007 6:33 PM

To: Shah, Himanshu

Cc: Busschbach, Peter B (Peter); Stewart Bryant; Mark Townsley; pwe3

Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

I would like to point out that the intent of the RFC 4447 text quoted by
Peter was to ONLY allow PHP to be used on the physical link between the
penultimate P router and the PE router where the PW terminates and
connects with the attachment circuit.  In this one case only, the MPLS
tunnel used to carry the PW terminates at the penultimate P router
rather than at the PE router. It was not meant to be a general escape
mechanism to allow the general use of PWs over tunneling mechanisms
other than MPLS or L2TPv3. 

Further, to quote the WG charter,

"Pseudowire Emulation Edge to Edge (PWE3) will specify the

encapsulation, transport, control, management, interworking and

security of services emulated over IETF specified PSNs."

Ethernet and SONET are not IETF specified PSNs.

So, while there may be value in supporting PWs over non-IETF-specified
PSNs, I do agree with Stewart and Mark that a charter change will be
necessary to pursue this work.

Cheers,

Andy

--------

At 3/5/2007 05:51 PM -0500, Shah, Himanshu wrote:

Content-class: urn:content-classes:message

Content-Type: multipart/alternative;

         boundary="----_=_NextPart_001_01C75F78.CAA52CEF"

I believe this is a key point.

In my view, discussions on in/out scope

really does not apply (for the reasons

described below). Also, note that as L2

technology becomes more intelligent (eg. PBT),

keeping it out-of-scope (artificially) would be

a mistake.

There are other docs (past/present), that already

use this concept, such as dry martini,

MEF3/8 (TDM-PWoETH, except ethType is different),

pw-over-pbt, etc.

IMO,

himanshu

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

From: Busschbach, Peter B (Peter) [
mailto:[email-masked]]

Sent: Mon 3/5/2007 5:24 PM

To: Stewart Bryant; Mark Townsley

Cc: pwe3

Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

Dave Allan made a point that I believe is valid and makes this whole

discussion irrelevant. To rephrase what he said:

Page 4 of RFC 4447 says:

   In the protocol specified herein, the pseudowire demultiplexor field

   is an MPLS label.  Thus, the packets that are transmitted from one

   end of the pseudowire to the other are MPLS packets, which must be

   transmitted through an MPLS tunnel.  However, if the pseudowire

   endpoints are immediately adjacent and penultimate hop popping

   behavior is in use, the MPLS tunnel may not be necessary. 

Based on this logic, PWs can be carried over SDH, Ethernet or any other

protocol that can carry MPLS packets without violating the PWE3 charter.

Peter

> -----Original Message-----

> From: Stewart Bryant [mailto:[email-masked]]

> Sent: Monday, March 05, 2007 1:35 PM

> To: Mark Townsley

> Cc: pwe3

> Subject: Re: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt

> So the proposal seems to be that PWE3 extends VCCV for use

> with a PWE3 PW over a non IP/MPLS PSN.

> We should put this on the agenda for Prague.

pwe3 mailing list

[email-masked]

pwe3 mailing list

[email-masked]