Re: [Isis-wg] Fwd: trill-adj Section 7.2 comments

[Donald Eastlake <[e-mail]>]

Hi Les,

On Mon, Feb 14, 2011 at 10:20 PM, Les Ginsberg (ginsberg)
<[e-mail]> wrote:
> Hi Donald.
...

>> Response to some comments by Les Ginsberg:
>>
>> > Section 7.2
>> > ------------
>>
>> > Is IIH padding ignored on receipt?? Or is a padded IIH discarded?
>>
>> I'm not sure why anyone would think that a padded TRILL Hello would be
>> discarded on reciept because of the padding. But, in any case, to
>> clear things up in a more general way, how about replacing
>>
>>   "TRILL Hellos MAY contain an Authentication TLV."
>>
>> at the end of the section with
>>
>>   "In addition to the TLVs mentioned in [RFCtisis] or above in this
>>   document as occuring in TRILL Hellos, a TRILL Hello MAY also
>>   contain any TLV permitted in a Layer 3 IS-IS Hello. Padding and
>>   Neighbor TLVs, as well as any unimplemented or unknown TLVs, are
>>   ignored."
>
> I asked about padding because TRILL makes it a point to deviate from
> the base IS-IS spec in regards to padding - so I thought it worth
> being "extra explicit".
>
> What now seems more important - and which I neglected to ask
> previously - is what happens to a received IIH which exceeds 1470
> bytes? Is it discarded? The draft says "TRILL Hello messages MUST
> NOT exceed 1,470 octets in length..." - which suggests that any IIH
> larger than this is "illegal". What is the intended behavior on
> receipt of a too large IIH?

Ah, good point. This seems like an instance where the IETF maxim of
being conservative in what you send and liberal in what you accept is
the right thing. Should there be some TRILL implementation that padded
TRILL Hellos to 1,471 bytes, on a link with multiple RBridges if those
Hellos were accepted and processed, things would most likely work fine
whereas if they were rejected, you would likely have a loop. So
perhaps

   "TRILL Hello messages MUST NOT exceed 1,470 octets in length and
   SHOULD NOT be padded."

should be replaced by

   "TRILL Hellos PDUs SHOULD NOT be padded and MUST NOT be sent
   exceeding 1,470 octets; however, a received TRILL Hello longer than
   1,470 octets is processed normally."

> As far as your suggested wording above I would propose a modest rewrite:
>
> "A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS
> Hello. TLVs which either have no defined functionality for TRILL or
> are unsupported/unknown are ignored."

Humm, well, what I don't like about the re-write is the "either...or"
part. It seems to me that there could be things that are
orthogonal/unrelated to TRILL and should be allowed and processed if
they are both allowed in Layer 3 IS-IS LAN Hellos and are supported by
a particular RBridge implementation. For example, IS-IS Authentication
seems for the most part, logically, to be a facility completely
orthogonal to everything else in IS-IS PDUs. An IS implementing
Authentication can add an Authentication TLV to any IS-IS PDU it
originates, check any Authentication TLV in any IS-IS PDU it receives,
etc. While there is mention of IS-IS Authentication in TRILL documents
and I'm not proposing its removal, one could argue that all those
mentions are logically unnecessary. You could even model IS-IS
Authentication as a separate layer between all the rest of IS-IS
(whether Layer 3 or TRILL) and the network. In any case, what exactly
would be your objeciton to simplifying the second sentence you propose
to just "TLVs which are unsupported/unknown are ignored." which is a
general principal of IS-IS anyway?

>> > In regards to what TLVs should be in an IIH, the text says:
>>
>> >   If there are no adjacencies with a non-zero Designated VLAN Hello
>> >   Holding timer, an empty TRILL Neighbor TLV MUST be included in each
>> >   Hello.  If there are such adjacencies, then the Hello MAY contain a
>> >   TRILL Neighbor TLV as described in Section 4.4.2.1 of [RFCtrill].
>>
>> > The Neighbor TLV is ONLY used to report neighbors I have seen in
>> > IIHs received on the D-VLAN and if I have NO such neighbors I MUST
>> > send an empty neighbor TLV - but if I do have one or more such
>> > neighbors then sending a neighbor TLV is optional??? What is the
>> > motivation for this?
>>
>> It was the consensus of the participants in the TRILL interop at UNH
>> IOL to add a requirement for sending a TRILL Neighbor TLV with an
>> empty list when you have no neighbors on the Designated VLAN and the
>> working group went along with them. I suppose it clears thing out more
>> quickly in the case of some types of failures and, in any case, a
>> TRILL Neighbor TLV with an empty list of neighbors is only 3 bytes
>> long.
>>
>> > One of the underlying concerns is that the indication of a
>> > connectivity change in a hello may already be delayed because of
>> > space limitations. The behavior you suggest here only seems to make
>> > that issue more significant.
>>
>> Since, in some cases, this provision requires information to be sent
>> sooner, I would have thought you would consider it an improvement.
>
> The mandatory requirement to send an empty neighbor TLV is not
> useful. If I receive an IIH which has no neighbor TLV I am supposed
> to conclude that the sender actually has some neighbors but they
> chose (for whatever reason) not to send any in this particular
> hello. But I can't draw any useful conclusion from this i.e. if they
> subsequently send an IIH with an empty neighbor TLV (presumably w
> both the smallest/largest flags set) am I to conclude that they lied
> in the previous IIH? And if I did, what would I do about it?
>
> The relevant point to make - which you discuss below - is to
> recommend that the full range of neighbors be advertised as
> frequently as practical as the consequence of not doing so is to
> impact convergence. I think the text about requiring an empty
> neighbor TLV to be sent when you have no neighbors should be removed
> for the sake of clarity.

I admit that it is a bit odd making the inclusion of a TRILL Neighbor
TLV mandatory if their are no neighbors. Perhaps the existing sentence

   "If there are no adjacencies with a non-zero Designated VLAN Hello
   Holding timer, an empty TRILL Neighbor TLV MUST be included in each
   Hello sent on the designated VLAN."

could be combined with the new sentence

   "If there are such adjacencies, it is RECOMMENDED that a TRILL
   Neighbor TLV or TLVs, as described in Section 4.4.2.1 of
   [RFCtrill], covering the entire range of MAC addresses, be in TRILL
   Hellos sent on the Designated VLAN, if there is sufficient room."

to produce a newer sentence

   "It is RECOMMENDED that, if there is sufficient room, a TRILL
   Neighbor TLV or TLVs, as described in Section 4.4.2.1 of
   [RFCtrill], covering the entire range of MAC addresses and listing
   all adjacencies with a non-zero Designated VLAN Hello Holding time,
   or an empty list of neighbors if there are no such adjacencies, be
   in TRILL Hellos sent on the Designated VLAN."

To be clear and to maintain the thrust of the output from the plug
fest, I think it is important to mention that, even if not necessarily
in every Hello, it is required to send a TRILL Neighbor TLV with an
empty neighbor list if you are not seeing any neighbors on the
Designated VLAN.

> The convergence issue is one which concerns me as in the presence of
> a large # of neighbors and/or a large number of supported VLANs
> hellos either have to be sent with higher frequency (=> poorer
> scalability) or a longer convergence time has to be accepted. But
> that is a larger issue which I hope we can discuss when you respond
> to my comments on "Reliable Circuit Scoped Flooding".

TRILL has chosen the longer convergence time alternative.

Thanks,
Donald

>   Les
>
>
>> It would be possible to add some general exhortation to implementers
>> not to dilly-dally around too much in sending TRILL Neighbor TLVs. It
>> seems like an issue in implementation quality that I can't believe
>> would be a problem in the real world. There are lots of ways people
>> can do an implementation with bad performance. For example, you could
>> implement or schedule the updating of topology and calculation of
>> shortest paths so that it took, say, an hour to process LSPs that
>> updated reachability. I believe such an implementation would be
>> conformant to the existing IS-IS specification but, somehow, I just
>> don't see people using it (or buying it if it were a product). Just
>> so, an implementation that, when the neighbor list was non-empty, only
>> sent a TRILL neighbor TLV once an hour wouldn't get used (or purchased
>> if it was a product), at least not for any environment that seems
>> plausible to me.
>>
>> In any case, "If there are such adjacencies, then the Hello MAY
>> contain a TRILL Neighbor TLV as described in Section 4.4.2.1 of
>> [RFCtrill]."  could be replaced with something like the following:
>>
>> "If there are such adjacencies, it is RECOMMENDED that a TRILL
>> Neighbor TLV or TLVs, as described in Section 4.4.2.1 of [RFCtrill],
>> covering the entire range of MAC addresses, be in TRILL Hellos sent on
>> the Designated VLAN, if there is sufficient room. If this is not
>> possible, then TRILL Neighbor TLV's covering sub-ranges of MAC
>> addresses should be sent so that the entire range is covered
>> reasonably promptly.  Delays in sending TRILL Neighbor TLVs will delay
>> the advancement of adjacencies to the Report state and the discovery
>> of some link failures. Rapid, for example sub-second, detection of
>> link or node failures is best addressed with a protocol designed for
>> that purpose, such as BFD [RFC5880], use of which with TRILL will be
>> specified in a separate document."

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [e-mail]