Subject: [Int-area] Ben Campbell's No Objection on draft-ietf-intarea-gre-ipv6-11: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 05 Aug 2015 11:49:40 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-intarea-gre-ipv6-11: No Objection

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-intarea-gre-ipv6/

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

I have a few minor comments:

-- 3.2, 2nd paragraph:

As worded, I expected to find defined procedures (or a citation to such)
to accomplish the verification. I see from the following paragraph that
this is not the case. I think the following change would be more clear:

OLD
   Before activating a GRE tunnel and periodically thereafter, the GRE
   ingress node MUST execute procedures that verify the tunnel’s ability
   to carry a 1280-byte IPv6 payload packet from ingress to egress,
   without fragmenting the payload.
NEW
   Before activating a GRE tunnel and periodically thereafter, the GRE
   ingress node MUST verify the tunnel’s ability
   to carry a 1280-byte IPv6 payload packet from ingress to egress,
   without fragmenting the payload.
END

-- 3.2, last paragraph:
Do all such existing implementations have the ability to be configured to
fragment and reassemble payload packets? That is, is there a class of
existing implementation that can no longer be considered compliant?

-- 3.3, last sentence:
Is there a reciprocal requirement for the egress to reassemble the
fragmented delivery header?

-- 4.2, 2nd to last paragraph:
This seems like a very subjective MUST NOT. Please consider stating this
without 2119 keywords.

-- 8.1, first reference:
That’s probably not appropriate as a normative reference. Neither the URL
or the content can be assumed to be stable. Would it make sense to
reference RFC 7042 instead?

** Nits **

--1, first sentence:
s/Generic Routing Encapsulation/The Generic Routing Encapsulation/

-- 3
s/carry IPv6 payload/carry an IPv6 payload/     ; (or /carry IPv6
payloads/)

-- 3.1
It would be helpful to mention that this is the IPv6 ether type.

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 6 Aug 2015 21:28:19 +0000

Hi Ben,

Thanks for the thoughtful review. Responses are inline.......

                                                                       Ron

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, August 05, 2015 2:50 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; draft-ietf-intarea-gre-
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's No Objection on draft-ietf-intarea-gre-ipv6-11: (with
> COMMENT)
> 
> 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.)
> 
> 
> As worded, I expected to find defined procedures (or a citation to such) to
> accomplish the verification. I see from the following paragraph that this is not
> the case. I think the following change would be more clear:
> 
> OLD
[RPB] 

Agree. I have imported your text verbatim and will post a new version in the next few hours.

> fragment and reassemble payload packets? That is, is there a class of existing
> implementation that can no longer be considered compliant?
> 
[RPB] 

In the last paragraph, we are talking about fragmentation of the delivery packet, not the payload packet.

All GRE/IPv6 implementations that I am aware of can fragment the delivery packet. However, this isn't a strict requirement of the current draft and it is rarely deployed. 

Most networks maintain a minimum MTU of 1500. In those networks MTU considerations are not significant. When the MTU is closer to 1280 than 1500, the concerns raised in the first paragraph of 3.2 become significant. In that case, an implementation must either a) prevent GRE tunnels with GMTU < 1280 from being instantiated or b) provide tunnel fragmentation capabilities.

In any event, I am not aware of any implementations that will become non-compliant.

> fragmented delivery header?
[RPB] 
Yes. The packet must be reassembled at the egress.

> This seems like a very subjective MUST NOT. Please consider stating this
[RPB] 

Spenser Dawkin's DISCUSS was in the same area. He suggested that I do something to make the judgement less subjective. Please see my response to his DISCUSS and see if it also satisfies your COMMENT.

> -- 8.1, first reference:
> That’s probably not appropriate as a normative reference. Neither the URL or
> the content can be assumed to be stable. Would it make sense to reference
> RFC 7042 instead?
[RPB] 

I have moved the reference from the Normative to the Informative section. Having done that, I am not sure if it is appropriate to reference the IANA registry or 7042. If I guessed wrong, I am sure that the RFC editor will make it right.
> s/Generic Routing Encapsulation/The Generic Routing Encapsulation/
[RPB] 

I'm the sure that the article is required. Let's see what the RFC editor says.
 
> s/carry IPv6 payload/carry an IPv6 payload/     ; (or /carry IPv6
[RPB] 

Done

> It would be helpful to mention that this is the IPv6 ether type.
[RPB] 
Done

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 06 Aug 2015 17:15:56 -0500

Hi,

Thanks for the response. A few comments inline, with things that seem to 
be closed removed:

On 6 Aug 2015, at 16:28, Ronald Bonica wrote:

[...]
> [RPB]
>
> Spenser Dawkin's DISCUSS was in the same area. He suggested that I do 
> something to make the judgement less subjective. Please see my 
> response to his DISCUSS and see if it also satisfies your COMMENT.

Do you refer to a response to Spencer's DISCUSS from this morning? (i.e. 
not his previous COMMENTs?) If so, I have not seen the message.

> I have moved the reference from the Normative to the Informative 
> section. Having done that, I am not sure if it is appropriate to 
> reference the IANA registry or 7042. If I guessed wrong, I am sure 
> that the RFC editor will make it right.

I predict that the RFC Editor will ask what you want it to say :-) I 
would personally lean towards 7042, since it's a stable reference that 
describes the value in question, but I'm not sure if we have policy for 
that sort of thing.

[...]