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

From: Vlad Yasevich <[email-masked]>
Date: Fri, 11 Oct 2013 10:14:17 -0400

On 10/11/2013 03:34 AM, Toshiaki Makita wrote:
> On Wed, 2013-10-09 at 11:01 -0400, Vlad Yasevich wrote:
>> On 10/01/2013 07:56 AM, Toshiaki Makita wrote:
>>> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote:
>>>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote:
>>>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote:
>>>>>> On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
>>>>>>> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
>>>>>>>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
>>>>>>>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
>>>>>>>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
>>>>>>>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
>>>>>>>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
>>>>>>>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you saying that - by default, set the 0th bit of
>>>>>>>>>>>>> untagged_bitmap; and - if we unset the 0th bit and
>>>>>>>>>>>>> set the "vid"th bit, we transmit frames classified as
>>>>>>>>>>>>> belonging to VLAN "vid" as priority-tagged?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If so, though it's attractive to keep current API,
>>>>>>>>>>>>> I'm worried about if it could be a bit confusing and
>>>>>>>>>>>>> not intuitive for kernel/iproute2 developers that VID
>>>>>>>>>>>>> 0 has a special meaning only in the egress policy.
>>>>>>>>>>>>> Wouldn't it be better to adding a new member to
>>>>>>>>>>>>> struct net_port_vlans instead of using VID 0 of
>>>>>>>>>>>>> untagged_bitmap?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or are you saying that we use a new flag in struct
>>>>>>>>>>>>> net_port_vlans but use the BRIDGE_VLAN_INFO_UNTAGGED
>>>>>>>>>>>>> bit with VID 0 in netlink to set the flag?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even in that case, I'm afraid that it might be
>>>>>>>>>>>>> confusing for developers for the same reason. We are
>>>>>>>>>>>>> going to prohibit to specify VID with 0 (and 4095) in
>>>>>>>>>>>>> adding/deleting a FDB entry or a vlan filtering
>>>>>>>>>>>>> entry, but it would allow us to use VID 0 only when a
>>>>>>>>>>>>> vlan filtering entry is configured. I am thinking a
>>>>>>>>>>>>> new nlattr is a straightforward approach to
>>>>>>>>>>>>> configure it.
>>>>>>>>>>>>
>>>>>>>>>>>> By making this an explicit attribute it makes vid 0 a
>>>>>>>>>>>> special case for any automatic tool that would
>>>>>>>>>>>> provision such filtering.  Seeing vid 0 would mean that
>>>>>>>>>>>> these tools would have to know that this would have to
>>>>>>>>>>>> be translated to a different attribute instead of
>>>>>>>>>>>> setting the policy values.
>>>>>>>>>>>
>>>>>>>>>>> Yes, I agree with you that we can do it by the way you
>>>>>>>>>>> explained. What I don't understand is the advantage of
>>>>>>>>>>> using vid 0 over another way such as adding a new
>>>>>>>>>>> nlattr. I think we can indicate transmitting
>>>>>>>>>>> priority-tags explicitly by such a nlattr. Using vid 0
>>>>>>>>>>> seems to be easier to implement than a new nlattr, but,
>>>>>>>>>>> for me, it looks less intuitive and more difficult to
>>>>>>>>>>> maintain because we have to care about vid 0 instead of
>>>>>>>>>>> simply ignoring it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The point I am trying to make is that regardless of the
>>>>>>>>>> approach someone has to know what to do when enabling
>>>>>>>>>> priority tagged frames.  You proposal would require the
>>>>>>>>>> administrator or config tool to have that knowledge.
>>>>>>>>>> Example is: Admin does: bridge vlan set priority on dev
>>>>>>>>>> eth0 Automated app: if (vid == 0) /* Turn on priority
>>>>>>>>>> tagged frame support */
>>>>>>>>>>
>>>>>>>>>> My proposal would require the bridge filtering
>>>>>>>>>> implementation to have it. user tool: bridge vlan add vid 0
>>>>>>>>>> tagged Automated app:  No special case.
>>>>>>>>>>
>>>>>>>>>> IMO its better to have 1 piece code handling the special
>>>>>>>>>> case then putting it multiple places.
>>>>>>>>>
>>>>>>>>> Thank you for the detailed explanation. Now I understand your
>>>>>>>>> intention.
>>>>>>>>>
>>>>>>>>> I have one question about your proposal. I guess the way to
>>>>>>>>> enable priority-tagged is something like bridge vlan add vid
>>>>>>>>> 10 dev eth0 bridge vlan add vid 10 dev vnet0 pvid untagged
>>>>>>>>> bridge vlan add vid 0 dev vnet0 tagged where vnet0 has sub
>>>>>>>>> interface vnet0.0.
>>>>>>>>>
>>>>>>>>> Here the admin have to know the egress policy is applied to a
>>>>>>>>> frame twice in a certain order when it is transmitted from
>>>>>>>>> the port vnet0 attached, that is, first, a frame with vid 10
>>>>>>>>> get untagged, and then, an untagged frame get
>>>>>>>>> priority-tagged.
>>>>>>>>>
>>>>>>>>> This behavior looks difficult to know without previous
>>>>>>>>> knowledge. Any good idea to avoid such a need for the admin's
>>>>>>>>> additional knowledge?
>>>>>>>>
>>>>>>>> To me, the fact that there is vnet0.0 (or typically, there is
>>>>>>>> eth0.0 in the guest or on the remote host) already tells the
>>>>>>>> admin vlan 0 has to be tagged.  The fact that we codify this in
>>>>>>>> the policy makes it explicit.
>>>>>>>
>>>>>>> My worry is that the admin might not be able to guess how to use
>>>>>>> bridge commands to enable priority-tag without any additional
>>>>>>> hint in "man bridge", "bridge vlan help", etc. I actually
>>>>>>> couldn't hit upon such a usage before seeing example commands you
>>>>>>> gave, because I had never think the egress policy could be
>>>>>>> applied twice.
>>>>>>>
>>>>>>>>
>>>>>>>> However, I can see strong argument to be made for an addition
>>>>>>>> egress policy attribute that could be for instance:
>>>>>>>>
>>>>>>>> bridge vlan add vid 10 dev eth0 pvid bridge vlan add vid 10 dev
>>>>>>>> vnet0 pvid untagged prio_tag
>>>>>>>>
>>>>>>>> But this has the same connotations as wrt to egress policy.
>>>>>>>> The 2 policies are applied: (1) untag the frame. (2) add
>>>>>>>> priority_tag.
>>>>>>>>
>>>>>>>> (2) only happens if initial fame received on eth0 was priority
>>>>>>>> tagged.
>>>>>>>
>>>>>>> If we do so, we will not be able to communicate using vlan 0
>>>>>>> interface under a certain circumstance. Eth0 can be receive mixed
>>>>>>> untagged and priority-tagged frames according to the network
>>>>>>> element it is connected to: for example, Open vSwitch can send
>>>>>>> such two kinds of frames from the same port even if original
>>>>>>> incoming frames belong to the same vlan.
>>>>>>
>>>>>> Which priority would you assign to the frame that was received
>>>>>> untagged?
>>>>>
>>>>> Untagged frame's priority is by default 0, so I think 0 is likely.
>>>>>
>>>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible
>>>>> parameter value are the values in the M_UNITDATA.indication.
>>>>>
>>>>> M_UNITDATA is passed from ISS.
>>>>>
>>>>> 802.1Q 6.7.1 The priority parameter provided in a data indication
>>>>> primitive shall take the value of the Default User Priority parameter
>>>>> for the Port through which the MAC frame was received. The default
>>>>> value of this parameter is 0, it may be set by management in which
>>>>> case the capability to set it to any of the values 0 through 7 shall
>>>>> be provided.
>>>>>
>>>>>>
>>>>>>> In this situation, we can only receive frames that is
>>>>>>> priority-tagged when received on eth0.
>>>>>>
>>>>>> Not sure I understand.  Let's look at this config: bridge vlan add
>>>>>> vid 10 dev eth0 pvid bridge vlan add vid 10 dev vnet0 pvid untagged
>>>>>> prio_tag
>>>>>>
>>>>>> Here, eth0 is allowed to receive vid 10 tagged, untagged, and
>>>>>> prio_tagged (if we look at the patch 2 from this set). Now, frame
>>>>>> is forwarded to vnet0. 1) if the frame had vid 10 in the tag or was
>>>>>> untagged, it should probably be sent untagged. 2) if the frame had
>>>>>> a priority tag, it should probably be sent as such.
>>>>>>
>>>>>> Now, I think a case could be made that if the frame had any
>>>>>> priority markings in the vlan header, we should try to preserve
>>>>>> those markings if prio_tag is turned on.  We can assume value of 0
>>>>>> means not set.
>>>>>
>>>>> If we don't insert prio_tag when PCP is 0, we might receive mixed
>>>>> priority-tagged and untagged frames on eth0.
>>>>
>>>> Right, and that's what you were trying to handle in your patch:
>>>>
>>>>> +		/* PVID is set on this port.  Any untagged or priority-tagged +
>>>>> * ingress frame is considered to belong to this vlan. */
>>>>
>>>> So, in this case we are prepared to handle the "mixed" scenario on ingress.
>>>>
>>>>> Even if we are sending frames from eth0.0 with some priority other
>>>>> than 0, we could receive frames with priority 0 or untagged on the
>>>>> other side of the bridge.
>>>>> For example, if we receive untagged arp reply on the bridge port, we
>>>>> migit not be able to communicate with such an end station, because
>>>>> untagged reply will not be passed to eth0.0.
>>>>
>>>> So the ARP request was sent tagged, but the reply came back untagged?
>>>
>>> Yes, it can happen.
>>> These are problematic cases.
>>>
>>> Example 1:
>>>               prio_tagged         prio_tagged
>>> +------------+ ---> +------------+ ---> +----------+
>>> |guest eth0.0|------|host1 Bridge|------|host2 eth0|
>>> +------------+ <--- +------------+ <--- +----------+
>>>                untagged            untagged
>>>
>>> Note: Host2 eth0, which is an interface on Linux, can receive
>>> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0).
>>
>> Hmm..  Just to see if this works, I ran the this scenario with
>> a dumb switch in the middle, and it did not work as you noted.
>> I then realized that one of the kernels was rather old and after
>> updating it, behaved differently.  The communication still didn't
>> work, but host2 behaved properly.
>>
>>>>
>>>> How does that work when the end station is attached directly to the
>>>> HW switch instead of a linux bridge?
>>>>
>>>> The station configures eth0.0 and sends priority-tagged traffic to
>>>> the HW switch.  If the HW switch sends back untagged traffic, then
>>>> the untagged traffic will never reach eth0.0.
>>>
>>> Currently we cannot communicate using eth0.0 via directly connected
>>> 802.1Q conformed switch, because we never receive priority-tagged frames
>>> from the switch.
>>> It is not a problem of Linux bridge and is why I wondered whether it
>>> should be fixed by bridge or vlan 0 interface.
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> IMO, if prio_tag is configured, the bridge should send any
>>>>>>> untagged frame as priority-tagged regardless of whatever it is on
>>>>>>> eth0.
>>>>>>
>>>>>> Which priority would you use, 0?  You are not guaranteed to
>>>>>> properly deliver the traffic then for a configuration such as: VM:
>>>>>> eth0: 10.0.0.1/24 eth0.0: 10.0.1.1/24
>>>>>
>>>>> I'd like to use priority 0 for untagged frames.
>>>>>
>>>>> I am assuming that one of our goals is at least that eth0.0 comes to
>>>>> be able to communicate with another end station. It seems to be hard
>>>>> to use both eth0 and eth0.0 simultaneously.
>>>>
>>>> I understand, but I don't agree that we should always tag.
>>>>
>>>> Consider config:
>>>>
>>>>       hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station)
>>>>
>>>> If the end station sends priority-tagged traffic it should receive
>>>> priority tagged traffic back.  Otherwise, untagged traffic may be
>>>> dropped by the end station.  This is true whether it is connected to
>>>> the hw switch or Linux bridge.
>>>
>>> Though such a behavior is generally not necessary as far as I can read
>>> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think.
>>> My proposal aims to resolve it at least when we use Linux bridge.
>>>
>>> Example configuration:
>>> 	bridge vlan add vid 10 dev eth1 pvid untagged
>>> 	bridge vlan add vid 10 dev eth0
>>> 	bridge vlan set prio_tag on dev eth1
>>>
>>> Intended behavior:
>>>
>>>           VID10-tagged                     prio_tagged
>>> +---------+ <--- +------------------------+ <--- +-----------------+
>>> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station|
>>> +---------+ ---> +------------------------+ ---> +-----------------+
>>>           VID10-tagged                     prio_tagged
>>>                                 (always if egress policy untagged)
>>
>> Ok, I think you've convinced me that this is the right approach. The
>> only thing that I am not crazy about is the API.  I'd almost want to
>> introduce a new flag that can be set in a 'vlan add' or 'vlan set'
>> command that communicates a new policy.
>
> I'm glad that we reached a consensus on the approach :)
>
> I agree with you that the API is flag based.
> I'm guessing your intention is that 'vlan add' means a per vlan per port
> policy and 'vlan set' means a per port one, that is,
> 	'vlan add': bridge vlan add vid 10 dev eth1 prio_tag
> 	'vlan set': bridge vlan set prio_tag on dev eth1
>
> I think they can behave differently only when we set untagged to
> multiple vlans on the same port.
>
> 'vlan add' example with vid 10 and 20:
> 	bridge vlan add vid 10 dev eth1 pvid untagged prio_tag
> 	bridge vlan add vid 10 dev eth0
> 	bridge vlan add vid 20 dev eth1 untagged
> 	bridge vlan add vid 20 dev eth2
>
>           VID10-tagged                  prio_tagged (from eth0)
> +---------+ ---> +------------------------+ ---> +-----------------+
> |hw switch|------|eth0                eth1|------|em1.0:end station|
> +---------+      |      Linux Bridge      | ---> +-----------------+
> +---------+      |                        | *untagged*
> |hw switch|------|eth2                    | (from eth2)
> +---------+ ---> +------------------------+
>           VID20-tagged
>

