Subject: RE: IEEE 802.1ad and VPLS

From: "O'Connor, Don" <[email-masked]>
Date: Thu, 17 Apr 2003 17:54:31 -0500

Vach,

To confirm the relationship with draft-lasserre - when 802.1AD defines
solutions for issues such as Provider Bridge customer BPDU snooping /
unlearn signaling (for customer STP reconfiguration with backdoors, etc) -
then this will be incorporated in draft-lasserre by reference. Is this an
accurate perception?

One issue I have been wondering about with respect to 802.1AD & PPVPN /
draft-lasserre is for single ended L2 VPN
provisioning, where will the interface between the L2 Control Plane (defined
by IEEE 802.1AD) and the L3 Control Plane (defined by PPVPN / PWE3) be
defined.

Don

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]]
Sent: Thursday, April 17, 2003 5:06 PM
To: O'Connor, Don; 'Serbest, Yetik'; [email-masked]
Cc: [email-masked]; 'Rick Wilder'; [email-masked]
Subject: IEEE 802.1ad and VPLS

Dan,

Yes it is.  One of the items in the ppvpn-wg minutes (note the date
pre-dates
the official PAR date which is Dec. 31, 2002, so we (as IETF participants)
have
been keeping in touch with the IEEE, albeit informally) for the Atlanta
meeting
shows:

=== clipped from minutes ===
Norm Finn - IEEE 802.1 unofficial liaison
-----------------------------------------

Project authorization request (amendment to 802.1q VLANs) - enable a SP to
offer the equivalent of separate LAN segments, bridged or virtual bridged
LANs (network of bridges doing l2vpn type services).

Name of project - 802.1AD.
MAC-in-MAC not possible with this amendment.

Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc
if mailing discussions are carried through.
=== end of clip ===

-Vach

> -----Original Message-----
> From: O'Connor, Don [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 1:54 PM
> To: 'Serbest, Yetik'; [email-masked]'
> Cc: [email-masked]'; 'Rick Wilder'; [email-masked]
> Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft
>
>
> Yetik & Cheng-Yin,
>
> Isn't the PPVPN group in theory working with the 802.1AD Provider Bridge
> Group to define solutions for these issues.
>
> Regards,
>
> Don
>
> -----Original Message-----
> From: Serbest, Yetik [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 2:58 PM
> To: [email-masked]'
> Cc: [email-masked]'; 'Rick Wilder'; [email-masked]
> Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft
>
>
> Cheng-Yin,
>
> When a draft becomes a working group document, that does not mean we stop
> working on it. Your point is good, and we will work on the issue. There
was
> some preliminary discussion among the authors; and when we have some
> conclusions, we will share them with the group. There are some other
issues
> as well.
>
> In DT, as you see from the mail (dated 2/6/2003) below I raised that
issue.
>
> ".....Anyway, as long as we move on and reach the time when we discuss how
> to support dual-homed CEs or customers with backdoor links, and how to
> troubleshoot the service when q or qinq spokes are present etc... I am
fine
> with it."
>
> Thanks,
> yetik
>
> -----Original Message-----
> From: Cheng-Yin Lee [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 2:02 PM
> To: Serbest, Yetik
> Cc: [email-masked]'; 'Rick Wilder'; [email-masked]
> Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft
>
>
> Yetik,
> As an one of the editor of draft-augustyn-ppvpn-l2vpn-requirements-02.txt,
I
> assume you care about the requirements in that draft. From the
requirements
> draft, Section 5.8: "In case of VPLS, the L2VPN service MUST ensure that
> loops be prevented."
>
> I agree that it is a fundamental requirement that bridging loops be
handled
> in a VPLS solution. As we know loops can have a devastating effect on a
> bridged network.
>
> So, has this point been carefully considered for the VPLS drafts being
> proposed to be progressed?
>
> I think the VPLS drafts being considered here (using full-meshed with
> split-horizon) are not able to handle common scenarios/requirements
leading
> to loops and causing network meltdowns.
>
> This point has been raised before by several people but it still has not
> been addressed. If this mandatory requirement (not a minor detail or rare
> scenario) is not addressed and we still progress these drafts what is the
> message to the industry? That it's ok to continue pushing solutions that
> don't meet fundamental requirements?
>
> Thanks,
> Cheng-Yin
>
> "Serbest, Yetik" wrote:
> >
> > I would like to second that.
> >
> > Thanks,
> > yetik
> >
> > -----Original Message-----
> > From: Matt Squire [mailto:[email-masked]]
> > Sent: Tuesday, April 15, 2003 7:08 AM
> > To: 'Rick Wilder'
> > Cc: [email-masked]
> > Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group
> > draft
> >
> > The Laserre/VKompella draft should definitely progress as a working
> > group draft.  Its a solid technical contribution with a lot of support
> > behind it.
> >
> > - Matt
> >
> > Olen Stokes wrote:
> > > I would also like to support making this a working group draft.
> > >
> > > Cheers,
> > > Olen
> > >
> > >     -----Original Message-----
> > >     *From:* Rick Wilder [mailto:[email-masked]]
> > >     *Sent:* Thursday, April 10, 2003 11:20 AM
> > >     *To:* [email-masked]
> > >     *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group
> > > draft
> > >
> > >     As noted in the minutes, at the San Francisco meeting strong
> > >     interest was expressed in pursuing the
> > >     "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We
> > >     agreed to finalize that decision only after the WG participants
who
> > >     weren't there could have a say.
> > >
> > >
> > >
> > >     So, if there are opinions that have not been heard, now is the
time,
> > >     and this list is the place. Let's set a one-week limit to conclude
> > >     this issue.
> > >
> > >
> > >
> > >     Rick
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > ----------------------------------------------------------------------
> > > -------
> > >
> > >      From the minutes:
> > >
> > >
> > >
> > >     Alex: For a document to become a WG draft, it doesn't have to be
> > >     100% correct.  It can become a WG document if it is a good
> > > start.
> > >
> > >     Matt: I wanted to make the same comment.
> > >
> > >
> > >     [snipped]
> > >
> > >      Marco: asked for show of hands to make this a wG draft.
> > >     Strong interest was shown in room. Further discussion on the
> > > list.
> > >
> > >
> > >
>
>
>
>

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 17 Apr 2003 16:20:15 -0700

Dan,

It isn't clear to me yet that the only reliable way to deal with L2 control
protocol packets such as BPDUs is to pass them through the data plane of the
VPLS.  It is possible that one of the ways to deal with unlearns, e.g., is to
use LDP messages, such as the MAC TLVs for specific or scoped unlearns.  So, if
"by reference" means that we don't assist the L2 solution with extensions to the
VPLS signaling draft, then I disagree.  If it means cooperative use of the L3
control plane with the IEEE work, I agree.  Basically, we don't want to
re-invent what is already there, but when we have L3 control plane methods
available, it makes sense to figure out a division of work that makes the
service work the best.

From Clause 16 of the 802.1ad-d0 document:
... (stuff dealing with a potential topology with loops) ... requires an IETF
connection (see also suggested Clause 6.6 Support of the Internal Sublayer
Service by IETF foo) and to deal with some of the ‘loop through a customer’
questions and the partial answers that we have to those.

-Vach

> Sent: Thursday, April 17, 2003 3:55 PM
> To: [email-masked]'; O'Connor, Don; 'Serbest, Yetik';
> [email-masked]
> Subject: RE: IEEE 802.1ad and VPLS
>
>
> Vach,
>