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

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

[Toshiaki Makita]

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.

This is my analysis for each behavior.
1. We are using VLAN_TAG_PRESENT bit when getting PVID, and not when
adding/deleting PVID.
It can be fixed in either way using or not using VLAN_TAG_PRESENT,
but I think the latter is slightly more efficient.

2. We are setting skb->vlan_tci with the value of PVID but the variable
vid, which is used in FDB later, is set to 0 at br_allowed_ingress()
when untagged frames arrive at a port with PVID valid. I'm afraid that
vid should be updated to the value of PVID if PVID is valid.

3. According to IEEE 802.1Q-2005 (6.7.1 and Table 9-2), we cannot use
VID 0 or 4095 as a PVID.
It looks like that there are more stuff to consider.

- VID 0:
VID 0 shall not be configured in any FDB entry and used in a tag header
to indicate it is a 802.1p priority-tagged frame.
Priority-tagged frames should be applied PVID (from IEEE 802.1Q 6.7.1).
In my opinion, since we can filter incomming priority-tagged frames by
deleting PVID, we don't need to filter them by vlan_bitmap.
In other words, priority-tagged frames don't have VID 0 but have no VID,
which is the same as untagged frames, and should be filtered by unsetting
PVID.
So, not only we cannot set PVID as 0, but also we don't need to add 0 to
vlan_bitmap, which enable us to simply forbid to add vlan 0.

- VID 4095:
VID 4095 shall not be transmitted in a tag header. This VID value may be
used to indicate a wildcard match for the VID in management operations or
FDB entries (from IEEE 802.1Q Table 9-2).
In current implementation, we can create a static FDB entry with all
existing VIDs by not specifying any VID when creating it.
I don't think this way to add wildcard-like entries needs to change,
and VID 4095 looks no use and can be unacceptable to add.

Consequently, I believe what we should do for 3rd problem is below:
- Not allowing VID 0 and 4095 to be added.
- Applying PVID to priority-tagged (VID 0) frames.

Patch set follows this mail.
The order of patches is not the same as described above, because the way
to fix 1st problem is based on the assumption that we don't use VID 0 as
a PVID, which is realized by fixing 3rd problem.
(1/4)(2/4): Fix 3rd problem.
(3/4): Fix 1st problem.
(4/4): Fix 2nd probelm.

If something wrong or any misunderstanding is found, please comment.
If another way to fix is better such as using VLAN_TAG_PRESENT, I can
submit modified patches.

Thanks,

Toshiaki Makita

Toshiaki Makita (4):
  bridge: Don't use VID 0 and 4095 in vlan filtering
  bridge: Handle priority-tagged frames properly
  bridge: Fix the way the PVID is referenced
  bridge: Fix updating FDB entries when the PVID is applied

 net/bridge/br_fdb.c     |   4 +-
 net/bridge/br_netlink.c |   2 +-
 net/bridge/br_private.h |   4 +-
 net/bridge/br_vlan.c    | 125 ++++++++++++++++++++++++++----------------------
 4 files changed, 71 insertions(+), 64 deletions(-)

-- 
1.8.1.2

[PATCH net 1/4] bridge: Don't use VID 0 and 4095 in vlan filtering

[Toshiaki Makita]

IEEE 802.1Q says that:
- VID 0 shall not be configured as a PVID, or configured in any Filtering
Database entry.
- VID 4095 shall not be configured as a PVID, or transmitted in a tag
header. This VID value may be used to indicate a wildcard match for the VID
in management operations or Filtering Database entries.
(See IEEE 802.1Q-2005 6.7.1 and Table 9-2)

Don't accept adding these VIDs in the vlan_filtering implementation.

Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
 net/bridge/br_fdb.c     |  4 +-
 net/bridge/br_netlink.c |  2 +-
 net/bridge/br_vlan.c    | 97 +++++++++++++++++++++++--------------------------
 3 files changed, 49 insertions(+), 54 deletions(-)

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index ffd5874..33e8f23 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -700,7 +700,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
 
 		vid = nla_get_u16(tb[NDA_VLAN]);
 
