Subject: [rbridge] trill-adj Section 7.2 comments

From: Donald Eastlake <[email-masked]>
Date: Sat, 12 Feb 2011 20:49:27 -0500

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."

> 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.

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   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 14 Feb 2011 22:20:31 -0800

Hi Donald.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Donald Eastlake
> Sent: Saturday, February 12, 2011 5:50 PM
> To: isis mailing list
> Subject: [Isis-wg] Fwd: trill-adj Section 7.2 comments
> 
> Sorry, forgot to cc the isis WG
> ---------- Forwarded message ----------
> From: Donald Eastlake <[email-masked]>
> Date: Sat, Feb 12, 2011 at 8:49 PM
> Subject: trill-adj Section 7.2 comments
> To: "Les Ginsberg (ginsberg)" <[email-masked]>, [email-masked]
> 
> 

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?

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."

> 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.

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".

   Les

> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 20 Feb 2011 09:05:53 -0800

Hi Les,

> Hi Donald.
...

> 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."

> "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?

> 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

Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 22 Feb 2011 17:46:09 -0800

Donald -

> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Sunday, February 20, 2011 9:06 AM
> To: Les Ginsberg (ginsberg); [email-masked]
> Cc: isis mailing list
> Subject: Re: [Isis-wg] Fwd: trill-adj Section 7.2 comments
> 
> Hi Les,
> 

OK

> general principal of IS-IS anyway?

OK

>    in TRILL Hellos sent on the Designated VLAN."

OK. This clarifies that the motivation for sending TRILL Neighbor TLV is
the same in the no neighbor case as in the case where there are
neighbors.

   Les

> >> Neighbor TLV or TLVs, as described in Section 4.4.2.1 of
[RFCtrill],