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

"Yaakov Stein" <yaakov_s@rad.com> Wed, 14 March 2007 05:55 UTC

Return-path: <pwe3-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRMSI-0001x6-LE; Wed, 14 Mar 2007 01:55:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRMSH-0001wr-9E for pwe3@ietf.org; Wed, 14 Mar 2007 01:55:21 -0400
Received: from mx2-012.rad.co.il ([212.199.240.16] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRMSE-0005gk-OH for pwe3@ietf.org; Wed, 14 Mar 2007 01:55:21 -0400
Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 14 Mar 2007 07:54:57 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 14 Mar 2007 07:54:57 +0200
Message-ID: <457D36D9D89B5B47BC06DA869B1C815D03771D7A@exrad3.ad.rad.co.il>
In-Reply-To: <3C2E60A2B33F124A8A702388733BB6064B4CF0@i2km99-ukbr.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt
Thread-Index: AcdfgQf34JxvdI/fS2CH+S4TJpcBKwAAE9qwAAoo8sABkGqFkA==
From: Yaakov Stein <yaakov_s@rad.com>
To: neil.2.harrison@bt.com, busschbach@alcatel-lucent.com, amalis@gmail.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 19fc2b47780353ba1ee25032fbc339e7
Cc: townsley@cisco.com, pwe3@ietf.org, hshah@ciena.com, stbryant@cisco.com
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0058466716=="
Errors-To: pwe3-bounces@ietf.org

Neil, 
 
Thanks for your clear statement of why you don't like MPLS.
 
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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] 
Sent: Tuesday, March 06, 2007 07:20
To: busschbach@alcatel-lucent.com; amalis@gmail.com
Cc: townsley@cisco.com; pwe3@ietf.org; hshah@ciena.com;
stbryant@cisco.com
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:busschbach@alcatel-lucent.com] 
	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:amalis@gmail.com] 
		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:amalis@gmail.com <mailto:amalis@gmail.com> ] 
				
				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:busschbach@alcatel-lucent.com]
				
				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:stbryant@cisco.com]
				
				> 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.
				
				>
				
				> - Stewart
				
				>
				
				>
				
				>
_______________________________________________
				
				> pwe3 mailing list
				
				> pwe3@ietf.org
				
				>
https://www1.ietf.org/mailman/listinfo/pwe3
				
				>
				
				
	
_______________________________________________
				
				pwe3 mailing list
				
				pwe3@ietf.org
				
	
https://www1.ietf.org/mailman/listinfo/pwe3
				
				
	
_______________________________________________
				
				pwe3 mailing list
				
				pwe3@ietf.org
				
	
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3