This is what I was thinking of, but I was actually considering that
untagged and prio_tag can not co-exist for the same vlan as they don't
really make sence together anymore.

So one can do:
	bridge vlan add vid 10 dev eth1 pvid prio_tag
	bridge vlan add vid 20 dev eth1 untagged

and recieve VLAN 10 as priority tagged and vlan 20 as untagged.

-vlad

>
> 'vlan set' example with vid 10 and 20:
> 	bridge vlan add vid 10 dev eth1 pvid untagged
> 	bridge vlan add vid 10 dev eth0
> 	bridge vlan add vid 20 dev eth1 untagged
> 	bridge vlan add vid 20 dev eth2
> 	bridge vlan set prio_tag on dev eth1
>
>           VID10-tagged                  prio_tagged (from eth0)
> +---------+ ---> +------------------------+ ---> +-----------------+
> |hw switch|------|eth0                eth1|------|em1.0:end station|
> +---------+      |      Linux Bridge      | ---> +-----------------+
> +---------+      |                        | prio_tagged
> |hw switch|------|eth2                    | (from eth2)
> +---------+ ---> +------------------------+
>           VID20-tagged
>
> Em1.0 can always receive traffic from eth1 if we adopt 'vlan set'.
> However, I cannot imagine when multiple untagged vlans is required, so
> cannot figure out whether 'vlan add' is useful or harmful.
> Anyway, both of approaches are OK with me.
>
> Thanks,
> Toshiaki Makita
>
>>
>> Thanks
>> -vlad
>>
>>>
>>> Thanks,
>>>
>>> Toshiaki Makita
>>>
>>>>
>>>> -vlad
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Toshiaki Makita
>>>>>
>>>>>>
>>>>>> -vlad
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I think I am ok with either approach.  Explicit vid 0 policy is
>>>>>>>> easier for automatic provisioning.   The flag based one is
>>>>>>>> easier for admin/ manual provisioning.
>>>>>>>
>>>>>>> Supposing we have to add something to help or man in any case, I
>>>>>>> think flag based is better. The format below seems to suitable
>>>>>>> for a per-port policy. bridge vlan set prio_tag on dev vnet0
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Toshiaki Makita
>>>>>>>
>>>>>>>>
>>>>>>>> -vlad.
>>>>>>>>
>>>>>>>> -vlad
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks -vlad
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> How it is implemented internally in the kernel isn't as
>>>>>>>>>>>> big of an issue. We can do it as a separate flag or as
>>>>>>>>>>>> part of existing policy.
>>>>>>>>>>>>
>>>>>>>>>>>> -vlad
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Toshiaki Makita
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> 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
>
>