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

Received changes through RFC Editor sync (created alias RFC 8249, changed abstract to 'The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets.  This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU.  In addition, it specifies an efficient algorithm for local MTU testing.  This document updates RFCs 6325, 7177, and 7780.', changed pages to 15, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-09-30, changed IESG state to RFC Published, created updates relation between draft-ietf-trill-mtu-negotiation and RFC 6325, created updates relation between draft-ietf-trill-mtu-negotiation and RFC 7177, created updates relation between draft-ietf-trill-mtu-negotiation and RFC 7780)

[Ballot comment]
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.

[Ballot discuss]
The tsv-art review has raised a number of substantial issues that need to be addressed before publication (big thanks to Magnus Westerlund!). As far as I can see solution to address these issues have been discussed by email but are not reflected in an updated draft yet. I'm holding this discuss till an update occurs. In other words, please update the draft!

[Ballot comment]
[ 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

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

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

[Ballot comment]
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. "

[Ballot comment]
- 2, first paragraph: "This document specifies a new value "Lz" for the acceptable inter-
  RBridge link MTU size on a local link."

Should "acceptable" be "minimum acceptable"?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-trill-mtu-negotiation-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

First, in the TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1 registry on the Transparent Interconnection of Lots of Links (TRILL) Parameters registry page located at:

https://www.iana.org/assignments/trill-parameters/

a new APPsub-TLV Type will be registered as follows:

Type: [ TBD-at-registration ]
Name: originatingSNPBufferSize
Reference: [ RFC-to-be ]

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: shares@ndzh.com., draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, trill@ietf.org, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'Transparent
Interconnection of Lots of Links (TRILL): MTU Negotiation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-06-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The base IETF TRILL protocol has a TRILL campus-wide MTU feature,
  specified in RFC 6325 and RFC 7177, that assures that link state
  changes can be successfully flooded throughout the campus while being
  able to take advantage of a campus-wide capability to support jumbo
  packets. This document specifies recommended updates to that MTU
  feature to take advantage, for appropriate link-local packets, of
  link-local MTUs that exceed the TRILL campus MTU. In addition, it
  specifies an efficient algorithm for local MTU testing. This document
  updates RFC 6325, updates RFC 7177, and updates RFC 7780.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1799/

Form: As required by RFC 4858, this is the current template for the Document Shepherd Write-Up (2/24/2012)


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

type: Proposed standard
Why: Specifies update to the campus-wide MTU feature specified in RFC6325 and RFC7177.
Title page: Indicates this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  The base IETF TRILL protocol has a TRILL campus-wide MTU feature,
  specified in RFC 6325 and RFC 7177, that assures that link state
  changes can be successfully flooded throughout the campus while being
  able to take advantage of a campus-wide capability to support jumbo
  packets. This document specifies recommended updates to that MTU
  feature to take advantage, for appropriate link-local packets, of
  link-local MTUs that exceed the TRILL campus MTU. In addition, it
  specifies an efficient algorithm for local MTU testing. This document
  updates RFC 6325, updates RFC 7177, and updates RFC 7780.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

    WG consensus was reasonable.

Document Quality

Reviews:
Shepherd's review
https://www.ietf.org/mail-archive/web/trill/current/msg07500.html
Shepherd review of draft-ietf-trill-mtu-negotiations-05.txt
https://www.ietf.org/mail-archive/web/trill/current/msg07643.html

RTG-DIR review: Julien Meuric
https://www.ietf.org/mail-archive/web/trill/current/msg07264.html

No yang, XML, MIB, or security needed as expansion of existing function.


Personnel

RTG-DIR review: Julien Meuric
Shepherd: Susan Hares
WG chairs: Susan Hares and Jon Hudson
AD: Alia Atlas
 
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Shepherd review:
1) review of document - considering the RFC6325 and RFC7177 features,
https://www.ietf.org/mail-archive/web/trill/current/msg07500.html

2) nits,
3) RTG-DIR review requested.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. The only improvement can be an implementation of this feature.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.  Even the need for a security review is low since the MTU only
provides an optimization of existing functionality to guess the
right MTU.  If the MTU is too large, the packet will just get tossed
by the normal processing.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.  Actually, this is a rather clever optimization.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Minqui Zhang
https://www.ietf.org/mail-archive/web/trill/current/msg07531.html

Xudong Zhang:
https://www.ietf.org/mail-archive/web/trill/current/msg07532.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07526.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07574.html

Somnath chatterjee
https://www.ietf.org/mail-archive/web/trill/current/msg07527.html

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There is a Ericsson IPR filed that was posted on 6/14/2012
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-trill-mtu-negotiation

it was queried for on 8/26/2016:
https://www.ietf.org/mail-archive/web/trill/current/msg07522.html

And no additional IPR was found.

(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


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No. 

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No MIB, media type, URI. 
Only note from shepherd's comment is for WG to recall to
add these features to the yang draft (pre-WG LC due to LIME).

(13) Have all references within this document been identified as
either normative or informative?
yes. 

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All references are RFC or drafts being advanced (past WG LC).
The drafts past WG LC and not at RFC are:

draft-ietf-trill-rfc6439bis (in IETF LC)


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.  Just an addition.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

One parameter is requested to have assignment. 
This parameter is listed as TBD in the document - so there is no conflict.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks required.