A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem
RFC 7588
Yes
(Alia Atlas)
(Brian Haberman)
No Objection
Alvaro Retana
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Terry Manderson)
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana
No Objection
Alia Atlas Former IESG member
Yes
Yes
(for -04)
Brian Haberman Former IESG member
Yes
Yes
(for -03)
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Ben Campbell Former IESG member
No Objection
No Objection
(for -04)
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Jari Arkko Former IESG member
No Objection
No Objection
(for -04)
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-05-09 for -04)
from Tom Taylor's opsdir review (looks like it's being addressed already)
My apologies -- I let this slip way past due date. This is a review of operational aspects of this document, primarily for use by the OPS area ADs in their evaluation of the document.
Summary: this document describes a commonly encountered set of implemented procedures for handling fragmentation of GRE packets. The described procedures include configuration options. The document is well-written and ready to go subject to the following observations, all of which are trivial except for the second minor issue noted below.
Tom Taylor
1) Very minor issue: there is no advice to the operator on coordinating the configuration of the ingress and egress nodes. Section 3.3.2 assumes that configuration is coordinated (i.e., fragmented GRE delivery packets are reassembled at egress). Section 3.4 simply presents the option. This could be fixed by changing the relevant sentence of 3.3.2.1 and 3.3.2.2 as follows:
OLD
If the delivery packet is fragmented, it is reassembled by the GRE
egress.
NEW
If the delivery packet is fragmented, it is reassembled by the GRE
egress if the latter is configured to do so.
2) Minor issue: 3.3.1.1, 3.3.1.2, 3.3.1.3 final paragraph:
s/delivery header/delivery packet/
Typos:
Last paragraph before Sec. 3, second line: s/lager/larger/
3.3.1.1 second paragraph, last line on page 5:
s/an Next-hop MTU/a Next-Hop MTU value/
3.3.1.2 first line: s/send/sends/
Sec. 5 last paragraph, fourth last line: s/includes/include/
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2015-05-14)
Thank you for adding text on fragmentation attacks.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-05-14 for -04)
I agree that adding a para in response to Kathleen's discuss is a good plan.
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)