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

[Donald Eastlake <[e-mail]>]

Hi Joel,

A -02 version has been posted intended to resolve your comments.

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


On Sun, Jul 3, 2016 at 3:30 PM, Joel M. Halpern <[e-mail]> wrote:
> Thanks Donald.  Looks good to me.
> Yours,
> Joel
>
>
> On 7/3/16 1:53 PM, Donald Eastlake wrote:
>>
>> 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