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

<neil.2.harrison@bt.com> Wed, 14 March 2007 10:04 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 1HRQL6-0004RT-0w; Wed, 14 Mar 2007 06:04:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRQL4-0004RK-4w for pwe3@ietf.org; Wed, 14 Mar 2007 06:04:10 -0400
Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRQKx-0007sM-Oj for pwe3@ietf.org; Wed, 14 Mar 2007 06:04:10 -0400
Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 10:04:03 +0000
Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Mar 2007 10:04:02 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [PWE3] question on draft-mohan-pwe3-vccv-eth-01.txt
Date: Wed, 14 Mar 2007 10:04:00 -0000
Message-ID: <3C2E60A2B33F124A8A702388733BB606805D93@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+S4TJpcBKwAAE9qwAAoo8sABkGqFkAAK9Huw
From: neil.2.harrison@bt.com
To: yaakov_s@rad.com, busschbach@alcatel-lucent.com, amalis@gmail.com
X-OriginalArrivalTime: 14 Mar 2007 10:04:02.0349 (UTC) FILETIME=[178D95D0:01C76620]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 11dcac9fca4206f69d2a663d7a4faf43
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="===============0614962089=="
Errors-To: pwe3-bounces@ietf.org

Yaakov,

-----Original Message-----
From: Yaakov Stein [mailto:yaakov_s@rad.com] 
Sent: 14 March 2007 05:55
To: Harrison,N,Neil,JCGA1 R; 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


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