Subject: Re: Re: Comments to draft-ietf-pwe3-arch-00

From: "Cheng-Yin Lee" <[email-masked]>
Date: 1 Nov 2002 14:13:02 -0500

Danny,
I was referring to Ethernet specifically in my previous email
http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03096.html
The Ethernet 'wire' inherently allows broadcasting. In my view, a bridge emulates
an Ethernet 'wire'. OTOH, whether bridging is done at PE/L2PE/CE, I believe, is
out of the scope of PWE3.

For services where multipoint transmission is not a property of the "wire", I
agree multipoint discussion is out of scope.

thanks
cheng-yin

Danny McPherson wrote:

> > Creating  a  multi-point system  out  of p2p  wires  is  definitely a  PPVPN
> > function  rather  than a  PWE3  function.  But  that  doesn't  rule out  the
> > possibility of PWE3 defining a p2mp wire of some sort.  Whether such a thing
> > is actually needed is an open question.
>
> I tend to agree with Eric here and would like to see some
> discussion of drivers for the work.
>
> > I think this should just be punted for now, left "for further study".
>
> My first inclination is to agree.  However, begin that there is
> apparent interest and it's technically chartered (at least in the
> case of Ethernet), we should at least give it some opportunity for
> consideration.
>
> I'd be interested in what others think...
>
> -danny
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Nov 2002 19:55:31 +0000

Cheng-Yin

To clarify: the sort of thing that you have in mind is to
explicitly cover the multicasting of Ethernet over the WAN
using something like IP or MPLS multicast?

Although this is not explicitly called out, you can do this
with the specs as they exist today, by for example, using
L2TPv3 in manual configuration mode and using an IP multicast
address as the IP DA.

Is there anyone who has an application for this mode?

The only use that I can see for this is to avoid replication
of broadcast packets when building a L2VPN, but I am not sure
the saving in packet replication justifies the complexity of
effectively running two parallel PW networks (ie the broadcast
network plus the point to point mesh). However that is a call
that the PPVPN WG need to make.

Regards

Stewart

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 1 Nov 2002 15:09:48 -0500

Stewart,

> using something like IP or MPLS multicast?

No, No, No !  :-).  I agree with you that "I am not sure the saving in packet
replication justifies the complexity ..."

I meant something like in draft-lee-l2tpext-pwe3-vpl-00.txt,  encapsulating Ethernet in
L2TPv3 and bridging at an LCCE.
A side note is that a PPVPN/PPVPL may have additional requirements besides the
emulation of an Ethernet wire.

regards,
cheng-yin.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Nov 2002 21:01:28 +0000

As I read this draft you are setting up individual PWs using
L2TP and then bridging across them. The bridging function
belongs in the FWRD component. I was working on the assumption
that FWRD was outside the scope of PWE3 (I had assumed that it
belonged to PPVPN). I am not sure why we would move it back in
scope, and if we did how we would set the demarcation with
PPVPN.

The present (implicit) restriction of PW to pt-pt Ethernet
provides a clean functional divide between transmission
and forwarding.

Stewart

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 1 Nov 2002 16:20:15 -0500

Stewart,
Just some quick points:
As I see it, a bridge emulates an Ethernet wire, a PPVPL would then be an application of this
ethernet pseudo wire service, and would have additional requirements e.g.  VPL/endpoints
discovery, among others. Mark Townsley may have articulated the latter point before?

Sorry, I have to go now, but will catch up with this later.

thanks
cheng-yin

---

From: "Nick Tingle" <[email-masked]>
Date: Fri, 1 Nov 2002 12:48:34 -0800

The problem with building a multipoint system such as VPLS out of p2p PWE3 wires
is that you can't take advantage of things you might get with multipoint wires
such as high performance multicast (using p2mp tunnels e.g. IP multicast) or n^2
scaling avoidance (with mp2p tunnels e.g. merging LSPs).

Such a multipoint Ethernet pseudowire would be pointless unless it did MAC
address learning (there's little point IMO in emulating a broadcast Ethernet
segment in which every packet goes to every node). Then you'd end up having to
sort out the emulated lan/brige issues that PPVPN are working on in VPLS.

I too think it's best left "for further study".

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Danny
> McPherson
> Sent: Friday, November 01, 2002 7:20 AM
> To: PWE3 WG (E-mail)
> Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Nov 2002 23:24:06 +0000

Cheng-Yin Lee wrote:
> Stewart,
> Just some quick points:
> As I see it, a bridge emulates an Ethernet wire, 

