Subject: VPLS Architecture

From: Shane Amante <[email-masked]>
Date: Thu, 24 Jul 2008 11:51:10 -0600

Recently, a significant number of drafts have been submitted, and 
discussed, to address incorporating 802.1ag, 802.1ah and other IEEE/ITU 
protocols within the VPLS Architecture.  These drafts appear to largely 
be: a) a re-specification of how IEEE protocols work over top of a VPLS; 
or, b) how IEEE protocols inter-work with other IEEE data-plane formats 
within a VPLS (or PWE3's).  In addition, for completeness, there is a 
question which L2VPN hasn't addressed: the potential for inter-working 
Native Service Layer control protocols from the IEEE/ITU with those 
created and maintained by L2VPN.

With respect to the first question (re-specification of other SDO's 
protocols), there are a significant number of concerns.  Specifically, 
when protocols from another SDO are re-specified within the IETF, there 
is the potential for errors or omissions to be introduced.  In general, 
there is likely to be insufficient expertise widely available within the 
IETF to review those drafts, in-depth, for accuracy or "faithfulness" to 
the original SDO's standard as they progress through the IETF standards 
process.  Finally, there is always the [unanswered] question of what 
SDO's document is considered authoritative in case a conflict, error or 
omission develops.  In summary, there is both little value and 
significant risk in widespread re-publication of IEEE/ITU specifications 
within the L2VPN WG.  In a well written draft, Normative References to 
another SDO's detailed architecture, protocol or technology documents 
should be more than adequate, and seems to have worked well, so far, 
particularly in the cases of VPLS-LDP [RFC 4762] and VPLS-BGP [RFC 4761] 
to cite just two examples.

On the other hand, the second and third questions, both raise 
significant concerns about the current and future architecture of VPLS.

With respect to the second question (interworking of two IEEE data-plane 
protocols within a VPLS), L2VPN (via PWE3 WG) seems to have gone down a 
path of just defining a new PW type for a new IEEE data-plane (i.e.: 
draft-martini-pwe3-802.1ah-pw-02), most likely based on past precedent 
of raw and tagged Ethernet PW types, which were originally specified as 
such to make up for hardware limitations at the time.  Instead, the 
(much) larger question that should be asked is: why can't the VPLS 
architecture *seamlessly* support existing/legacy and new Ethernet 
data-plane formats concurrently?  In other words, what is lacking in the 
current emulation of PW's that needs to be fixed in order to provide 
more seamless carriage of Ethernet frames within a VPLS, so that the 
VPLS architecture can remain agnostic to current and future IEEE 
data-plane protocols?

Related to this last point, a number of people have put together the 
following draft specifying a "Generic Ethernet PW", 
<http://tools.ietf.org/html/draft-vkompella-pwe3-ethernet-pw-bis-01>, 
whose purpose is to re-cast Ethernet PW's back into a generic Ethernet 
transport mechanism, (as was originally desired).  In doing so, 
processing related to the "normalization" of Ethernet frames is then 
shifted back into the ingress or egress PW Native Service Processing 
(NSP) functions.  From an architecture standpoint, the NSP function has 
direct (configured) knowledge of the incoming/outgoing data-plane format 
as well as any associated actions that need to be performed when 
receiving from or transmitting to the AC.  This would allow a (Generic 
Ethernet) PW and, consequently, VPLS to (again) remain agnostic as to 
the Ethernet data-plane, thus allowing seamless support of existing and 
emerging (or, even, future) IEEE data-plane protocols.

Finally, there is the third question (inter-working of Native Service 
Layer (NSL) control protocols with VPLS).  One component of the VPLS 
Architecture, is a "Bridge Module", which is equivalent to a PW NSP[1]. 
  Furthermore, within the L2VPN Framework [RFC 4664], Section 2.2, it is 
noted that "precise functionality that the bridge modules must have in 
particular circumstances is, however, out of scope of the current 
document".  In other words, the VPLS architecture should be oblivious to 
Native Service Layer control protocols entering, exiting or processed 
within the Bridge Module.  The main reason for this is to avoid 
re-specification of other SDO's protocols.  A secondary reason is to 
avoid unnecessary and uncomfortably tight coupling of other SDO's NSL 
control protocols with those specified and maintained within the IETF 
L2VPN (or PWE3) WG's.  Finally, this allows end-users and implementers 
to expect the NSL Layer-2 Control Protocols operating within the Bridge 
Module (or, PW NSP) to remain "faithful" to the original SDO's 
specification of those L2 control protocols.

In summary, we believe that the architecture of VPLS (and PW's) should 
remain agnostic to the underlying data-plane, in order to simplify the 
overall architecture and /operation/ of VPLS.  Therefore, as co-chairs, 
we will be placing overwhelming scrutiny on **all** drafts within the 
L2VPN WG, going forward, in order to avoid re-specification of other 
SDO's standards even as Informational Drafts.  Furthermore, we also will 
be guiding the WG to look at the fundamental architecture of VPLS, and 
its underlying PW's, to *first* determine what are the /requirements/ to 
ensure VPLS remains agnostic to data-plane protocols.  Eventually, that 
should lead to specific enhancements/solutions to IETF protocols (VPLS 
and/or PW's) in order that we have the most straightforward 
implementations of VPLS, which are able to accommodate both present and 
future data-plane protocols, thereby increasing the longevity of VPLS 
implementations and deployments.  Also, just to be clear, this latter 
task will most likely require careful coordination between both the 
L2VPN and PWE3 WG's, since PWE3 is an integral part of the VPLS 
architecture and own/maintain key elements of VPLS control, signaling 
and encapsulation formats.

Thanks,

-shane & Vach
co-chairs of L2VPN WG

[1] The following is defined within PWE3 Architecture [RFC 3985]:
---snip---
    Native Service Processing (NSP): Processing of the data received by
    the PE from the CE before presentation to the PW for transmission
    across the core, or processing of the data received from a PW by a PE
    before it is output on the AC.  NSP functionality is defined by
    standards bodies other than the IETF, such as ITU-T, ANSI, or ATMF.)
---snip---
In the context of this conversation, it is important to note that "NSP 
functionality is defined by standards bodies other than the IETF".

[2] If we step back and look at history, the SUBIP and, subsequently, 
PWE3 WG's were clear about **not** providing perfect emulation of a 
Native Service over an MPLS PSN.  In fact, if one refers to the PW 
encapsulation RFC's for Frame Relay [RFC 4619], ATM [RFC 4717] and 
Ethernet [RFC 4448] there is a clear "Applicability Statement" in 
Section 3 of all RFC's, where this is pointed out.  In addition, it 
points out in a very concise manner, "notable differences" between the 
traditional Native Service and the new <FOO> over PW service.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 24 Jul 2008 17:38:02 -0700

Shane,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Thursday, July 24, 2008 10:51 AM
> To: [email-masked]
> Subject: VPLS Architecture
> 
> Recently, a significant number of drafts have been submitted, 
> and discussed, to address incorporating 802.1ag, 802.1ah and 
> other IEEE/ITU protocols within the VPLS Architecture.  These 
> drafts appear to largely
> be: a) a re-specification of how IEEE protocols work over top 
> of a VPLS; or, b) how IEEE protocols inter-work with other 
> IEEE data-plane formats within a VPLS (or PWE3's).  In 
> addition, for completeness, there is a question which L2VPN 
> hasn't addressed: the potential for inter-working Native 
> Service Layer control protocols from the IEEE/ITU with those 

Can you be more precise on which drafts you are talking about. It is
hard to formulate a response to your comments without knowing what
drafts you mean specifically. 

> With respect to the first question (re-specification of other 
> SDO's protocols), there are a significant number of concerns. 
>  Specifically, when protocols from another SDO are 
> re-specified within the IETF, there is the potential for 
> errors or omissions to be introduced.  In general, there is 
> likely to be insufficient expertise widely available within 
> the IETF to review those drafts, in-depth, for accuracy or 
> "faithfulness" to the original SDO's standard as they 
> progress through the IETF standards process.  Finally, there 
> is always the [unanswered] question of what SDO's document is 
> considered authoritative in case a conflict, error or 
> omission develops.  In summary, there is both little value 
> and significant risk in widespread re-publication of IEEE/ITU 
> specifications within the L2VPN WG.  In a well written draft, 
> Normative References to another SDO's detailed architecture, 
> protocol or technology documents should be more than 
> adequate, and seems to have worked well, so far, particularly 
> in the cases of VPLS-LDP [RFC 4762] and VPLS-BGP [RFC 4761] 

I concur. There should be no reason for the re-specification of IEEE
drafts for many reasons some of which you have mentioned above. As the
matter of fact in my pbb-interop draft, I put a short primer on PBB in
the Appendix for just this purpose so that any re-specification be
avoided in the main body of the draft. And I was told by many people
that this one page primer was very helpful to them.

> With respect to the second question (interworking of two IEEE 
> data-plane protocols within a VPLS), L2VPN (via PWE3 WG) 
> seems to have gone down a path of just defining a new PW type 
> for a new IEEE data-plane (i.e.: 
> draft-martini-pwe3-802.1ah-pw-02), most likely based on past 
> precedent of raw and tagged Ethernet PW types, which were 
> originally specified as such to make up for hardware 
> limitations at the time.  Instead, the
> (much) larger question that should be asked is: why can't the 
> VPLS architecture *seamlessly* support existing/legacy and 
> new Ethernet data-plane formats concurrently?  In other 
> words, what is lacking in the current emulation of PW's that 
> needs to be fixed in order to provide more seamless carriage 
> of Ethernet frames within a VPLS, so that the VPLS 
> architecture can remain agnostic to current and future IEEE 
> data-plane protocols?
> 

"raw" and "tagged" modes were debated many times since the genesis of
PWE3 and the WG decided on using them as specified and we got not RFC in
both PWE3 and L2VPN regarding their applications. Are you suggesting
that we start from square one again ??

Also, I think a point may be getting missed here with respect to L2VPN
services using these PWs. The type of the PW frankly is not as important
as having the two sides agree on exchanging the same packet format and
agree on the interpretation of such format; whether that is done
explicitly or implicitly (via PW type) is a small point. The precedence
for last seven years has been explicit indication via PW type (e.g., raw
mode versus tagged mode).    

> Related to this last point, a number of people have put 
> together the following draft specifying a "Generic Ethernet 
> PW", 
> whose purpose is to re-cast Ethernet PW's back into a generic 
> Ethernet transport mechanism, (as was originally desired).  
> In doing so, processing related to the "normalization" of 
> Ethernet frames is then shifted back into the ingress or 
> egress PW Native Service Processing
> (NSP) functions.  From an architecture standpoint, the NSP 
> function has direct (configured) knowledge of the 
> incoming/outgoing data-plane format as well as any associated 
> actions that need to be performed when receiving from or 
> transmitting to the AC.  This would allow a (Generic
> Ethernet) PW and, consequently, VPLS to (again) remain 
> agnostic as to the Ethernet data-plane, thus allowing 
> seamless support of existing and emerging (or, even, future) 
> IEEE data-plane protocols.
> 

There are pros/cons for this where we can discuss in the PWE3 or L2VPN
sessions but frankly I don't think of this explicit v.s. implicit PW
type indication as a significant one which deserves such attention and
being made center piece of "VPLS architecture".  

> Finally, there is the third question (inter-working of Native 
> Service Layer (NSL) control protocols with VPLS).  One 
> component of the VPLS Architecture, is a "Bridge Module", 
> which is equivalent to a PW NSP[1]. 
>   Furthermore, within the L2VPN Framework [RFC 4664], Section 
> 2.2, it is noted that "precise functionality that the bridge 
> modules must have in particular circumstances is, however, 
> out of scope of the current document".  In other words, the 
> VPLS architecture should be oblivious to Native Service Layer 
> control protocols entering, exiting or processed within the 
> Bridge Module.  The main reason for this is to avoid 
> re-specification of other SDO's protocols.  A secondary 
> reason is to avoid unnecessary and uncomfortably tight 
> coupling of other SDO's NSL control protocols with those 
> specified and maintained within the IETF L2VPN (or PWE3) 
> WG's.  Finally, this allows end-users and implementers to 
> expect the NSL Layer-2 Control Protocols operating within the 
> Bridge Module (or, PW NSP) to remain "faithful" to the 
> original SDO's specification of those L2 control protocols.
> 

The nature of service being offered in VPLS (e.g., qualified v.s.
non-qualifed modes) affect the interaction with some of these bridging
protocols which needs to be captured. If there was no affect, I would
have agreed with you but if there is an impact then we need to at least
specify what we expect from this magic box (bridge module). Regarding
how it is done, it can simply be referred to IEEE spec. Remember that
VPLS (as a service) is defined among a set of Attachment Circuits !!

> In summary, we believe that the architecture of VPLS (and 
> PW's) should remain agnostic to the underlying data-plane, in 
> order to simplify the overall architecture and /operation/ of 
> VPLS. Therefore, as co-chairs, we will be placing 
> overwhelming scrutiny on **all** drafts within the L2VPN WG, 
> going forward, in order to avoid re-specification of other 
> SDO's standards even as Informational Drafts.  Furthermore, 
> we also will be guiding the WG to look at the fundamental 
> architecture of VPLS, and its underlying PW's, to *first* 
> determine what are the /requirements/ to ensure VPLS remains 
> agnostic to data-plane protocols.  Eventually, that should 
> lead to specific enhancements/solutions to IETF protocols 
> (VPLS and/or PW's) in order that we have the most 
> straightforward implementations of VPLS, which are able to 
> accommodate both present and future data-plane protocols, 
> thereby increasing the longevity of VPLS implementations and 
> deployments.  Also, just to be clear, this latter task will 
> most likely require careful coordination between both the 
> L2VPN and PWE3 WG's, since PWE3 is an integral part of the 
> VPLS architecture and own/maintain key elements of VPLS 
> control, signaling and encapsulation formats.
> 

I think we first need to decide whether we are going to rehash all the
PW type discussion all over again and change the application of existing
"raw" and "tagged" mode as being defined in both PWE3 and L2VPN RFCs. 

Cheers,
Ali 

> In the context of this conversation, it is important to note 
> that "NSP functionality is defined by standards bodies other 
> than the IETF".
> 
> PWE3 WG's were clear about **not** providing perfect 
> emulation of a Native Service over an MPLS PSN.  In fact, if 
> one refers to the PW encapsulation RFC's for Frame Relay [RFC 
> 4619], ATM [RFC 4717] and Ethernet [RFC 4448] there is a 
> clear "Applicability Statement" in Section 3 of all RFC's, 
> where this is pointed out.  In addition, it points out in a 
> very concise manner, "notable differences" between the

---

From: "David Allan" <[email-masked]>
Date: Fri, 25 Jul 2008 05:28:59 -0400

HI Shane: I'm trying to understand this in the context of
draft-allan-mmrp... And other proposals....

What I get out of this raises a number of points of interest....

1) No interaction with L2 protocols in theory takes all possibility of
resilient access off the table except as a pure overlay over totally
static and unfiltered VPLS instance(s). Some interaction is required to
ensure VPLS is not creating a loop if it has more than one point of
attachment to a broadcast domain. However if that interaction is off the
table then (for example) preferred forwarding which implies interaction
with peer networks protocols such as LACP, is a piece of work that
should be abandoned by this criteria...

MAC withdraw is effectively interaction with IEEE control protocols of
some form similar to 1. Topology change BPDUs transparently passed over
PWs between bridge modules would appear to be the only acceptable
approach by this criteria...

Which actually would work just fine as far as draft allan is
concerned... But for the case where ALL bridge modules do not have STP
enabled, preferred forwarding needs to stunt double... 

2) In the case of MMRP if the PW is presented as an interface to a
bridge module...I do not think there is a conflict. It is filtering
programmed prior to PW ingress by IEEE registration protocols for the
purpose of multicast pruning in a single broadcast domain. Registration
of filtering needs to be tied to topology change being what I think is
both your interest and concern....

But if I were to back this up to where efforts appear to be going....

1) preferred forwarding as a means of semaphoring a topology change
across a VPLS instance appears to be well advanced. That it can be used
as an aggregated MAC withdraw for PBBNs seems consistent with where PWE
is already going. That it can stunt double for a topology change BPDU I
do not think is a stretch as that is exactly what it is
communicating....

2) Multicast MAC filtering at the ingress to a broadcast domain does not
involve modifications to IEEE registration protocols in my proposal, or
is statically provisioned (as in Ali's proposal),and at least that part
is exclusive to the bridge module so does not seem to undermine your
concerns.

Does my analysis align with yours?
Thanks
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: Thursday, July 24, 2008 1:51 PM
To: [email-masked]
Subject: VPLS Architecture

Thanks,

-shane & Vach
co-chairs of L2VPN WG

---snip---
    across the core, or processing of the data received from a PW by a
PE

---

From: "BALUS Florin" <[email-masked]>
Date: Fri, 25 Jul 2008 09:15:04 -0500

Hi Dave,

This is not about VPLS not being aware about IEEE protocols you list
below. It's about the fact that with proper, IEEE compliant
implementations, the VPLS NSP (native service processing) module will
handle the interactions in an interoperable fashion. That was the whole
idea, otherwise we will keep reproducing all the IEEE work in IETF L2VPN
WG. 

So I agree with Shane's email: i.e. for IEEE specifically, if a solution
requires development or new interaction for an IEEE protocol then it
should be brought up in the related IEEE session first. Especially if it
applies to both IEEE native domains (e.g. native QinQ or PBB) and VPLS.

For the case in hand (your draft and IEEE 802.1ah, 802.1ak MMRP specs)
if a VPLS designer reads the IEEE specifications it will be able to
implement them no problem. And the resulting (proper) implementations
will just interoperate. Why do we need to spend any cycles in L2VPN WG
on this?

If something is broken in the IEEE protocol then the interested parties
should just go to IEEE and discuss fixes, extensions to the protocol in
the related IEEE sessions, where all the protocol knowledge is
concentrated. 

This is actually what happened 18 months ago with IEEE 802.1ak - there
were problems with the protocol base, a corrigendum was opened and
solutions were discussed in there that can be applied, no problem, to
both native Ethernet domains and VPLS. Tony, one of the IEEE 802.1ak
editor (in CC), drove the changes smoothly through the process.

There were no cycles spent on this in L2VPN WG. I think we should keep
it this way to maintain proper protocol development.

Florin

> Of David Allan
> Sent: Friday, July 25, 2008 2:29 AM
> To: Shane Amante; [email-masked]
> Subject: RE: VPLS Architecture
>

---

From: "Dinesh Mohan" <[email-masked]>
Date: Fri, 25 Jul 2008 11:32:54 -0400

Shane,

I must admit I am still trying to grasp the context of your note, since
as a WG we had recently spent quite a bit of time in updating the
charter for L2PVN and most drafts that you refer to, if not all, were
already in consideration for the WG.

In the meantime I would like to make few observations:

- It seems to me that the basic VPLS functionality becomes questionable
here since as you state below <<One component of the VPLS Architecture,
is a "Bridge Module", which is equivalent to a PW NSP[1]>> and if NSP is
not the focus, then we should simply be working on defining PWs and
should be done. IEEE already a well defined definition of a bridge, and
we should not need VPLS. But I am sure I have misunderstood.

- There is no disagreement that we should not re-specify other SDO
protocols and technologies. However, when we do take the liberty of
using these protocols and technologies, should we not be obligated to
ensure that we get approval from these bodies to ensure that our
interpretation of these protocols and technologies is consistent with
the other SDOs. I bring this up since you have mentioned below <<In
general, there is likely to be insufficient expertise widely available
within the IETF to review those drafts, in-depth, for accuracy or
"faithfulness" to the original SDO's standard as they progress through
the IETF standards process.>> As far as I know neither VPLS-LDP [RFC
4762] and VPLS-BGP [RFC 4761] have gone through such review yet we, as
L2VPN WG cite these as shining examples. So what are the issues that we
are confronted with now suddenly?

- We can certainly try to step aside some of the discussions by citing
<<**not** providing perfect emulation of a Native Service over an MPLS
PSN>> but I am not sure if this is sufficient.
draft-ietf-l2vpn-vpls-bridge-interop highlights the issues confronted
with current day VPLS solutions and no wonder WG has been trying to
address some of these already and with the charter updating highlighting
others that need to be and which already have active work underway in
WG. If this is not an issue, why bother with these follow-ups since VPLS
is already done via VPLS-LDP [RFC 4762] and VPLS-BGP [RFC 4761].

Therefore, I am still confused with this sudden message.

---
Dinesh

-----Original Message-----

Thanks,

-shane & Vach
co-chairs of L2VPN WG

---

From: "David Allan" <[email-masked]>
Date: Fri, 25 Jul 2008 11:40:54 -0400

Hi Florin 

> This is not about VPLS not being aware about IEEE protocols you list
below. It's about the fact that with proper, IEEE 
> compliant implementations, the VPLS NSP (native service processing)
module will handle the interactions in an 
> interoperable fashion. That was the whole idea, otherwise we will keep
reproducing all the IEEE work in IETF L2VPN WG.

That of course makes perfect sense, I was seeking to clarify that. But I
actually need that confirmation from the chairs... 

> So I agree with Shane's email: i.e. for IEEE specifically, if a
solution requires development or new interaction for an > IEEE protocol
then it should be brought up in the related IEEE session first.
Especially if it applies to both IEEE 
> native domains (e.g. native QinQ or PBB) and VPLS.

I do not think that is what is being proposed....

> For the case in hand (your draft and IEEE 802.1ah, 802.1ak MMRP specs)
if a VPLS designer reads the IEEE specifications > it will be able to
implement them no problem. And the resulting (proper) implementations
will just interoperate. Why do > we need to spend any cycles in L2VPN WG
on this?

So you are suggesting we are already done and do not need to consider
this or any other drafts on 802.1ah???? You surprise me!

There is one point to be validated,  the distinction that a PE is at a
boundary between an active topology an a split horizon mesh, VPLS may
provide an input into the state machine for the mesh facing MMRP
implementation. That is a missing component to produce a very viable
model, and IMO would be worth spending a small number of cycles upon.

If the group finds it of interest, a liaison to Tony and co. to test
that this does not break anything would be useful if the group does not
consider it immediately obvious. I believe it doesn't break anything. 

> If something is broken in the IEEE protocol then the interested
parties should just go to IEEE and discuss fixes, 
> extensions to the protocol in the related IEEE sessions, where all the
protocol knowledge is concentrated. 

> This is actually what happened 18 months ago with IEEE 802.1ak - there
were problems with the protocol base, a 
> corrigendum was opened and solutions were discussed in there that can
be applied, no problem, to both native Ethernet 
> domains and VPLS. Tony, one of the IEEE 802.1ak editor (in CC), drove
the changes smoothly through the process.

> There were no cycles spent on this in L2VPN WG. I think we should keep
it this way to maintain proper protocol 
> development.

As the draft proposes a model of how MMRP is used and does not suggest
anything is broken with it, your points escape me..

Cheers
Dave

> attachment to a broadcast domain. However if that interaction is off 
> the table then (for example) preferred forwarding which implies
interaction

> 2) Multicast MAC filtering at the ingress to a broadcast domain does 
> not involve modifications to IEEE registration protocols in my 
> proposal,
or

