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

From: Anil Rijhsinghani <[email-masked]>
Date: Wed, 31 Mar 2010 10:02:17 -0400

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

The new info specific to Rbridges, in my opinion, is the IS-IS
TLV for VLAN mapping. This is optional as it's not required for
protocol correctness (it's described as a troubleshooting measure.)

Having now read the draft, I do have some comments:

1) The "null VLAN" semantic is not necessary, as standard VLAN
mechanisms allow preventing a VLAN from egressing on a port. This
rule would be applied before you get to mapping a VLAN.

2) "Region number" in the L2 IS-IS TLV is something that VLAN mapping
implementations have not used. Instead, the Rbridge could send
Internal VLAN ID/External VLAN ID/port number. (Otherwise we may
need to specify a new system of administrative domains, protocol to
sync them, et al.)

3) In both "Reporting Attached VLANs by Cut Set RBridges in LSPs"
and "Advertising of Multicast Groups by Cut Set RBridges", I believe
RB1 should not advertise both VLAN A and B on both sides,
to prevent unnecessary flooding of multicasts. Instead, it
advertises VLAN B on the West side and VLAN A on the East. This
would be compatible with the sort of thing done in ESADI and
forwarded data packets.

4) Just a comment, dedicated "cut-set bridges" as shown in the
examples and diagrams are rare.

Anil

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

---

From: Radia Perlman <[email-masked]>
Date: Wed, 31 Mar 2010 07:44:33 -0700

> mechanisms allow preventing a VLAN from egressing on a port. This

OK, though might it be worth allowing advertising of this, just for
detecting misconfiguration?

> need to specify a new system of administrative domains, protocol to

The reason for having a region number is to make it possible for a
management tool to
detect differently configured mappings. Doing it based on port number
alone would not allow comparing different configurations.

> would be compatible with the sort of thing done in ESADI and

The reason this is necessary is, suppose RB1 in East has a
multidestination frame for VLAN A. Suppose for simplicity there are
only two links with "VLAN A"; the one attached to RB1 and one attached
to RB2 in West, but RB2 is in West, thinking the link is VLAN B. But
RB3, on the cut set, is mapping (West; B) = (East A).
Since VLAN attachment is in the text of an LSP and is not mapped by
cut set bridges, RB1 (and other RBs in East) would not know to forward
that multidestination frame anywhere.

RB2 won't advertise both A and B because RB2 is not in the cut set and
doesn't know about the mapping.

So RB3 has to advertise that it is connected to both A (so that VLAN B
multidestination frames will reach the cut set from West) and B (so
that VLAN A frames will reach the cut set from East).

> examples and diagrams are rare.

What is rare? VLAN mapping itself is rare, or the topologies are
different somehow, in which case, how?

Thanks...

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 31 Mar 2010 11:12:17 -0400

>
>
> I think Ayan was saying that cut-set bridges/RBridges would normally have
> many more links,
>

Ayan -> Anil.

Sorry,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 31 Mar 2010 11:08:20 -0400

> > mechanisms allow preventing a VLAN from egressing on a port. This

Assume that an RBridge is at a triple point and has some ports in East, some
in West, and some in North. You want frames arriving from West in VLAN-1 to
be mapped to VLAN-2 if they are sent to North but dropped if they would have
been sent to East... You could configure the East ports to drop VLAN-1 but,
since I haven't said anything about it, the assumption would be that frames
in VLAN-1 arriving from North and going to East are to be sent along
unmapped. That requires the East ports to be configure to let VLAN-1
through. The East ports can't be simultaneously configured to block and to
allow VLAN-1.

It seems to me that the way bridges work is very port-centric. VLAN mapping
occurs when a frame is received at a port and does not depend on the
destination of the frame. VLAN mapping does not occur when a frame is sent
through a port but it is easy to block VLANs at an output port.

That's not how the RBridge VLAN mapping feature is currently specified. It's
more like it is part of the forwarding function and is sensitive to the
region labeling of both the source and destination port.

> alone would not allow comparing different configurations.

The region numbers are arbitrary and it is managements responsibility to
sync them. If the are inconsistent, they only problem is that if you report
mapping in the link state, you may be false indications of errors from some
management tool... I don't see a need for a protocol to sync them.

> > would be compatible with the sort of thing done in ESADI and

You can't advertise different things on different "sides" or ports. The
advertising all goes into the unified link state database which is reliably
flooded to all RBridges in the campus. VLAN attachment information has to be
in the core link state since it is used for distribution tree pruning.

I think Ayan was saying that cut-set bridges/RBridges would normally have
many more links, probably some with end-stations. I don't think this makes
any difference. All ports must be labeled as to the region they are in,
including a port which just goes to a point-to-point link to an end station.

Thanks,
Donald

---

From: Anil Rijhsinghani <[email-masked]>
Date: Wed, 31 Mar 2010 11:46:47 -0400

> detecting misconfiguration?

Sure, but in the typical VLAN mapping configs I've seen the
majority of internal VLANs are blocked and only a small number is
mapped, in which case you'd be sending a lot of information. I'd
opt for advertising only mapped VLANs.

> alone would not allow comparing different configurations.

