Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation
RFC 8249

[ I have removed my DISCUSS after discussing this with Alia. She has reassured me that there has been sufficient discussion on the topic, so I'm a happy camper now... ]

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



-- Original discuss for posterity --
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

Are there implementations of this optimization?  Have they shown the expected improvements?  The mechanism seems ok, but the introductory text made we wonder, specially the part about "*potentially* improving the efficiency of link utilization and speeding link state convergence."  IOW, if the advantages are not really know, then maybe a Standards Track document is premature.  I really don't have a strong opinion, so I'm just wondering at this point.


Some nits:

1. There are some places where rfc2119 language is used that I think is out of place because it is really just stating a fact or quoting what different documents say (without actually using quotations); IOW, these are really not normative statements defined in this document:

- "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU...all RBridges MUST format their LSPs..."

- "As specified in [RFC8139], RBridges MUST support..."

- "as required by [RFC7780], all RBridges MUST..."


2. From 2.1, these 2 sentences are redundant: "An originatingSNPBufferSize APPsub-TLV occurring in any other fragment MUST be ignored. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored. "

Thanks for resolving my comment on version 06.

Thanks for adressing the tsv-art comments (and thanks to Magnus for the tsv-artt review)!

It might still be valuable to note that RTT estimation is out-of scope for this document and if the RTT can not estimed acoordingly an conservative upper bound estimation should be assumed.

I echo Mirja's thanks for your work addressing Magnus's TSV-ART review.