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

From: Donald Eastlake <[email-masked]>
Date: Thu, 1 Apr 2010 19:42:43 -0400

Hi Anil,

On Wed, Mar 31, 2010 at 5:57 PM, Anil Rijhsinghani <[email-masked]> wrote:

> ---- Donald Eastlake <[email-masked]> wrote:
> > Another problem with mapping all the VLAN ID fields inside TLVs/sub-TLVs
> is
> > that you would have to do it not just for all existing TLVs/sub-TLVs but
> > also for all types of TLV/sub-TLV specified in the future. I do not think
> > that is practical.
>
> Only TLVs that involve the VLAN.
>

Right. So if you are doing TLV/sub-TLV  mapping you can't define any new
TLVs or sub-TLVs with VLAN IDs in them unless you upgrade all your VLAN
mapping RBridges. And, as Radia pointed out, you can't do origin
authentication of LSPs.

Here's the rub: if an implementation can do the TLV mapping
> because they want to prevent unnecessary flooding, they can't
> because of how it's specified. You've just made an implementation
> choice for all vendors -- one that results in a suboptimal solution.
>

Just speaking as a working group member, I think the currently described
solution is better for customer VLAN mapping.

> I don't see the work involved as overly complex, and I do think in
> any significant mapping scenario you could undo a lot of pruning.
> Maybe we could just describe both methods?

> I think doing mapping at input ports cannot handle the case of general
> > mappings for N > 2 regions attached to a single RBridge. In fact, it
> seems
> > to me that if you map VLAN 1 coming in port p1 to VLAN 2 at the input
> port,
> > you have problems if there are any other ports, say p2, which are
> connected
> > to the same region as p1 and which that frame might get forwarded out
> > through...
>
> It seems like you're implying two problems here: one, when
> there's more than two regions on an Rbridge, another if there's more
> than 1 port in a region. I'm not sure I understand, can you explain it a
> bit more?
>

I had been thinking about problems in using VLAN mapping at an input port
when an RBridge has either ports connected to three regions or two ports
connected to the same region. I'll explain my thinking there but on further
thought I believe there are much worse problems with trying to use input
port VLAN mapping at all for RBridge VLAN mapping, which I will discuss
further below.

Say you configure port p1 at RBridge RB1, below the EISS interface, so that
it maps VLAN ID 1 into VLAN ID 2 and port p1 connects to West.
      If RB1 has both p2 connected to North and p3 connected to East, it
might be that different VLAN ID translations are needed for a frame coming
from West depending on whether it is going to North or East. So, at best,
the RBridge could not do the mapping described in the RBridge VLAN Mapping
draft but only a much more limited kind of mapping.
      If RB1 also has p4 also connected to West, then a frame received on p1
and forwarded out p4 should not be mapped at all since both are in West. But
the input port VLAN mapping always maps.
      So, it seems to me, not only would an RBridge using input port VLAN
mapping be restricted to having ports connected to no more than two regions,
it would also be restricted to having no more than one port per region. That
is, it would only be a two port device.

But, I now believe my thinking above was off the mark because input port
VLAN filtering is actually useless for RBridge VLAN mapping.
      Consider a transit RBridge, with various ports in various regions,
forwarding TRILL data frames. Input port VLAN translation affects only the
Outer.VLAN. This VLAN is an insignificant transport artifact. The data VLAN
is indicated by the Inner.VLAN which is unchanged by input port VLAN
translation. Similarly, disabling a VLAN at an output port only blocks TRILL
data frames whose Outer.VLAN is that disabled VLAN, not TRILL data frames
whose Inner.VLAN matches the disabled VLAN.
       Consider TRILL control frames. I don't think input port VLAN mapping
has any effect except for Hellos. For Hellos, setting up such mapping would
make it look like VLAN mapping was happening inside the link connected to
that port. This would cause the DRB to make sure there was only on appointed
forwarder for the link.
      Input port VLAN mapping and output port VLAN disablement would affect
native frames and that might be useful under some circumstances but it seems
like it would mostly cause confusion.

So, for the above reasons, I believe that RBridge VLAN mapping has to occur
as part of the forwarding process, above the EISS.

> Thanks,
> Anil

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

---

From: Radia Perlman <[email-masked]>
Date: Thu, 1 Apr 2010 16:53:27 -0700

>> Maybe we could just describe both methods?
The problem with describing both methods is that if one cut set RB is
reaching into the LSP to change the TLVs, and another is advertising
connectivity to all the mapped VLANs, but not changing the TLVs in
forwarded LSPs, I think it will not work.

