On 17/03/2017 21:56, Bob Hinden wrote:
Hi Stewart,
Thanks for the detailed review. I am responding after reading the email thread
that resulted, some issues were closed.
Several of the reviews have suggested significant changes to this document.
The working group was trying to make a few
Hi Stewart,
Thanks for the detailed review. I am responding after reading the email thread
that resulted, some issues were closed.
Several of the reviews have suggested significant changes to this document.
The working group was trying to make a few changes to bring it into alignment
with so
On 2/16/2017 1:29 PM, Stewart Bryant wrote:
>
>
> On 16/02/2017 18:49, Joe Touch wrote:
>>
>> On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>>>
>>> On 14/02/2017 23:00, Templin, Fred L wrote:
Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmenta
On 16/02/2017 18:49, Joe Touch wrote:
On 2/16/2017 7:59 AM, Stewart Bryant wrote:
On 14/02/2017 23:00, Templin, Fred L wrote:
Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmentation to
guarantee that - at a minimum - packets up to 1280 will get
On 2/16/2017 11:59 AM, Brian E Carpenter wrote:
> On 17/02/2017 04:59, Stewart Bryant wrote:
>>
>> On 14/02/2017 23:00, Templin, Fred L wrote:
>>> Unless there is operational assurance of
>>> some size X>1280, however, tunnels have to use fragmentation to
>>> guarantee that - at a minimum - packe
On 17/02/2017 04:59, Stewart Bryant wrote:
>
>
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> Unless there is operational assurance of
>> some size X>1280, however, tunnels have to use fragmentation to
>> guarantee that - at a minimum - packets up to 1280 will get through.
>
> In that case the
On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>
>
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> Unless there is operational assurance of
>> some size X>1280, however, tunnels have to use fragmentation to
>> guarantee that - at a minimum - packets up to 1280 will get through.
>
> In that case the
On 14/02/2017 23:00, Templin, Fred L wrote:
Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmentation to
guarantee that - at a minimum - packets up to 1280 will get through.
In that case there really needs to be a note about MPLS.
You can fragment
Hi, Brian,
On 2/15/2017 1:26 PM, Brian E Carpenter wrote:
> On 16/02/2017 10:12, Joe Touch wrote:
>> Brian (et al.),
>>
>>
>> On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
practice the
Internet breaks the mechanism. However it breaks it is a way that seems
disruptive to some user
On 16/02/2017 10:12, Joe Touch wrote:
> Brian (et al.),
>
>
> On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>>> practice the
>>> Internet breaks the mechanism. However it breaks it is a way that seems
>>> disruptive to some user traffic. The document is really guidance
>>> one how hosts might u
Brian (et al.),
On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>> practice the
>> Internet breaks the mechanism. However it breaks it is a way that seems
>> disruptive to some user traffic. The document is really guidance
>> one how hosts might use ICMP for optimization, and arguable need
>> no
Hi, Ole,
On 2/14/2017 10:33 AM, otr...@employees.org wrote:
>> *If* you care about packet loss, then your only option is to probe the path
>> with with
>> synthetic data that exactly mimics the live data, or not to probe at all and
>> live
>> with the 1280. As I said 1280 is pretty close to 14
essage-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> Sent: Tuesday, February 14, 2017 8:45 AM
> To: Templin, Fred L ; Stewart Bryant
> ; Brian E Carpenter
> ; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis....@ietf.org
> Subject: Re: [Gen
> On Feb 14, 2017, at 2:14 PM, otr...@employees.org wrote:
>
> Stewart,
>
>
>> Maybe we could sort this out faster with a short phone call.
>
> Yes, we can certainly do that!
Let me know if you would like me to call in as well.
Thanks
Suresh
smime.p7s
Description: S/MIME cryptographic sign
c1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>
> Fred,
>
> >> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose
> >> of the minimum MTU was to give space for tunnel
> headers
> >> (1500-
Fred,
>> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of
>> the minimum MTU was to give space for tunnel headers
>> (1500-1280).
>
> But, if non-tunnel links set a 1280 MTU which is perfectly OK with the
> standard then
> there is no space for headers. Given the issu
Stewart,
> Maybe we could sort this out faster with a short phone call.
Yes, we can certainly do that!
> As I read the spec it says hunt for a new upper limit every 10 mins, won't
> there be packet as it sends out oversized packets looking for a higher MTU?
Yes.
Best regards,
Ole
> On 14/0
c1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>
> Stewart,
>
> > *If* you care about packet loss, then your only option is to probe the
> > path with with
> > synthetic data that exactly mimics the live data, or not to probe at
> On Feb 14, 2017, at 10:33 AM, otr...@employees.org wrote:
>
>> *If* you care about packet loss, then your only option is to probe the path
>> with with
>> synthetic data that exactly mimics the live data, or not to probe at all and
>> live
>> with the 1280. As I said 1280 is pretty close to
Ole
Maybe we could sort this out faster with a short phone call.
As I read the spec it says hunt for a new upper limit every 10 mins,
won't there be packet as it sends out oversized packets looking for a
higher MTU?
Stewart
On 14/02/2017 18:33, otr...@employees.org wrote:
Stewart,
*If*
Stewart,
> *If* you care about packet loss, then your only option is to probe the path
> with with
> synthetic data that exactly mimics the live data, or not to probe at all and
> live
> with the 1280. As I said 1280 is pretty close to 1496 which is all most
> networks
> will give you in pract
...@gmail.com]
Sent: Tuesday, February 14, 2017 8:13 AM
To: Templin, Fred L ; Brian E Carpenter
; Stewart Bryant
; gen-art@ietf.org
Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
On 14/02/2017 15:50, Templin
-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>
>
>
> On 14/02/2017 15:50, Templin, Fred L wrote:
> >
> >> As to you first point remember that the convergence process disrupts the
> >> traffic flow as it does so, an
Bryant
; gen-art@ietf.org
Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
On 10/02/2017 03:25, Brian E Carpenter wrote:
Stewart,
On 10/02/2017 04:19, Stewart Bryant wrote:
...
I wonder if we would best
-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>
> Hi Fred
>
> Looks like a good point on RFC4821.
OK.
> As to you first point remember that the convergence process disrupts the
> traffic flow as it does so, and that this wil
; Stewart Bryant
; gen-art@ietf.org
Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
On 10/02/2017 03:25, Brian E Carpenter wrote:
Stewart,
On 10/02/2017 04:19, Stewart Bryant wrote:
...
I wonder if we would best
c1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>
> > How does this work for UDP?
> >
> > Sending packets no larger than 1280 bytes is always an option, and in
> > the case of UDP-based request-response protocols such as DNS that d
Hi,
On 2017-2-11, at 7:42, Suresh Krishnan wrote:
> How does this work for UDP?
See draft-ietf-tsvwg-rfc5405bis (which is in AUTH48), Section 3.2 "Message Size
Guidelines".
Lars
signature.asc
Description: Message signed with OpenPGP
___
Gen-art mai
In message ,
otr...@employees.org writes:
> > How does this work for UDP?
> >
> > Sending packets no larger than 1280 bytes is always an option, and in
> > the case of UDP-based request-response protocols such as DNS that do
> > not have connection state, it may be the only feasible option.
>
> Y
> How does this work for UDP?
>
> Sending packets no larger than 1280 bytes is always an option, and in
> the case of UDP-based request-response protocols such as DNS that do
> not have connection state, it may be the only feasible option.
Yes, but DNS tend to use IP fragmentation that suffers an
On Fri, Feb 10, 2017 at 10:42 PM, Suresh Krishnan wrote:
> On Feb 10, 2017 11:30 PM, "C. M. Heard" wrote:
>
> On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> > On 10/02/2017 23:20, Stewart Bryant wrote:
> > > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > > On 10/02/2017 04:19,
Hi Mike,
On Feb 10, 2017 11:30 PM, "C. M. Heard" wrote:
On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best ser
On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared
On 10/02/2017 23:20, Stewart Bryant wrote:
>
>
> On 10/02/2017 03:25, Brian E Carpenter wrote:
>> Stewart,
>>
>> On 10/02/2017 04:19, Stewart Bryant wrote:
>> ...
>>> I wonder if we would best serve both our future and our heritage
>>> if we declared RFC1981 as historic, and either left the idea
7 2:21 AM
> To: Brian E Carpenter ; Stewart Bryant
> ; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
>
>
>
> On 10/02/2017 03:25, Brian E Carpenter wrote:
> &g
On 10/02/2017 03:25, Brian E Carpenter wrote:
Stewart,
On 10/02/2017 04:19, Stewart Bryant wrote:
...
I wonder if we would best serve both our future and our heritage
if we declared RFC1981 as historic, and either left the idea there,
or declared it as historic and wrote a new text from a cle
Stewart,
On 10/02/2017 04:19, Stewart Bryant wrote:
...
> I wonder if we would best serve both our future and our heritage
> if we declared RFC1981 as historic, and either left the idea there,
> or declared it as historic and wrote a new text from a clean start?
I don't see that. It's a stable, w
Reviewer: Stewart Bryant
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more i
38 matches
Mail list logo
