Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00

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

cc'ing ppvpn

Cheng-Yin Lee wrote:
> 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?

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

> 
> Sorry, I have to go now, but will catch up with this later.
> 
> thanks
> cheng-yin
> 
> Stewart Bryant wrote:
> 
> 
>>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
>>
>>Cheng-Yin Lee wrote:
>>
>>>Stewart,
>>>
>>>Stewart Bryant wrote:
>>>
>>>
>>>
>>>>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?
>>>
>>>
>>>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.
>>>
>>>
>>>
>>>>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
>>>>
>>>>Cheng-Yin Lee wrote:
>>>>
>>>>
>>>>>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
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>pwe3 mailing list
>>>>>[email-masked]
>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
>>>>>
>>>>>
>>>>
>>>
>>>
>>_______________________________________________
>>pwe3 mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

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

---

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

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 8 Nov 2002 17:48:00 +0000 (GMT)

> (e.g. a bird is a mammal, but a mammal is not necessarily a bird).

Birds aren't mammals. Lactating (monotremes lay eggs, but lactate,
making them mammals) distinguishes mammals; hair's a secondary
characteristic of mammals.

Avians and mammals are vertebrates, if that helps.

> May I know if this type of logic is acceptable?

Reasoning by entirely false analogy to confuse a point you're trying
to make while waving undefined abbreviations around? (PPVPL?)

Oh, absolutely. It's a longstanding tradition, and the only way
anything ever gets done around here.

As for logic, you might want to figure out your propositions (the
major premise and the minor premise), your syllogism, and your
fallacies.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

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

Llyod,
Thanks for your clarifications.

To get back to my original point, let me try with another example :

An emulated LAN is not necessarily a PPVPL (Provider Provisioned Virtual
Private LAN).
(e.g. a human is a mammal, but a mammal is not necessarily a human).
 
regards
cheng-yin

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 8 Nov 2002 21:52:46 +0000 (GMT)

> Thanks for your clarifications.

No, thank _you_, for giving me the opportunity to be on-topic _and_
talk about breasts.

L.

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 10 Nov 2002 01:34:56 +0000

> An emulated LAN is not necessarily a PPVPL (Provider Provisioned Virtual

What specific details of the PPVPL and / or PWE3 drafts prevent you from
deploying the system that you desire to build?

What features are missing?

What features are you prevented from turning off?

What features must be done differently?

Have you already documented the specific issues, if so, please could you
remind me of the mail, or refer me to a draft?

Regards

Stewart