Re: [Gen-art] Review of draft-ietf-mpls-residence-time-13

Hi Robert, Section 5 Data Plane Theory of Operation has the following recommendation on reading time value at ingress and egress: Each RTM-capable node on the explicit path receives an RTM packet and records the time at which it receives that packet at its ingress interface as well as

Re: [Gen-art] [DMM] Review of draft-ietf-dmm-4283mnids-04

Charlie Perkins writes: > I am hesitant to replace so many MNID types by a single URN type with > substructure. What would you think about replacing the existing > RFID-*-URI types with a single URN type, but leaving the existing binary > types? This gets the

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Hi Stewart, > *If* you care about packet loss I can say that, for air traffic communications at least, we do care very much about packet loss. > then your only option is to probe the path with with > synthetic data that exactly mimics the live data Yes, that is exactly correct - so, the

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

> 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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Hi Ole, > -Original Message- > From: otr...@employees.org [mailto:otr...@employees.org] > Sent: Tuesday, February 14, 2017 11:17 AM > To: Templin, Fred L > Cc: Stewart Bryant ; Brian E Carpenter > ;

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-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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Hi Ole, > -Original Message- > From: otr...@employees.org [mailto:otr...@employees.org] > Sent: Tuesday, February 14, 2017 10:33 AM > To: Stewart Bryant > Cc: Templin, Fred L ; Brian E Carpenter > ;

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

> 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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

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,

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 all and > live > with the 1280. As I said 1280 is pretty close to 1496 which is all most > networks > will give you in

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Fred *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 practice. When I

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Hi Stewart, > -Original Message- > From: Stewart Bryant [mailto:stewart.bry...@gmail.com] > Sent: Tuesday, February 14, 2017 8:13 AM > To: Templin, Fred L ; Brian E Carpenter > ; Stewart Bryant > ;

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, and that this will repeat every 10 mins as it tries to re-optimise. Yes, you are right. So, even in the case of RFC1981bis it might not be a good

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

HI Stewart, > -Original Message- > From: Stewart Bryant [mailto:stewart.bry...@gmail.com] > Sent: Tuesday, February 14, 2017 1:51 AM > To: Templin, Fred L ; Brian E Carpenter > ; Stewart Bryant > ;

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Hi Fred Looks like a good point on RFC4821. As to you first point remember that the convergence process disrupts the traffic flow as it does so, and that this will repeat every 10 mins as it tries to re-optimise. - Stewart On 10/02/2017 15:38, Templin, Fred L wrote: Hi, about ECMP I