On 2/18/2014 10:45 AM, Ronald Bonica wrote:
Folks,
I think that we are conflating two separate efforts.
Draft-bonica-intarea-gre-mtu describes what is widely deployed
today.
Understood, but it also out to explain how that corresponds to what
should be done, referring to a generic doc to explain the details of
what should be done.
In today's, one of the following conditions frequently holds:
- the operator of the GRE ingress knows that the GRE egress cannot
reassemble fragments at the required rate
>
- the operator of the GRE ingress has no information regarding
whether the GRE egress can reassemble fragments at the required rate
Therefore, in draft-bonica, by default, the PTU is equal to the MTU.
Fragmentation doesn't happen in the tunnel. However, in the exceptional
case, where the operator of the ingress knows that the egress can
reassemble at the required rate, fragmentation of the delivery packet is
permitted.
Understood, but as Fred points out, that means that the GRE tunnel is
non-compliant with IPv6 requirements. That needs to be discussed, even
if we admit that this is current operation.
The draft that Joe and Fred are considering
It's a draft that I and Mark Townsley already wrote. We started in 09 at
the request of a few different ADs, as an effort to aggregate
recommendations about how to tunnel IP packets, but it got virtually no
discussion on the list.
FWIW, it's still in the INTAREA charter, and still a WG doc, even
thought he current draft expired.
> applies to environments
where egress routers are commonly capable of reassembling at line rate.
All tunnels that cannot transit an IPv6 minimum MTU unfragmented MUST
ingress fragment and egress reassemble. Otherwise you're noncompliant
with IPv6, i.e., you're not a valid IPv6 link.
Any tunnel that uses IPv6 internally MUST therefore fragment/reassemble.
Whether they can at line rate or not determines whether they're broken
or not, not whether the spec has changed.
Since this is a different environment, it should be addressed in a
separate draft.
Neither of us is debating whether this should be a separate draft; every
tunnel mechanism needs a distinct presentation. The issue is how much
this doc should explain the issues and/or try to rationalize a
noncompliant solution simply because it's deployed.
IMO, we ought to explain what it DOES, discuss whether it's compliant,
and include what it would need to become compliant if not.
And refer to the tunnel draft for the details. That draft ought to be
revived (I can easily resubmit) and we ought to wrap-up the
recommendations in that doc and get it out the door (finally).
Joe
Ron
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Tuesday, February 18, 2014 1:29 PM
To: Templin, Fred L
Cc: Ronald Bonica; [email protected]
Subject: Re: [Int-area] FW: New Version Notification for
draft-bonica-intarea-gre-mtu-04.txt
On 2/18/2014 10:22 AM, Templin, Fred L wrote:
Hi Joe,
I can see that I am going to have to write a draft on generic tunnel
fragmentation.
-
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