-		if (vid >= VLAN_N_VID) {
+		if (!vid || vid >= VLAN_VID_MASK) {
 			pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
 				vid);
 			return -EINVAL;
@@ -794,7 +794,7 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
 
 		vid = nla_get_u16(tb[NDA_VLAN]);
 
-		if (vid >= VLAN_N_VID) {
+		if (!vid || vid >= VLAN_VID_MASK) {
 			pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
 				vid);
 			return -EINVAL;
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index b9259ef..9bac61e 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -243,7 +243,7 @@ static int br_afspec(struct net_bridge *br,
 
 		vinfo = nla_data(tb[IFLA_BRIDGE_VLAN_INFO]);
 
-		if (vinfo->vid >= VLAN_N_VID)
+		if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK)
 			return -EINVAL;
 
 		switch (cmd) {
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 9a9ffe7..21b6d21 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -45,37 +45,34 @@ static int __vlan_add(struct net_port_vlans *v, u16 vid, u16 flags)
 		return 0;
 	}
 
-	if (vid) {
-		if (v->port_idx) {
-			p = v->parent.port;
-			br = p->br;
-			dev = p->dev;
-		} else {
-			br = v->parent.br;
-			dev = br->dev;
-		}
-		ops = dev->netdev_ops;
-
-		if (p && (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
-			/* Add VLAN to the device filter if it is supported.
-			 * Stricly speaking, this is not necessary now, since
-			 * devices are made promiscuous by the bridge, but if
-			 * that ever changes this code will allow tagged
-			 * traffic to enter the bridge.
-			 */
-			err = ops->ndo_vlan_rx_add_vid(dev, htons(ETH_P_8021Q),
-						       vid);
-			if (err)
-				return err;
-		}
-
-		err = br_fdb_insert(br, p, dev->dev_addr, vid);
-		if (err) {
-			br_err(br, "failed insert local address into bridge "
-			       "forwarding table\n");
-			goto out_filt;
-		}
+	if (v->port_idx) {
+		p = v->parent.port;
+		br = p->br;
+		dev = p->dev;
+	} else {
+		br = v->parent.br;
+		dev = br->dev;
+	}
+	ops = dev->netdev_ops;
+
+	if (p && (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
+		/* Add VLAN to the device filter if it is supported.
+		 * Stricly speaking, this is not necessary now, since
+		 * devices are made promiscuous by the bridge, but if
+		 * that ever changes this code will allow tagged
+		 * traffic to enter the bridge.
+		 */
+		err = ops->ndo_vlan_rx_add_vid(dev, htons(ETH_P_8021Q),
+					       vid);
+		if (err)
+			return err;
+	}
 
+	err = br_fdb_insert(br, p, dev->dev_addr, vid);
+	if (err) {
+		br_err(br, "failed insert local address into bridge "
+		       "forwarding table\n");
+		goto out_filt;
 	}
 
 	set_bit(vid, v->vlan_bitmap);
@@ -98,7 +95,7 @@ static int __vlan_del(struct net_port_vlans *v, u16 vid)
 	__vlan_delete_pvid(v, vid);
 	clear_bit(vid, v->untagged_bitmap);
 
-	if (v->port_idx && vid) {
+	if (v->port_idx) {
 		struct net_device *dev = v->parent.port->dev;
 		const struct net_device_ops *ops = dev->netdev_ops;
 
@@ -248,7 +245,9 @@ bool br_allowed_egress(struct net_bridge *br,
 	return false;
 }
 
-/* Must be protected by RTNL */
+/* Must be protected by RTNL.
+ * Must be called with vid in range from 1 to 4094 inclusive.
+ */
 int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags)
 {
 	struct net_port_vlans *pv = NULL;
@@ -278,7 +277,9 @@ out:
 	return err;
 }
 
-/* Must be protected by RTNL */
+/* Must be protected by RTNL.
+ * Must be called with vid in range from 1 to 4094 inclusive.
+ */
 int br_vlan_delete(struct net_bridge *br, u16 vid)
 {
 	struct net_port_vlans *pv;
@@ -289,14 +290,9 @@ int br_vlan_delete(struct net_bridge *br, u16 vid)
 	if (!pv)
 		return -EINVAL;
 
-	if (vid) {
-		/* If the VID !=0 remove fdb for this vid. VID 0 is special
-		 * in that it's the default and is always there in the fdb.
-		 */
-		spin_lock_bh(&br->hash_lock);
-		fdb_delete_by_addr(br, br->dev->dev_addr, vid);
-		spin_unlock_bh(&br->hash_lock);
-	}
+	spin_lock_bh(&br->hash_lock);
+	fdb_delete_by_addr(br, br->dev->dev_addr, vid);
+	spin_unlock_bh(&br->hash_lock);
 
 	__vlan_del(pv, vid);
 	return 0;
@@ -329,7 +325,9 @@ unlock:
 	return 0;
 }
 
-/* Must be protected by RTNL */
+/* Must be protected by RTNL.
+ * Must be called with vid in range from 1 to 4094 inclusive.
+ */
 int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
 {
 	struct net_port_vlans *pv = NULL;
@@ -363,7 +361,9 @@ clean_up:
 	return err;
 }
 
-/* Must be protected by RTNL */
+/* Must be protected by RTNL.
+ * Must be called with vid in range from 1 to 4094 inclusive.
+ */
 int nbp_vlan_delete(struct net_bridge_port *port, u16 vid)
 {
 	struct net_port_vlans *pv;
@@ -374,14 +374,9 @@ int nbp_vlan_delete(struct net_bridge_port *port, u16 vid)
 	if (!pv)
 		return -EINVAL;
 
-	if (vid) {
-		/* If the VID !=0 remove fdb for this vid. VID 0 is special
-		 * in that it's the default and is always there in the fdb.
-		 */
-		spin_lock_bh(&port->br->hash_lock);
-		fdb_delete_by_addr(port->br, port->dev->dev_addr, vid);
-		spin_unlock_bh(&port->br->hash_lock);
-	}
+	spin_lock_bh(&port->br->hash_lock);
+	fdb_delete_by_addr(port->br, port->dev->dev_addr, vid);
+	spin_unlock_bh(&port->br->hash_lock);
 
 	return __vlan_del(pv, vid);
 }
-- 
1.8.1.2

[PATCH net 2/4] bridge: Handle priority-tagged frames properly

[Toshiaki Makita]

IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
use the PVID for the port as its VID.
(See IEEE 802.1Q-2005 6.7.1 and Table 9-2)

Apply the PVID to not only untagged frames but also priority-tagged frames.

Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
 net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 21b6d21..5a9c44a 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -189,6 +189,8 @@ out:
 bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
 			struct sk_buff *skb, u16 *vid)
 {
+	int err;
+
 	/* If VLAN filtering is disabled on the bridge, all packets are
 	 * permitted.
 	 */
@@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
 	if (!v)
 		return false;
 
-	if (br_vlan_get_tag(skb, vid)) {
+	err = br_vlan_get_tag(skb, vid);
+	if (!*vid) {
 		u16 pvid = br_get_pvid(v);
 
-		/* Frame did not have a tag.  See if pvid is set
-		 * on this port.  That tells us which vlan untagged
-		 * traffic belongs to.
+		/* Frame had a tag with VID 0 or did not have a tag.
+		 * See if pvid is set on this port.  That tells us which
+		 * vlan untagged or priority-tagged traffic belongs to.
 		 */
 		if (pvid == VLAN_N_VID)
 			return false;
 
-		/* PVID is set on this port.  Any untagged ingress
-		 * frame is considered to belong to this vlan.
+		/* PVID is set on this port.  Any untagged or priority-tagged
+		 * ingress frame is considered to belong to this vlan.
 		 */
-		__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
+		if (likely(err))
+			/* Untagged Frame. */
+			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
+		else
+			/* Priority-tagged Frame.
+			 * At this point, We know that skb->vlan_tci had
+			 * VLAN_TAG_PRESENT bit and its VID field was 0x000.
+			 * We update only VID field and preserve PCP field.
+			 */
+			skb->vlan_tci |= pvid;
+
 		return true;
 	}
 
-- 
1.8.1.2

[PATCH net 3/4] bridge: Fix the way the PVID is referenced

[Toshiaki Makita]

We are using the VLAN_TAG_PRESENT bit to detect whether the PVID is
set or not at br_get_pvid(), while we don't care about the bit in
adding/deleting the PVID, which makes it impossible to forward any
incomming untagged frame with vlan_filtering enabled.

Since vid 0 cannot be used for the PVID, we can use vid 0 to indicate
that the PVID is not set, which is slightly more efficient than using
the VLAN_TAG_PRESENT.

Fix the problem by getting rid of using the VLAN_TAG_PRESENT.

Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
 net/bridge/br_private.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 598cb0b..435ca4d 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -646,9 +646,7 @@ static inline u16 br_get_pvid(const struct net_port_vlans *v)
 	 * vid wasn't set
 	 */
 	smp_rmb();
-	return (v->pvid & VLAN_TAG_PRESENT) ?
-			(v->pvid & ~VLAN_TAG_PRESENT) :
-			VLAN_N_VID;
+	return v->pvid ?: VLAN_N_VID;
 }
 
 #else
-- 
1.8.1.2

[PATCH net 4/4] bridge: Fix updating FDB entries when the PVID is applied

[Toshiaki Makita]

We currently set the value that variable vid pointing, which will be used
in FDB later, to 0 at br_allowed_ingress() when we receive untagged or
priority-tagged frames, even though the PVID is valid.
This leads to FDB updates in such a wrong way that they are learned with
VID 0.
Update the value to that of PVID if the PVID is applied.

Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
 net/bridge/br_vlan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 5a9c44a..53f0990 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -217,6 +217,7 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
 		/* PVID is set on this port.  Any untagged or priority-tagged
 		 * ingress frame is considered to belong to this vlan.
 		 */
+		*vid = pvid;
 		if (likely(err))
 			/* Untagged Frame. */
 			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
-- 
1.8.1.2

Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly

[Vlad Yasevich]

On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
> use the PVID for the port as its VID.
> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>
> Apply the PVID to not only untagged frames but also priority-tagged frames.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
>   net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
>   1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 21b6d21..5a9c44a 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -189,6 +189,8 @@ out:
>   bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>   			struct sk_buff *skb, u16 *vid)
>   {
> +	int err;
> +
>   	/* If VLAN filtering is disabled on the bridge, all packets are
>   	 * permitted.
>   	 */
> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>   	if (!v)
>   		return false;
>
> -	if (br_vlan_get_tag(skb, vid)) {
> +	err = br_vlan_get_tag(skb, vid);
> +	if (!*vid) {
>   		u16 pvid = br_get_pvid(v);
>
> -		/* Frame did not have a tag.  See if pvid is set
> -		 * on this port.  That tells us which vlan untagged
> -		 * traffic belongs to.
> +		/* Frame had a tag with VID 0 or did not have a tag.
> +		 * See if pvid is set on this port.  That tells us which
> +		 * vlan untagged or priority-tagged traffic belongs to.
>   		 */
>   		if (pvid == VLAN_N_VID)
>   			return false;
>
> -		/* PVID is set on this port.  Any untagged ingress
> -		 * frame is considered to belong to this vlan.
> +		/* PVID is set on this port.  Any untagged or priority-tagged
> +		 * ingress frame is considered to belong to this vlan.
>   		 */
> -		__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> +		if (likely(err))
> +			/* Untagged Frame. */
> +			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> +		else
> +			/* Priority-tagged Frame.
> +			 * At this point, We know that skb->vlan_tci had
> +			 * VLAN_TAG_PRESENT bit and its VID field was 0x000.
> +			 * We update only VID field and preserve PCP field.
> +			 */
> +			skb->vlan_tci |= pvid;
> +

In the case of a priority tagged frame, we should unroll the 
modification above and restore the VID field to 0.  Otherwise, you
may end up either stripping the vlan header completely or forwarding
with pvid of the ingress port.

-vlad
>   		return true;
>   	}
>
>

Re: [PATCH net 3/4] bridge: Fix the way the PVID is referenced

[Vlad Yasevich]

On 09/10/2013 06:37 AM, Toshiaki Makita wrote:
> We are using the VLAN_TAG_PRESENT bit to detect whether the PVID is
> set or not at br_get_pvid(), while we don't care about the bit in
> adding/deleting the PVID, which makes it impossible to forward any
> incomming untagged frame with vlan_filtering enabled.
>
> Since vid 0 cannot be used for the PVID, we can use vid 0 to indicate
> that the PVID is not set, which is slightly more efficient than using
> the VLAN_TAG_PRESENT.
>
> Fix the problem by getting rid of using the VLAN_TAG_PRESENT.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>

Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>

-vlad

> ---
>   net/bridge/br_private.h | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 598cb0b..435ca4d 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -646,9 +646,7 @@ static inline u16 br_get_pvid(const struct net_port_vlans *v)
>   	 * vid wasn't set
>   	 */
>   	smp_rmb();
> -	return (v->pvid & VLAN_TAG_PRESENT) ?
> -			(v->pvid & ~VLAN_TAG_PRESENT) :
> -			VLAN_N_VID;
> +	return v->pvid ?: VLAN_N_VID;
>   }
>
>   #else
>

Re: [PATCH net 1/4] bridge: Don't use VID 0 and 4095 in vlan filtering

[Vlad Yasevich]

On 09/10/2013 06:32 AM, Toshiaki Makita wrote:
> IEEE 802.1Q says that:
> - VID 0 shall not be configured as a PVID, or configured in any Filtering
> Database entry.
> - VID 4095 shall not be configured as a PVID, or transmitted in a tag
> header. This VID value may be used to indicate a wildcard match for the VID
> in management operations or Filtering Database entries.
> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>
> Don't accept adding these VIDs in the vlan_filtering implementation.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>

Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>

-vlad
> ---
>   net/bridge/br_fdb.c     |  4 +-
>   net/bridge/br_netlink.c |  2 +-
>   net/bridge/br_vlan.c    | 97 +++++++++++++++++++++++--------------------------
>   3 files changed, 49 insertions(+), 54 deletions(-)
>
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index ffd5874..33e8f23 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -700,7 +700,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
>
>   		vid = nla_get_u16(tb[NDA_VLAN]);
>
> -		if (vid >= VLAN_N_VID) {
> +		if (!vid || vid >= VLAN_VID_MASK) {
>   			pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
>   				vid);
>   			return -EINVAL;
> @@ -794,7 +794,7 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
>
>   		vid = nla_get_u16(tb[NDA_VLAN]);
>
> -		if (vid >= VLAN_N_VID) {
> +		if (!vid || vid >= VLAN_VID_MASK) {
>   			pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
>   				vid);
>   			return -EINVAL;
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index b9259ef..9bac61e 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -243,7 +243,7 @@ static int br_afspec(struct net_bridge *br,
>
>   		vinfo = nla_data(tb[IFLA_BRIDGE_VLAN_INFO]);
>
> -		if (vinfo->vid >= VLAN_N_VID)
> +		if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK)
>   			return -EINVAL;
>
>   		switch (cmd) {
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 9a9ffe7..21b6d21 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -45,37 +45,34 @@ static int __vlan_add(struct net_port_vlans *v, u16 vid, u16 flags)
>   		return 0;
>   	}
>
> -	if (vid) {
> -		if (v->port_idx) {
> -			p = v->parent.port;
> -			br = p->br;
> -			dev = p->dev;
> -		} else {
> -			br = v->parent.br;
> -			dev = br->dev;
> -		}
> -		ops = dev->netdev_ops;
> -
> -		if (p && (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
> -			/* Add VLAN to the device filter if it is supported.
> -			 * Stricly speaking, this is not necessary now, since
> -			 * devices are made promiscuous by the bridge, but if
> -			 * that ever changes this code will allow tagged
> -			 * traffic to enter the bridge.
> -			 */
> -			err = ops->ndo_vlan_rx_add_vid(dev, htons(ETH_P_8021Q),
> -						       vid);
> -			if (err)
> -				return err;
> -		}
> -
> -		err = br_fdb_insert(br, p, dev->dev_addr, vid);
> -		if (err) {
> -			br_err(br, "failed insert local address into bridge "
> -			       "forwarding table\n");
> -			goto out_filt;
> -		}
> +	if (v->port_idx) {
> +		p = v->parent.port;
> +		br = p->br;
> +		dev = p->dev;
> +	} else {
> +		br = v->parent.br;
> +		dev = br->dev;
> +	}
> +	ops = dev->netdev_ops;
> +
> +	if (p && (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
> +		/* Add VLAN to the device filter if it is supported.
> +		 * Stricly speaking, this is not necessary now, since
> +		 * devices are made promiscuous by the bridge, but if
> +		 * that ever changes this code will allow tagged
> +		 * traffic to enter the bridge.
> +		 */
> +		err = ops->ndo_vlan_rx_add_vid(dev, htons(ETH_P_8021Q),
> +					       vid);
> +		if (err)
> +			return err;
> +	}
>
> +	err = br_fdb_insert(br, p, dev->dev_addr, vid);
> +	if (err) {
> +		br_err(br, "failed insert local address into bridge "
> +		       "forwarding table\n");
> +		goto out_filt;
>   	}
>
>   	set_bit(vid, v->vlan_bitmap);
> @@ -98,7 +95,7 @@ static int __vlan_del(struct net_port_vlans *v, u16 vid)
>   	__vlan_delete_pvid(v, vid);
>   	clear_bit(vid, v->untagged_bitmap);
>
> -	if (v->port_idx && vid) {
> +	if (v->port_idx) {
>   		struct net_device *dev = v->parent.port->dev;
>   		const struct net_device_ops *ops = dev->netdev_ops;
>
> @@ -248,7 +245,9 @@ bool br_allowed_egress(struct net_bridge *br,
>   	return false;
>   }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
>   int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags)
>   {
>   	struct net_port_vlans *pv = NULL;
> @@ -278,7 +277,9 @@ out:
>   	return err;
>   }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
>   int br_vlan_delete(struct net_bridge *br, u16 vid)
>   {
>   	struct net_port_vlans *pv;
> @@ -289,14 +290,9 @@ int br_vlan_delete(struct net_bridge *br, u16 vid)
>   	if (!pv)
>   		return -EINVAL;
>
> -	if (vid) {
> -		/* If the VID !=0 remove fdb for this vid. VID 0 is special
> -		 * in that it's the default and is always there in the fdb.
> -		 */
> -		spin_lock_bh(&br->hash_lock);
> -		fdb_delete_by_addr(br, br->dev->dev_addr, vid);
> -		spin_unlock_bh(&br->hash_lock);
> -	}
> +	spin_lock_bh(&br->hash_lock);
> +	fdb_delete_by_addr(br, br->dev->dev_addr, vid);
> +	spin_unlock_bh(&br->hash_lock);
>
>   	__vlan_del(pv, vid);
>   	return 0;
> @@ -329,7 +325,9 @@ unlock:
>   	return 0;
>   }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
>   int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
>   {
>   	struct net_port_vlans *pv = NULL;
> @@ -363,7 +361,9 @@ clean_up:
>   	return err;
>   }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
>   int nbp_vlan_delete(struct net_bridge_port *port, u16 vid)
>   {
>   	struct net_port_vlans *pv;
> @@ -374,14 +374,9 @@ int nbp_vlan_delete(struct net_bridge_port *port, u16 vid)
>   	if (!pv)
>   		return -EINVAL;
>
> -	if (vid) {
> -		/* If the VID !=0 remove fdb for this vid. VID 0 is special
> -		 * in that it's the default and is always there in the fdb.
> -		 */
> -		spin_lock_bh(&port->br->hash_lock);
> -		fdb_delete_by_addr(port->br, port->dev->dev_addr, vid);
> -		spin_unlock_bh(&port->br->hash_lock);
> -	}
> +	spin_lock_bh(&port->br->hash_lock);
> +	fdb_delete_by_addr(port->br, port->dev->dev_addr, vid);
> +	spin_unlock_bh(&port->br->hash_lock);
>
>   	return __vlan_del(pv, vid);
>   }
>

Re: [PATCH net 3/4] bridge: Fix the way the PVID is referenced

[Vlad Yasevich]

On 09/10/2013 06:37 AM, Toshiaki Makita wrote:
> We are using the VLAN_TAG_PRESENT bit to detect whether the PVID is
> set or not at br_get_pvid(), while we don't care about the bit in
> adding/deleting the PVID, which makes it impossible to forward any
> incomming untagged frame with vlan_filtering enabled.
>
> Since vid 0 cannot be used for the PVID, we can use vid 0 to indicate
> that the PVID is not set, which is slightly more efficient than using
> the VLAN_TAG_PRESENT.

Yes, that is simpler.
>
> Fix the problem by getting rid of using the VLAN_TAG_PRESENT.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>

Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>

-vlad

> ---
>   net/bridge/br_private.h | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 598cb0b..435ca4d 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -646,9 +646,7 @@ static inline u16 br_get_pvid(const struct net_port_vlans *v)
>   	 * vid wasn't set
>   	 */
>   	smp_rmb();
> -	return (v->pvid & VLAN_TAG_PRESENT) ?
> -			(v->pvid & ~VLAN_TAG_PRESENT) :
> -			VLAN_N_VID;
> +	return v->pvid ?: VLAN_N_VID;
>   }
>
>   #else
>

Re: [PATCH net 4/4] bridge: Fix updating FDB entries when the PVID is applied

[Vlad Yasevich]

On 09/10/2013 06:39 AM, Toshiaki Makita wrote:
> We currently set the value that variable vid pointing, which will be used
> in FDB later, to 0 at br_allowed_ingress() when we receive untagged or
> priority-tagged frames, even though the PVID is valid.
> This leads to FDB updates in such a wrong way that they are learned with
> VID 0.
> Update the value to that of PVID if the PVID is applied.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>

Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>

-vlad

> ---
>   net/bridge/br_vlan.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 5a9c44a..53f0990 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -217,6 +217,7 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>   		/* PVID is set on this port.  Any untagged or priority-tagged
>   		 * ingress frame is considered to belong to this vlan.
>   		 */
> +		*vid = pvid;
>   		if (likely(err))
>   			/* Untagged Frame. */
>   			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
>

Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly

[Toshiaki Makita]

On Tue, 2013-09-10 at 10:03 -0400, Vlad Yasevich wrote:
> On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
> > IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
> > use the PVID for the port as its VID.
> > (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
> >
> > Apply the PVID to not only untagged frames but also priority-tagged frames.
> >
> > Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> > ---
> >   net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
> >   1 file changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> > index 21b6d21..5a9c44a 100644
> > --- a/net/bridge/br_vlan.c
> > +++ b/net/bridge/br_vlan.c
> > @@ -189,6 +189,8 @@ out:
> >   bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >   			struct sk_buff *skb, u16 *vid)
> >   {
> > +	int err;
> > +
> >   	/* If VLAN filtering is disabled on the bridge, all packets are
> >   	 * permitted.
> >   	 */
> > @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >   	if (!v)
> >   		return false;
> >
> > -	if (br_vlan_get_tag(skb, vid)) {
> > +	err = br_vlan_get_tag(skb, vid);
> > +	if (!*vid) {
> >   		u16 pvid = br_get_pvid(v);
> >
> > -		/* Frame did not have a tag.  See if pvid is set
> > -		 * on this port.  That tells us which vlan untagged
> > -		 * traffic belongs to.
> > +		/* Frame had a tag with VID 0 or did not have a tag.
> > +		 * See if pvid is set on this port.  That tells us which
> > +		 * vlan untagged or priority-tagged traffic belongs to.
> >   		 */
> >   		if (pvid == VLAN_N_VID)
> >   			return false;
> >
> > -		/* PVID is set on this port.  Any untagged ingress
> > -		 * frame is considered to belong to this vlan.
> > +		/* PVID is set on this port.  Any untagged or priority-tagged
> > +		 * ingress frame is considered to belong to this vlan.
> >   		 */
> > -		__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> > +		if (likely(err))
> > +			/* Untagged Frame. */
> > +			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> > +		else
> > +			/* Priority-tagged Frame.
> > +			 * At this point, We know that skb->vlan_tci had
> > +			 * VLAN_TAG_PRESENT bit and its VID field was 0x000.
> > +			 * We update only VID field and preserve PCP field.
> > +			 */
> > +			skb->vlan_tci |= pvid;
> > +
> 
> In the case of a priority tagged frame, we should unroll the 
> modification above and restore the VID field to 0.  Otherwise, you
> may end up either stripping the vlan header completely or forwarding
> with pvid of the ingress port.

Thank you for reviewing.

It is my intended behavior that an incoming priority-tagged frame is
forwarded as a frame untagged or tagged with pvid.

IEEE 802.1Q-2011:

  section 8.1.7 Conversion of frame formats

  NOTE - As all incoming frames, including priority-tagged frames, are
  classified as belonging to a VLAN, the transmitting Port transmits
  VLAN-tagged frames or untagged frames. Hence, a station sending a
  priority-tagged frame via a Bridge will receive a response that is
  either VLAN-tagged or untagged, as described in 8.5.

  3. Definitions

  3.132 Priority-tagged frame: A tagged frame whose tag header carries
  priority information but carries no VLAN identification information.

  3.203 VLAN-tagged frame: A VLAN-tagged frame is a tagged frame whose
  tag header carries *both* VLAN identification and priority
  information.

Toshiaki Makita

> 
> -vlad
> >   		return true;
> >   	}
> >
> >

Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly

[Vlad Yasevich]

On 09/11/2013 03:00 AM, Toshiaki Makita wrote:
> On Tue, 2013-09-10 at 10:03 -0400, Vlad Yasevich wrote:
>> On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
>>> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
>>> use the PVID for the port as its VID.
>>> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>>>
>>> Apply the PVID to not only untagged frames but also priority-tagged frames.
>>>
>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>> ---
>>>    net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
>>>    1 file changed, 20 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
>>> index 21b6d21..5a9c44a 100644
>>> --- a/net/bridge/br_vlan.c
>>> +++ b/net/bridge/br_vlan.c
>>> @@ -189,6 +189,8 @@ out:
>>>    bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>>>    			struct sk_buff *skb, u16 *vid)
>>>    {
>>> +	int err;
>>> +
>>>    	/* If VLAN filtering is disabled on the bridge, all packets are
>>>    	 * permitted.
>>>    	 */
>>> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
>>>    	if (!v)
>>>    		return false;
>>>
>>> -	if (br_vlan_get_tag(skb, vid)) {
>>> +	err = br_vlan_get_tag(skb, vid);
>>> +	if (!*vid) {
>>>    		u16 pvid = br_get_pvid(v);
>>>
>>> -		/* Frame did not have a tag.  See if pvid is set
>>> -		 * on this port.  That tells us which vlan untagged
>>> -		 * traffic belongs to.
>>> +		/* Frame had a tag with VID 0 or did not have a tag.
>>> +		 * See if pvid is set on this port.  That tells us which
>>> +		 * vlan untagged or priority-tagged traffic belongs to.
>>>    		 */
>>>    		if (pvid == VLAN_N_VID)
>>>    			return false;
>>>
>>> -		/* PVID is set on this port.  Any untagged ingress
>>> -		 * frame is considered to belong to this vlan.
>>> +		/* PVID is set on this port.  Any untagged or priority-tagged
>>> +		 * ingress frame is considered to belong to this vlan.
>>>    		 */
>>> -		__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
>>> +		if (likely(err))
>>> +			/* Untagged Frame. */
>>> +			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
>>> +		else
>>> +			/* Priority-tagged Frame.
>>> +			 * At this point, We know that skb->vlan_tci had
>>> +			 * VLAN_TAG_PRESENT bit and its VID field was 0x000.
>>> +			 * We update only VID field and preserve PCP field.
>>> +			 */
>>> +			skb->vlan_tci |= pvid;
>>> +
>>
>> In the case of a priority tagged frame, we should unroll the
>> modification above and restore the VID field to 0.  Otherwise, you
>> may end up either stripping the vlan header completely or forwarding
>> with pvid of the ingress port.
>
> Thank you for reviewing.
>
> It is my intended behavior that an incoming priority-tagged frame is
> forwarded as a frame untagged or tagged with pvid.
>
> IEEE 802.1Q-2011:
>
>    section 8.1.7 Conversion of frame formats
>
>    NOTE - As all incoming frames, including priority-tagged frames, are
>    classified as belonging to a VLAN, the transmitting Port transmits
>    VLAN-tagged frames or untagged frames. Hence, a station sending a
>    priority-tagged frame via a Bridge will receive a response that is
>    either VLAN-tagged or untagged, as described in 8.5.
>
>    3. Definitions
>
>    3.132 Priority-tagged frame: A tagged frame whose tag header carries
>    priority information but carries no VLAN identification information.
>
>    3.203 VLAN-tagged frame: A VLAN-tagged frame is a tagged frame whose
>    tag header carries *both* VLAN identification and priority
>    information.
>
> Toshiaki Makita
>

Hmm..  The problem is that if a system attached to a port configures a
vlan interface with vid 0 and some priority mappings, then that
interface will not be able to properly receive traffic, as the bridge 
now will never transmit priority tagged frames.

-vlad

>>
>> -vlad
>>>    		return true;
>>>    	}
>>>
>>>
>
>

Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly

[Toshiaki Makita]

On Wed, 2013-09-11 at 12:32 -0400, Vlad Yasevich wrote:
> On 09/11/2013 03:00 AM, Toshiaki Makita wrote:
> > On Tue, 2013-09-10 at 10:03 -0400, Vlad Yasevich wrote:
> >> On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
> >>> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
> >>> use the PVID for the port as its VID.
> >>> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
> >>>
> >>> Apply the PVID to not only untagged frames but also priority-tagged frames.
> >>>
> >>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>> ---
> >>>    net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
> >>>    1 file changed, 20 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> >>> index 21b6d21..5a9c44a 100644
> >>> --- a/net/bridge/br_vlan.c
> >>> +++ b/net/bridge/br_vlan.c
> >>> @@ -189,6 +189,8 @@ out:
> >>>    bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >>>    			struct sk_buff *skb, u16 *vid)
> >>>    {
> >>> +	int err;
> >>> +
> >>>    	/* If VLAN filtering is disabled on the bridge, all packets are
> >>>    	 * permitted.
> >>>    	 */
> >>> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >>>    	if (!v)
> >>>    		return false;
> >>>
> >>> -	if (br_vlan_get_tag(skb, vid)) {
> >>> +	err = br_vlan_get_tag(skb, vid);
> >>> +	if (!*vid) {
> >>>    		u16 pvid = br_get_pvid(v);
> >>>
> >>> -		/* Frame did not have a tag.  See if pvid is set
> >>> -		 * on this port.  That tells us which vlan untagged
> >>> -		 * traffic belongs to.
> >>> +		/* Frame had a tag with VID 0 or did not have a tag.
> >>> +		 * See if pvid is set on this port.  That tells us which
> >>> +		 * vlan untagged or priority-tagged traffic belongs to.
> >>>    		 */
> >>>    		if (pvid == VLAN_N_VID)
> >>>    			return false;
> >>>
> >>> -		/* PVID is set on this port.  Any untagged ingress
> >>> -		 * frame is considered to belong to this vlan.
> >>> +		/* PVID is set on this port.  Any untagged or priority-tagged
> >>> +		 * ingress frame is considered to belong to this vlan.
> >>>    		 */
> >>> -		__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> >>> +		if (likely(err))
> >>> +			/* Untagged Frame. */
> >>> +			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> >>> +		else
> >>> +			/* Priority-tagged Frame.
> >>> +			 * At this point, We know that skb->vlan_tci had
> >>> +			 * VLAN_TAG_PRESENT bit and its VID field was 0x000.
> >>> +			 * We update only VID field and preserve PCP field.
> >>> +			 */
> >>> +			skb->vlan_tci |= pvid;
> >>> +
> >>
> >> In the case of a priority tagged frame, we should unroll the
> >> modification above and restore the VID field to 0.  Otherwise, you
> >> may end up either stripping the vlan header completely or forwarding
> >> with pvid of the ingress port.
> >
> > Thank you for reviewing.
> >
> > It is my intended behavior that an incoming priority-tagged frame is
> > forwarded as a frame untagged or tagged with pvid.
> >
> > IEEE 802.1Q-2011:
> >
> >    section 8.1.7 Conversion of frame formats
> >
> >    NOTE - As all incoming frames, including priority-tagged frames, are
> >    classified as belonging to a VLAN, the transmitting Port transmits
> >    VLAN-tagged frames or untagged frames. Hence, a station sending a
> >    priority-tagged frame via a Bridge will receive a response that is
> >    either VLAN-tagged or untagged, as described in 8.5.
> >
> >    3. Definitions
> >
> >    3.132 Priority-tagged frame: A tagged frame whose tag header carries
> >    priority information but carries no VLAN identification information.
> >
> >    3.203 VLAN-tagged frame: A VLAN-tagged frame is a tagged frame whose
> >    tag header carries *both* VLAN identification and priority
> >    information.
> >
> > Toshiaki Makita
> >
> 
> Hmm..  The problem is that if a system attached to a port configures a
> vlan interface with vid 0 and some priority mappings, then that
> interface will not be able to properly receive traffic, as the bridge 
> now will never transmit priority tagged frames.
> 
> -vlad

I see.  As you say, for example, if we configure vnet0.0 and attach
vnet0 to a bridge with vlan_filtering enabled, even though we are
sending priority-tagged frames from vnet0.0 and they are successfully
forwarded by the bridge to another port, we cannot receive any frame on
vnet0.0 because all incoming frames from a bridge port are not
priority-tagged and never passed to vnet0.0.

I think this might be a problem as an end station that cannot receive
incoming untagged frames and priority-tagged frames on the same
interface when vlan 0 interface is defined.
(We can receive both untagged and priority-tagged frames on the same
interface that is not configured vlan 0.)

If we assume it as a problem of vlan interface, I guess we should enable
vlan 0 interface to receive untagged frames (treat vnet0.0 as an alias
of vnet0), or add a setting of egress priority map to vnet0 so that vlan
0 interface can become unnecessary.

If it is preferable to deal with it by bridge, I don't think a
priority-tagged frame's VID field should be restored to 0 on the egress
port.  If we do so, we may receive both untagged frames and
priority-tagged frames from a bridge port when another end station sends
both untagged and priority-tagged frames by mixture.
IMO, it will be resolved by adding a new per-port policy that enables us
to send priority-tagged frames instead of untagged frames, like the
"priority-tags" option of openvswitch.
This solution, however, makes the bridge not be conformed with IEEE
802.1Q, and the problem remains that we cannot receive any frames on a
vlan 0 interface such as eth0.0 when we connect eth0 to another 802.1Q
conformed switch.

I'd like to hear further comments or suggestions, everyone :)

Thanks,

Toshiaki Makita

> 
> >>
> >> -vlad
> >>>    		return true;
> >>>    	}
> >>>
> >>>
> >
> >

Re: [PATCH net 1/4] bridge: Don't use VID 0 and 4095 in vlan filtering

[David Miller]

From: Vlad Yasevich <vyasevic@redhat.com>
Date: Tue, 10 Sep 2013 10:22:26 -0400

> On 09/10/2013 06:32 AM, Toshiaki Makita wrote:
>> IEEE 802.1Q says that:
>> - VID 0 shall not be configured as a PVID, or configured in any
>> - Filtering
>> Database entry.
>> - VID 4095 shall not be configured as a PVID, or transmitted in a tag
>> header. This VID value may be used to indicate a wildcard match for
>> the VID
>> in management operations or Filtering Database entries.
>> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>>
>> Don't accept adding these VIDs in the vlan_filtering implementation.
>>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> 
> Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>

Vlad, as far as I can see your redhat.com email ends just with a "c"
not a "ch".  It's your gmail account that ends in a "ch".

I'm fixing this up while applying these patches, if you have something
automatically generating these reviewed-by strings please fix it up
although I note that some are correct and some are not so maybe you
do this by hand :-)

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

[David Miller]

From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
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.

Re: [PATCH net 1/4] bridge: Don't use VID 0 and 4095 in vlan filtering

[Vlad Yasevich]

On 09/12/2013 03:55 PM, David Miller wrote:
> From: Vlad Yasevich <vyasevic@redhat.com>
> Date: Tue, 10 Sep 2013 10:22:26 -0400
>
>> On 09/10/2013 06:32 AM, Toshiaki Makita wrote:
>>> IEEE 802.1Q says that:
>>> - VID 0 shall not be configured as a PVID, or configured in any
>>> - Filtering
>>> Database entry.
>>> - VID 4095 shall not be configured as a PVID, or transmitted in a tag
>>> header. This VID value may be used to indicate a wildcard match for
>>> the VID
>>> in management operations or Filtering Database entries.
>>> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>>>
>>> Don't accept adding these VIDs in the vlan_filtering implementation.
>>>
>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>
>
> Vlad, as far as I can see your redhat.com email ends just with a "c"
> not a "ch".  It's your gmail account that ends in a "ch".
>
> I'm fixing this up while applying these patches, if you have something
> automatically generating these reviewed-by strings please fix it up
> although I note that some are correct and some are not so maybe you
> do this by hand :-)
>

Apologies.  Yes, I usually ack things by hand and sometimes fingers just
keep going...

-vlad

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

[Toshiaki Makita]

On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> 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?


Thanks,

Toshiaki Makita

> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Veaceslav Falico]

On Fri, Sep 13, 2013 at 09:06:53PM +0900, Toshiaki Makita wrote:
>On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>> 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.

Take a look at how was it done for bonding - it just goes through the list
of attached vlan devs, and doesn't care about vlan0 (which can, btw, exist
technically). I'm not sure if that's what you're looking for, but worth a
try.

bond_arp_send_all() might be a good starting point.

>
>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?
>
>
>Thanks,
>
>Toshiaki Makita
>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Toshiaki Makita]

On Fri, 2013-09-13 at 17:21 +0200, Veaceslav Falico wrote:
> On Fri, Sep 13, 2013 at 09:06:53PM +0900, Toshiaki Makita wrote:
> >On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> >> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >> 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.
> 
> Take a look at how was it done for bonding - it just goes through the list
> of attached vlan devs, and doesn't care about vlan0 (which can, btw, exist
> technically). I'm not sure if that's what you're looking for, but worth a
> try.
> 
> bond_arp_send_all() might be a good starting point.

Thanks a lot.
I looked over it and took it that bonding driver doesn't send any arp
probe as a priority-tagged frame even if the routing table tells that
the outgoing interface to reach the arp target is bond0.0.

If we seek to take a similar way with bonding, we might be able to
simply ignore vlan 0 interface, or incoming priority-tagged frames.
I'm, however, afraid that it may be undesirable in view of
interoperability.

Anyway, thank you again for your suggestion.
I'm going to think a bit more about the issue and rearrange the patch
set.

Thanks,

Toshiaki Makita

> 
> >
> >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?
> >
> >
> >Thanks,
> >
> >Toshiaki Makita
> >
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majordomo@vger.kernel.org
> >> 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 majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Vlad Yasevich]

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 <makita.toshiaki@lab.ntt.co.jp>
>> 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

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

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

[Toshiaki Makita]

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 <makita.toshiaki@lab.ntt.co.jp>
> >> 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.

Thanks,

Toshiaki Makita

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

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

[Vlad Yasevich]

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 <makita.toshiaki@lab.ntt.co.jp>
>>>> 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 majordomo@vger.kernel.org
>>>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Toshiaki Makita]

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 <makita.toshiaki@lab.ntt.co.jp>
> >>>> 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.

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 majordomo@vger.kernel.org
> >>>> 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

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

[Vlad Yasevich]

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 <makita.toshiaki@lab.ntt.co.jp>
>>>>>> 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.

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 majordomo@vger.kernel.org
>>>>>> 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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>
>

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

[Toshiaki Makita]

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 <makita.toshiaki@lab.ntt.co.jp>
> >>>>>> 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.

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 majordomo@vger.kernel.org
> >>>>>> 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 majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >
> >
> 

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

[Vlad Yasevich]

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 <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>> 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.

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 majordomo@vger.kernel.org
>>>>>>>> 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 majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>
>>>
>>
>
>

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

[Toshiaki Makita]

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 <makita.toshiaki@lab.ntt.co.jp>
> >>>>>>>> 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?

> 
> 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 majordomo@vger.kernel.org
> >>>>>>>> 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 majordomo@vger.kernel.org
> >>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>>
> >>>
> >>>
> >>
> >
> >

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

[Vlad Yasevich]

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 <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>>>> 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.

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.

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.

-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 majordomo@vger.kernel.org
>>>>>>>>>> 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 majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

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

[Toshiaki Makita]

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 <makita.toshiaki@lab.ntt.co.jp>
> >>>>>>>>>> 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. 
In this situation, we can only receive frames that is priority-tagged
when received on eth0.
IMO, if prio_tag is configured, the bridge should send any untagged
frame as priority-tagged regardless of whatever it is on eth0.

> 
> 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 majordomo@vger.kernel.org
> >>>>>>>>>> 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 majordomo@vger.kernel.org
> >>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
> >
> 

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

[Vlad Yasevich]

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 <makita.toshiaki@lab.ntt.co.jp>
>>>>>>>>>>>> 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?

> 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.

> 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

-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 majordomo@vger.kernel.org
>>>>>>>>>>>> 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 majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>

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

[Toshiaki Makita]

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 <makita.toshiaki@lab.ntt.co.jp>
> >>>>>>>>>>>> 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.
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.

> 
> > 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.

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 majordomo@vger.kernel.org
> >>>>>>>>>>>> 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 majordomo@vger.kernel.org
> >>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >

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

[Vlad Yasevich]

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
>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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?

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.

>
>>
>>> 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.

-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 majordomo@vger.kernel.org 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
>>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
>>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>

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

[Toshiaki Makita]

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
> >>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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).


Example 2:

            prio_tagged         prio_tagged       untagged
+------------+ ---> +------------+ ---> +---------+ ---> +-----+
|guest eth0.0|------|host1 Bridge|------|HW switch|------|host2|
+------------+ <--- +------------+ <--- +---------+ <--- +-----+
             untagged            untagged       prio/untagged

Note: 802.1Q conformed HW switch transmits only untagged or VLAN-tagged
frames.

> 
> 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)

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 majordomo@vger.kernel.org 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
> >>>>>>>>>>> majordomo@vger.kernel.org More majordomo info at
> >>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
> >

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

[Vlad Yasevich]

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
>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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.

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 majordomo@vger.kernel.org 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
>>>>>>>>>>>>> majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Toshiaki Makita]

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
> >>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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


'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 majordomo@vger.kernel.org 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
> >>>>>>>>>>>>> majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Vlad Yasevich]

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
>>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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 majordomo@vger.kernel.org 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
>>>>>>>>>>>>>>> majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
>>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

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

[Toshiaki Makita]

On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote:
> 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
> >>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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.

You're right.
In this case 'untagged' for 'vid 10' is no longer necessary.

> 
> 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.

Can you make a patch set implementing this?

I'd like to re-send this patch set related to PVID with more comments
about the unresolved vlan 0 interface problem and the prospect that it
will be addressed by another patch set of yours.

Is this procedure OK with you?

Thanks,

Toshiaki Makita

> 
> -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 majordomo@vger.kernel.org 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
> >>>>>>>>>>>>>>> majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
> >>> 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 majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> 

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

[Vlad Yasevich]

On 10/13/2013 12:11 PM, Toshiaki Makita wrote:
> On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote:
>> 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
>>>>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> 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.
>
> You're right.
> In this case 'untagged' for 'vid 10' is no longer necessary.
>
>>
>> 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.
>
> Can you make a patch set implementing this?
>
> I'd like to re-send this patch set related to PVID with more comments
> about the unresolved vlan 0 interface problem and the prospect that it
> will be addressed by another patch set of yours.
>
> Is this procedure OK with you?

Sure.  Can you re-send the patch series, since I think 3 of the paches 
are really needed.  I'll work on the prio_tag stuff.

-vlad

>
> Thanks,
>
> Toshiaki Makita
>
>>
>> -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 majordomo@vger.kernel.org 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
>>>>>>>>>>>>>>>>> majordomo@vger.kernel.org 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 majordomo@vger.kernel.org
>>>>> 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 majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>
>