Subject: Martini Ethernet mode

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jul 2002 14:27:48 -0700

Hi,

What is the PW selection criteria in case of Martini native Ethernet mode?
MAC? or port #? or ?

Yours,
Shahram

---

From: Eric Rosen <[email-masked]>
Date: Wed, 31 Jul 2002 10:58:34 -0400

Shahram> What  is  the PW  selection  criteria  in  case of  Martini  native
Shahram> Ethernet mode? 

This is a  bit like asking what the "TCP  connection selection criteria" are
when you have packets to send.  It's  up to the users of the TCP connections
to know which ones to use when.

It  is the  "forwarders" (see  draft-ietf-pwe3-protocol-layer-00  and draft-
andersson-ppvpn-l2-framework-01) that  decide which  frames to put  on which
pseudowires.   Different  forwarders may  use  different  criteria. This  is
discussed in the PPVPN L2VPN framework.

---

From: Shahram Davari <[email-masked]>
Date: Wed, 31 Jul 2002 08:16:56 -0700

Thanks Eric,

Actually based on this I wanted to find out what kind of lookup should be done
at the egress point of the PW:

1) If VLAN tag was used to select the PW at the ingress, then it doesn't make
sense to do any VLAN (or MAC) lookup at the egress, since the VC label represents the VLAN information.

2) If the port# has been used to select the PW at the ingress, also there is no
point in looking up the VLAN (or MAC) at the egress, since this is supposed to be
a transparent mode.

3) If the MAC or MAC+VLAN is used to select the PW at the ingress, then you
need to do VLAN and/or MAC lookup at the egress.

Is my understanding correct?

-Shahram

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, July 31, 2002 10:59 AM
> To: Shahram Davari
> Cc: [email-masked]'
> Subject: Re: [PWE3] Martini Ethernet mode 
> 
> 
> 
> It  is the  "forwarders" (see  
> draft-ietf-pwe3-protocol-layer-00  and draft-

---

From: Eric Rosen <[email-masked]>
Date: Wed, 31 Jul 2002 13:49:40 -0400

I'm a little out of my element  with this ethernet stuff, but let me give it
a try. 

Shahram> 1) If VLAN  tag was used to select  the PW at the  ingress, then it
Shahram>    doesn't make sense to do any VLAN (or MAC) lookup at the egress,
Shahram>    since the VC label represents the VLAN information.  

Well, suppose  at the  ingress PE  there is a  single port  serving multiple
customers,  and the  SP  uses VLAN  tags  to distinguish  one customer  from
another.  The  ingress PE pops  off the VLAN  tag and then sends  the frames
from a given customer on one PW.  These frames might or might not still have
VLAN  tags on  them;  if  they do,  these  are the  VLAN  tags  used by  the
customer, rather than the VLAN tag used by the SP for service delimitation. 

Now  let's suppose that  at the  egress PE,  that customer  has a  number of
different CE devices attached.  As frames come off the PW, the customer VLAN
tag could be used to choose which CE device gets which frame. 

This seems to me to be  a legitimate possibility, and is a counterexample to
your statement 1). 

Shahram> 2) If the port# has been used to select the PW at the ingress, also
Shahram>    there is no point in looking up the VLAN (or MAC) at the egress,
Shahram>    since this is supposed to be a transparent mode. 

Well,  suppose the  port at  the ingress  PE is  a "VLAN  trunk", containing
packets from multiple VLANs, but all  from the same customer.  These all get
put on a single PW.  But at  the egress PE, maybe that customer has multiple
CEs, and each VLAN indicates to a different CE. 

Again,  this   seems  to   me  to  be   a  legitimate  possibility,   and  a
counter-example to your statement 2. 

Shahram> 3) If the MAC or MAC+VLAN  is used to select the PW at the ingress,
Shahram>    then you need to do VLAN and/or MAC lookup at the egress. 