> be: a) a re-specification of how IEEE protocols work over top of a 
> VPLS; or, b) how IEEE protocols inter-work with other IEEE data-plane
formats

> there is likely to be insufficient expertise widely available within 
> "faithfulness"
> to
> significant risk in widespread re-publication of IEEE/ITU 
> Normative References to another SDO's detailed architecture, protocol 
> or technology documents should be more than adequate, and seems to 
> have worked well, so far, particularly in the cases of VPLS-LDP [RFC 
> 4762] and VPLS-BGP [RFC 4761] to cite just two examples.
> 
> With respect to the second question (interworking of two IEEE data- 
> plane protocols within a VPLS), L2VPN (via PWE3 WG) seems to have gone

> down
a

> data-plane formats concurrently?  In other words, what is lacking in 
> the current emulation of PW's that needs to be fixed in order to 
> provide more seamless carriage of Ethernet frames within a VPLS, so 
> that the VPLS architecture can remain agnostic to current and future 
> IEEE data-plane protocols?
> 

> direct (configured) knowledge of the incoming/outgoing data-plane 
> format as well as any associated actions that need to be performed 
> when receiving from or transmitting to the AC.  This would allow a 
> (Generic
>   Furthermore, within the L2VPN Framework [RFC 4664], Section 2.2, it 
> is noted that "precise functionality that the bridge modules must have

> in particular circumstances is, however, out of scope of the current 
> document".  In other words, the VPLS architecture should be oblivious 
> to Native Service Layer control protocols entering, exiting or 
> processed within the Bridge Module.  The main reason for this is to 
> avoid re-specification of other SDO's protocols.  A secondary reason 
> is to avoid unnecessary and uncomfortably tight coupling of other 
> SDO's NSL control protocols with those specified and maintained within

> the IETF L2VPN (or PWE3) WG's.  Finally, this allows end-users and 
> implementers to expect the NSL Layer-2 Control Protocols operating 
> within the
Bridge

> SDO's standards even as Informational Drafts.  Furthermore, we also 
> will be guiding the WG to look at the fundamental architecture of 
> VPLS, and its underlying PW's, to *first* determine what are the 
> /requirements/ to ensure VPLS remains agnostic to data-plane 
> protocols.  Eventually,
that

---

From: "Dinesh Mohan" <[email-masked]>
Date: Fri, 25 Jul 2008 11:41:53 -0400

And just to add to my second bullet: 

I do not think that we currently have any activities in WG (in context
of activities that I have been involved in) which are attempting to
redefine the protocols/technologies being used in other SDOs, rather,
what we have is an application of these to address issues identified
with VPLS in draft-ietf-l2vpn-vpls-bridge-interop, similar to
application of Ethernet bridging in VPLS-LDP [RFC 4762] and VPLS-BGP
[RFC 4761].

---
Dinesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mohan, Dinesh (CAR:NP02)
Sent: Friday, July 25, 2008 11:33 AM
To: Shane Amante; [email-masked]
Subject: RE: VPLS Architecture

Shane,

---
Dinesh

-----Original Message-----

Thanks,

-shane & Vach
co-chairs of L2VPN WG

---

From: "KOMPELLA Vach" <[email-masked]>
Date: Fri, 25 Jul 2008 13:38:32 -0500

Dinesh, Dave, Ali, Florin,

This is not a sudden email, but we have been discussing this issue for a
while internally.

The basic point is an architectural issue: if we have done a decent job
in describing what is in the scope of the PWE and L2VPN architectures,
and what is NSP/Bridge module functionality, then we can clearly
distinguish what protocols are IEEE and what are IETF, and whether there
needs to be any interaction between them.

If we haven't done a good job, then we should fix the architecture.
Shane put down our thoughts at some length so there would be enough
context to understand the concerns on direction.

I hesitate to step in and argue points yet because I want to gauge the
WG concerns.

-Vach

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 25 Jul 2008 17:16:01 -0400

Well, I'm a co-author, so you can't call me neutral, but I think
draft-vkompella-pwe3-ethernet-pw-bis-01 is a much architecturally cleaner
recasting of RFC 4448, and we made sure that it's backwards compatible with
existing 4448 implementations.

Cheers,
Andy
On Fri, Jul 25, 2008 at 2:38 PM, KOMPELLA Vach <

---

From: "BALUS Florin" <[email-masked]>
Date: Fri, 25 Jul 2008 19:56:14 -0500

Hi Dave,

> Sent: Friday, July 25, 2008 8:41 AM
> To: BALUS Florin; Shane Amante; [email-masked]
> Cc: Tony Jeffree

[[FB]] I was talking here about the general case not about your
proposal.

> this or any other drafts on 802.1ah???? You surprise me!

[[FB]] I like to surprise especially people that used to know me! :) 
I don't think I said something about "any other IEEE 802.1ah drafts". I
was talking about the IEEE 802.1ah specification in the context of MMRP:
i.e. IEEE 802.1ah section 26.4 describes how 802.1ak MMRP can be used in
a PBB context. IEEE 802.1ak MMRP also describes the protocol in detail.
In my opinion between the two specs there is plenty of information to
make it work for PBB-VPLS. 
> model, and IMO would be worth spending a small number of cycles upon.
[[FB]] The VPLS PW Mesh is part of the active topology that MMRP can
just use to distribute its declarations/receive the registrations on a
per PW basis. I do not see an issue, maybe we can do some whiteboarding
on that in IETF-72. 

