Subject: Re: [rbridge] Readiness of the VLAN Mapping Draft

From: Anil Rijhsinghani <[email-masked]>
Date: Tue, 30 Mar 2010 10:57:20 -0400

Radia,

> The questions is....bridges do VLAN mapping. How are bridges
> configured with VLAN mapping? Are mappings one-way? Are they
> allowed to be configured to not be one-to-one?

VLAN mapping is not a standard function, so the answer to
this isn't straightforward. As with any non-standard thing,
different people may implement it different ways.

Let's say,

(East, VLAN A) = (West, VLAN B) = (North, VLAN C) = (South, VLAN D)

Now VLAN E (a "canonical" VLAN) is configured to be used in the
core to denote VLAN A in East, VLAN B in West, etc. (This is the
general use case; network managers of the four sites don't want to
reconfigure their respective networks to achieve a new connectivity.)

We clearly want to be symmetric in this case. The manager
specifies only the egress mapping on the switch in the edge switch
they manage, e.g. VLAN A-> VLAN E. The reverse case (ingress) is
typically implied, which can be suggested in the draft.

Then there's the question of what happens in your example,
VLAN A-> VLAN E; then VLAN X-> VLAN E on the same switch.

If you want to specify exactly how VLAN mapping works, which
current standards don't, then the easy answer is to to overwrite
the previous config.

A better way might be to allow it, and leave it to the
implementor to interpret. There are interesting things that can
be done when you allow mappings that aren't 1-to-1. If you
disallow it, then one cannot do with an RBridge what one can do
with one's existing switch.

If it's possible to ignore the issue (i.e. there's no problem
with IS-IS and ESADI encoding, etc), I would. Or you could
recommend symmetric mappings, without mandating it.

Anil

> From: Radia Perlman <[email-masked]>
> Date: March 29, 2010 3:41:04 PM EDT
> To: Donald Eastlake <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [rbridge] Readiness of the VLAN Mapping Draft
> 
> I think I'd prefer if rules were symmetric, as in
> 
> (East, VLAN A) = (West, VLAN B)
> or
> (East, VLAN C) = (West, null)
> 
> And if there is already a rule for
> (East, VLAN A) = West, VLAN B)
> and you try to configure
> (East, VLAN D) = (West, VLAN B)
> that you get an warning, saying "(West, VLAN B) is already mapped to
> (East, VLAN A). Do you wish to supercede that rule?"
> 
> However, as someone that is always annoyed when a newer version of
> something changes the user interface after I've finally gotten used to
> the older version, even if the engineers think the new commands are
> better somehow, it means I have to figure out how it works again....
> 
> The questions is....bridges do VLAN mapping. How are bridges
> configured with VLAN mapping? Are mappings one-way? Are they allowed
> to be configured to not be one-to-one?
> 
> Radia
> 
> On Mon, Mar 29, 2010 at 12:08 PM, Donald Eastlake <[email-masked]> wrote:
> At the Anaheim meeting I suggested that it might be time for a Working Group
> Last Call on the VLAN Mapping
> Draft: http://tools.ietf.org/html/draft-ietf-trill-rbridge-vlan-mapping-02
> However, in reviewing that document, I noticed an inconsistency:
> The draft assumes that you configure rules of the form [ v1, r1 -> v2, r2 ],
> which means that if you receive a frame in VLAN 1 from a port connected to
> Region 1 and you output that frame to a port connected to Region 2, you map
> the VLAN of the from to VLAN 2.
> At one place in the draft there is a paragraph beginning "Note that mappings
> are always symmetric" which says that if you have configured a rule [ v1, r1
> -> v2, r2 ] then the RBridge will also act as if you had a rule [ v2, r2 ->
> v1, r1 ] in place. However, in the more explicit description of the rules
> for mapping, just below that paragraph, it implies that translations are
> only caused by explicit rules where the "from" VLAN and region and the "to"
> region match. (Either way there is an implication that you can't have
> directly conflicting rules, that is two rules that differ only in the "to"
> VLAN.)
> There are two way to clarify this possible inconsistency:
> (A) Stick with the explicit rule description, which means that having a [
> v1, r1 -> v2, r2 ] in place would have no effect on a frame in VLAN 2
> received from Region 2 and being forwarded into Region 1.  If there were no
> other matching explicit rule, such a frame would not be mapped.
> (B) Stick with the description where translations can occur due to an
> explicit rules or implicitly for the inverse of the rule. Thus an explicit [
> v1, r1 -> v2, r2 ] would also imply [ v2, r2 -> v1, r1 ] unless there was an
> different explicit rules for VLAN 2 frames from Region 2 being forwarded to
> Region 1. This would generally mean fewer rules to configure but also the
> possibility of conflicting implied rules. For example, you could have both [
> v1, r1 -> v2, r2] and [ v3, r1 -> v2, r2 ] in which case what to do with a
> frame in VLAN 2 from Region 2 being forwarded to Region 1 is unclear and the
> draft would either have to specify a tie-breaker or say the result is
> unspecified.
> Would people prefer A or B?
> Thanks,
> Donald
> =============================
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street
> Milford, MA 01757 USA
> [email-masked]
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Mar 2010 09:07:37 -0700

> different people may implement it different ways.

After an off-line discussion with Radia, I'd like to raise a point -

is this an rbridge issue?

If not 100% related, then it's worth being *very* clear about the part
that is independent and the part that's related to rbridges.

Joe