Subject: [rbridge] Proposal for making per-VLAN instance optional (to listen to)

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 17 Apr 2007 12:37:50 -0700

First an explanation of the issue:

Some people have expressed a scalability concern: that if there are many 
more endnodes
(that the Designated RBridge R1 knows about) than ones that are talking 
to endnodes
on Designated RBridge R2's link, there is no reason for R2 to know about 
all those other
endnodes, and the traffic to keep R2 informed about R1's endnodes' 
comings and goings
might be a concern.

TRILL will work if some RBridges decide they want to learn endnode 
locations from
decapsulated traffic rather than from the per-VLAN instance in which the 
Designated RBridge
announces its attached endnodes. (and other RBridges learn from the 
per-VLAN instance).

So it is OK to make *learning* from the IS-IS endnode announcements 
optional. R2
could learn only from the source MAC address of frames it decapsulates 
onto its link, even
if other RBridges are learning from the IS-IS endnode announcements.

But we can't make *advertising* attached endnodes optional, because if 
there's any RBridge R3
that does NOT want to learn from decapsulated traffic, and wants to 
learn from IS-IS announcements, then if all the other RBridges stop 
advertising, then R3 will flood everything.

So--you ask--why don't we *only* learn from decapsulated data traffic?

The reasons are as follows:
a) some people have said that router products don't like to learn from 
the data plane; they
want to forward traffic without thinking very hard, and want to do the 
work of updating
forwarding tables based on control traffic
b) there are some layer 2 technologies in which endnodes enroll, and 
being able to announce
these attached endnodes is nice because it is definitive -- you know 
when they attach,
you know when they go away -- it's more secure than learning from data, 
since anyone
can send data with any source address and cause disruption. The IS-IS 
announcement
can even modify how definitive the attached endnode is "it enrolled" "it 
enrolled
cryptographically" "I learned it just because I heard a data packet with 
that as source
address"
c) the per-VLAN IS-IS endnode announcements also announce the layer 
3/layer 2
correspondence to facilitate proxy ARP/ND (though that could probably be 
learned
from decapsulated data traffic as well).

***********************
OK, now the proposal:

One suggestion of course is to eliminate the per-VLAN IS-IS instance, 
and make
everyone learn from data traffic. I don't have strong opinions on that, 
but we should
make sure the people doing router products can cope with this, and that 
we don't
care about the other potential advantages of advertising endnodes with 
IS-IS.

But I think we can have a compromise that will make both sides happy.

The idea is to have RB1 announce, in its core instance, whether it wants 
to learn
from IS-IS endnode announcements. If any RBridge in VLAN A wants to learn
from endnode announcements, then all the RBridges in VLAN A MUST send
IS-IS endnode announcements.

But if *all* the RBridges in VLAN A say they don't want them, then the 
VLAN A
endnode announcements stop.

Even if there are endnodes announcements in VLAN A, it is optional for 
an RBridge
whether it wants to learn from data or from the announcements, or from some
combination of the two (like perhaps it will only learn from endnode 
announcements
which are definitive, or that it will learn from endnode announcements, 
but if
it runs out of room to store them, it will fall back on learning from data).

We could even have core RBridges filter IS-IS endnode announcements for 
VLAN A
to only deliver them to RBridges in VLAN A that say that want to learn 
from them.

***************
What do people think?

Radia

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 18 Apr 2007 07:45:44 -0700

The proposal strikes me as a reasonable compromise that ensures
interoperability
while allowing specific implementations to optimize as they see best for
their
target deployment.

Assuming both this and the VLAN-sharing ideas make it into the next
draft,
it might be worth noting than RBridges using the VLAN-sharing concept
will
need the IS-IS advertisements.

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 19 Apr 2007 09:13:45 -0500

Radia,

	I think you are making this too hard.  Please see
my comments below.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Tuesday, April 17, 2007 3:38 PM
> To: rbridge at postel.org
> Subject: [rbridge] Proposal for making per-VLAN instance 
> optional (to listento)
> 
> Some people have expressed a scalability concern: that if 
> there are many more endnodes (that the Designated RBridge
> R1 knows about) than ones that are talking to endnodes on
> Designated RBridge R2's link, there is no reason for R2 to 
> know about all those other endnodes, and the traffic to 
> keep R2 informed about R1's endnodes' comings and goings
> might be a concern.

A picture right about here would be extremely useful.

> 
> TRILL will work if some RBridges decide they want to learn
> endnode locations from decapsulated traffic rather than
> from the per-VLAN instance in which the Designated RBridge
> announces its attached endnodes. (and other RBridges learn
> from the per-VLAN instance).

This is true.  Is it worth the price to other RBridges (in
terms of option complexity) to support this?

> 
> So it is OK to make *learning* from the IS-IS endnode 
> announcements optional. 

I am unsure that this follows.  When you say "it is ok", you
are apparently referring to the fact that it will work.  That
is not the same as "it is okay" (acceptable), IMO.

> R2 could learn only from the source MAC address of frames
> it decapsulates onto its link, even if other RBridges are 
> learning from the IS-IS endnode announcements.

There are (at least) three ways in which this impacts the way 
other RBridges are required to behave:

1) it now becomes an issue for either configuration (yech!)
   or negotiation in protocol to determine which of two 
   kinds of behavior will apply;
2) this might occur in one of three ways -
   a) on the basis of peer-adjacency - in which case a peer
      will need to decide whether or not to propagate IS-IS
      end-node announcements on a per-peer basis,
   b) on the basis of domain-wide policy that applies to all
	RBridges in a campus, or
   c) some complicated combination of both;
3) all RBridges are likely to have to endure a greater load
   of unicast flooding as a result of information not kept
   by the "lame-duck" implementations that simply do not
   want to receive (or retain) IS-IS endnode announcements.

> 
> But we can't make *advertising* attached endnodes optional, 
> because if there's any RBridge R3 that does NOT want to 
> learn from decapsulated traffic, and wants to learn from 
> IS-IS announcements, then if all the other RBridges stop 

This is but one issue with making the decision on a basis 
of peer adjacencies.  Another is that - in a deployment
where the majority of edge RBridges elect not to receive
such announcements, the core RBridges (in environments
where there is actually a real distinction between "core"
and "edge" RBridges) should be configured not to receive
them either.  Otherwise, the edge RBridges will originate
a lot of announcement traffic that will then be dropped
rather than being propagated.

But, of course, if the core RBridges are configured not to
receive these announcements, then your problem arises.  I
assume that we're not suggesting that all RBridges MUST 
support this "old-style" learning, so even when the ones
that do not are a minority, they still need to receive the
endnode announcements.

> So--you ask--why don't we *only* learn from decapsulated 

Not my question at all.

Learning from decapsulation is a flagrant layer violation,
and - as such - is either too risky, or too restrictive in
future developments.

With that caveat, if you want to do it, more power to you.

> a) some people have said that router products don't like 
>    to learn from the data plane; they want to forward
>    traffic without thinking very hard, and want to do
>    the work of updating forwarding tables based on control
>    traffic
> b) there are some layer 2 technologies in which endnodes
>    enroll, and being able to announce these attached 
>    endnodes is nice because it is definitive 
>    -- you know when they attach, you know when they go away 
>    -- it's more secure than learning from data, since anyone
>       can send data with any source address and cause 
>       disruption. 
>
> The IS-IS announcement can even modify how definitive the 
> attached endnode is 
>    "it enrolled" 
>    "it enrolled cryptographically" 
>    "I learned it just because I heard a data packet with 
>     that as source address"
>
> c) the per-VLAN IS-IS endnode announcements also announce the
>    layer 3/layer 2 correspondence to facilitate proxy ARP/ND
>    (though that could probably be learned from decapsulated
>    data traffic as well).

This last point assumes a behavior that - IMO - should be 
included, but is not (AFAIK) included in the current WG 
consensus.

> 
> ***********************
> OK, now the proposal:
> 
> One suggestion of course is to eliminate the per-VLAN IS-IS
> instance, and make everyone learn from data traffic. I don't
> have strong opinions on that, but we should make sure the
> people doing router products can cope with this, and that 
> we don't care about the other potential advantages of
> advertising endnodes with IS-IS.
> 
> The idea is to have RB1 announce, in its core instance, 
> whether it wants to learn from IS-IS endnode announcements. 
> If any RBridge in VLAN A wants to learn from endnode
> announcements, then all the RBridges in VLAN A MUST send
> But if *all* the RBridges in VLAN A say they don't want them, 
> then the VLAN A endnode announcements stop.
> 
> Even if there are endnodes announcements in VLAN A, it is 
> optional for an RBridge whether it wants to learn from data
> or from the announcements, or from some combination of the
> two (like perhaps it will only learn from endnode 
> announcements which are definitive, or that it will learn
> from endnode announcements, but if it runs out of room to
> store them, it will fall back on learning from data).
> 
> We could even have core RBridges filter IS-IS endnode 
> announcements for VLAN A to only deliver them to RBridges
> in VLAN A that say that want to learn from them.
> 
> ***************
> What do people think?

As I said above, I think you are making this too hard.

As with bridges before them, all RBridges may eventually
have to deal with memory (scale) limitations by purging 
their least-used, or least recently refreshed "filter"
information.

This implies two choices in implementation: 

1) optimize for the IS-IS approach by designing both for
   large and expandable memory capacity to minimize the
   need for purging and (potentially) having to re-learn 
2) optimize for the data-learning approach, save on cost 
   of memory at a cost of increased forwarding complexity

Clearly if the IS-IS endnode announcements are sent to all
RBridges in a campus, then any that are unable to retain
the information (because of their optimization choices) 
will be able to either ignore them, or purge their DBs
according to whatever local policy applies to their own
implementation.

The only time the IS-IS endnode announcement traffic is 
likely to be a problem is if all RBridges are ignoring
them.  Since this will be an exclusive property of those
RBridges that only use "old-style" learning, I assume it
will be possible to configure those same RBridges not to
send IS-IS announcements in the event that a specific
deployment scenario does not require them.

This places the (minimal) additional complexity in those
RBridges that choose to learn without any impact at all
on those that choose to use IS-IS endnode announcements.

> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>