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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Sunday, February 20, 2011 9:06 AM
> To: Les Ginsberg (ginsberg); [e-mail]
> Cc: isis mailing list
> Subject: Re: [Isis-wg] Fwd: trill-adj Section 7.2 comments
> 
> 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."

OK

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

OK

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


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

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