Subject: Re : [PWE3] STP BPDU tunneling over PWs

From: Marc Rapoport <[email-masked]>
Date: Sat, 19 Jan 2008 10:58:23 -0800

Hi Tao,

Case 1 : STP come from customer network.
Theses BPDU are at the same level of VLAN encap as the Data frames, and there should not be any issue to tunnel them.

Eg
Case 1.1 : VLAN is service delimiter on AC. It means each customer sends untagged traffic, whith or without RSTP in it.
if the L2PE receives .1q traffic, there is an intermediate L2 MTU in between customer port & L2PE that tags each customer with a different VLAN,
and this L2 MTU should tag RSTP frames at the same time.

Case 1.2 : QinQ traffic, S-VLAN is service delimiter.
Each customer send .1q traffic with (or without) MSTP frames.
the L2 MTU switch will apply .1ad encap on it, and MSTP frames will be S-VLAN tagged as well as other customer data frames.

In both cases, BPDU frames are at the same level of encap than customer data frames.

Case 2 : BPDU are not at the same level of encap as Customer frames:
- BPDU untagged, customer frames tagged
- BPDU 1.q tagged, customer frames .1ad tagged
BPDU are then generated by the intermediate MTU access bridges, not by the customer network.
These BPDU are typically used as a control protocol inside the access network to resolve loops for redundant topologies.
They are not part of customer traffic, and there is no real interest to tunnel them through the PW ..

In both cases, I don't see where is the issue that needs to be addressed.
 Rgds,

Marc.

Date: Sat, 19 Jan 2008 11:52:12 +0800
From: Tao Gu <[email-masked]>
Subject: [PWE3] STP BPDU tunneling over PWs
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi Gurus,

When Vlan is service-delimiting on Ethernet LAN AC, it will be used to distinguish one customer's traffic from another's. This works well for data frames which are vlan tagged. But for STP BPDUs and other layer2 protocol PDUs that are not vlan tagged, it's required to classify them into different PWs based on other mechanisms. I think such issue needs to be addressed and included in future RFCs.

The same problem applies to 802.1ad (QinQ) networks as well. 802.1ad does mention STP PDUs "received by Customer Network Ports and addressed to the Bridge Group Address are subject to service instance selection and relay in the same way as customer data frames."

but doesn't seem to realize that STP PDUs are untagged thus can not be done in the same way as customer data frames.

Best regards,

--
Tao Gu

Centec Networks Inc.
www.centecnetworks.com

-

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

---

From: Tao Gu <[email-masked]>
Date: Mon, 21 Jan 2008 10:40:58 +0800

Hi Marc,

Thank you for the prompt feedback.

If I understand you correctly, you are saying an intermediate L2 MTU is 
mandatory in order to add the service delimiting VLAN in case1,  but I 
thought this is only one option. The other option being CEs connect to 
PEs directly and the VLAN (CVLAN or SVLAN depending on the type of l2 
network the customer is based .1q or .1ad) embedded in customer traffic 
itself is service delimiting and thus used for service instance 
selection. The BPDU tunneling problem needs to be addressed in such 
scenarios.

Best regards,
Tao

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 21 Jan 2008 03:55:00 +0100

Tao,

Why don't you use PVSTP support in order to tag the BPDU(s). This
provides VLAN delineation in single tagged scenarios.

Cheers,
Wim 

-----Original Message-----
From: Tao Gu [mailto:[email-masked]] 
Sent: maandag 21 januari 2008 3:41
To: Marc Rapoport
Cc: [email-masked]
Subject: Re: Re : [PWE3] STP BPDU tunneling over PWs

Hi Marc,

Best regards,
Tao

Marc Rapoport wrote:
> Theses BPDU are at the same level of VLAN encap as the Data frames,
and there should not be any issue to tunnel them.
>
> Eg
> Case 1.1 : VLAN is service delimiter on AC. It means each customer
sends untagged traffic, whith or without RSTP in it.
> if the L2PE receives .1q traffic, there is an intermediate L2 MTU in 
> between customer port & L2PE that tags each customer with a different
VLAN, and this L2 MTU should tag RSTP frames at the same time.
> the L2 MTU switch will apply .1ad encap on it, and MSTP frames will be
S-VLAN tagged as well as other customer data frames.
> - BPDU 1.q tagged, customer frames .1ad tagged BPDU are then generated