> consider it immediately obvious. I believe it doesn't break anything.

[[FB]] I do not expect anything to break but asking the IEEE experts
won't hurt. 

> anything is broken with it, your points escape me.

[[FB]] I thought the way MMRP issues were handled was a good generic
example on how we should handle issues related to IEEE protocol
development: i.e. although the interest for MMRP usage came from VPLS
implementations, the fixes were addressed in IEEE without involving
IETF. The example just happened to be MMRP, no linkage to your proposal.

> > is already going. That it can stunt double for a topology change
BPDU
> I
protocol
> precedent
> Ethernet
Service

---

From: Shane Amante <[email-masked]>
Date: Sat, 26 Jul 2008 10:16:29 -0600

Dave,

On Jul 25, 2008, at 3:28 AM, David Allan wrote:
> the
> BPDU I
> not

No, it does not.

Let's bring this back up a level and attempt to apply a much simpler  
"litmus test".  Specifically, what if VPLS were never invented or  
simply did not exist?  Alternatively, and more practically, what is  
done when VPLS does not exist in certain topologies/deployments?  In  
that case, the IEEE would either have a (scalable) solution that you  
are looking for or people would go to the IEEE and kick-off an effort  
to create such a solution, correct?

When viewed at from that perspective, it should hopefully be clear  
that solutions to this specific problem should belong in the NSP/ 
Bridge Module and, therefore, are out of the hands of the L2VPN WG.   
(Furthermore, if folks want to implement said solutions, they should  
go read the full IEEE spec to do so and we should not duplicate or  
otherwise re-publish it within the L2VPN WG).

