Subject: [rbridge] last call comments on <draft-ietf-trill-rbridge-vlan-mapping-00.txt>

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 15 Apr 2009 20:05:50 -0700

- How do "cloud IDs" get assigned?

- For a cut set RBridge, all ports MUST
  be designated as being in one cloud 
  or the other.  This should be stated
  in the spec.

Anoop

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 15 Apr 2009 23:28:05 -0400

The cloud IDs get manually configured.

Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 16 Apr 2009 10:58:00 -0700

That should probably be stated in the document,
along with how many bits the cloud ID should be.

A couple more points -

- "VLAN mapping" is not standard terminology so
  the draft should state somewhere that this is
  trying to achieve what VID translation does
  in IEEE 802.1 bridges.

- As a result of advertising reachability 
  to both VLANs, you can get some suboptimal
  behavior.  For example, lets have the
  following:
  - Cloud 1, VLAN A -> Cloud 2, VLAN B
  - The cut set RBridge would advertise
    that it can reach both VLANs (so that
    packets don't inadvertently get filtered).
  - Let's say cloud 1 is using VLAN B
    for something else.
  - We will need to create another VLAN,
    VLAN C in cloud 2 to which this maps.
    (Not mentioned in the draft.)  In the
    absence of that this VLAN B would also
    be connected to VLAN B in cloud 2 
    effectively merging VLAN A & B.
  - Even if we do that, all multicast 
    traffic for VLAN B in Cloud 1 will
    hit the cut set RBridge, even though
    there is nobody interested in receiving
    that traffic in Cloud 2.

Anoop

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]] 
> Sent: Wednesday, April 15, 2009 8:28 PM
> To: Anoop Ghanwani
> Cc: TRILL/RBridge Working Group
> Subject: Re: [rbridge] last call comments on 
> <draft-ietf-trill-rbridge-vlan-mapping-00.txt>
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Apr 2009 15:49:01 -0400

Hi Anoop.

> along with how many bits the cloud ID should be.

OK. I would suggest 16 bits as being plenty big enough.

>  trying to achieve what VID translation does

OK.

>    packets don't inadvertently get filtered).

Yes, generally speaking the cut-set RBridges get extra traffic to be
sure than none gets inadvertently pruned...

>    effectively merging VLAN A & B.

Actually, although it is not stated in the draft, I don't think that
should be true. It seems to me that if you have "Cloud 1, VLAN A <->
Cloud 2, VLAN B" and no other mappings, then Cloud 1, VLAN B, traffic
and Cloud 2, VLAN A traffic should not be forwarded into the other
cloud by cut set RBridges. (By the way, I changed the "->" to "<->" in
the mapping because all VLAN mapping are required to be two way by the
draft.)

>    there is nobody interested in receiving

Yes, but to further optimize traffic flows would required a much more
complicated feature.

> Anoop

Thanks,
Donald

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 16 Apr 2009 17:41:26 -0700

> the mapping because all VLAN mapping are required to be two way by the

What would prevent this from happening?
When going from Cloud 1 to Cloud 2, I haven't
specified any special operation to be performed
on VLAN B.  So when the frame, which originated
on VLAN B in Cloud 1, arrives in Cloud 2
(because it has been multicast to every device
that listens to VLAN B), what would prevent
it from getting decap'ed and put out on ports
that have VLAN B configured on them in Cloud 2?

> Sent: Thursday, April 16, 2009 12:49 PM
> To: Anoop Ghanwani

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Apr 2009 20:58:05 -0400

The rule would have to be something like the following:

When going from VLAN W on a Cloud x port to a Cloud y port:
(1) If a mapping of VLAN W in Cloud x to some other VLAN in Cloud y
has been configured, do that mapping.
(2) If point 1 does not apply but VLAN W in Cloud y is being mapped to
a different VLAN in Cloud x, discard the frame.
(3) If neither of the above applies, forward the frame with the VLAN unchanged.

Donald