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

[Jari Arkko <[e-mail]>]

Meral, many thanks for the review. Donald, many thanks for the changes.

I have balloted no-obj.

On re: conflicts, I understood the sentence as a usual if-all-else-fails clause of specifying which document has precedence in case some conflicts are discovered later. I think that’s fine. Is this your understanding too, Donald?

Jari

On 21 Oct 2015, at 17:20, Meral Shirazipour <[e-mail]> wrote:

> 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
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art