Also, to bring this back to the context of VPLS Architecture, you did  
say the following:
---snip---
> bridge module...
---snip---
Currently, a VPLS instance on a VPLS-PE is defined (at least from a  
theoretical standpoint) as having a single LAN emulation interface  
between the Bridge Module and the VPLS Forwarder, which likely  
prevents one from applying IEEE filtering/forwarding Control Protocols  
against an individual PW, such as what you're attempting to define in  
draft-allan-mrrp (as an example).  Again, the larger question that  
should be being asked is: do we have a broken architecture and need to  
consider fixing it to allow it to more accurately (but, not perfectly)  
"emulate" a IEEE LAN?

Thanks,

-shane

---

From: Shane Amante <[email-masked]>
Date: Sat, 26 Jul 2008 10:38:02 -0600

One follow-up to my own message, just to make sure I'm more clear ...

On Jul 26, 2008, at 10:16 AM, Shane Amante wrote:

> are looking for or people would go to the IEEE and kick-off an  
> effort to create such a solution, correct?
>
> Also, to bring this back to the context of VPLS Architecture, you  
> did say the following:
> ---snip---
> prevents one from applying IEEE filtering/forwarding Control  
> Protocols against an individual PW, such as what you're attempting  
> to define in draft-allan-mrrp (as an example).  Again, the larger  
> question that should be being asked is: do we have a broken  
> architecture and need to consider fixing it to allow it to more  
> accurately (but, not perfectly) "emulate" a IEEE LAN?

