Avoiding zillions of pseudonodes in TRILL when there are zillions of VLANs

Someone asked how IS-IS would handle a layer 2 cloud that
was running 1000
VLANs.

If RBridge R1 can talk on the same "layer 2 cloud"
to R2 (i.e., same 
link, maybe some bridges
between them, but no RBridges between them), R1 might
need to put in a VLAN tag in order to talk to R2 (because
of
how bridges between R1 and R2 are configured.

TRILL will consider R1 and R2 to be neighbors, and nobody
outside that 
link needs
to know what VLAN tag R1 needs to communicate with R2 with.

Because of the way bridges might be configured, a particular
layer 2 
cloud might be
partitioned for VLAN A but not for VLAN B. So, R1 might be
able to talk 
to R2
using a VLAN A tag, and R1 might be able to talk to R3 using
a VLAN B tag,
but R1 might not be able to talk to R3 at all.

The only way to know for sure who you can talk to as a
neighbor
on a shared medium, and what VLAN tag to use when
talking to them, seems to be to send the Hellos tagged with
each 
potential VLAN.

The straightforward thing would be to send Hellos with every
possible 
VLAN tag,
(4000 of them), which is not very palatable.

So RBridges would, as default, send Hellos only with
untagged (or VLAN 
1), and
be configurable to send Hellos with other VLAN tags as
well.

So there would be a DR election separately for each VLAN.
Some even consider
this a feature, so that by diddling with priorities you can
have 
different RBridges
be DR for different VLANs.

So now let's say that there are 1000 VLANs on a particular
link. You 
would not want
there to be 1000 pseudonodes.

Here are other possibilities:

a) get rid of the pseudonode concept in the LSPs, and have
all the 
RBridges on the link
report each other as neighbors. One adjacency per neighbor
RBridge on 
that link,
regardless of how many VLANs you can talk to him on.
(there's already an 
IS-IS
WG draft about this)

b) have the DR give only one name to the link, regardless of
what VLAN 
the Hello is tagged
with. So, for instance, if R1 is DR for VLANs {A, B, C, F}
on a link, R1 
would
name the pseudonode something like "R1.1", and
even though the 
information in
the Hello that R1 sends on VLAN A might be different than
the Hello that
R1 sends tagged with VLAN B, R1 will use the same pseudonode
name.
The information that might be different is the set of
RBridges that R1 
can hear.
So in R1's Hello tagged with VLAN A, R1 will report all the
RBridge 
Hellos it heard
on that link that were tagged with VLAN A.

This means that even if R2 and R3 cannot actually talk to
each other 
(since R2 can only
talk with VLAN B and R3 can only talk with VLAN F), they
will each report
reachability to R1.1.

The way I'd handle this is that when R2 is calculating its
forwarding 
database, when it
notices that it needs to forward to R3 through pseudonode
R1.1, and that it
actually doesn't have an adjacency to R3, R2 instead puts
the DR (R1) into
the forwarding table in place of R3.

***********
Pros and cons of the 2 solutions

a) nice and simple. Only scalability problem is if there are
a zillion 
RBridges on
the same layer 2 cloud. But if most of the bridges are
replaced with 
RBridges, then
there won't be very large layer 2 clouds.

b) a bit hacky in the case where R2 can't actually talk to
R3, but other 
than that
I think it works, and I personally don't have a lot of
sympathy with 
such complex
configuration of VLANs that the cloud winds up partitioned.

Are there other solutions? Comments?

Thanks,

Radia

_______________________________________________
Isis-wg mailing list
Isis-wgietf.org
https:
//www1.ietf.org/mailman/listinfo/isis-wg

Avoiding zillions of pseudonodes in TRILL when there are zillions of VLANs

Thread: Avoiding zillions of pseudonodes in TRILL when there are zillions of VLANs