Subject: RE: customer BPDU ethernet encapsulation over rfc1483(2684) ATM PVCs.

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Mon, 8 Aug 2005 22:42:02 -0700

In case of either 2684 (bridged encap over ATM) or 2427 (bridge encap
over FR), the interworking unit of the PE needs to add the MAC header to
the BPDU frames before passing it to the forwarding unit of the PE. The
destination address is the standard IEEE 802.1D multicast address for
BPDU and the source address is the MAC address of the PE (or more
precisely of the IW unit). 

-Ali

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of narasimhan g
> Sent: Thursday, August 04, 2005 2:49 PM
> To: [email-masked]
> Subject: customer BPDU ethernet encapsulation over 
> rfc1483(2684) ATM PVCs.
> 
> Hi,
> 
> I have a question regarding customer BPDU encapsulation over ATM PVCs.
> 
> The VPLS draft draft-ietf-l2vpn-vpls-ldp-07.txt seems to 
> suggest that the all frames that traverse a VPLS will have 
> ethernet encasulation ( see below for quotes from the draft). 
>  Does it mean that customer BPDUs received over an 
> rfc1483/2684 ATM PVC will/must also have an ethernet 
> encasulation?  RFC1483 encapsulation of BPDUs suggests 
> otherwise. Can someone please clarify.
> 
> Attached below is relevant text from sections 7.1 and 4.4.
> 
> 
> thanks,
> 
> narasim
> 
> 7.1. VPLS Encapsulation actions 
> 
> <snip>
> 
>  
> 
>  By following the above rules, the Ethernet frame that 
> traverses a   <==============
>   VPLS is always a customer Ethernet frame.  Note that the two
>   actions, at ingress and egress, of dealing with service delimiters
>   are local actions that neither PE has to signal to the other.  They
>   allow, for example, a mix-and-match of VLAN tagged and untagged
>   services at either end, and do not carry across a VPLS a VLAN tag
>   that has local significance only.  The service delimiter may be an
>   MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET]
>   can serve as the access side connection into a PE.  An RFC1483
>   Bridged PVC encapsulation could also serve as a service delimiter.  
>   By limiting the scope of locally significant encapsulations to the
>   edge, hierarchical VPLS models can be developed that provide the
>   capability to network-engineer scalable VPLS deployments, as
>   described below. 
> 
>  
> 
> 4.4. Loop free VPLS 
>    
>   If the topology of the VPLS is not restricted to a full mesh, then
>   it may be that for two PEs not directly connected via PWs, they
>   would have to use an intermediary PE to relay packets.  This
>   topology would require the use of some loop-breaking protocol, like
>   a spanning tree protocol. 
>    
>   Instead, a full mesh of PWs is established between PEs.  Since
>   every PE is now directly connected to every other PE in the VPLS
>   via a PW, there is no longer any need to relay packets, and we can
>   instantiate a simpler loop-breaking rule - the "split horizon" 
>   rule: a PE MUST NOT forward traffic from one PW to another in the
>   same VPLS mesh. 
>    
>   Note that customers are allowed to run the Spanning Tree Protocol
>   (STP) such as when a customer has "back door" links used to provide 
>   redundancy in the case of a failure within the VPLS.  In 
> such a     <==============
>   case, STP Bridge PDUs (BPDUs) are simply tunneled through the
>   provider cloud. 
> 
> 
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
>

---

From: narasimhan g <[email-masked]>
Date: Tue, 9 Aug 2005 11:40:10 -0700 (PDT)

Hi Ali,

Thanks for the clarification.

narasim

> >   case, STP Bridge PDUs (BPDUs) are simply tunneled through the

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com