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

[Ronald Bonica <[e-mail]>]

Hi Ben,

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

                                                                       Ron

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Wednesday, August 05, 2015 2:50 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; draft-ietf-intarea-gre-
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Ben Campbell's No Objection on draft-ietf-intarea-gre-ipv6-11: (with
> COMMENT)
> 
> 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
> 
[RPB] 

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

> -- 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?
> 
[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.

> -- 3.3, last sentence:
> Is there a reciprocal requirement for the egress to reassemble the
> fragmented delivery header?
[RPB] 
Yes. The packet must be reassembled at the egress.

> 
> -- 4.2, 2nd to last paragraph:
> This seems like a very subjective MUST NOT. Please consider stating this
> without 2119 keywords.
>
[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.
> 
> ** Nits **
> 
> --1, first sentence:
> 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.
 
> -- 3
> s/carry IPv6 payload/carry an IPv6 payload/     ; (or /carry IPv6
> payloads/)
[RPB] 

Done

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