> by the intermediate MTU access bridges, not by the customer network.
> These BPDU are typically used as a control protocol inside the access
network to resolve loops for redundant topologies.
> When Vlan is service-delimiting on Ethernet LAN AC, it will be used to
distinguish one customer's traffic from another's. This works well for
data frames which are vlan tagged. But for STP BPDUs and other layer2
protocol PDUs that are not vlan tagged, it's required to classify them
into different PWs based on other mechanisms. I think such issue needs
to be addressed and included in future RFCs.
>
> The same problem applies to 802.1ad (QinQ) networks as well. 802.1ad
does mention STP PDUs "received by Customer Network Ports and addressed
to the Bridge Group Address are subject to service instance selection
and relay in the same way as customer data frames."
>
> but doesn't seem to realize that STP PDUs are untagged thus can not be
done in the same way as customer data frames.

---

From: Tao Gu <[email-masked]>
Date: Mon, 21 Jan 2008 12:19:43 +0800

Hi Wim,

Yes I could but PVSTP is proprietary and RSTP/MSTP is more widely used. 
That's why I think we need to address this issue.

Best regards,
Tao

HENDERICKX Wim wrote:
>> In both cases, BPDU frames are at the same level of encap than
>>     
> customer data frames.
>   
>> They are not part of customer traffic, and there is no real interest
>>     
> to tunnel them through the PW ..
>   
>> In both cases, I don't see where is the issue that needs to be
>>     
> addressed.
>   
>>  Rgds,
>>
>> Marc.
>>

---

From: Marc Rapoport <[email-masked]>
Date: Mon, 21 Jan 2008 14:03:48 -0800

Hi Tao,
I assume that what you describe is a multi-services customer :
There is a single customer behind the access port, but different VLANs used to provide different services
 (VLAN 10 = Internet Access, VLAN 20 = Private E-LAN, ...).

If you are going to map these diff. VLANs to different VPLS instances,
these VLANs obviously do not share topologies /networks.

In that case, I don't see how you can have a common STP protocol shared for these VLANs even on the customer bridged network side.

The typical example I see of STP+VLAN as service delimiter is the dual attached CE case,
 with STP used to break the loop in the triangle between CE,PE1 and PE2.

For that case, you just run an extra VPLS instance with  VLAN 0/untagged as service delimiter, that encaps STP and transport BPDUs between the 2 PEs (this VPLS instance is distinct from ones used for customer data tagged traffic).
This will ensure that one of the uplink ports on the CE is blocked.

The key point is that STP is tied & local to the topology of the dual homed CE,
and has nothing to do with the bridging domains of the customer services transported in the VLANs.

If you have another case of STP + VLANs with VLAN as service delimiter in mind, can you describe it?

Rgds,
Marc.

-----Original Message-----
From: Tao Gu [mailto:[email-masked]]
Sent: Sunday, January 20, 2008 6:41 PM
To: Marc Rapoport
Cc: [email-masked]
Subject: Re: Re : [PWE3] STP BPDU tunneling over PWs

Hi Marc,

If I understand you correctly, you are saying an intermediate L2 MTU is mandatory in order to add the service delimiting VLAN in case1,  but I thought this is only one option. The other option being CEs connect to PEs directly and the VLAN (CVLAN or SVLAN depending on the type of l2 network the customer is based .1q or .1ad) embedded in customer traffic itself is service delimiting and thus used for service instance selection. The BPDU tunneling problem needs to be addressed in such scenarios.

Best regards,
Tao

Marc Rapoport wrote:
> between customer port & L2PE that tags each customer with a different VLAN, and this L2 MTU should tag RSTP frames at the same time.
>

---