I should have added on to the last sentence the following: " ... by,  
perhaps, considering an architectural change to VPLS such as exposing  
individual PW's to the Bridge Module".

-shane

---

From: Shane Amante <[email-masked]>
Date: Sun, 27 Jul 2008 11:36:13 -0600

Ali,

I'm going to break this response up into two parts.  In this thread, I 
continue on the points related to the architecture of VPLS.

Ali Sajassi (sajassi) wrote:

[--snip--]

> that we start from square one again ??

Ultimately, since we're talking about the need to support a new IEEE 
data-plane format, it appears that debate has (already) been re-opened.

I'm hopeful that starting from "square one" will be unnecessary, so long 
as the chosen solution provides *both* backward compatibility with the 
two, previous PW types (raw and tagged) as well as much more flexibility 
for incorporating "new" data plane formats.

[--snip--]

> mode versus tagged mode).    

Actually, I think this is the key point of this entire conversation and 
must not be lightly dismissed.  Specifically, explicit signaling of the 
PW type creates a variety of headaches with respect to interoperability 
of data-plane protocols carried by the PW's, as well as inability to 
easily adapt to emerging/new data-plane formats.

Furthermore, why is the onus on VPLS (or PWE3) to provide interworking 
of IEEE data-plane formats?  Isn't that a function of the IEEE and the 
Bridge Module?

