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

From: Shahram Davari <[email-masked]>
Date: Tue, 9 Aug 2005 07:49:08 -0700

Hi,

I am not sure what problem you see. RFC1483 shows how Ethernet 802.3 is encapsulated in AAL5, and the VPLS draft says if the attached circuit is ATM (AAL5), then the Ethernet frames must be extracted from the AAL5 PDU and sent over MPLS. In such case the attached circuit PVC could act as service delimiting tag.

Yours,
Shahram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> narasimhan g
> Sent: Monday, August 08, 2005 10:05 PM
> To: [email-masked]
> Subject: [PWE3] customer BPDU ethernet encapsulation over 
> rfc1483(2684)
> ATM PVCs.
> 
> 
> Hi,
> 
> I have a question regarding customer BPDU encapsulation over ATM PVCs.
> I have also posted this question on the l2vpn mailing list
> 
> 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 of 
> the draft.
> 
> 
> 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. 
> 
> 
> 
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail 
> Stay connected, organized, and protected. Take the tour: 
> http://tour.mail.yahoo.com/mailtour.html 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3