Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Mar 2015 17:33:33 +0000

Hi Suresh,

I see that you are also co-author on the draft? But, see below:

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Saturday, February 28, 2015 11:52 AM
> To: Ronald Bonica; Templin, Fred L; Joe Touch; Carlos Pignataro (cpignata)
> Cc: [email-masked]
> Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> 
> Hi Ron,
> 
> On 02/27/2015 07:13 PM, Ronald Bonica wrote:
> > Guys,
> >
> > I would like to suggest that this discussion is beyond the scope of draft-ietf-intarea-gre-ipv6. The chairs may correct me, but it might
> even be outside the scope of this WG.
> 
> Agree with you that the discussion is out of scope for the draft.

The draft currently permits send PTBs that report a size less than 1280. That option
was formerly reserved for only IPv6/IPv4 translators. So, if this document now
recommends sending degenerate PTBs it needs to discuss the implications of
doing so - or, it needs to cite another document that discusses the implications.

Thanks - Fred
[email-masked]

> I think it is may or may not be in the scope of the wg depending on what
> actions may be required. 6man may be a better home depending on what
> people are aiming to change.
> 
> Thanks
> Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Mar 2015 18:08:40 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, February 27, 2015 4:39 PM
> To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
> Cc: [email-masked]
> On 2/27/2015 3:50 PM, Templin, Fred L wrote:
> ...
> > I do not see any "MUST NOTs" in RFC2460, nor any dire consequences for
> > allowing a tunnel ingress to fragment atomic fragments. So, if we update
> > the final paragraph of Section 5 of RFC2460 we should be good to go.
> 
>     On any link that cannot convey a 1280-octet
>     packet in one piece, link-specific fragmentation and reassembly must
>     be provided at a layer below IPv6.

Link-specific fragmentation and reassembly of the delivery packet is a pain
point that can be alleviated by fragmenting the payload packet.

> also:
>     (Note: unlike
>     IPv4, fragmentation in IPv6 is performed only by source nodes, not by
>     routers along a packet's delivery path -- see section 5.)
> 
> So you're talking about updating RFC2460 to allow on-path fragmentation
> of source fragments. I disagree with that, for the same reasons it was
> omitted from IPv6 in the first place.

In this case, the tunnel ingress uses on-path fragmentation of the payload
packet instead of link-specific fragmentation of the delivery packet. The
tunnel egress is therefore excused from having to reassemble. That is
better than link-specific fragmentation and reassembly, and will make
for a better IPv6 Internet.

Thanks - Fred

> Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Mar 2015 10:13:23 -0800

> for a better IPv6 Internet.

I disagree. This method, IMO, simply lets tunnels make work that
endpoints need to clean up. It trades profit for tunnel equipment
vendors (who get to make what I consider to be underpowered equipment)
at the expense of endpoints.

See "tragedy of the commons".

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Mar 2015 18:30:46 +0000

Hi Joe,

> Sent: Monday, March 02, 2015 10:13 AM
> endpoints need to clean up.

Actually, the very best solution would be for the original source itself to
do the fragmentation - that way, the tunnel ingress never has to. In the
scenario I am describing, the tunnel ingress is actually having to work hard
on behalf of original sources that are too lazy to do the work themselves.
That hurts the tunnel ingress, which only hurts the original source.

> It trades profit for tunnel equipment

How bad is that, really, Joe? The most we will ever ask the endpoints to
fragment and reassemble is 1500; everything larger than that will go as
one piece or not at all. In the long run, it is in the endpoints' best interest
to offload the tunnel ingress and egress.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Mar 2015 10:49:27 -0800

On 3/2/2015 10:30 AM, Templin, Fred L wrote:
> do the fragmentation - that way, the tunnel ingress never has to.

That is viable only if we have no lower bound on fragment size.

If we did (do), then that would be the min MSS, and it will always be a
problem at some point.

> In the

If the tunnel can't transport min-MSS datagrams, it is the ingress that
is causing the problem by claiming to support a protocol (IPv6) when it
does not.

Having tunnels do work to play IPv6 doesn't mean the sources are lazy in
not supporting capabilities outside the scope of IPv6.

> to offload the tunnel ingress and egress.

For every reason you want to allow the tunnel to offload work to the
endpoints, I think it is equally fair (if not more fair) to ask the
egress to clean up the mess made by the source.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Mar 2015 19:10:29 +0000

Hi Joe,

> Sent: Monday, March 02, 2015 10:49 AM

I was thinking that a reasonable lower bound on frag size could be
something like 750 (1/2 of 1500). Or maybe 576 (slightly more than
1/3 of 1500).
 
> is causing the problem by claiming to support a protocol (IPv6) when it

You will have to tell that to the draft-ietf-intarea-gre-ipv6 authors,
because they are saying to do exactly that.

> not supporting capabilities outside the scope of IPv6.

It doesn't scale for tunnels to support thousands or millions of end systems
all placing a heavy frag/reass burden on them.

> egress to clean up the mess made by the source.

Asking to the egress to reassemble on behalf of great multitudes of end
systems doesn't scale. And, in the end, all end systems suffer.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Mar 2015 11:24:34 -0800

Fred,

We've had this entire discussion before.

We should label it with an name and in the future cite by reference.

It is out of scope until the WG decides it's important to deal with this
issue, IMO - and that hasn't happened yet.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Mar 2015 20:44:57 +0000

Hi Joe,

> Sent: Monday, March 02, 2015 11:25 AM

The GRE folks are saying that it is OK for the tunnel ingress to send PTB
with size less than 1280. That forces us to consider what happens when
a source node actually receives and acts on that message.

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Mar 2015 12:58:09 -0800

On 3/2/2015 12:44 PM, Templin, Fred L wrote:
> with size less than 1280. 

I'm not sure what you're getting at.

Either they're saying that this is already what's deployed or they're
saying it's something new.

The former is the purpose of the current doc. The latter is new work.

> That forces us to consider what happens when

It forces them to document existing behavior. Not for us to extrapolate.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Mar 2015 21:17:36 +0000

Hi Joe,

> Sent: Monday, March 02, 2015 12:58 PM

I'm getting at what they wrote. Nowhere else (except for IPv6/IPv4 translators)
does it say that it is OK to send a PTB with size smaller than 1280.

> saying it's something new.

If it is already deployed, then what happens if it is ever invoked? The
document does not say. Once a source receives a PTB with a size smaller
than 1280, it is supposed to start sending future packets as large as 1280
and with a fragment header included. What is the GRE ingress supposed
to do then? Fragment the inner? Fragment the outer? Drop and return yet
another PTB with size smaller than 1280? That's the point; it doesn't say.

If the intent is to document what's already deployed, then it is only
documenting one half of the behavior. The other half is what happens
*after* a PTB with size smaller than 1280 is sent. On this point, the
document is silent.

Thanks -Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Mar 2015 13:28:40 -0800

...
> does it say that it is OK to send a PTB with size smaller than 1280.

And if that's what it DOES, then that's what it does.

> document does not say. 

Then it should.

The behavior shouldn't be reasoned-out.

...
> *after* a PTB with size smaller than 1280 is sent. On this point, the

Agreed.

Joe