[--snip--]

> being made center piece of "VPLS architecture".  

I disagree.  See above.

[--snip--]

> how it is done, it can simply be referred to IEEE spec. 

Actually, this is another very key point and I'm glad you brought it up, 
because it again goes directly to the heart of the discussion around the 
architecture of VPLS.

Again, as I stated in my originally e-mail, I submit that if there is an 
impact on the Bridging Module, which requires new specifications on our 
part, then we haven't properly designed the Bridge Module function and 
need to re-visit that to provide better "emulation" of Ethernet.

> Remember that

Right, and that's it!  We SHOULD NOT be defining functions within the 
Bridge Module, including interaction, adaptation or interworking of IEEE 
protocols, since that is the IEEE's bailiwick.

[--snip--]

> "raw" and "tagged" mode as being defined in both PWE3 and L2VPN RFCs. 

See above.

-shane

---

From: Shane Amante <[email-masked]>
Date: Mon, 28 Jul 2008 01:36:33 -0600

Ali,

This is second part of the earlier response.  See below.

> drafts you mean specifically. 

The one I'm most concerned with is:
draft-mohan-l2vpn-vpls-oam-01

And, to a large extent the following, as well:
draft-sajassi-l2vpn-pbb-vpls-cmac-flush-00
draft-sajassi-l2vpn-pbb-vpls-mpls-access-00
draft-sajassi-l2vpn-pbb-vpls-multicast-00
draft-sajassi-l2vpn-vpls-pbb-interop-03
draft-balus-l2vpn-vpls-802.1ah-03
Although, to be fair, this latter group is IMO more likely a consequence 
of the current architecture of VPLS.  So, for this group in particular, 
I would prefer if we focus instead on discussing what might be 
limitations with the architecture of VPLS and what might be done to fix 
it in order that we reduce the volume of drafts in order to support a 
new IEEE data-plane.

In addition, you do realize that the sum total of draft-sajassi* & 
draft-balus* is currently at 87 pages.  However, RFC 4762 is a mere 29 
pages?  IMO, the reason for the volume of pages is detailed descriptions 
of interworking (or, "interoperability scenarios") of IEEE data-plane 
technologies, which should be found in IEEE documents, not in IETF drafts.

> drafts for many reasons some of which you have mentioned above.

I'm glad you agree.

> As the

-shane

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 28 Jul 2008 06:07:42 -0700

Shane, 

> draft-mohan-l2vpn-vpls-oam-01

Can you tell me what the concern is exactly. This is a draft which
describes oam-vpls solution adherent to all the requirements of
vpls-oam-req-frwk which has passed last WG call quite a while ago. In
the last meeting, there was a very good consensus to move this draft to
WG status. 

> draft-balus-l2vpn-vpls-802.1ah-03

Did you leave out any drafts :-) All this work is within the new updated
WG charter. The scenario drafts describes what scenarios we need to
concern with and the solution drafts talk about the solutions.
Unfortunately, the progress of the work in this working group has been
very slow because the issues are not being understood and as the result
any work to address these issues are not being look at properly. 

> Although, to be fair, this latter group is IMO more likely a 
> consequence of the current architecture of VPLS.  So, for 
> this group in particular, I would prefer if we focus instead 
> on discussing what might be limitations with the architecture 
> of VPLS and what might be done to fix it in order that we 
> reduce the volume of drafts in order to support a new IEEE data-plane.
>

That's the objective. To address the issues at hand without creating any
unnecessary work. 
 
> draft-balus* is currently at 87 pages.  However, RFC 4762 is 
> a mere 29 pages?  IMO, the reason for the volume of pages is 
> detailed descriptions of interworking (or, "interoperability 
> scenarios") of IEEE data-plane technologies, which should be 
> found in IEEE documents, not in IETF drafts.
> 

And there will be more. Take a look at where MPLS WG got started and
were they are now. We need to continue improve our solutions to the
market need. If WG thought that RFC 4762 was sufficient, then we
wouldn't need to do the re-chartering.

Regards,
Ali

> >> protocols), there are a significant number of concerns.
> >>  Specifically, when protocols from another SDO are re-specified 
> >> within the IETF, there is the potential for errors or 
> omissions to be 
> >> introduced.  In general, there is likely to be 
> insufficient expertise 
> >> widely available within the IETF to review those drafts, in-depth, 
> >> for accuracy or "faithfulness" to the original SDO's 
> standard as they 
> >> progress through the IETF standards process.  Finally, there is 
> >> always the [unanswered] question of what SDO's document is 
> considered 
> >> authoritative in case a conflict, error or omission develops.  In 
> >> summary, there is both little value and significant risk in 
> >> widespread re-publication of IEEE/ITU specifications 
> within the L2VPN 
> >> WG.  In a well written draft, Normative References to 
> another SDO's 
> >> detailed architecture, protocol or technology documents should be 
> >> more than adequate, and seems to have worked well, so far, 
> >> particularly in the cases of VPLS-LDP [RFC 4762] and VPLS-BGP [RFC 
> >> 4761] to cite just two examples.
> >>
> >

---

From: "BALUS Florin" <[email-masked]>
Date: Mon, 28 Jul 2008 16:01:41 -0500

Shane,

> Sent: Monday, July 28, 2008 12:37 AM
> To: Ali Sajassi (sajassi)
> Cc: [email-masked]
> Subject: Re: VPLS Architecture
> 
> Ali,
> 
> consequence
[[FB]] We believe there are a number of items in
draft-balus-l2vpn-vpls-802.1ah-03 that fit the L2VPN scope and address
the VPLS scalability: the discussion around VPLS Addressing for both BGP
AD and LDP Signaling, the extension to LDP MAC Flush and the
introduction of NSP capabilities specific to PBB NSP. The rest of the
text was supposed to help the understanding of the solution space. I can
work with the other authors to summarize the later part/eventually
include it in the Appendix for the next version of the document. 

Florin