Subject: [Isis-wg] Avoiding zillions of pseudonodes in TRILL when there are zillions of VLANs

From: Radia Perlman <[email-masked]>
Date: Thu, 14 Jun 2007 23:07:59 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Fri, 15 Jun 2007 09:40:28 +0100

> the forwarding table in place of R3.
On reading this I thought "but ISO 10589 already specifies that 
behaviour". Unfortunately I can't find it anywhere (or even in the 
DECnet PhaseV spec!). I'm SURE is WAS in there, but maybe it got taken 
out sometime. It used to say pretty much what you just proposed. i.e. 
that if your SPF showed that something was reachable through the 
pseudonode, but you didn't have an adjacency to the next hop node, then 
you should send the packet to the DR (since that MUST have an adjacency 
to the next hop otherwise it wouldn't have been able to advertise it in 
its pseudonode LSP).

Am I just unable to find it, or has it really gone missing?

    Mike

---

From: mike shand <[email-masked]>
Date: Fri, 15 Jun 2007 11:46:32 +0100

mike shand wrote:
> pseudonode, but you didn't have an adjacency to the next hop node, 
> then you should send the packet to the DR (since that MUST have an 
> adjacency to the next hop otherwise it wouldn't have been able to 
> advertise it in its pseudonode LSP).
>
Aha! it was skulking in appendix C, clause 2.5 bullet h)

"Now add any systems to which the local Intermediate system does not 
have adjacencies, but which are mentioned in neighbouring
pseudonode LSPs. The adjacency for such systems is set to that of the 
Designated Intermediate System."

So I did remember correctly:-)

However, since this is an informative, rather than normative appendix, 
there is no guarantee that an implementation will do this.

But, anyway, the point is there is a precedent for this behaviour.

    Mike