Hi Meral,
On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
<[email protected]> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
>
> Document: draft-ietf-trill-rfc7180bis-06
> Reviewer: Meral Shirazipour (was originally assigned to another gen-art)
> Review Date: 2015-10-19
> IETF LC End Date: 2015-10-19
> IESG Telechat date: 2015-10-22
>
>
>
> Summary:
>
> This draft is ready to be published as Standards Track RFC but I have some
> comments .
Thanks. See below.
> Major issues:
>
>
> Minor issues:
>
> -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325. The
> update is about conflict resolution between sections of the RFC.
>
> Shouldn't this bis highlight those conflicts if any?
I do not believe there are any real conflicts. RFC 6325 has some
general/introductory sections and some detailed technical sections.
The general sections, particularly Section 2, are written with a
pedagogical goal of giving the reader the best general understanding
and such general sections are not necessarily precise and do not, in
general, include every corner case. During the development of RFC
6325, some reader focused on such general descriptions and claimed
that the "conflicted" with the precise, detailed technical sections.
Thus Section 1.2 was added to RFC6325 to resolve this and make it
clear that the later detailed sections should be followed in case of
any such apparent "conflict".
I don't really remember exactly what motivated making the material
about precedence of sections in RFC 6325 more complete in RFC 7180 but
it was probably based on some comment.
The only change from Section 1.1 of RFC 7180 to this Section 1.1
draft-ietf-trill-rfc7180bis is updating of some other RFC numbers in
this section.
> -[Page 14], Section 3.4. Should this section have a MUST sentence just
> before the last sentence?
>
> "All RBridges in a campus MUST determine distribution trees in the same way
> "
I don't think so. The mandatory implementation of the distribution
tree computation provisions is elsewhere. The sentence you refer to is
just discussion of the consequences of failure to follow that.
> -[Page 10], Section 2.4.2.1 , gives an example, then the first bullet after
> the figure explains the problem with that scenario and says "MUST NOT be
> locally distributed in native form ".
>
> Is it possible to clarify what should be done instead?
This section is about tunneling the frame to a neighbor that is
offering the OOMF service. It could be re-worded a little to use
"instead" rather than "before". The change would be
OLD
The multi-destination frame MUST NOT be locally distributed in
native form at RB2 before tunneling to a neighbor because this
would cause the frame to be delivered twice.
NEW
The multi-destination frame MUST NOT be locally distributed in
native form at RB2 because this
would cause the frame to be delivered twice. Instead it is
tunneling to a neighbor as provided in this section.
> -[Page 11], last line, "forwards the packet on that tree."
>
> Just checking if that is supposed to say "packet" or if it should say
> "frame" or "TRILL Data packet"?
It would be more consistent to say TRILL Data packet.
> Naming ("frame" or "TRILL Data packet") are used throughout, but it would
> help to mention the convention at the beginning of the draft.
I believe the intent to is use "frame" for native frames to/from end
stations and "TRILL Data packet" or "packet" for TRILL encapsulated
packets between TRILL switches. This convention could be mentioned in
Section 1.3.
> Nits/editorial comments:
>
> -[Page 6], Section 1.3, "RBridge - An alternative name for a TRILL Switch."
>
> To remain true to RFC7325, better to add Routing Bridge: "RBridge - Routing
> Bridge, an alternative name for a TRILL Switch."
OK.
> -[Page 15], Section 3.6 , "can implemented"--typo-->"can implement"
OK.
> -[Page 16], Section 3.6.1 , "program their hardware tables",
>
> is it assumed that TRILL fast path will only/always be HW based?
There are software implementations of TRILL. Probably better to say
"program their forwarding tables."
> -[Page 17], "RB1 is show with three ports"--typo-->"RB1 is shown with three
> ports"
OK.
> -[Page 34], "then behavior is as specified"---> "the behavior" or "then the
> behavior"
OK.
> -[Page 35], Section 10.2.2, "those capabilites"--typo-->"those capabilities"
OK.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
[email protected]
> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson
>
> Research
>
> www.ericsson.com
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
