Re: [trill] Routing directorate QA review of draft-ietf-trill-rfc6439bis

[Donald Eastlake <[e-mail]>]

Hi Joel,

Thanks for your comments.

Because this draft happens to be close to expiring and we are coming
up on the refractory period before the Berlin meeting, I'm going to do
my best at editing it based on your comments and upload a revision.
But if that does not resolve your comments, further changes can be
made.

See below.

On Sun, Jun 26, 2016 at 8:58 PM, Joel M. Halpern <[e-mail]> wrote:
> This is a QA review, intended to provide an additional perspective,
> requested by the TRILL chairs and Routing ADs.
> The reviewer understands that the WG last call has completed, and hopes that
> this review will prove helpful to the working group.
> [For clarity, the above is written before performing the review.]
>
> This document is ready for publication as a Proposed Standard RFC.
>
> Major: N/A
>
> Minor: N/A
>
> Nits:
>     Section 2.2 base has two bullet items.  the first appears to be a subset
> of the second.  Is this deliberate?

You are correct. I guess as an author I thought of the second point as
being more restricted than the words actually are. I was thinking it
actually said something like "When it observes a change in DRB on the
link from one RBridge other than itself to another RBridge other than
itself." However, it seems like it would be clearer to re-write that
small section of text.

>     The counter-example at the end of the second paragraph of section 2.4
> seems to be missing some limitation that would explain it.  (It is possible
> this is more obvious to a reader who is more conversant with TRILL, but
> there does seem to be something missing.)

Maybe the wording isn't very clear. Let me describe the counter
example somewhat more verbosely in different words.
     Say that all the end stations in a TRILL campus that are in
VLAN-x are attached to RBridge-1.  That means that they are on links
that is attached to RBridge-1 and there might be one or more other
RBridges attached to those links. (Note that in TRILL, a link can be a
bridged LAN.) On each such link, there will be a Designated RBridge
election to chose the RBridge that is in charge of end station traffic
on that link, either ingressing/egress such traffic itself or
assigning it to one or more other RBridges on that link by VLAN.
     Assume that RBridge-1 is overloaded. Thus RBridge-1 will
typically do a poor job of forwarding traffic, because it cannot hold
the complete topology. Normally, you would not want RBridge-1 handling
end station traffic. If RBridge-1 wins the DRB election on a link, it
should assign the handling that traffic to other non-overloaded
RBridges on its links, if such RBridges are available, and if some
other RBridge on a link wins the DRB election, it should not assign
the handling of such traffic to RBridge-1.
     However, in the case of VLAN-x traffic, all the end stations in
VLAN-x have local connectivity to RBridge-1. The inability of
RBridge-1 to do a good job forwarding traffic is immaterial to traffic
in VLAN-x because it will never have to forward it because all end
stations in VLAN-x are local. Thus, even through RBridge-1 is in
overload, it SHOULD be assigned the handling of end station traffic
for VLAN-x.

I'll try to clarify the wording in the draft.

> Editorial:
>     In section 10.4 defining the FGL-VLAN Mapping Bitmap APPsub-TLV, the
> diagram calls the fifth field "Starting FGL".  The text below that refers to
> it the field simply as "FGL".  I believe the text should also name it
> "Starting FGL".

OK.

> Side note: I really appreciate the thorough additional explanations as to
> the reasons various actions are safe or unsafe.  Thank you.

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

> Yours,
> Joel M. Halpern