So would it be up to the managers of the various sites to come up
with a system to uniquely assign region numbers? It's just
something I haven't seen before, but if this is how we want to have
VLAN mapping work then I understand.

> that VLAN A frames will reach the cut set from East).

Unless I'm misunderstanding the issue, the way I'd do it is map the TLVs
in RB3's LSP. (Other existing control protocols advertising VLANs must
be adapted to deal with similar issues.)

The problem I see with the described mechanism is that if there were a
real VLAN A in West, its multicasts would be propagated up to RB3,
only to be dropped there.

Typically RB3 is part of RB1; a port on RB3 provides the mapping,
which makes it easier to do that mapping in the LSP. 

> different somehow, in which case, how?

The cut-set functionality can be done in edge ports of otherwise
internal bridges, rather than in dedicated cut-set bridges. I tend
to think of this function as port-based rather than bridge-based,
although I don't think that affects how you've modeled it.

Thanks,
Anil

---

From: Anil Rijhsinghani <[email-masked]>
Date: Wed, 31 Mar 2010 12:08:55 -0400

aha, Donald's doing name-mapping now :)

I was suggesting that there are cut-set ports rather than
cut-set bridges. You could have one port on an Rbridge mapping
VLAN A to VLAN B, another port on the same Rbridge mapping
VLAN A to VLAN C, and yet another port not mapping VLAN A at all.

Anil

---

From: Radia Perlman <[email-masked]>
Date: Wed, 31 Mar 2010 09:43:37 -0700

> be adapted to deal with similar issues.)

You are not misunderstanding. Having the cut set RBridges map the
relevant TLVs in other RBridge's LSPs is another way of accomplishing
this, though if we ever did public key-based signatures on LSPs, then
it would be impossible for cut set RBridge RB3 to modify anything in
RB1's LSP. I guess it seemed simpler to just have the cut set RBridges
advertise attachment to the mapped VLANs. But it's a clearcut and
understandable technical issue, so could certainly be discussed
further.

> only to be dropped there.

Correct. If the mechanism were as you suggested (mapping TLVs inside
of LSPs isntead of what's in the draft), then there would be a little
more effective pruning.

> which makes it easier to do that mapping in the LSP.

RB1 might be several hops away from RB3. It doesn't change things, but
just probably clarifies how I think about the topology...separating
functions from RB1, generating the LSP, to RB3 which is a cut set guy
doing the VLAN mapping, to RB2, an "innocent" RBridge in the other
region.

---------

As for "region number", and who assigns it...,if I were managing a
network I might prefer an ASCII string describing RB3's manager's view
of the region, as in "previously acquired company ZZX's Ethernet",
"main corporate Ethernet". It wouldn't matter if two RBridge managers
called the regions different strings... it's all informational, to
detect misconfiguration. For brevity, the actual mapping tables
advertised wouldn't contain the ASCII strings...you'd want a
shorthand, but in addition to advertising the tables, there could
perhaps be a TLV in which the terse region numbers were described with
ASCII strings.

Radia

---

From: Anil Rijhsinghani <[email-masked]>
Date: Wed, 31 Mar 2010 13:31:26 -0400

> of LSPs isntead of what's in the draft), then there would be a little

The only other thing I would add is, in my earlier customer scenario
of several sites all using different VLANs to a single mapped one,
the additional effectiveness of the pruning may scale proportionately
to the total number of mapped VLANs times the number of sites.

> doing the VLAN mapping, to RB2, an "innocent" RBridge in the other

Agreed, plus possibly a transit Rbridge in the path between two cut-set
bridges, unaware of the mapping.

> perhaps be a TLV in which the terse region numbers were described with

OK, sounds like a good basis for the mib - an Rbridge can be configured
with a set of Regions, each of which has an ASCII Region name and a
2-byte Region ID. Each Region is associated with one or more ports on
this Rbridge, and a set of From-Vlan to To-Vlan mappings. Does that
sound about right?

Anil

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 31 Mar 2010 13:43:12 -0400

Hi Anil,

> opt for advertising only mapped VLANs.

The IEEE 802.1Q-2005 ability to configure a port so that it blocks some
sub-set of the possible VLANs is still there in RBridges, since RBridge
ports are 802.1Q-2005 ports. So, if the network manager can accomplish the
mapping/blocking they want that way, they certainly can. This should
probably be pointed out in the VLAN mapping draft.

Thanks,
Donald

> ...

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 31 Mar 2010 15:51:09 -0400

> understandable technical issue, so could certainly be discussed

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.

So, no field translations are done in the current proposal. For the general
link state database, pre-mature pruning is avoided by attracting more data
frames to the cut-set RBridges, in many cases more data frames that would be
strictly necessary. For ESADI, the occurrence of VLAN ID fields (at least
VLAN ID fields with a non-zero value) inside the LSPs is prohibited.

> > which makes it easier to do that mapping in the LSP.

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

Thanks,
Donald

---

From: Anil Rijhsinghani <[email-masked]>
Date: Wed, 31 Mar 2010 17:57:39 -0400

> also for all types of TLV/sub-TLV specified in the future. I do not think

Only TLVs that involve the VLAN.
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.

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?

> to the same region as p1 and which that frame might get forwarded out

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?

Thanks,
Anil