Subject: RE: IEEE 802.1ad and VPLS

From: "O'Connor, Don" <[email-masked]>
Date: Fri, 18 Apr 2003 09:41:54 -0500

Vach,

Are you suggesting that customer BPDUs should not be tunneled through the
provider VPLS network? If this is the case it would not be possible for
customers to run STP across multiple sites interconnected by the VPLS
network.

I agree with your point that it may also be possible to use L3 signaling for
MAC unlearn signaling especially for the case where bridging and MPLS are
supported in the same NE. This is relevant to my question pertaining to how
the L2 control plane interacts with the L3 control plane.

I think it would be good to have a more formalized liaison structure between
ppvpn and 802.1AD - maybe some common email 
list.

Don

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

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

> -----Original Message-----
> From: O'Connor, Don [mailto:[email-masked]]
> Sent: Thursday, April 17, 2003 3:55 PM
> To: [email-masked]'; O'Connor, Don; 'Serbest, Yetik';
> [email-masked]
> Cc: [email-masked]; 'Rick Wilder'; [email-masked]
> Subject: RE: IEEE 802.1ad and VPLS
>
>
> 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: Fri, 18 Apr 2003 08:23:52 -0700

I think we have agreed that tunneling BPDUs is going to be done.  I think that
over and above that, it may be possible to use L3 control plane mechanisms to
assist the convergence.  I'm only saying that it is possible that as we develop
some scenarios of customer and provider topologies, I don't want to assume that
the only solution lies in L2 protocols.

-Vach

> Sent: Friday, April 18, 2003 7:42 AM
> Cc: [email-masked]; 'Rick Wilder'; [email-masked];
> [email-masked]'; [email-masked]'

---

From: [email-masked]
Date: Fri, 18 Apr 2003 12:16:45 -0400 (EDT)

Vach,

So is the plan here to come up with a 802.1ad solution and a separate
ppvpn (L3 control plane) solution?  Or is this ppvpn committee going to
work with 802.1 to design a specific interoperable solution?  These
options are not mutually exclusive.

I am unclear as to how this effort is being organized beyond norm finn's
unofficial liason.

Thanks,
-Ben

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 18 Apr 2003 09:31:03 -0700

It's too early to say exactly how the pieces interact.  Initial discussions with
members in the IEEE (particularly Mick Seaman, Norm Finn, Tony Jeffree, Matt
Squire) have shown that they think that draft-lasserre-vkompella can fit in the
IEEE model.  On our side, the design team discussions have confirmed that.

The IEEE believes it takes some definition on their part, which is what 802.1ad
is.  Both 802.1ad and draft-lasserre-vkompella are "works in progress."  The
IEEE has clearly gotten far enough that they got a draft0.  We are still
deciding whether draft-lasserre-vkompella is a WG document or not.  I'd say,
when we get past that stage in the IETF, we can ask for formal liaisons.

That's why I've been pushing for IETF recognition that what we are working on
here in ppvpn is worth furthering.  I don't think the process calls for
everything to be nailed down before the IETF recognizes the work as its own
rather than an individual contribution.

As a final point, this has been a call to make draft-lasserre-vkompella a
working group document, nothing more.  I (fondly) think that phase has been
achieved, but I'll wait for official confirmation from the chairs.

-Vach

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 18, 2003 9:17 AM
> To: Vach Kompella
> Cc: O'Connor, Don; 'Serbest, Yetik'; [email-masked];
> [email-masked]; 'Rick Wilder'; [email-masked];
> [email-masked]; [email-masked]; Gerard Goubert

---

From: Matt Squire <[email-masked]>
Date: Mon, 28 Apr 2003 07:58:12 -0400

I apologize for jumping into this fray late, but I've been a wee bit 
behind in my email.

The good thing about the current structure of the vkompella draft (IMHO) 
is that we can, at the end of the day, treat the VPLS like a LAN 
segment.  So one could treat 802.1ad and VPLS independently, just as one 
can treat 802.1ad and Ethernet independently.

802.1ad can, at the edge, tunnel BPDUs over VPLS.  As VPLS looks like a 
LAN segment to 802.1, it can tunnel BPDUs and other things over a VPLS. 
  One can argue if thats a useful thing, but it can be done, as long as 
we continue with the VPLS=LAN model.

As far as the orgnization between the groups, its unclear how much more 
is needed.  Many people in 802.1 know whats happening in PPVPN, and 
vice-versa.  As emulating LAN segments has been done in the past (ATM, 
FR, etc.), and there weren't really any 802.1 specific issues to deal 
with in the past, I don't expect there will be with VPLS unless we 
deviate from the model of LAN emulation.

- Matt

Vach Kompella wrote:
>>>I think we have agreed that tunneling BPDUs is going to be done.  I
>>
>>think that
>>
>>>over and above that, it may be possible to use L3 control plane
>>
>>mechanisms to
>>
>>>assist the convergence.  I'm only saying that it is possible that
>>
>>as we develop
>>
>>>some scenarios of customer and provider topologies, I don't want to
>>
>>assume that
>>
>>>>I agree with your point that it may also be possible to use L3
>>
>>signaling for
>>
>>>>supported in the same NE. This is relevant to my question
>>
>>pertaining to how
>>
>>>>I think it would be good to have a more formalized liaison
>>
>>structure between
>>
>>>>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
>>
>>>>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
>>>>Service by IETF foo) and to deal with some of the 'loop through a
>>
>>customer'
>>
>>>>>unlearn signaling (for customer STP reconfiguration with
>>
>>backdoors, etc) -
>>
>>>>>then this will be incorporated in draft-lasserre by reference.
>>
>>Is this an
>>
>>>>>accurate perception?
>>>>>
>>>>>the official PAR date which is Dec. 31, 2002, so we (as IETF
>>
>>participants)
>>
>>>>>have
>>>>>Project authorization request (amendment to 802.1q VLANs) -
>>
>>enable a SP to
>>
>>>>>offer the equivalent of separate LAN segments, bridged or
>>
>>virtual bridged
>>
>>>>>>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
>>