[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isis-wg] [rbridge] Why is MTU discovery important?



Hi Donald,

> draft-ietf-trill-rbridge-protocol-12.txt? You have studied that draft,
> haven't you?

It seems to me just like section 4.2.4.3 Hello Contents of the above draft says there is sufficiently large number of optional information usable for TRILL which could be added to today's ISIS header that perhaps it may make sense to just define it as separate TRILL-Hello msg. My point was that in the same time the padding issue would be solved yet a lot of already available code for L3 ISIS could be reused.

Cheers,
R.

Hi Robert,

See below...

On Fri, Apr 10, 2009 at 1:36 PM, Robert Raszuk <robert at raszuk.net> wrote:
Hi Radia,

Keeping the Hello mechanism exactly as it is in IS-IS today will not work
for TRILL.
That should be the end of discussion. Not padding the Hellos obviously
works for robustly finding neighbors, and is a trivial change. The
only thing that gets lost is MTU discovery.

The only feasible choices at this point are:
a) only do unpadded Hellos, and live with weirdnesses due to not
testing MTU size, deferring MTU discovery to the future
b) do unpadded Hellos, and come up with a mechanism for MTU discovery now.
It would be easy to do so.
+

So to really test the MTU requires a padded packet,
(but it need not be (and MUST NOT be, for TRILL) the same, simultaneous
mechanism
as finding neighbors, such as layer 3 IS-IS which does not see neighbors
that can't
be reached using the largest packets.)
So how about option c) which would leave current L3 ISIS Hellos as is today
and define a new TRILL ISIS Hello mechanism ? Seems to me like quite simple
and trivial solution to accomplish without any compromises.

The short message, whatever it is called, has to have most if not all
the Hello header information. It also has to have in its body (in some
TLV or otherwise) at least the Designated VLAN for link and a copy of
the VLAN ID with which it was tagged on transmission as well as a flag
indicating whether it thinks it is Appointed Forwarder for that VLAN.
Furthermore, the option must be available to authenticate this
message, so it sure seems convenient to be able to include the IS-IS
Security TLV. Furthermore, it needs to participate in DRB
determination in essentially the same way that Hellos need to. By the
time you are through with all that (and maybe I missed something else
that needs to be added), what is the point of not having this short
message be a Hello? Or are you just saying that you favor the two
kinds of Hello solution which is in
draft-ietf-trill-rbridge-protocol-12.txt? You have studied that draft,
haven't you?

Of course if we down the road find that minor changes like this will be
required to other functions of today's ISIS it will be also easier to
separate L3 ISIS from ISIS twicked for TRILL and perhaps even run it fully
independently.

Cheers,
R.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com