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

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 9 Aug 2005 14:48:37 -0400

Its easy to miss and RFC 2684 is very scanty (in fact I could not
find any text - only the diagram, in quick check). It is on page 10, 
BPDU sent with pid 0x00-0E.

I guess authors assumed that all BPDUs will be consumed/originated by the
bridges (with AAL5 interfaces) and where will these bridges get MAC addr
for this interface? In VPLS, where C-STP frames are tunneled, PE would
bear the responsibility of generating MAC header before frames are 
forwarded out over Ethernet PW (as Ali mentioned in L2VPN mailing list).

/himanshu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Prakash Jayaraman
> Sent: Tuesday, August 09, 2005 2:27 PM
> To: Ali Sajassi (sajassi)
> Cc: narasimhan g; Shahram Davari; [email-masked]
> Subject: Re: [PWE3] customer BPDU ethernet encapsulation over
> rfc1483(2684)ATM PVCs.
> 
> 
> When using standard RFC 2684 (Multiprotocol encapsulation over AAL5), 
> the mac-header is not stripped when sending Ethernet frames over AAL5 
> connections. There is a 10-byte header for RFC2684-bridged LLC 
> encapsulation  (or a 2-byte header for RFC2684-bridged vc-multiplexed 
> encapsulation). The header is followed by the entire Ethernet frame 
> (mac-header, all VLAN tags, ethertype, payload). Inclusion of CRC is 
> optional. The header indicates if CRC is part of the AAL5-payload.
> 
> - prakash
> 
> 
> Ali Sajassi (sajassi) wrote:
> 
> >Shahram,
> >
> >The issue is that the MAC header is stripped when 
> encapsulated by 2684
> >and 2427.
> >
> >-Ali
> >
> >
> >  
> >
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On 
> >>Behalf Of Shahram Davari
> >>Sent: Tuesday, August 09, 2005 7:49 AM
> >>To: 'narasimhan g'; [email-masked]
> >>Subject: RE: [PWE3] customer BPDU ethernet encapsulation over 
> >>rfc1483(2684) ATM PVCs.
> >>
> >>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
> >>
> >>    
> >>
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >  
> >
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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