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

From: narasimhan g <[email-masked]>
Date: Mon, 8 Aug 2005 19:05:17 -0700 (PDT)

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

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 9 Aug 2005 11:58:55 -0700

If you look at both RFC 2684 and RFC 2427, you see MAC header in all
encapsulated messages for IEEE frame types except for BPDUs. I think the
reason was this is bridged encap and there is no point in sending the
MAC header because BPDUs always get terminated by next hop bridge. So,
if your implementation doesn't strip the MAC header, then you don't have
to do anything but if it does, then you need to add the MAC header.

-Ali

> -----Original Message-----
> From: Prakash Jayaraman [mailto:[email-masked]] 
> Sent: Tuesday, August 09, 2005 11:27 AM
> To: Ali Sajassi (sajassi)
> Cc: Shahram Davari; narasimhan g; [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.
> >>    
> >>
> >>>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 
> >>>  actions, at ingress and egress, of dealing with service
> >>>      
> >>>
> >>delimiters
> >>    
> >>
> >>>  are local actions that neither PE has to signal to the
> >>>      
> >>>
> >>other.  They
> >>    
> >>
> >>> that has local significance only.  The service delimiter
> >>>      
> >>>
> >>may be an
> >>    
> >>
> >>> Bridged PVC encapsulation could also serve as a service
> >>>      
> >>>
> >>delimiter.  
> >>    
> >>
> >>>  By limiting the scope of locally significant
> >>>      
> >>>
> >>encapsulations to the
> >>    
> >>
> >>>  If the topology of the VPLS is not restricted to a full
> >>>      
> >>>
> >>mesh, then
> >>    
> >>
> >>> topology would require the use of some loop-breaking
> >>>      
> >>>
> >>protocol, like
> >>    
> >>
> >>> via a PW, there is no longer any need to relay packets,
> >>>      
> >>>
> >>and we can
> >>    
> >>
> >>>  (STP) such as when a customer has "back door" links used
> >>>      
> >>>
> >>to provide
> >>    
> >>