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

Mark et al,

"W. Mark Townsley" wrote:

> 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).

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,

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

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
> subject of a "bridged network or network of bridges" debate. 
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.

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

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