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

From: Meral Shirazipour <[email-masked]>
Date: Tue, 20 Oct 2015 00:02:30 +0000

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 .

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?

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

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

-[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"?

Naming ("frame" or "TRILL Data packet") are used throughout,  but it would help to mention the convention at the beginning of the draft.

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

-[Page 15], Section 3.6 , "can implemented"--typo-->"can implement"

-[Page 16], Section 3.6.1 , "program their hardware tables",
is it assumed that TRILL fast path will only/always be HW based?

-[Page 17], "RB1 is show with three ports"--typo-->"RB1 is shown with three ports"

-[Page 34], "then behavior is as specified"---> "the behavior" or "then the behavior"

-[Page 35], Section 10.2.2, "those capabilites"--typo-->"those capabilities"

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 21 Oct 2015 10:54:30 -0400

Hi Meral,

On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
<[email-masked]> 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.
>
>

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

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.

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

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.

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

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

> 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

OK.

> -[Page 34], "then behavior is as specified"---> "the behavior" or "then the

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-masked]

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 21 Oct 2015 16:20:23 +0000

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:[email-masked]]
> Sent: Wednesday, October 21, 2015 7:54 AM
> To: Meral Shirazipour
> Cc: [email-masked]; [email-masked]
> Subject: Re: Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06
> 
> Hi Meral,
> 
> > 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:
> >
> > -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325.
> > The update is about conflict resolution between sections of the RFC.
> >
> 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" ?

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

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

> > To remain true to RFC7325, better to add Routing Bridge: "RBridge -
> > Routing Bridge, an alternative name for a TRILL Switch."
> 
> OK.
> 

[MSh] Thanks.

>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]
> 
> > Best Regards,
> >
> > Meral
> >
> > ---
> >
> > Meral Shirazipour
> >
> > Ericsson
> >
> > Research
> >
> > www.ericsson.com

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2015 13:51:00 +0100

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 <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 22 Oct 2015 11:14:43 -0400

Hi Jari,

> 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…

Yes, I would say that sentence is really just a back-stop as you describe.

Thanks,
Donald