From: "Serbest, Yetik" <[email-masked]>
Date: Mon, 21 Jan 2008 16:08:37 -0600

I agree with Marc here. Just tag it (QinQ) in a L2 MTU. That is the
simplest solution. No new solution is needed really.

Thanks,
yetik

-----Original Message-----
From: Marc Rapoport [mailto:[email-masked]] 
Sent: Monday, January 21, 2008 4:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Re : [PWE3] STP BPDU tunneling over PWs

Hi Tao,
I assume that what you describe is a multi-services customer :
There is a single customer behind the access port, but different VLANs
used to provide different services
 (VLAN 10 = Internet Access, VLAN 20 = Private E-LAN, ...).

In that case, I don't see how you can have a common STP protocol shared
for these VLANs even on the customer bridged network side.

The typical example I see of STP+VLAN as service delimiter is the dual
attached CE case,
 with STP used to break the loop in the triangle between CE,PE1 and PE2.

For that case, you just run an extra VPLS instance with  VLAN 0/untagged
as service delimiter, that encaps STP and transport BPDUs between the 2
PEs (this VPLS instance is distinct from ones used for customer data
tagged traffic).
This will ensure that one of the uplink ports on the CE is blocked.

The key point is that STP is tied & local to the topology of the dual
homed CE,
and has nothing to do with the bridging domains of the customer services
transported in the VLANs.

If you have another case of STP + VLANs with VLAN as service delimiter
in mind, can you describe it?

Rgds,
Marc.

-----Original Message-----
From: Tao Gu [mailto:[email-masked]]
Sent: Sunday, January 20, 2008 6:41 PM
To: Marc Rapoport
Cc: [email-masked]
Subject: Re: Re : [PWE3] STP BPDU tunneling over PWs

Hi Marc,

Best regards,
Tao

customer data frames.
addressed.

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 21 Jan 2008 23:37:46 +0100

Hi *,

Yes it seems that putting a L2 MTU for the VLAN encapsulation seems to
be the most appropriate solution. All other options will require
extensions in the BPDU messages somehow, so how do you see PWE
addressing this if PVST is already proprietary.
Just put an L2 MTU in front of the PW encapsulation as Marc and Yetik
suggest.

Cheers,
Wim 

-----Original Message-----
From: Serbest, Yetik [mailto:[email-masked]] 
Sent: maandag 21 januari 2008 23:09
To: Marc Rapoport; [email-masked]
Cc: [email-masked]
Subject: RE: Re : [PWE3] STP BPDU tunneling over PWs

Thanks,
yetik

-----Original Message-----
From: Marc Rapoport [mailto:[email-masked]]
Sent: Monday, January 21, 2008 4:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Re : [PWE3] STP BPDU tunneling over PWs

Hi Tao,
I assume that what you describe is a multi-services customer :
There is a single customer behind the access port, but different VLANs
used to provide different services  (VLAN 10 = Internet Access, VLAN 20
= Private E-LAN, ...).

The typical example I see of STP+VLAN as service delimiter is the dual
attached CE case,  with STP used to break the loop in the triangle
between CE,PE1 and PE2.

The key point is that STP is tied & local to the topology of the dual
homed CE, and has nothing to do with the bridging domains of the
customer services transported in the VLANs.

Rgds,
Marc.

-----Original Message-----
From: Tao Gu [mailto:[email-masked]]
Sent: Sunday, January 20, 2008 6:41 PM
To: Marc Rapoport
Cc: [email-masked]
Subject: Re: Re : [PWE3] STP BPDU tunneling over PWs

Hi Marc,

Best regards,
Tao

customer data frames.

addressed.

---

From: Tao Gu <[email-masked]>
Date: Tue, 22 Jan 2008 11:45:29 +0800

Hi Marc,

Thanks again for you insightful analysis, please see my reply inclined.

Best regards,
Tao