So I think we need to choose one mechanism or another, and mandate it
in cut set RBridges.

Radia

---

From: Anil Rijhsinghani <[email-masked]>
Date: Fri, 2 Apr 2010 07:11:36 -0400

Hi Donald,

>       Consider a transit RBridge, with various ports in various  
> regions, forwarding TRILL data frames. Input port VLAN translation  
> affects only the Outer.VLAN. This VLAN is an insignificant transport  
> artifact. The data VLAN is indicated by the Inner.VLAN which is  
> unchanged by input port VLAN translation. Similarly, disabling a  
> VLAN at an output port only blocks TRILL data frames whose  
> Outer.VLAN is that disabled VLAN, not TRILL data frames whose  
> Inner.VLAN matches the disabled VLAN.
>        Consider TRILL control frames. I don't think input port VLAN  
> mapping has any effect except for Hellos. For Hellos, setting up  
> such mapping would make it look like VLAN mapping was happening  
> inside the link connected to that port. This would cause the DRB to  
> make sure there was only on appointed forwarder for the link.
>       Input port VLAN mapping and output port VLAN disablement would  
> affect native frames and that might be useful under some  
> circumstances but it seems like it would mostly cause confusion.
>
> So, for the above reasons, I believe that RBridge VLAN mapping has  
> to occur as part of the forwarding process, above the EISS.

Two problems:
a) Transit Rbridges aren't supposed to look at the inner Vlan at all  
(4.6.2.4)
b) Vlan-mapping is not needed in transit Rbridges in any case.

Regards,
Anil

---

From: Radia Perlman <[email-masked]>
Date: Fri, 2 Apr 2010 06:35:47 -0700

> b) Vlan-mapping is not needed in transit Rbridges in any case.

I'm very confused. Cut set RBridges *are* transit RBridges, and they
are the ones that will need to do the VLAN mapping, on unicast as well
as multidestination frames.

I agree that other than VLAN mapping, transit RBridges would not look
at inner VLAN on *unicast*. However, they *would* look at inner VLAN
on multidestination, in order to do filtering.

But cut set RBridges configured to do VLAN mapping would have to look
at inner VLAN on both unicast and multidestination, and do the
mapping.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 2 Apr 2010 13:42:26 -0400

> > a) Transit Rbridges aren't supposed to look at the inner Vlan at all

Right. 4.6 is Frame Processing Behavior, 4.6.2 is Receipt of a TRILL Frame,
and 4.6.2.4 is Known Unicast TRILL Data Frames. For those frames, an
ordinary Rbridge does not look at the Inner.VLAN. But the VLAN Mapping draft
updates the base protocol specification to change that and the draft needs
to be changed in the upper left of the first page to indicate that it
updates the base protocol specification. If no changes were needed in the
base protocol specification, the RBridge VLAN mapping draft wouldn't have to
be on the standards track, it could just be some sort of informational
implementation note.

If you don't change the Inner.VLAN ID of a TRILL data frame, then you
haven't actually mapped the VLAN of the data.

>  > b) Vlan-mapping is not needed in transit Rbridges in any case.

The base scenario for VLAN mapping was the merger/acquisition case where you
are taking two previously independent RBridge campuses and merging them and
don't want to have to do all the reconfiguration to get the VLANs in synch
right away. For reliability and bandwidth, you would need multiple points of
connection. The only way I can see that this will work is with cut-set
Rbridges that map the Inner.VLAN ID of TRILL data frames. If you instead try
to configure cut-set bridges or cut-set ports, they will at best map the
Outer.VLAN ID and have no effect on the actual VLAN labeling of the data and
you will fail.

A second scenario was where you had, perhaps, two islands in a bridged LAN
with the same VLAN ID and were upgrading to RBridges and didn't want the
standard RBridge behavior of connecting all stations that are in the same
VLAN that are in the same campus. If there exists a cut-set line of RBridges
between these two islands, they can drop frames in that VLAN and keep the
islands separated.

If you are thinking of some completely different scenario, say where you
have a core of Rbridges with peripheral bridges such that you can succeed in
doing the VLAN mapping you want by mapping the VLAN of native frames only,
not TRILL data frames, in a cut-set of Rbridge ports, that's fine. But I
don't think that should be called Rbridge VLAN mapping and it doesn't have
much of anything to do with the feature described in this draft.

Thanks,
Donald