Subject: Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**

From: Maarten Vissers <[email-masked]>
Date: Thu, 15 May 2008 15:12:58 +0200

retry... 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: 13 May 2008 17:14
To: 'Yaakov Stein'; 'Rahul Aggarwal'; 'Stewart Bryant'; 'Ben Niven-Jenkins';
'Alexander Vainshtein'
Cc: 'pwe3'; 'Danny McPherson'
Subject: RE: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**

Yaakov,

There is a major difference between the use of PWs in a VPLS and the use of
one PW for a p2mp service. 

In a VPLS, the PWs provide simply a link connection identifier for each VPLS
(i.e. ETH) link connection; the PW is as such just a demultiplexer and there
is no need to deploy a PW layer network between the VPLS/ETH layer network
and the MPLS Tunnel layer networks. The monitoring of the mp2mp service will
be done via Ethernet OAM (Y.1731/802.1ag). In terms of G.805, there is an
ETH layer network on top of a MPLS Tunnel layer network.

For the case of a p2mp service, you will use a MPLS PW layer network to
support this service. This MPLS PW layer network will run MPLS PW OAM to
monitor the service. In terms of G.805, there is a MPLS PW layer network on
top of a MPLS Tunnel layer network.

By using the term "PW" for both the label (i.e. demultiplex identifier) and
the layer network connection it is easy to get confused. It would be better
if we have different terms for these two constructs; e.g. 
- PWID for the identifier which identifies either a PW instance or a VPLS
instance within a MPLS tunnel
- PW for the MPLS PW layer connection.

Compare this with ATM, where the connection is referred to as VC and the
connection identifier is referred to as VCI.
Compare this with Ethernet, where the connection is referred to as VLAN and
the connection identifier is referred to as VID or SID.

A mp2mp VPLS Instance, a p2p PW Instance and a p2mp PW Instance deploy a
PWID, which PWID has MPLS Tunnel local significance. If the tunnel is p2p,
then the PWIDs "are p2p", and you will get a set of such PWIDs for a mp2mp
VPLS instance and a p2mp PW instance.

When you would deploy a p2mp MPLS Tunnel, then you only get one PWID to
support the p2mp PW.

When it would be possible to use a mp2mp MPLS Tunnel, then you would only
get one PWID to support the mp2mp VPLS. MPLS is not capable to support this,
but PBB is; specifically a mp2mp VPLS within one PBBN would only use a
single ISID (PWID equivalent).

When you have to support a p2mp PW and the network has only a full mesh of
p2p MPSL Tunnels connecting the PE ndoes, then a n-port p2mp PW will be
implemented by n-1 p2p PW link connections between one ingress PE and n-1
egress PE nodes. Exactly as you describe. There is no alternative in this
case.

The alternative only becomes available when you build a scalable network...
i.e. you then get T-PE and S-PE nodes, and  intermediate P nodes. Now it is
not longer the intention to create a full mesh of MPLS tunnels between T-PE
nodes... Instead tunnels are between T-PE and S-PE and between S-PE and S-PE
nodes. A p2mp PW can now locate its replication points at one or more S-PE
nodes to get better performance (less bandwidth used).

The alternative to create and manage p2mp PWs in the MPLS PW layer using
MPLS PW switches is to use p2mp MPLS tunnels for such p2mp MPLS PWs.
Specifically, p2mp services are typically broadcast TV services, and the
number of those services in a network is restricted. It would be affordable
as such to deploy service specific p2mp tunnels to carry a set of p2mp PWs
with braodcast TV signals.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: 13 May 2008 16:04
To: Rahul Aggarwal; Stewart Bryant; Ben Niven-Jenkins; Alexander Vainshtein
Cc: pwe3; Danny McPherson
Subject: Re: [PWE3] PWE3 Charter Update - **DRAFT Charter v0.1**

To all who responded on the p2mp issue.

I was not claiming that using many p2p PWs to emulate a p2mp service was
efficient.  I was only saying that this was ONE way of implementing a p2mp
service using pseudoWIREs.

This is precisely what we do with VPLS. The PW remains p2p, and a layer
above it provides the needed connectivity.
If we CAN relatively efficiently implement a mp2mp service by using a mesh
of p2p PWs, why do we need to extend the definition of a PW?

Another way would be to define a pseudotree (PT).
This would be an inherently p2mp entity, that would enable running p2mp
applications over p2mp upstream label allocated MPLS.

Perhaps instead we should go all the way to a pseudomesh (PM), that would
run over a mesh of LSPs, or over PSNs capable of supporting mp2mp traffic.

When such a radical extension is proposed the alternatives should be
weighed.

Y(J)S
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

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