[rbridge] Proposal for making per-VLAN instance optional (to listento)

[Eric Gray (LO/EUS)]

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

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 
> advertising, then R3 will flood everything.

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 
> data traffic?

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.

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

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

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
>