Subject: Re: [PATCH net 0/4] bridge: Fix problems around the PVID

From: Vlad Yasevich <[email-masked]>
Date: Mon, 23 Sep 2013 10:41:00 -0400

On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich wrote:
>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
>>> On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
>>>> From: Toshiaki Makita <[email-masked]>
>>>> Date: Tue, 10 Sep 2013 19:27:54 +0900
>>>>
>>>>> There seem to be some undesirable behaviors related with PVID.
>>>>> 1. It has no effect assigning PVID to a port. PVID cannot be applied
>>>>> to any frame regardless of whether we set it or not.
>>>>> 2. FDB entries learned via frames applied PVID are registered with
>>>>> VID 0 rather than VID value of PVID.
>>>>> 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
>>>>> This leads interoperational problems such as sending frames with VID
>>>>> 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
>>>>> 0 as they belong to VLAN 0, which is expected to be handled as they have
>>>>> no VID according to IEEE 802.1Q.
>>>>>
>>>>> Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
>>>>> is fixed, because we cannot activate PVID due to it.
>>>>
>>>> Please work out the issues in patch #2 with Vlad and resubmit this
>>>> series.
>>>>
>>>> Thank you.
>>>
>>> I'm hovering between whether we should fix the issue by changing vlan 0
>>> interface behavior in 8021q module or enabling a bridge port to sending
>>> priority-tagged frames, or another better way.
>>>
>>> If you could comment it, I'd appreciate it :)
>>>
>>>
>>> BTW, I think what is discussed in patch #2 is another problem about
>>> handling priority-tags, and it exists without this patch set applied.
>>> It looks like that we should prepare another patch set than this to fix
>>> that problem.
>>>
>>> Should I include patches that fix the priority-tags problem in this
>>> patch set and resubmit them all together?
>>>
>>
>> I am thinking that we might need to do it in bridge and it looks like
>> the simplest way to do it is to have default priority regeneration table
>> (table 6-5 from 802.1Q doc).
>>
>> That way I think we would conform to the spec.
>>
>> -vlad
>
> Unfortunately I don't think the default priority regeneration table
> resolves the problem because IEEE 802.1Q says that a VLAN-aware bridge
> can transmit untagged or VLAN-tagged frames only (the end of section 7.5
> and 8.1.7).
>
> No mechanism to send priority-tagged frames is found as far as I can see
> the standard. I think the regenerated priority is used for outgoing PCP
> field only if egress policy is not untagged (i.e. transmitting as
> VLAN-tagged), and unused if untagged (Section 6.9.2 3rd/4th Paragraph).
>
> If we want to transmit priority-tagged frames from a bridge port, I
> think we need to implement a new (optional) feature that is above the
> standard, as I stated previously.
>
> How do you feel about adding a per-port policy that enables a bridge to
> send priority-tagged frames instead of untagged frames when egress
> policy for the port is untagged?
> With this change, we can transmit frames for a given vlan as either all
> untagged, all priority-tagged or all VLAN-tagged.

That would work.  What I am thinking is that we do it by special casing
the vid 0 egress policy specification.  Let it be untagged by default 
and if it is tagged, then we preserve the priority field and forward
it on.

This keeps the API stable and doesn't require user/admin from knowing 
exactly what happens.  Default operation conforms to the spec and allows
simple change to make it backward-compatible.

What do you think.  I've done a simple prototype of this an it seems to 
work with the VMs I am testing with.

-vlad

>
> Thanks,
>
> Toshiaki Makita
>
>>
>>>
>>> Thanks,
>>>
>>> Toshiaki Makita
>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to [email-masked]
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>