Hi Joel, A -02 version has been posted intended to resolve your comments.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Sun, Jul 3, 2016 at 3:30 PM, Joel M. Halpern <[email protected]> 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 <[email protected]> >> 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 +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> [email protected] >> >>> Yours, >>> Joel M. Halpern _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
