[rbridge] Proposed compromise for short/long hellos

[Eric Gray]

Radia,

	I like the outline of a compromise you propose, though I suspect
that this is pretty much the opposite of what the IS-IS folks are very
likely to find acceptable.

	Assuming we go with your proposal, I would suggest that we
should 
be more precise in mentioning a maximum size.  I would suggest something

along the lines of:

<hello PDUs> must be shorter than the lesser of the maximum <PDU length>
presumed for the <carrying technology>, or a configurable maximum value.

	The one reservation people may have is that what was discussed
in 
the meeting was more along the lines of -

1) let's have one type of (IS-IS based) hello.
2) let's define a separate message type - if necessary (as it seems
clear
   that it is) - to address this issue.

   (so far, consistent with your suggestion)

3) The hello message needs to ensure that the maximum packet size each
   end assumes is correct, since (one of) the purpose(s) of these PDUs
   (in IS-IS) is to determine whether an adjacency should be formed.
4) This means that the separate message type would need to address the
   issue with making sure that topologically adjacent RBridges are, in
   fact, discovered irrespective of the appropriateness of making them
   adjacent peers.

	All of that said, however, I think there was a clear sense that
the important objective in the RBridge case is to protect against loop
formation - which is unavoidable in the event that RBridge topological
adjacencies are not discovered.  Prevention of blackholing a subset of
forwarded data because of excessive size is much less of a concern in
this context.  Hence the important message to define first is the one
that allows this discovery of topologically adjacent RBridges.  Since
we have done all of this work to define how to do this using IS-IS,
and the problem that arises is the padding of IS-IS hello messages,
the simplest approach is to eliminate this padding.

	I agree with the proposal, otherwise, as you've proposed it.

--
Eric

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Wednesday, March 25, 2009 12:58 PM
To: TRILL/RBridge Working Group
Subject: [rbridge] Proposed compromise for short/long hellos

After listening to the discussion at the meeting, and talking to some 
people in the hall, I hope
this might be palatable to everyone.

a) have only one type of Hello: the original type, but say in the spec 
that Hellos
MUST NOT be padded. Also mention a maximum size, and say that this might
limit really really really creative appointments of lots of appointed 
forwarders for lots
of VLANs.

b) have another type of mechanism, perhaps called "MTU discovery", which

would
be a pairwise protocol between two RBridges R1 and R2, where R1 sends a 
padded
message, and R2 acks it if R2 received it. This would be an optional 
protocol specified
in a separate document

c) we'd add a bit to the Hello saying "I support the MTU discovery
protocol"
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge