Subject: RE: IEEE 802.1ad and VPLS

From: "O'Connor, Don" <[email-masked]>
Date: Mon, 28 Apr 2003 17:06:27 -0500

For Hierarchical VPLS, draft-lasserre indicates that the MTU-s can support
Q-in-Q. It would appear that the MTU-s could be a 802.1AD Provider Bridge or
could contain a Provider Bridge component. The draft also indicates that LDP
signaling can be used for distribution of Q tags. This raises the issue of
how does the MPLS control plane interface with the 802.1AD control plane to
support applications such as single ended provisioning? In theory the bridge
function in draft-lasserre PE-rs could be a 802.1AD Provider Bridge. This is
my perception of the "understanding" between of IETF PPVPN and IEEE 802.1.
It would seem like the service interface (E-ISS in IEEE 802.1 terms) between
the 802.1AD Provider Bridge function in the PE-rs and the LAN Emulation
function defined by draft-lasserre should be jointly defined / agreed by
IETF PPVPN and IEEE 802.1. There are other issues (e.g. bridge unlearn
signaling) that should ideally be defined across these two groups, otherwise
there could be multiple overlapping standards in the same area.  My view is
that: 1) draft-lasserre & other PPVPN working group drafts / eventual RFCs
need future updates to be consistent with / mesh with 802.1AD 2) the final
form of 802.1AD should correlate with PPVPN RFC(s) 3) More interaction is
required between PPVPN and IEEE 802.1 on issues such as described above. I
think this is potentially possible after: 1) PPVPN selects one or more
drafts to progress as WG documents 2) IEEE 802.1AD adds more detail to the
current draft. 

Don

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Monday, April 28, 2003 6:58 AM
To: [email-masked]
Cc: [email-masked]; O'Connor, Don; 'Serbest, Yetik';
[email-masked]; 'Rick Wilder'; [email-masked];
[email-masked]; [email-masked]; Gerard Goubert
Subject: Re: IEEE 802.1ad and VPLS

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:
> 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
> 
> 
>>-----Original Message-----
>>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
>>Subject: RE: IEEE 802.1ad and VPLS
>>
>>
>>
>>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
>>
>>On Fri, 18 Apr 2003, 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
>>
>>>the only solution lies in L2 protocols.
>>>
>>>-Vach
>>>
>>>
>>>>-----Original Message-----
>>>>From: O'Connor, Don [mailto:[email-masked]]
>>>>Sent: Friday, April 18, 2003 7:42 AM
>>>>To: [email-masked]'; O'Connor, Don; 'Serbest, Yetik';
>>>>[email-masked]
>>>>Cc: [email-masked]; 'Rick Wilder'; [email-masked];
>>>>[email-masked]'; [email-masked]'
>>>>Subject: RE: IEEE 802.1ad and VPLS
>>>>
>>>>
>>>>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

---

From: Matt Squire <[email-masked]>
Date: Tue, 29 Apr 2003 09:01:27 -0400

Its not like 802.1ad is re-defining bridging.  If you want to know if 
VPLS, or anything, will work with 802.1ad, then see if it works with 
802.1.  802.1ad is only doing a few clarifications and additions, but 
nothing earth shattering.

The issues you mention are valid things to talk about, and that have 
been talked about multiple times over.  And I'm not arguing that PPVPN 
should be inconsistent with 802.1, I generally argue exactly the 
opposite.  The final form of 802.1ad should be consistent with the 
historical approach to bridging, and I'm sure it will be.   Anything 
above/outside the bridging layer including PPVPN should be consistent 
with 802.1, but that doesn't really put any put any restriction on 802.1 
any more than MPLS required cooperation with Ethernet.

The communication you seem to be asking for has happened and continues 
to happen as there are a number of 802.1 people that have given input to 
  various PPVPN drafts, and there are more IETF people showing up in the 
802.1 meetings every time.  So its already happening, formally and 
informally.

I'm not saying any of the VPLS drafts are perfect, and people are 
commenting on them all the time.  And when they suggest violating the 
layering principal (e.g. signaling Q-tags with LDP), its generally a bad 
thing.  And those will all come out during the comment reviews if not 
before.

- Matt