This one I'm sure  isn't true!  This might be a VPLS  case where the ingress
is a hub and the egress is a spoke.  If at the egress end of the PW there is
only one CE in the given VPLS, there is no need to do a MAC lookup.

---

From: Shahram Davari <[email-masked]>
Date: Wed, 31 Jul 2002 11:27:32 -0700

Eric,

> Sent: Wednesday, July 31, 2002 1:50 PM
> To: Shahram Davari
> Cc: [email-masked]'
> tag could be used to choose which CE device gets which frame
> 

This is a legitimate possibility, but demuxing customer traffic
is not a PWE3 service any more. In your example, from PWE3 point
of view, the egress port MUST be the mentioned customer. Now if
customer happens to have multiple sites connected to the same PE,
and wants the SP to demux the traffic based on his private VLAN tagging,
then that is another service, not PWE3. It might a VPLS service!

> counter-example to your statement 2. 

Same as above. This is not a PWE3 service. It might a VPLS service!

> only one CE in the given VPLS, there is no need to do a MAC lookup. 

My mistake. This one is a VPLS service.

-Shahram

---

From: Samir Sanghani <[email-masked]>
Date: Wed, 31 Jul 2002 14:56:52 -0400

Pls see my response inline. (I am referring to 
draft-martini-ethernet-encap-mpls-01.txt)

- Samir 

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 10:50 AM
To: Shahram Davari
Cc: [email-masked]'
Subject: Re: [PWE3] Martini Ethernet mode 

	***[Samir]****
	(Per Martini Draft)
	Each incoming VLAN should be mapped to 
	DIFFERENT VC Labels and Egress PE would 
	switch the packets based on these VC labels. 
	And no need to do VLAN
	based forwarding at Egress PE.
	Otherwise what's point of
	a VC label? Am I missing something?
	And Egress PE should not even care whether VLAN 
	was removed or kept.

	( Egress PE is configured to map VC labels to 
	one of the multiple Ethernet ports that it may
	have! )

	******* [Samir] ********
	Again, if you are trying to expect Egress PE
	to do the VLAN based forwarding, i.e. in a way
	achieving one point/port to many point/port type
	topology out of a PW.

	I feel what's best to do for this is:
	Assign separate VC to each of those VLANs coming in 
	on the trunk port at Ingress. and Egress 
	PE does forwarding based on those VCs. So
	you can distribute different VLANs/VCs to 
	different ports/CEs. 

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

---

From: Giles Heron <[email-masked]>
Date: 31 Jul 2002 21:21:58 +0000

On Wed, 2002-07-31 at 18:27, Shahram Davari wrote:
[snip]
> then that is another service, not PWE3. It might a VPLS service!
[rest snipped]
no -  VPLS is about switching on MAC addresses.

If you are just switching on VLAN tags then that is still a PWE service.

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Shahram Davari <[email-masked]>
Date: Wed, 31 Jul 2002 13:48:45 -0700

> From: Giles Heron [mailto:[email-masked]]
> Sent: Wednesday, July 31, 2002 5:22 PM
> To: Shahram Davari
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: [PWE3] Martini Ethernet mode
> 
> 

OK.

> If you are just switching on VLAN tags then that is still a 

Here is what martini-ethernet draft says:

"The "NSP" function includes packet processing needed to translate the
Ethernet packets that arrive at the CE-PE interface to/from the Ethernet
packets that are applied to the PW termination point. Such functions may
include stripping, overwriting or adding VLAN tags, physical port multi!
plexing and demultiplexing, PW-PW bridging, L2 encapsulation, shaping,
policing, etc."

So physical port demuxing is an NSP function, that is outside of PWE scope.

-Shahram

---

From: [email-masked]
Date: Thu, 1 Aug 2002 04:21:39 +0100

Shahram Davari wrote 31 July 2002 21:49
> To: 'Giles Heron'
NH=> I agree with you on this Shahram.  If you are swithing on VLAN tags
this is some form of new type of ethernet service that sits above the PSN
and below MAC (Name) forwarding.  IMO trying to build too much 'client
specific' parameters into a lower layer network (because the functionality
required is missing in the higher layer network for whatever reason) is a
dangerous road to go down. 

regards, Neil

---

From: Giles Heron <[email-masked]>
Date: 01 Aug 2002 10:05:38 +0000

> So physical port demuxing is an NSP function, that is outside of PWE scope.

agreed.  What you have here is a bunch of PWs with an NSP selecting
between them - i.e. a PWE service.  I'm sorry if my slack wording led
you to think I considered this part of the scope of PWE3 - clearly it
isn't (well - not unless the ADs have changed their minds again!)

At any rate you *don't* have is VPLS...

Giles

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Aug 2002 10:35:49 -0400

Shahram> Here is what martini-ethernet draft says:

Shahram> "The "NSP" function includes  packet processing needed to translate
Shahram> the Ethernet packets that arrive at the CE-PE interface to/from the
Shahram> Ethernet packets that are applied to the PW termination point. Such
Shahram> functions may  include stripping, overwriting or  adding VLAN tags,
Shahram> physical port  multiplexing and demultiplexing,  PW-PW bridging, L2
Shahram> encapsulation, shaping, policing, etc."

Strictly speaking, PW-PW  bridging is not an NSP  function but a "forwarder"
function, as these terms are used in PWE3's protocol layering document and
in PPVPN's L2VPN framework. 

Shahram> So physical  port demuxing is an  NSP function, that  is outside of
Shahram> PWE scope.  

Yes,  that's  why  I've always  insisted  that  PWE3  must not  specify  the
procedures that are used for assigning packets to pseudowires. 

That's also  why I think  a "VCid" is  a very poor  construct to use  in the
signaling protocol.  The identification  information that needs to be passed
is information  which identifies the PW  users at both  ends (the forwarders
and/or NSP functions). 

The  PW users  will  also have  a need  to  signal each  other, to  exchange
parameters and/or  to signal various  state changes.  This signaling  may be
considered to be  outside the scope of PWE3.  HOWEVER,  it is very desirable
to be  able to  do this signaling  with the  same control protocol  used for
setting up and maintaining the PW.  Perhaps the best way to think of this is
that  we  want  to  be  able   to  use  the  LDP/L2TP  connection  to  carry
service-specific PDUs which relate to  specific PWs.  In LDP, these would be
TLVs.  With  this capability, the specification and  interpretation of these
TLVs  could  be  the  responsibility  of  PPVPN,  but  the  basic  signaling
mechanisms could be the responsibility of PWE3.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 01 Aug 2002 17:17:23 +0200

> is information  which identifies the PW  users at both  ends (the forwarders

Further, the PW-Type should be used for the PW to know how to format and send
packets between the forwarders. This should be separate from the VCid, VC Type,
or any other inference to the type of interface that the native link might
happen to be, where it arrived from, or where it is destined to.

> setting up and maintaining the PW.  

Agreed. For L2TP, it belongs in L2TPEXT. For LDP, I wonder where it lies
sometimes....

> Perhaps the best way to think of this is

In L2TP, these would be AVPs sent in control messages. Right now, we have an
opaque (End Identifier) AVP that we insert a service-specific value in (perhaps
a VCid in some cases). As long as both sides agree on how to interpret this
identifier, this is sufficient for multiple applications (given that you can
encode the opaque value however you like, and assuming both sides are configured
accordingly). However, I think now that it would be advantageous to define an
additional "service application type" which is used and passed along with the
identifier so that advance agreement and configuration does not have to be
relied upon so heavily. Each type would then be defined based on how the
identifier is to be interpreted and used. The definition of this type is clearly
placed outside of the rhelm of L2TPEXT and (I hope) PWE3 as well. If LDP created
the same type of opaque constructs in TLVs, then I think in many cases we could
define what goes in them in a single place.