Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-clear-correct-04.txt

From: Donald Eastlake <[email-masked]>
Date: Sun, 1 Jul 2012 13:05:23 -0400

Hi Mike,

Thanks for your review and comments, see below:

On Wed, Jun 27, 2012 at 11:50 AM, Mike Shand <[email-masked]>
wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review
> is to provide assistance to the Routing ADs. For more information
> about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any
> other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
> Document: draft-ietf-trill-clear-correct-04.txt
> Reviewer: Mike Shand
> Review Date: 27 June 2012
> IETF LC End Date: ???
> Intended Status: Proposed Standard
>
> Summary:
>
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
> Comments:
>
> Given that this is essentially a set of corrections to earlier RFCs,
> this draft is well structured and the changes, and reasons for them,
> are clearly described.

Thanks.

> I have listed below as Major, my concerns about the description of
> forwarding while in overload state. However, these concerns are most
> likely the result of me misunderstanding the description, in which
> case, some simple clarification is all that is required to resolve
> them.
>
> Major Issues:
>
> Section 2.1 states "Frames are not least cost routed through an
> overloaded TRILL Switch if any other path is available..."
>
> However, ISO/IEC precludes the routing of frames through an
> overloaded router, even when no other path is available.
> (see clause 7.2.8.1) [ note all references to ISO/IEC 10589 are to
> the second edition ]
>
> Is the intention to change this behaviour for TRILL?

No. The general statement you quote from 2.1 of the draft above is
incorrect but the specific provisions later in the draft, I believe,
correspond to RBridges not forwarding unicast to overloaded RBridges
unless they are the egress.

> Section 2.3.1 seems relevant here, but I don't understand the
> description. I must be missing something, since it would appear that
> a data frame forwarded to RB2 MUST attempt to forward the frame to
> ANY non-overloaded neighbor (other than the one it was received
> from). However, surely that non overloaded neighbor might then have
> RB2 as its next hop, and forward the frame back to RB2, which would
> then be required to forward the frame possibly back to the original
> RBridge from which it was received. Clearly this is not the desired
> operation, so the text needs clarifying to make it clear what is
> really supposed to happen.

However, if the non-overloaded neighbor will not forward to an
overloaded RBridge, so it will not forward back to RB2, there should
be no problem. We'll try to clarlify the wording in Section 2 on these
points.

> Minor Issues:
>
> Section 4 bullet 4
>
> I THINK this is saying that the check must be made on any "new" LSP
> even if the RBridge is in overload state, and cannot store the
> received "new" LSP.  It may be clearer to explicitly say it must do
> this even when overloaded.  The existing parenthetical remark
> doesn't seem adequate.

OK, although I'm a little unsure about "new", perhaps for the reason
you put it in quotes. It might be the receipt of an LSP that was
previously received but not remembered due to overload. Making it
explicit that it must do this even when overloaded is reasonable.

> Section 5 2nd para
>
> I don't understand the term "refragment LSPs".
>
> Is this saying that an RBridge may start with some value of
> originatingL1LSPBufferSize, and then be required to change to a
> lower value, thus necessitating that it re-generates all its LSPs
> which were previously larger than this new value?

Well, the originatingLSPL1BufferSize for an RBridge doesn't change
but, as specified in RFC 6325, the size LSP that can be sent is the
minimum of the originatingLSPL1BufferSizes it sees for the RBridges in
the campus but not less than 1470. It's always safe for an RBridge to
use 1470 and, as stated in this draft, in a well configured campus all
the RBridges will be configured with the same
originatingLSPL1BufferSize so no re-sizing would occur. But, if you
have a campus capable of and configured to use jumbo LSPs, should an
RBridge or RBridges with a smaller originatingLSPL1BufferSize join the
campus, it would not be capable of handling those LSPs so link state
flooding wouldn't work. (You mght be trying to merge two campuses or
something.) The choice is to isolate the new RBridge(s) or to have the
rest conform to the new lower minimum originatingLSPL1BufferSize.
TRILL chose the second.

> Nits:
>
> Section 2.
> There are two instances of "pseudo node". The ISO/IEC 10589 term is
> pseudonode.
> (note this is correctly used in section 4)

OK.

> Section 2.2 first line
> s/A RBridge/An RBridge/

Thanks.

> Section 2.2 second para
> "...and Bridge RB1 can similarly...."
>
> Can is ambiguous. Is that MAY or MUST?

It's a MAY. "... RB1 MAY similarly ignore ..."  If RB1 does not
ignore, it just means that it creates extra RPF check state that isn't
needed. Probably this should be made clearer. How about "When
calculating RPF checks for multi-destination frames, an RBridge RB1 MAY, to
avoid calculating unnecessary RPF check state, ignore any trees that
cannot ..."

> Section 10.1 para below bullet 2.
>
> s/Two different encoding are providing above/Two different encodings are
> provided above/  (I assume)

OK.

> and in the second sentence
>
> s/These encoding may/ The encodings may/
>
> or should the instances of "encoding" be "encoding mechanisms" ?

I think encodings should be OK.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]