On 7/20/2016 6:22 PM, Templin, Fred L wrote:
>
> Joe,
>
>
>
> Another high-level point – will you agree that an egress needs to be
> able to discard
>
> any packet that is too large to be reassembled?
>
Yes.
> So, if the egress receives fragments
>
> that would reassemble to, e.g., 4KB but the
Please see the end sections of intarea-tunnels. This doc is intended to resolve
inconsistencies, not propagate them. Besides, that doc was only ever
informational anyway and we should be aiming for BCP.
Joe
> On Jul 20, 2016, at 6:12 PM, Templin, Fred L
> wrote:
>
> Hi Joe,
>
> Ø I have
Joe,
Another high-level point - will you agree that an egress needs to be able to
discard
any packet that is too large to be reassembled? So, if the egress receives
fragments
that would reassemble to, e.g., 4KB but the egress is only capable of
reassembling
up to 2KB, the egress needs to take m
Hi Joe,
? I have made it clear why this is inconsistent with this this document.
Your document needs to be made consistent with RFC2764; not the other way
around.
Thanks - Fred
From: Joe Touch [mailto:to...@isi.edu]
Sent: Wednesday, July 20, 2016 5:38 PM
To: Templin, Fred L ; int-area@ietf.o
Hi Joe,
PTB messages coming from the egress will be encapsulated and returned to the
ingress w/o them being dropped by an ICMP-filtering middlebox because they
will not look like ICMPs to the network - they will look like ordinary tunneled
packets. So, the ingress will receive the PTBs coming from
On 7/20/2016 5:41 PM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> Ø That quote is (still) intended for the case where the destination
> is actually more than one hop away. It is not intended to cover a
> multipoint link that itself has varying MTUs.
>
>
>
> It also says:
>
>If any o
Hi Joe,
? That quote is (still) intended for the case where the destination is
actually more than one hop away. It is not intended to cover a multipoint link
that itself has varying MTUs.
It also says:
If any of the packets sent on that path are too large to be forwarded
by some
Fred,
I have made it clear why this is inconsistent with this this document.
For this topic as well, I need to hear someone else who confirms that
this is critical, AND we need to then resolve the inconsistency in
terminology of that outdated document.
Joe
On 7/20/2016 5:32 PM, Templin, Fred L
Hi Joe,
The RFC2764, Section 3.1.7 reference needs to be in there, as well as
discussion of inner, outer, *and* tunnel fragmentation. I have made
it very clear what is meant by "tunnel fragmentation".
Thanks - Fred
From: Joe Touch [mailto:to...@isi.edu]
Sent: Wednesday, July 20, 2016 5:12 PM
To:
On 7/20/2016 5:03 PM, Templin, Fred L wrote:
>> > Note - all this need for egress MTU variation concern convinces me
>> > further that you are focused on optimizing MTUs. That way lies madness.
>> > MTUs need to be considered as minimums for communication, not limits to
>> > *try* to approach.
>
On 7/20/2016 4:56 PM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> Ø RFC2764 is inconsistent with intarea-tunnels. There are plenty of
> tunnels that do not use any of what you call tunnel fragmentation, yet
> they are tunnels and they do fragment and will work just fine for
> existing network t
Hi Joe,
> -Original Message-
> From: Joe Touch [mailto:to...@isi.edu]
> Sent: Wednesday, July 20, 2016 4:52 PM
> To: Templin, Fred L ; int-area@ietf.org
> Subject: Re: intarea-tunnels meta-comment: multipoint tunnels
>
>
>
> On 7/20/2016 4:47 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
>
Hi Joe,
? RFC2764 is inconsistent with intarea-tunnels. There are plenty of tunnels
that do not use any of what you call tunnel fragmentation, yet they are tunnels
and they do fragment and will work just fine for existing network technologies.
For tunnels that cannot do RFC2764 tunnel fragmen
On 7/20/2016 4:47 PM, Templin, Fred L wrote:
> Hi Joe,
>
>> -Original Message-
>> From: Joe Touch [mailto:to...@isi.edu]
>> Sent: Wednesday, July 20, 2016 4:37 PM
>> To: Templin, Fred L ; int-area@ietf.org
>> Subject: Re: intarea-tunnels meta-comment: multipoint tunnels
>>
>>
>>
>> On 7/2
Hi Joe,
> -Original Message-
> From: Joe Touch [mailto:to...@isi.edu]
> Sent: Wednesday, July 20, 2016 4:37 PM
> To: Templin, Fred L ; int-area@ietf.org
> Subject: Re: intarea-tunnels meta-comment: multipoint tunnels
>
>
>
> On 7/20/2016 4:34 PM, Templin, Fred L wrote:
> > For multipoin
Hi Joe,
Inner fragmentation is what happens *before* encapsulation.
Tunnel fragmentation is what happens *during* encapsulation.
Outer fragmentation is what happens *after* encapsulation.
For completion, your document needs to discuss tunnel fragmentation,
and needs to cite RFC2764, Section 3.1.7
Fred,
RFC2764 is inconsistent with intarea-tunnels. There are plenty of
tunnels that do not use any of what you call tunnel fragmentation, yet
they are tunnels and they do fragment and will work just fine for
existing network technologies.
I have already confirmed that the doc will be updated to
On 7/20/2016 4:34 PM, Templin, Fred L wrote:
> For multipoint tunnels, it should be OK if not all egresses configure the same
> reassembly buffer size, so the ingress may have an MTU that is greater than
> the reassembly buffer size of one or more egresses.
Why is that not effectively modeled as
Joe,
For multipoint tunnels, it should be OK if not all egresses configure the same
reassembly buffer size, so the ingress may have an MTU that is greater than
the reassembly buffer size of one or more egresses. Your document needs
to say this.
This is supported by RFC1981(bis), where it says:
Fred,
I'm going to wait for someone else on the list to confirm that they too
do not understand that egress processing includes as many levels of
fragmentation as are needed to implement the "link" of a tunnel.
Joe
On 7/20/2016 2:01 PM, Templin, Fred L wrote:
>
> Joe,
>
>
>
> Your draft is mis
Joe,
Your draft is missing discussion of tunnel fragmentation, which is necessary to
avoid the hazards of IP fragmentation - you need to add a discussion of steps
2-3 in my list below.
Thanks - Fred
From: Joe Touch [mailto:to...@isi.edu]
Sent: Wednesday, July 20, 2016 1:18 PM
To: Templin, Fred L
On 7/20/2016 12:53 PM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> This is all much simpler than you are making it out to be. The steps are:
>
>
>
> 1) Perform inner fragmentation on the original IP packet if necessary
>
That is already in the doc.
> 2) Encapsulate the original IP p
Hi Joe,
This is all much simpler than you are making it out to be. The steps are:
1) Perform inner fragmentation on the original IP packet if necessary
2) Encapsulate the original IP packet (or fragments) in a tunnel
encapsulation header (e.g., GUE, GRE, etc.)
3) Perform tunnel
On 7/20/2016 11:35 AM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> Ø Outer fragmentation (as you're using the term, which again is not
> consistent with the current doc) happens as part of encapsulation too.
> It's not "after" anything.
>
>
>
> I disagree with that. With outer fragmentation,
Hi Joe,
? Outer fragmentation (as you're using the term, which again is not consistent
with the current doc) happens as part of encapsulation too. It's not "after"
anything.
I disagree with that. With outer fragmentation, you first encapsulate in an
outer IP
header *and then* apply fragmenta
On 7/20/2016 10:47 AM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> We are talking now about fragmentation, and not atomic datagrams.
>
It matters because atomic datagrams can be transmitted without consuming
ID space.
> And, it
>
> must be agreed that IPv4 fragmentation at high data rates is u
Hi Joe,
We are talking now about fragmentation, and not atomic datagrams. And, it
must be agreed that IPv4 fragmentation at high data rates is unacceptable
per RFC4963.
Your math for IPv6 fragmentation does show a potential RFC4963 scenario
for conceivable future data rates. That would not happen
On 7/20/2016 10:22 AM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> There are other reasons for using tunnel fragmentation, but let’s talk
>
> only about the IP ID for now:
>
>
>
> IPv4 has a 16bit IP ID and a 120sec MSL, and we know that that tunnels
>
> would need to go way too slow for moder
Hi Joe,
There are other reasons for using tunnel fragmentation, but let's talk
only about the IP ID for now:
IPv4 has a 16bit IP ID and a 120sec MSL, and we know that that tunnels
would need to go way too slow for modern technologies in order to
avoid reassembly misassociations.
IPv6 has a 32bit
On 7/20/2016 9:09 AM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> Inner fragmentation, tunnel fragmentation and outer fragmentation are the
>
> three layers at which fragmentation can be applied. Outer fragmentation is
>
> understood by all to be IP fragmentation applied at the outer IP layer. W
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group of the IETF.
Title : Multi-hop Ad Hoc Wireless Communication
Authors : Emmanuel Baccelli
Charles
Hi Joe,
Inner fragmentation, tunnel fragmentation and outer fragmentation are the
three layers at which fragmentation can be applied. Outer fragmentation is
understood by all to be IP fragmentation applied at the outer IP layer. We
know that this kind of fragmentation is broken due to IP ID limita
On 7/20/2016 8:10 AM, Templin, Fred L wrote:
>
> Hi Joe,
>
>
>
> Inner fragmentation is what happens **before** encapsulation.
>
> Tunnel fragmentation is what happens **during** encapsulation.
>
> Outer fragmentation is what happens **after** encapsulation.
>
It's very clear that inner and ou
Hi Joe,
Inner fragmentation is what happens *before* encapsulation.
Tunnel fragmentation is what happens *during* encapsulation.
Outer fragmentation is what happens *after* encapsulation.
The document needs to say something about this for completion.
Thanks - Fred
From: Joe Touch [mailto:to...@
All,
Last year, RFC 6890 was published as a mechanism for standardizing
the information maintained in IANA's Special Use Address registries.
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
http://www.iana.org/assignments/iana-ipv6-special-registry/
Hello Bernard,
Thanks for the pointer to RFC 4907. I haven't finished reading it yet,
but the parts about handover and metric consistency already caught my
attention. I definitely think it should be included if there is another
draft to discuss link quality indicators.
Regards,
Charlie P.
Security considerations generally fall in two parts (a) that which is essential
to the matter in hand, and (b) that which is needed to show people - especially
SEC ADs - that you've really thought about the problem. I'd agree that 7182
does not fall under (a). Whether it falls under (b) as a "wi
Hello Alex,
Please excuse my delay in answering -- your email got buried in a mass
flood of other emails. Follow-up below...
On 5/18/2016 4:37 AM, Alexandre Petrescu wrote:
Hello,
I would like to give a few comments on this draft.
Thanks much for your review!
It says:
For the purpose
The reference is one of those "I happened to notice" things. As I noted, this
could be left to RFC Editor. Or a query made ahead of time (I think they are
quite friendly). But it's not important (and had I note had other points, I'd
not have mentioned it, it was a "since I'm posting" thing).
--
Hello again Chris,
I forgot to mention the reference DoD01. This is a book chapter by
James Freebersyser and Barry Leiner in a book that I edited. Do you mean
to suggest that I should delete the part of the citation about the
book's editorship? I don't really know how best to format the cita
Hello Chris,
Thanks for your review of this document. Your email somehow eluded my
attention until today, please excuse the delay.
Follow-up below...
On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote:
I haven’t yet found time to read this (I’m still hoping to before
indicated date).
41 matches
Mail list logo
