Re: [trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT)

["Susan Hares" <[e-mail]>]

Warren:

As the shepherd, thank you for your comments and DISCUSS.  Part of this
discuss appears to be a process discuss on: 
1) What you want to see in the shepherd's report
2) How you want to see discussions represented on the mail list. 

It is always a pleasure to readjust shepherd's reports to answer the current
IESG questions as opposed to the previous year's IESG questions.   Shepherd
and WG chairs serve to enlighten IESG, and I am glad to provide any details
I can for you. 

 Let me provide you the background: 

1) 2015 IESG member - So, previous IESG members like to see the mail list
comments without any editorializing.   Hence, this format 

2) Relevant vibrant discussion occurred in face-to-face meetings at IETF
meetings.  

The TRILL WG transition between the INT and RTG WG area and we have been
pushing documents through at best possible speed.  You will note a steady
progression of drafts in the history.   Why so lengthy a time?   First, the
transition of the area required that the RTG-DIR reviews occurred.  Until
our current Routing ADs revised the RTG-DIR QA review process to be like the
OPS-DIR review process, TRILL reviews were simply not being processed.
Second, we were getting feedback slowly from other groups. 

I see interesting feedback from Transport based on the new Transport review
system that we may take back to the WG.  I am not quite clear on all of
Magnus' points - but at least it is substantive reviews.   Our previous "no
comment" state plus the stall in the review process for 1 year - has a
tendency to make WGs stall.   As Alia may have mentioned, we are trying to
complete all of these drafts and publish these drafts.   

3) Finally, we started with 3 companies:  Huawei, cisco, and brocade - with
pre-standards or standards.   Due to business environments, the three
companies are now: Huawei, IP-Infusion, and the legacy work in brocade and
cisco. 

So, please let me know what you want in the shepherd's report.  If this type
of history is useful, I am happy to provide this level of discussion in the
shepherd's reports.  Or more details on the specific pros/cons of the
discussion. 

3) updates/news - Again,  previous reviews had said this was not useful
information.   Such statements, is "why include this information?"  Tends to
make people less interested in including this in the future.   Donald
Eastlake and other authors who used to include this - stopped putting it in.
If you would like the update information as an appendix, we can add it.  

Thank you for your excellent process questions. 

Sue Hares 


-----Original Message-----
From: trill [mailto:[e-mail]] On Behalf Of Warren Kumari
Sent: Wednesday, July 5, 2017 3:16 PM
To: The IESG
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: [trill] Warren Kumari's Discuss on
draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-trill-mtu-negotiation-06: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1: Instead of answering the questions, the Shepherd Writeup just has links
to things - for example:

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

WG LC:
Passed:
https://www.ietf.org/mail-archive/web/trill/current/msg07304.html
Discussion:
https://www.ietf.org/mail-archive/web/trill/current/msg07210.html

This caused me to go investigate further - it seems that there were only 4
comments received during WGLC (excluding the RtgDir review, a short exchange
with Julien Meuric). The comments which *were* received largely just fell
into the "Support" (with no real discussion) category.

The document was adopted 06 March 2015, and then there were a few automated
mentions of it (e.g [0], [1]), but I see no real discussion of the draft *in
the WG*.

It is entirely possible that my search fu is weak today, and that there has
been sufficient discussion and review of the draft (or that none was needed
because it is so obviously right and pure, but I'd like some reassurance of
that), especially because a quick review found multiple readability issues /
nits.

Note: I'm not holding the discuss on the readability / nits, rather on has
the process been followed / is there consensus grounds

2: The document also says that it Updates: 6325, 7177, 7780 - but I don't
see clear discussion of the Updates (OLD / NEW).

[0]:
https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd_X4
[1]:
https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX_
b4


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Major:
I found much of the document really hard to read - I approve of the concept
/ see the need for this, but reading the document itself is not well
written.

Nits:

General
RFC 6325 says:
"4.3.1.  Determining Campus-Wide TRILL IS-IS MTU Size

   In a stable campus, there must ultimately be agreement among all
   RBridges on the value of "Sz", the minimum acceptable inter-RBridge
   link size for the campus, for the proper operation of TRILL IS-IS."
and this document says:
"[RFC6325] describes the way RBridges agree on the campus-wide minimum
   acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the
   campus-wide "Sz" "
Ok, so Sz is campus-wide -- but, for some reason this document has ~35
instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is
there any time the Sz would not be campus-wide?

Section 1.
"[RFC6325] describes the way RBridges agree on the campus-wide minimum
   acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the
   campus-wide "Sz" to ensure that link state flooding operates properly
   and all RBridges converge to the same link state."
This is really hard to parse - the bit before the hyphen is fine, but then
it gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the
campus-wide minimum
   acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called
"Sz")
   to ensure that link state flooding operates properly and all RBridges
   converge to the same link state."

"By calculating and using Lz
   as specified herein, link-scoped PDUs can be formatted greater than
   the campus-wide Sz up to the link-wide minimum acceptable inter-
   RBridge MTU size potentially improving the efficiency of link
   utilization and speeding link state convergence."
"formatted" seems clumsy - perhaps just drop it? Or reorder to be
"link-scoped PDUs larger than Sz, up to ...  can be used"?

O: "The new MTU size testing method specified in this document is backward
compatible to the old one." P: "The new MTU size testing method specified in
this document is backward compatible with the old one." C: Grammar

O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridges
on a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed
amongst all RBridges on a specific link." C: Between only if two.

Section 2. Link-Wide TRILL MTU Size
O: "These PDUs are exchanged just on the local link."
P: "These PDUs are exchanged only on the local link."

O: "They use that flooding to exchange their maximally supportable value of
"Lz"." P: "They use that flooding to exchange their maximum supported value
of "Lz"." C: Maximally would be an adverb, describing the process of
maximizing the flooding (or something).

Section 2.1:
O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs"
P:  "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs"
C: I think.

O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded
by B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be
discarded by B1." C: chunks is plural.

Section 6:
"The CSNPs and PSNPs MUST be formatted in chunks of size at most the
   link-wide Lz but are processed normally if received larger than that
   size." -- why the MUST? Is this supposed to be an instance of the sender
   being conservative and the receiver liberal? It so, I think it would be
   better to be much clearer.

Section 7:
O: "Unlike RBridges, end stations do not participate in the exchange of
   TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU
   size from a TRILL campus automatically. "
C: should be a semicolon and not a comma before therefore, and a comma after
therefore.

Section 8. Backwards Compatibility
O: "This will act properly although it may not be as efficient as  it would
be if all RBridges on the link are Lz-aware." P: "This will act properly
although, it may not be as efficient as  it would be if all RBridges on the
link are Lz-aware." C: Missing comma.

"Then the path MTU can be set as the smallest tested link MTU on this path
and end stations should not generate frames that, when encapsulated as TRILL
Data packets, exceed this path MTU."
-- instead:
"Then, the path MTU can be set as the smallest tested link MTU on this path;
and end stations should not generate frames that, when encapsulated as TRILL
Data packets, exceed this path MTU."


_______________________________________________
trill mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trill