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

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 9 Aug 2005 10:43:35 -0700

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

---

From: Prakash Jayaraman <[email-masked]>
Date: Tue, 09 Aug 2005 11:26:44 -0700

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

---

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

Hi Prakash,

Thanks for your reply.  I am specifically
talking about encapsulation of bridged BPDUs for which the mac-header
must be stripped off as per rfc2684.

thanks,
narasim

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

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