Subject: Re: VPLS Architecture

From: "David Allan" <[email-masked]>
Date: Sun, 27 Jul 2008 04:42:49 -0400

Hi shane

OK I get the model and the implications. Let's follow up in Dublin

D
--------------------------
Thumb typed by Dave Allan, Nortel

----- Original Message -----
From: Shane Amante <[email-masked]>
To: Allan, David (CAR:NS00)
Cc: [email-masked] <[email-masked]>
Sent: Sat Jul 26 12:38:02 2008
Subject: Re: VPLS Architecture

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:

> Dave,
>
> On Jul 25, 2008, at 3:28 AM, David Allan wrote:
>> 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?
>
> 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---
>> 2) In the case of MMRP if the PW is presented as an interface to a
>> 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?

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