Subject: Re: [Int-area] Comments on draft-ietf-intarea-tunnels-00.txt

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 Jan 2015 04:11:39 +0000

Fred,

Draft-ietf-intarea-tunnels is a statement regarding the capabilities and default behaviors of existing implementations. It makes no value judgments.

Existing implementations can do all of the things that you recommend, below. The behaviors that you describe below may not be the defaults, but they are achievable.

Existing implementations can also behave in other ways. It's a matter of configuration.

                                                                                                    Ron

> 
>   - Do not set any explicit limitation on the size of packets that can be
> admitted
>     into the tunnel ingress (i.e., no MTU clamping)
>   - For packets no larger than 1280-ENCAPS bytes, and for packets larger than
>     1500 bytes, encapsulate and send without fragmentation
>   - For packets larger than 1280-ENCAPS but no larger than 1500, encapsulate
>     and break the packet into two fragments no larger than 1024 bytes then
>     send both fragments
>   - If probing indicates that packets in this "fragmentation zone" can traverse
>     the tunnel without fragmentation, suspend fragmentation and begin
>     sending whole packets
>   - make a best effort to deliver any ensuing Packet to Big (PTB) messages
>      to the original source.
> 
> See Section 3.12 of draft-templin-aerolink for the detailed specification.
> 
> Comments?
> 
> Thanks - Fred
> [email-masked]
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jan 2015 15:56:22 +0000

Hi Ron,

If you have no issues with what I have said, then I think you would also agree
that we need to get existing implementations to stop clamping the tunnel MTU
so we can avoid black holes and support larger packet sizes. That is the sort of
guidance that belongs in intarea-tunnels.

Thanks - Fred

> -----Original Message-----
> From: Ronald Bonica [mailto:[email-masked]]
> Sent: Wednesday, January 14, 2015 8:12 PM
> To: [email-masked]; Templin, Fred L
> Subject: Re: Comments on draft-ietf-intarea-tunnels-00.txt
> 
> Fred,
>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 Jan 2015 16:21:50 +0000

Fred,

At IETF 89, the WG instructed the authors of intarea-tunnel to refrain from offering guidance. Simply document how existing implementations work. This we have done.

                               Ron

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Thursday, January 15, 2015 10:56 AM
> To: Ronald Bonica; [email-masked]
> Subject: RE: Comments on draft-ietf-intarea-tunnels-00.txt
> 
> Hi Ron,
> 
> that we need to get existing implementations to stop clamping the tunnel
> MTU so we can avoid black holes and support larger packet sizes. That is the
> sort of guidance that belongs in intarea-tunnels.
> 
> Thanks - Fred
> > Draft-ietf-intarea-tunnels is a statement regarding the capabilities
> > and default behaviors of existing implementations. It makes no value
> judgments.
> >
> > Existing implementations can do all of the things that you recommend,
> > below. The behaviors that you describe below may not be the defaults, but
> they are achievable.
> >
> > >   - Do not set any explicit limitation on the size of packets that
> > > can be admitted

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Jan 2015 16:41:37 +0000

?

I think we need to call a huddle with the authors of intarea-tunnel, because it was
not even on the agenda at IETF89.

Thanks - Fred

> Sent: Thursday, January 15, 2015 8:22 AM
> To: Templin, Fred L; [email-masked]

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 Jan 2015 17:12:24 +0000

Fred,

My bad. I was confusing draft-ietf-intarea-tunnels with draft-ietf-intarea-gre-mtu.

Draft-intarea-tunnels is free to give advice. I will comment on that later.

                                                                                        Ron

> Sent: Thursday, January 15, 2015 11:42 AM
> I think we need to call a huddle with the authors of intarea-tunnel, because it
> was not even on the agenda at IETF89.
> 
> Thanks - Fred
> > At IETF 89, the WG instructed the authors of intarea-tunnel to refrain
> > from offering guidance. Simply document how existing implementations
> work. This we have done.
> >
> >                                Ron
> >
> > > If you have no issues with what I have said, then I think you would
> > > also agree that we need to get existing implementations to stop
> > > clamping the tunnel MTU so we can avoid black holes and support
> > > larger packet sizes. That is the sort of guidance that belongs in intarea-
> tunnels.
> > >
> > > Thanks - Fred
> > > > Draft-ietf-intarea-tunnels is a statement regarding the
> > > > capabilities and default behaviors of existing implementations. It
> > > > makes no value
> > > judgments.
> > > >
> > > > Existing implementations can do all of the things that you
> > > > recommend, below. The behaviors that you describe below may not be
> > > > the defaults, but
> > > they are achievable.
> > > >
> > > > Existing implementations can also behave in other ways. It's a
> > > > matter of
> > > configuration.
> > > >
> > > >
> > > > Ron
> > > >
> > > > >
> > > > >   - Do not set any explicit limitation on the size of packets
> > > > > that can be admitted
> > > > >   - For packets no larger than 1280-ENCAPS bytes, and for
> > > > > packets larger
> > > than
> > > > >     and break the packet into two fragments no larger than 1024
> > > > > bytes
> > > then
> > > > >     send both fragments
> > > > >   - If probing indicates that packets in this "fragmentation
> > > > > zone" can
> > > traverse