> In that case, I don't see how you can have a common STP protocol shared for these VLANs even on the customer bridged network side.
You are right, these VLANs can not share a common STP, but MSTP can be 
used here to assign different MSTI to different VLANs,  even these VLANs 
do not share the  same topology. 
> If you have another case of STP + VLANs with VLAN as service delimiter in mind, can you describe it?
Dual attached CE is just one case and your solution will work fine. 
Another case is dual attached site connected to VPLS with two separate 
CEs, in this case STP is not tied & local to the CE and instead run 
cross the combined bridged network across VPLS,  the loop might be 
broken at a link within the customer networks.

---

From: Tao Gu <[email-masked]>
Date: Tue, 22 Jan 2008 11:52:38 +0800

It has two implications though:

1. An extra L2 device is needed which means higher cost.
2. It can't support the customer networks that are already running QinQ.

Is this acceptable to service providers? I doubt it.

Best regards,
Tao

---

From: "Serbest, Yetik" <[email-masked]>
Date: Tue, 22 Jan 2008 09:31:06 -0600

Tao,

[Yetik] yes, but you already need a demarcation device and/or for
end-end SLA.

[Yetik] Yes that can also be supported.

Thanks,
Yetik

---

From: "Serbest, Yetik" <[email-masked]>
Date: Mon, 21 Jan 2008 15:27:44 -0600

Thanks,
yetik

-----Original Message-----
From: Tao Gu [mailto:[email-masked]] 
Sent: Sunday, January 20, 2008 10:20 PM
To: HENDERICKX Wim
Cc: Marc Rapoport; [email-masked]
Subject: Re: Re : [PWE3] STP BPDU tunneling over PWs

Hi Wim,

Best regards,
Tao

---

From: Tao Gu <[email-masked]>
Date: Wed, 23 Jan 2008 09:22:34 +0800

> [Yetik] yes, but you already need a demarcation device and/or for
Sounds like a demarcation device mandatory between a CE and a PE, could 
you confirm?

> [Yetik] Yes that can also be supported.
You mean the L2 MTU will add a third VLAN tag on traffic that's already 
double tagged?
That's certainly not what Marc described in his earlier email:

"Case 1.2 : QinQ traffic, S-VLAN is service delimiter.
Each customer send .1q traffic with (or without) MSTP frames. the L2 MTU 
switch will apply .1ad encap on it, and MSTP frames will be S-VLAN 
tagged as well as other customer data frames."

Could you clarify?

Best regards,
Tao
>> used to provide different services  (VLAN 10 = Internet Access, VLAN
>>     
> 20
>   
>> = Private E-LAN, ...).
>>
>> In that case, I don't see how you can have a common STP protocol
>>     
> shared
>   
>> For that case, you just run an extra VPLS instance with  VLAN
>>     
> 0/untagged
>   
>> as service delimiter, that encaps STP and transport BPDUs between the
>>     
> 2
>   
>> If I understand you correctly, you are saying an intermediate L2 MTU
>>     
> is
>   
>> network the customer is based .1q or .1ad) embedded in customer
>>     
> traffic
>   
>>> the L2 MTU switch will apply .1ad encap on it, and MSTP frames will
>>>       
> be
>   
>>>     
>>>       
>>> - BPDU 1.q tagged, customer frames .1ad tagged BPDU are then
>>>       
> generated
>   
>>>     
>>>       
>>   
>>     
>>> When Vlan is service-delimiting on Ethernet LAN AC, it will be used
>>>       
> to
>   
>>>     
>>>       
>> does mention STP PDUs "received by Customer Network Ports and
>>     
> addressed
>   
>>> but doesn't seem to realize that STP PDUs are untagged thus can not
>>>       
> be
>   
>>>     
>>>

---

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 23 Jan 2008 10:36:10 -0600

[Yetik] That is correct. Perhaps not "must", but "should".

[Yetik] That is a solution, but not necessarily the only one. As Marc
describes below, customer's outer tag can be the service delimiter for
the service provider. Since QinQ customer already tags STP frames with
its own S-VLAN tunneling STP frames will not be a problem for the
service provider any more. Hope this helps.

Could you clarify?

Best regards,
Tao