[rbridge] Proposed compromise for short/long hellos

Fri Apr 3 06:56:29 PDT 2009

Mike,

    Based on the discussion thus far, the ideal solution would be
something along
the lines of the following:

    1) Padding of IS-IS messages would be optional (we could argue what
the default
        would be) - and would be determined either by configuration, or
by any method
        an implementation may choose (for example, an implementation
might simply
        elect to remove padding if a sharp rise in congestion
indications is noted - for
        example, a sudden and continuous stream of buffer overflow
indications from
        forwarding components).
    2) RBridge implementations MUST NOT reject a hello message because
it is not
        padded - for whatever reason.
    3) RBridge implementations MUST NOT make any assumptions based on
the size
        of a hello PDU (such as guessing that this is the peer's MTU
size), unless there
        is an explicit indication that a specific hello PDU is padded.

I would argue that padding of the RBridge IS-IS messages would be done
if there is
any way for a specific implementation to be certain that the MTU size
used in padding 
is well known.  This would be the case if a pair of RBridge
implementations has any sort 
of MTU discovery mechanism that will determine an accurate MTU size, if
there is a
useful minimum MTU size defined for the technology (useful in that it is
large enough
to support at least a maximum size un-fragmentable control message), or
if the network
operator is certain enough of this size to enable padding.

    I would also argue that - if there is a mechanism capable of being
used for MTU 
discovery - MTU discovery/determination should occur BEFORE the DRB
(and/or 
designated forwarder) determination process begins (and certainly before
forwarding
begins), and would be repeated periodically after this is done.

--
Eric

________________________________

From: mike shand [mailto:mshand at cisco.com] 
Sent: Friday, April 03, 2009 7:29 AM
To: Eric Gray
Cc: Radia Perlman; TRILL/RBridge Working Group
Subject: Re: [rbridge] Proposed compromise for short/long hellos
Importance: High

Eric Gray wrote: 

	Radia,

		I liked the wording of the second part of this better in
your
	previous posting - i.e. - where the mechanism used for MTU
discovery
	is clearly to be specified separately.

		As I mentioned during the meeting, there are capabilties
at the
	L2 level that can be used to determine the L2 MTU size.  Since
this 
	is clearly a general problem for L2 networks, defining a
solution for
	it in the IETF - particularly one that is very specific to a
single
	application - is probably not appropriate.

But IS-IS requires the enforcement of a minimum MTU size to ensure that
its LSPs are correctly delivered and it already has the mechanism to do
that (in the padded hellos). Why change that?

    Mike

	--
	Eric

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

	Mike,

	Personally, I would have been OK with what was in the latest
version
	of the spec (I think I might even have been the one that
suggested that 
	solution
	on the mailing list), but it did not get a warm reception at the
WG 
	meeting in San Fransisco. Two types of hellos, padded
	and unpadded, being sent on different VLANs -- it seemed
unnecessarily 
	complicated, and indeed I kind of tripped
	over my words as I was trying to describe it. People were saying
that 
	Hellos should be for finding neighbors, not
	also for MTU discovery.

	After hearing people's
	concerns and suggestions, I described what I thought would go
over 
	better, and actually, I like it much better.

	a) Hellos just as we'd specified it before Jim Carlson noticed
the 
	problem with padded hellos, but adding to the
	spec that TRILL Hellos MUST NOT be padded.
	b) Having a separate protocol, that actually works better I
think, for 
	MTU discovery, where to allow it to be optional,
	we add a flag to the Hello saying "I support MTU discovery", and
then 
	having an MTU discovery protocol where R1
	sends a padded message of some size, and other RBridges on the
link that

	hear that message reply with an ack to R1.

	Radia

	mike shand wrote:

		Radia,
		   Re-reading draft-ietf-trill-rbridge-protocol-12,
isn't the 
		combination of adjacency hellos and protection hellos
essentially the 
		same as what I proposed below? So why are you proposing
that it should

		be reversed to have non-padded IS-IS hellos (which would
also have to 
		have the IS-IS rules changed with respect to not using
only UP 
		adjacencies and still electing even when there are no
other 
		adjacencies) and (optional?) MTU discovery hellos, which
interact in 
		some yet to be completely specified way with the
adjacency formation 
		rules. Why is that better than what seems to be the
natural approach 
		of keeping the IS-IS stuff unchanged and adding
something which has 
		the required TRILL semantics for the identification of
the 
		forwarders. It seems to have traded two hellos, one of
which was 
		identical to the existing IS-IS mechanisms, for two
hellos, neither of

		which are the same as IS-IS.

		   Mike

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090403/c76f98c2/attachment-0001.html