A bridge is much more a L2 router than a wire emulator.
A wire does not do filtering, blocking, spanning tree etc.

> a PPVPL would then be an application of this
> ethernet pseudo wire service, 

True, and there is a gap in the way that we have things
laid out, because PPVPN is defining something much
more complex.

If there is a requirement for a basic bridge without the
full gamit of PPVPL stuff, then it's still not clear to
me whether this is a PWE3plus problem or a PPVPNminus
problem (ie indeed whether we should be asking the IEEE
to do some of this stuff).

Stewart

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 2 Nov 2002 08:52:21 -0500

Stewart,

> laid out, because PPVPN is defining something much
Agree. 

> to do some of this stuff).
I believe the questions are, what does an Ethernet wire support, and
what should an Ethernet pseudo-wire support.
"Ethernet transmission to a "multicast" IEEE-48 address is in scope" is
in the PWE3 charter and I believe it's in the charter for the right
technical reason.

regards
cheng-yin

---

From: Eric Rosen <[email-masked]>
Date: Mon, 04 Nov 2002 14:31:29 -0500

> I meant something like in draft-lee-l2tpext-pwe3-vpl-00.txt,

In that  draft, the emulated LAN  is created by  interconnecting MAC address
forwarders with point-to-point pseudowires.  This pretty clearly falls under
the scope  of PPVPN,  where there  are a number  of much  more comprehensive
drafts on the topic.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 05 Nov 2002 00:48:46 -0800

cc'ing ppvpn

> discovery, among others. Mark Townsley may have articulated the latter point before?

I will re-iterate and expound based on the current discussion.

Auto-discovery for L2VPNs are clearly within the rhelm of PPVPN.

Wire properties are defined within PWE3 (and any L2TP-specific support for such 
within l2tpext).

P2MP wire properties fall within the "could" rhelm of PWE3 (as chartered), and 
the discussion on this thread has been more about whether they "should" or not. 
Most of the current mindshare on this topic is within PPVPN, particularly on the 
subject of a "bridged network or network of bridges" debate.

Cheng-yin, if I understand your problem with defining your work within ppvpn, it 
is that the application of the lee-l2tpext draft you cited on this thread are 
ce-based vpns defined in draft-lee-ce-based-vpl-00.txt, which quite specifically 
leaves the first "p" in ppvpn out of the equation. That said, ppvpn has already 
tackled some ce-based VPNs via IPsec, though this is a L3 approach and certainly 
does not include VPLS. It is not clear to me whether your ce-based solution is 
provider or customer provisioned. If provider-provisioned, than from ppvpn's 
perspective, there is a pretty decent argument for your work under a L2VPN 
CE-based architecture heading, similar in spirit to that for L3VPNs defined in 
draft-ietf-ppvpn-framework-06.txt. If customer-provisioned, the topology doesn't 
change too terribly much, but the language in the document certainly would.

I can certainly understand some level of frustration with the l2vpn work in 
ppvpn to date, and the desire to bypass it on grounds that your work is not 
provider-equipment based. However, there has been some very recent work by the 
l2vpn design team, which yielded a posting to the ppvpn list within the past 24 
hours. There is some very good discussion behind this, and it would be a shame 
for application not to fit within this framework.

So, to the WGs I would ask, where do CE-based L2VPNs lie? I would prefer within 
the same group working on the larger issue of ppvpns. This would require at 
least a section detailing how it looks when the PE and the CE are collapsed into 
a single box, and perhaps any associated provider-specific requirements are 
adjusted to "customer"-specific requirements.

