Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06

[Meral Shirazipour <[e-mail]>]

Hi Donald,
  Thank you for considering the changes. Please see in-line for a few more comments.

Best,
Meral

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Wednesday, October 21, 2015 7:54 AM
> To: Meral Shirazipour
> Cc: [e-mail]; [e-mail]
> Subject: Re: Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06
> 
> Hi Meral,
> 
> On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
> <[e-mail]> 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.
> 

[MSh] Would it be possible to add a few sentences to clarify that? or maybe remove the word "conflict" ?


> > -[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.
> 

[MSh] NEW looks good to me. Thanks.

> > -[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.
> 

[MSh] Thanks agree.

> > 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."
> 

[MSh] Thanks.

> > -[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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA  [e-mail]
> 
> > Best Regards,
> >
> > Meral
> >
> > ---
> >
> > Meral Shirazipour
> >
> > Ericsson
> >
> > Research
> >
> > www.ericsson.com