Subject: [rbridge] Proposed details for announcing endnodes

From: [email-masked]
Date: Fri, 25 Apr 2008 16:56:36 -0700

The unfortunate choice of the words ('per-VLAN instance of IS-IS") for the protocol in
which endnodes would be announced has definitely confused people, so let me
give details about how I think it should work.

What we want to accomplish: If R1 is a VLAN-A forwarder on at least one link, R1 wants to inform
other VLAN-A forwarders about at R1's attached VLAN-A endnodes.

The proposal:

a) R1 multicasts a packet throughout the campus, directed at VLAN-A. This packet is encoded as a link
state packet, with a sequence number. If it is too large to fit into a single packet IS-IS allows LSP "fragments",
where each fragment is separately flooded, and has its own sequence number. If data in one fragment changes,
that fragment needs to be flooded, but unchanged fragments do not need to be.

b) An RBridge that is not a VLAN-A forwarder on any of its links participates in the
flooding of the packet on the tree chosen by ingress R1, but does not otherwise process the packet.

c) If R2 is a VLAN-A forwarder on at least one of its ports, it stores R1's most recently generated packet, in order
to fold the information into its endnode learning table (to know that those endnodes should be forwarded
to R1)

d) To ensure reliable delivery of R1's announcement, we need for one of the VLAN-A forwarders to take
on the responsibility of sending an IS-IS CSNP periodically.

e) Traditionally, IS-IS would choose which switch is responsible for sending a CSNP, by sending Hello messages
and doing a DR election. However, in this case, the LSPs in the "core instance" of IS-IS gives enough information
for all the RBridges to know which RBridge should be issuing the CSNP. The necessary information is for R1
to announce (in its core LSP), which VLANs R1 is VLAN forwarder for. Note: This information is already
in the protocol spec.

However, since generating and processing VLAN A endnodes announcements is optional, we should add
a flag that says "I participate in the endnode announcement protocol for VLAN A".
There are two reasons for this flag: one is that if R1 is the only VLAN-A forwarder that participates, then R1
should not make announcements (since they'll just be ignored). The other reason is to elect (without
further protocol message", the VLAN-A forwarder that will periodically send CSNPs.

f) Based on (priority, ID) one VLAN-A forwarder will be elected to periodically issue CSNPs. However, if
any VLAN-A forwarder hasn't seen a CSNP recently, it is not problem for it to send a CSNP.

********************
So...what is the cost of this?

Already we have the information in R1's LSP about which VLANs R1 is forwarder for. I'm not sure whether we
already have the flag "I participate in endnode announcements for VLAN A".

The information about attached endnodes is in the format of IS-IS endnode announcements. No other information
appears. The endnode announcement LSP gets flooded like any VLAN A multicast/unknown destination data
packet, so that it will be delivered to all RBridges that are VLAN A forwarders.

One of the VLAN A forwarders sends periodic CSNPs so that if any RBridges miss any of the announcements,
this will be detected and corrected.

Radia

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

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 28 Apr 2008 16:36:30 -0700

Although I don't think I would be interested
in implementing this aspect of the protocol, I think
this is a reasonable proposal.

There is one concern - how do we deal
with moves?  A move would mean that there are
2 forwarders that think they own the address so
how would they resolve the conflict?