Would the ppvpn WG be willing to cover this (with Cheng-yin's help, of course!)?

Thanks,

- Mark

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 5 Nov 2002 20:57:12 -0500

Mark et al,

> Wire properties are defined within PWE3 (and any L2TP-specific support for such

I think the first and most fundamental question then is what is an
Ethernet pseudo-wire.
The PWE3 WG charter alluded this:
"Ethernet transmission to a "multicast" IEEE-48 address is in scope"
We may choose to ignore this inherent aspect of Ethernet transmission,
and do the work in PPVPN, but,

> Most of the current mindshare on this topic is within PPVPN,

the next point that I should reiterate then is an Ethernet pseudo-wire
may not necessarily be a PPVPL.

In addition, I think there are advantages in partitioning the Ethernet
pseudo-wire aspects from PPVPL (which has many additional requirements).
An Ethernet pseudo-wire may also be used in different applications.

> particularly on the
As I see it, many of the issues raised in "Bridging network or networked
bridges" email are related to bridging customers' traffic in the
provider's network, a smaller number of issues are independent of
whether the VPL is customer or provider provisioned, some are in IEEE
realm, while others are implementation details. 
Hence it looks like it is even more important to partition these
different issues and problems - it is easier to focus on a scoped
problem.

> adjusted to "customer"-specific requirements.
Strictly speaking, PPVPN is only for provider provisioned VPN, but I
think what you suggest is good way to reuse some of the work in PPVPN.

On work partitioning, I still think it's better to partition Ethernet
pseudo-wire from the applications because of the reasons I gave above
and in previous email.

thanks
cheng-yin

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 06 Nov 2002 19:12:54 +0000

Cheng-Yin

> in the PWE3 charter and I believe it's in the charter for the right

I have been mulling this over. The implicit definition of an Ethernet
wire that has been used in the PWE3 work so far is an Ethernet
attachement point, ie a Cat5 cable (or AUI cable or the middle leg of
a coax T).

Given that none of us are suggesting unfiltered multicast, that would
sufficient provided we can emulate everything that we want using it.

Perhaps we should make this definition of an ethernet wire explicit
somewhere?

Now we get to the issue of emulating a bridged/switched network
(given that we agreed above that we are not doing multicast, we
are doing filtering/learning and therefore we are emulating one
or more bridges).

Can we agree that we emulate such a network by using our ethernet
wire definition above and run some function in the NSP and FWRD
functions to complete the emulation?

If so, that leads us to the definition of these functions and where
they should be defined.

As I understand things, the protocols being defined by PPVPN could be
used between user equipment (by making the their PE function run on a
CE box) without explicit support from the SP. Is that correct?

If so, then surely we should just use their work to implement such
functions, and end this discussion.

However if we do not think that PPVPN are satisfying the requirements,
then we need to document the short-commings, before desciding whether
the work item is a PWE3 issue or a PPVPN issue.

Have I sumarised this correctly?

Regards

Stewart

---

From: Eric Rosen <[email-masked]>
Date: Wed, 06 Nov 2002 14:30:17 -0500

Stewart> As I understand things, the  protocols being defined by PPVPN could
Stewart> be used between user equipment (by making the their PE function run
Stewart> on a CE box) without explicit support from the SP. Is that correct? 

Yes.  There is nothing inherent in  any of the L2VPN protocols (or the L3VPN
protocols for that matter) which prevents their being run on equipment which
is not owned by a service provider.

Stewart> If so, then surely we should  just use their work to implement such
Stewart> functions, and end this discussion.

Stewart> However  if  we  do  not   think  that  PPVPN  are  satisfying  the
Stewart> requirements, then  we need to document  the short-commings, before
Stewart> desciding whether the work item is a PWE3 issue or a PPVPN issue.

Stewart> Have I sumarised this correctly?

I think  you have  it just  right -- until  someone actually  articulates an
"emulated LAN" issue which is not  being worked in PPVPN, there really isn't
anything to discuss.

---

From: "Mitsuru Higashiyama" <[email-masked]>
Date: Thu, 7 Nov 2002 23:27:34 +0900

Hi Mark,

I have a questions.

> subject of a "bridged network or network of bridges" debate.

P2MP wire discussion will be in PPVPN and return back to PWE3 if there is
request to packet format. Is it correct ?

> adjusted to "customer"-specific requirements.

I would like PPVPN deal with CE-base include multi-point issue.

Thanks,
Mitsuru

> >>>I meant something like in draft-lee-l2tpext-pwe3-vpl-00.txt,
encapsulating Ethernet in

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 07 Nov 2002 19:31:46 +0000

> request to packet format. Is it correct ?

That looks to me to be the best way forward to me.

Stewart

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 7 Nov 2002 16:28:12 -0500

Stewart,
Thanks for taking my comments into consideration. Some comments inline.

> Perhaps we should make this definition of an ethernet wire explicit

I am not sure what  is being defined above.  I don't believe it's up to the
PWE3 WG to redefine Ethernet. Ethernet has already been defined.
In Ethernet I know, regardless of whether a node is connected to a segment,
hub or a switch (via any of the cable you mentioned) , the node can transmit
to multiple nodes.

regards
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 8 Nov 2002 12:03:15 -0500

Stewart et al,

An emulated LAN is not necessarily a PPVPL.
(e.g. a bird is a mammal, but a mammal is not necessarily a bird).

May I know if this type of logic is acceptable?

thanks
cheng-yin