Anoop

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, April 25, 2008 4:57 PM
> To: [email-masked]
> Subject: [rbridge] Proposed details for announcing endnodes
> 
> The unfortunate choice of the words ('per-VLAN instance of 
> IS-IS") for the protocol in which endnodes would be announced 
> has definitely confused people, so let me give details about 
> how I think it should work.
> 
> What we want to accomplish: If R1 is a VLAN-A forwarder on at 
> least one link, R1 wants to inform other VLAN-A forwarders 
> about at R1's attached VLAN-A endnodes.
> 
> The proposal:
> 
> a) R1 multicasts a packet throughout the campus, directed at 
> VLAN-A. This packet is encoded as a link state packet, with a 
> sequence number. If it is too large to fit into a single 
> packet IS-IS allows LSP "fragments", where each fragment is 
> separately flooded, and has its own sequence number. If data 
> in one fragment changes, that fragment needs to be flooded, 
> but unchanged fragments do not need to be.
> 
> b) An RBridge that is not a VLAN-A forwarder on any of its 
> links participates in the flooding of the packet on the tree 
> chosen by ingress R1, but does not otherwise process the packet.
> 
> c) If R2 is a VLAN-A forwarder on at least one of its ports, 
> it stores R1's most recently generated packet, in order to 
> fold the information into its endnode learning table (to know 
> that those endnodes should be forwarded to R1)
> 
> d) To ensure reliable delivery of R1's announcement, we need 
> for one of the VLAN-A forwarders to take on the 
> responsibility of sending an IS-IS CSNP periodically.
> 
> e) Traditionally, IS-IS would choose which switch is 
> responsible for sending a CSNP, by sending Hello messages and 
> doing a DR election. However, in this case, the LSPs in the 
> "core instance" of IS-IS gives enough information for all the 
> RBridges to know which RBridge should be issuing the CSNP. 
> The necessary information is for R1 to announce (in its core 
> LSP), which VLANs R1 is VLAN forwarder for. Note: This 
> information is already in the protocol spec.
> 
> However, since generating and processing VLAN A endnodes 
> announcements is optional, we should add a flag that says "I 
> participate in the endnode announcement protocol for VLAN A".
> There are two reasons for this flag: one is that if R1 is the 
> only VLAN-A forwarder that participates, then R1 should not 
> make announcements (since they'll just be ignored). The other 
> reason is to elect (without further protocol message", the 
> VLAN-A forwarder that will periodically send CSNPs.
> 
> f) Based on (priority, ID) one VLAN-A forwarder will be 
> elected to periodically issue CSNPs. However, if any VLAN-A 
> forwarder hasn't seen a CSNP recently, it is not problem for 
> it to send a CSNP.
> 
> ********************
> Already we have the information in R1's LSP about which VLANs 
> R1 is forwarder for. I'm not sure whether we already have the 
> flag "I participate in endnode announcements for VLAN A".
> 
> The information about attached endnodes is in the format of 
> IS-IS endnode announcements. No other information appears. 
> The endnode announcement LSP gets flooded like any VLAN A 
> multicast/unknown destination data packet, so that it will be 
> delivered to all RBridges that are VLAN A forwarders.
> 
> One of the VLAN A forwarders sends periodic CSNPs so that if 
> any RBridges miss any of the announcements, this will be 
> detected and corrected.
> 
> Radia
> 
> 
> 
> 
>

---

From: Radia Perlman <[email-masked]>
Date: Mon, 28 Apr 2008 20:53:54 -0700

Yeah. Moving endnodes is always an issue. Even with bridges. The problem 
with having R1 (the one announcing that endnode E is
attached to R1) having a very short learning cache is that makes R1's 
endnode announcement LSP information annoyingly volatile. The problem
with the learning
cache timer being long is that R1 can be a black hole, sucking traffic 
away from where E really is.

There are some layer 2 protocols, I believe, with explicit registration 
and keep-alives. (anyone care to chime in about which protocols
these are?). Endnodes learned that way are good candidates for 
explicitly advertising.

For attached IP endnodes, R1 could do something like, if it seems 
someone else advertise E, R1 could do an ARP to see if E is
still there. And there might be similar purely layer 2 "pings". (are there?)

Also, if R1 is the only one advertising E, it doesn't really matter if E 
isn't there, so long as nobody is trying to send traffic to E.
So R1 could delay attempting to see if E is there until someone tries to 
talk to it.

Radia

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Apr 2008 22:10:23 -0700

> still there. And there might be similar purely layer 2 "pings". (are there?)

I do not believe rbridges should ever issue ARPs. Silent movement is a 
known problem with existing bridges; this is not an issue we should be 
solving.

Joe

---

From: "Steve Dalberg" <[email-masked]>
Date: Tue, 29 Apr 2008 07:32:33 -0700

> Radia Perlman wrote:
> > Yeah. Moving endnodes is always an issue. Even with bridges. The 
> > problem with having R1 (the one announcing that endnode E 
> is attached 
> > to R1) having a very short learning cache is that makes 
> R1's endnode 
> > announcement LSP information annoyingly volatile. The 
> problem with the 
> > learning cache timer being long is that R1 can be a black hole, 
> > sucking traffic away from where E really is.
> > 
> > There are some layer 2 protocols, I believe, with explicit 
> > registration and keep-alives. (anyone care to chime in about which 
> > protocols these are?). Endnodes learned that way are good 
> candidates 
> > for explicitly advertising.
> > 
> > someone else advertise E, R1 could do an ARP to see if E is still 
> > there. And there might be similar purely layer 2 "pings". 
> (are there?)
> 
> I do not believe rbridges should ever issue ARPs. Silent 
> movement is a known problem with existing bridges; this is 
> not an issue we should be solving.
> 
> Joe

I agree, although from a protocol level, what is the fallout from
conflicting MAC's?  Will it cause protocol thrashing in any way?  

As for the Layer 2 "pings" question, you'd be better off just looking
for traffic sourced by the MAC in question over a couple of second
period.  Not sure what you would want to do with that, but if you don't
see anything you can safely clear your forwarding table 

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Apr 2008 07:51:09 -0700

> conflicting MAC's?  Will it cause protocol thrashing in any way?  

Radia noted it above - it black-holes traffic to the true MAC location.

> see anything you can safely clear your forwarding table 

That works only for bidirectional traffic. Silent listeners that move 
always cause problems - and, as I onted, we shouldn't propose to fix 
that issue.

Joe

---

From: James Carlson <[email-masked]>
Date: Tue, 29 Apr 2008 11:50:52 -0400

> always cause problems - and, as I onted, we shouldn't propose to fix 

If it's a truly silent listener, then it won't really cause us any
problems.  Absent special tricks (such as 802.11 in AP mode), we won't
learn of its location by any means, and we thus will be forced to
flood all packets sent to that receiver.  No location-related problem
should occur.

If it's a listener that speaks once in a blue moon, then Steve's note
holds: we'll time out the entry, stop using it, and revert back to
flooding for an unknown destination.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Apr 2008 09:38:23 -0700

> flood all packets sent to that receiver.  No location-related problem

A silent listener that moves will never trigger broadcast, UNLESS we 
time-out entries. That might be desirable - and since truly silent 
liseners are an exception, that shouldn't cause a problem. I.e., a 
passive solution might be appropriate.

> flooding for an unknown destination.

Right - the speaking tells us when they move.

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 29 Apr 2008 09:42:24 -0700

Agree with Joe,

Dinesh
Joe Touch wrote:
>> problem with having R1 (the one announcing that endnode E is
>> cache timer being long is that R1 can be a black hole, sucking 
>> traffic away from where E really is.
>>
>> protocols
> ------------------------------------------------------------------------
>

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 29 Apr 2008 21:30:14 -0400

(1) I don't see any point in discussing ARP now since the working group
has decided to move ARP and similar IP optimization out of the base
protocol draft to another document which does not yet even exist.

(2) The purpose of Rbridges is to do better than bridges. Arguments of
the form 'X is a known problem with bridges so we shouldn't solve it'
seem odd when the main premise of Rbridges is 'spanning tree is a known
problem with bridges so we WILL solve it'.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dinesh G Dutt
Sent: Tuesday, April 29, 2008 12:42 PM
To: Joe Touch
Cc: [email-masked]; Radia Perlman
Subject: Re: [rbridge] Proposed details for announcing endnodes

Agree with Joe,

Dinesh

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 29 Apr 2008 22:17:03 -0400

See below at @@@ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, April 29, 2008 12:38 PM
To: James Carlson
Cc: [email-masked]
Subject: Re: [rbridge] Proposed details for announcing endnodes

@@@ Time out only matters if it got into the address cache somehow to
begin with which wouldn't happen if it was always silent. And, we have
decided that addresses learned at the data plane will be timed out in
the same way as in an 802.1 bridge. See
http://www.postel.org/pipermail/rbridge/2007-October/002507.html.

@@@ Thanks,
@@@ Donald

Joe

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 29 Apr 2008 23:44:50 -0400

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Steve Dalberg
Sent: Tuesday, April 29, 2008 10:33 AM
To: [email-masked]
Subject: Re: [rbridge] Proposed details for announcing endnodes

...

@@@ If you are just doing data plane learning (i.e., learning from
received frames and decapsulated frames), it's pretty much like 802.1
bridges. Frames addressed to a MAC address can get sent out the wrong
port until an old learned MAC address that is no longer correct times
out. If you are listening to the VLAN end station address IS-IS frames,
there could be multiple other Rbridges advertising that the have the
same end station MAC address attached. The various different sources of
information as to what Rbridge an end station address is attached two
all have a one byte unsigned confidence level associated with them. If
there are more than one with the same confidence, the current spec does
not say how to choose but it seems likely that most implementations
would just end up using whatever information they had most recent
processed as, in general, "newer" information of equal confidence to
what an Rbridge is currently using over-rides older information. See
Section 4.6 of the current base protocol specification
draft-ietf-trill-rbridge-protocol-07.txt. In any case, there isn't
anything I would call "thrashing".

@@@ I don't see how you can say that for all layer 2 interfaces. IEEE
802.11, for example, rapid movement of end stations from one network
attachment point to another has always been an assumed part of the
protocol. It has explicit association, disassociation, and
re-association messages (although it is really a bit more complex with
authentication and security ...).

@@@ Thanks,
@@@ Donald

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Apr 2008 20:58:33 -0700

Eastlake III Donald-LDE008 wrote:
...
> problem with bridges so we WILL solve it'.

My understanding is that the WG was created with a number of assumptions 
that limit how and where rbridges do better than bridges.

Specifically, they do better in replacing spanning tree with 
Internet-style routing protocols.

Specifically, they do NOT:
	- scale better than bridges
	- handle dynamic endstation movement better
	- handle silent receiver movement better
	- fix any other deficiency in the 802 suite

I.e., TRILL is focused on the spanning tree issue. We're not here to fix 
issues that are not created by our solution. We discussed this with 
respect to scale numerous times, but it seems like it's worth stating in 
general.

Joe

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 30 Apr 2008 11:34:05 -0500

Donald,

	On your second point, this is a specious argument.  The fact
that we (collectively) have decided to take on a specific problem
that we (or at least some of us) feel exists with bridges does not
grant license to including all problems that we (definitely some 
of us this time) also feel exist.  That is a recipe for closure of
the working group, rather than the work...

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, April 29, 2008 9:30 PM
> To: Dinesh G Dutt; Joe Touch
> Cc: [email-masked]
> [mailto:[email-masked]] On
> Behalf Of Dinesh G Dutt
> >> still there. And there might be similar purely layer 2 
> "pings". (are 
> >> there?)
> >
> movement is a

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 30 Apr 2008 12:35:46 -0400

Hi Joe,

I partly agree with you and partly disagree. See below at @@@

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2008 11:59 PM
To: Eastlake III Donald-LDE008
Cc: Dinesh G Dutt; [email-masked]
Subject: Re: [rbridge] Proposed details for announcing endnodes

@@@ Yes, there were assumptions. But I see these as simply setting goals
for the WG. While they may limit those goals, they do not "limit how and
where RBridges do better than bridges". That would be a limit on
results, not on goals.

@@@ They do. But the charter says very little about other performance
related goals or non-goals. It mostly speaks about scope in more general
terms, such as prohibiting the working group from designing a new
routing protocols. I would point out that the WG charter also
specifically states that the starting point is
draft-perlman-rbridge-03.txt which had extensive material on ARP
optimization, etc. The working group has decided to remove such IP
optimizations from the base protocol specification and make them into a
separate document, which is fine, but the effort would also have been
charter conformant if it had left such provisions in the base protocol
document and refined them.

@@@ As I say, I do not agree that there has been a decision, by the
TRILL working group or in its charter, that Rbridges MUST be no better
than bridges in scaling. It is just not particularly a goal of the group
to have them scale better. Quite possibly they will scale better due to
some Rbridge routing tables scaling with the number of Rbridges rather
than the number of MAC addresses or some other reason.

@@@ I'd have no problem is you said "they need not" above instead of
"they do NOT". To, in effect, say that it is forbidden to include any
facet in the TRILL protocol which happens to improve scaling or the
handling of dynamic end station movement or the like seems to me to be
unsupported by either our charter or the discussions that have been
held.

@@@ Thanks,
@@@ Donald

general.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2008 10:25:26 -0700

...
> than bridges in scaling.

We agreed that they need not support scale in the PAS discussions a long 
time ago. (i.e., NEED NOT, not "NOT").

...
> "they do NOT". 

Agreed.

> To, in effect, say that it is forbidden to include any

Yes, there's a big difference between:

	A- a decision happens to support scale

	B- a decision is motivated by support for scale

I agree that A is in-scope, and I think we agree that B is not. I think 
that some of the discussions for optimization here for announcing 
end-nodes fall under B rather than A.

Joe