Re: [Int-area] Probe sizes for MTU discovery

Hi Iljitsch, I agree. However, I think RFC 4821 and my variable MTU subnet mechanism would complement each other. In an earlier version of the draft I skipped the probing if a system supports RFC 4821, but I removed that as there were just too many ways for things to fall through the

Re: [Int-area] Probe sizes for MTU discovery

] Sent: Monday, November 17, 2014 5:39 PM To: Black, David; Iljitsch van Beijnum Cc: int-area@ietf.org Subject: RE: [Int-area] Probe sizes for MTU discovery Hi David, (1) RFC 4821 should be the basis for the algorithm used for probing, While Iljitsch is considering you message, can you

Re: [Int-area] Probe sizes for MTU discovery

examples. Thanks, --David -Original Message- From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] Sent: Monday, November 17, 2014 6:01 PM To: Black, David; Iljitsch van Beijnum Cc: int-area@ietf.org Subject: RE: [Int-area] Probe sizes for MTU discovery Hi David, -Original

Re: [Int-area] WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes

: Tuesday, March 31, 2015 8:53 PM To: Black, David; Zuniga, Juan Carlos; int-area@ietf.org; i...@ietf.org Cc: draft-ietf-intarea-gre-i...@tools.ietf.org; intarea-cha...@ietf.org Subject: RE: WGLC for draft-ietf-intarea-gre-ipv6 - Ethertypes David, One way to address this problem would be to remove

Re: [Int-area] Start of WGLC for draft-ietf-intarea-gre-ipv6

IPv6 is only practical when operators can deal with that risk is also useful, IMHO. Thanks, --David -Original Message- From: Tom Herbert [mailto:t...@herbertland.com] Sent: Tuesday, March 31, 2015 6:57 PM To: Ronald Bonica Cc: Lucy yong; Black, David; int-area@ietf.org; i...@ietf.org

Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration

some other words) to such networks. Upshot: the use of necessarily in the text quoted above is correct, but misses the point. Thanks, --David -Original Message- From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] Sent: Wednesday, April 01, 2015 10:13 AM To: Black, David; int-area

Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration

To: Black, David; int-area@ietf.org; i...@ietf.org Cc: draft-ietf-intarea-gre-i...@tools.ietf.org; intarea-cha...@ietf.org Subject: RE: draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration Hi David, -Original Message- From: Black, David [mailto:david.bl...@emc.com] Sent

Re: [Int-area] draft-ietf-intarea-gre-ipv6 - Sec 3.1 alternative configuration

is appropriate for this draft. I hesitate to generalize it to all IPv6 tunnels or have the GRE provisions await that being done. Thanks, --David -Original Message- From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] Sent: Wednesday, April 01, 2015 5:34 PM To: Black, David; int-area

Re: [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt

cases where the latter doesn't happen. Got it now, sorry for the confusion. So I don't really care much about the middlebox behind a NAT on the other side - it's *my* side I care about. The usage examples in the draft refer to talking people in my institution or at the airport where I'm

Re: [Int-area] Spencer Dawkins' Discuss on draft-ietf-intarea-gre-ipv6-13: (with DISCUSS and COMMENT)

a network node that is not participating in VPN B is a concern even if that node promptly drops that cleartext. Thanks, --David From: Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com] Sent: Monday, August 24, 2015 7:16 PM To: Black, David Cc: The IESG; int-area@ietf.org; draft-ietf-i

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

-- As GRE/UDP draft shepherd > > Do equivalent arguments apply also to > > ietf-tsvwg-gre-in-udp-encap/>? Not exactly ;-). The motivating GRE in UDP encap use cases involves operator use of GRE for traffic management, as summarized in the draft

[Int-area] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-03.txt

This draft will get some agenda time at the TSVWG meeting in Berlin - it may be of interest to INTAREA, given the increasing use of UDP for tunnels. FYI, --David (TSVWG co-chair) From: tsvwg [mailto:tsvwg-boun...@ietf.org] On Behalf Of Joe Touch Sent: Tuesday, June 28, 2016 6:08 PM To: tsvwg

[Int-area] -00 drafts and meeting time (was RE: IETF97 Minutes)

+1 - the primary purpose of WG meeting time is for WG work. Particularly for area-wide WGs like intarea and tsvwg that have a broad scope, authors SHOULD NOT assume that submitting a -00 draft entitles that draft to agenda time at the next WG meeting, particularly when the draft is submitted at

Re: [Int-area] [Intarea] Meeting Minutes

Small correction in this section: [ Congestion Notification Across IP Tunnel Headers Separated by a Shim ] Bob Briscoe [... snip ...] OLD * David Black * we're going to last call this where it is NEW * David Black * we're going to last call this draft where it is in TSVWG and will

Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt

+1 – I concur with Fred that this draft should become a BCP. The concept of a tunnel as a link is fundamental and should be a foundational principle for how tunnels are designed/specified. Thanks, --David From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Templin, Fred L Sent:

Re: [Int-area] Call for support: IPmix I-D (was IPv10)

> The draft and the concept have been thoroughly discussed on int-area > list (twice). I don't see that the problem is worth solving, the > proposed solution is remotely feasible, or that the author is willing > to apply feedback from the discussion. I am not interested in further > discussions

Re: [Int-area] Call for support: IPmix I-D (was IPv10)

gt; Sent: Wednesday, October 11, 2017 3:10 PM > To: int-area@ietf.org > Subject: Re: [Int-area] Call for support: IPmix I-D (was IPv10) > > Agree > > > > > > On 10/10/2017 12:49 AM, Black, David wrote: > > >> The draft and the concept have been thor

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

> I still think it would be useful for this doc to describe how tunnels interact > with fragmentation (per draft-ietf-intarea-tunnels), which seems to be > something I’ve noted several times before. I believe that Ron's already promised to add text on this ... Thanks, --David > -Original

Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

I support intarea WG adoption of this draft - a BCP in this space is highly appropriate and likely to be quite useful. Thanks, --David (as an individual, not as TSVWG chair) > -Original Message- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Wassim > Haddad > Sent:

Re: [Int-area] Which CRC to use to enhance payload integrity in GUE extensions

CRC-32c is the CRC that I referred to in my remarks at the microphone, including the existence of CPU instruction support. Thanks, --David > -Original Message- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of G Fairhurst > Sent: Monday, March 19, 2018 1:08 PM > To: G

[Int-area] Agenda bash request - GUE timing

I have a conflict with the first half of the intarea meeting in Prague on Thursday - as the TSV-ART reviewer of the GUE draft, it would be very helpful if the agenda could be bashed to put GUE in the second hour of the intarea meeting. I hope that's possible. Thanks, --David

[Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

This may be of interest to INT folks who are interested in tunnels and encapsulations. Comments by the WGLC deadline are encouraged, but comments after the deadline are ok, as they'd have to be dealt with anyway at IETF Last Call. Thanks, --David From: tsvwg On Behalf Of Black, David Sent

Re: [Int-area] [tsvwg] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

a "bug" ... Additional thoughts/comments? Thanks, --David > -Original Message- > From: Bob Briscoe > Sent: Saturday, July 27, 2019 6:01 AM > To: Jonathan Morton > Cc: Joe Touch; Black, David; int-area@ietf.org; tsvwg > Subject: Re: [tsvwg] [Int-area] 2nd TSVWG W

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

+1 (agreeing with Tom and Fred) on retaining this text: > >This document acknowledges that in some cases, packets must be > >fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels]. > >Therefore, this document makes no additional recommendations > >regarding IP-in-IP

Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

There may be a relatively contained early-adopter opportunity to try something in this area of IPv4 options – Deterministic Networking (DetNet – detnet WG) is using 6-tuple match (2 x IP address, L4 protocol [e.g., TCP, UDP], 2 x port, DSCP) to pick off traffic flows that go through the DetNet

Re: [Int-area] [tsvwg] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

Briscoe Sent: Monday, July 8, 2019 8:28 AM To: Joe Touch; Black, David Cc: int-area@ietf.org; tsvwg Subject: Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019 [EXTERNAL EMAIL] Joe, Following up my email to you in May quoted further down

Re: [Int-area] 2nd WGLC: draft-ietf-tsvwg-transport-encrypt-12, closes 16 March 2020

With correct version and date in Subject line this time ☹. Thanks, --David From: Black, David Sent: Friday, February 28, 2020 2:37 PM To: ts...@ietf.org Cc: IETF SAAG; int-area; Black, David Subject: 2nd WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 This email announces

[Int-area] 2nd WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

This email announces a 2nd TSVWG Working Group Last Call (WGLC) on: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols draft-ietf-tsvwg-transport-encrypt-12

Re: [Int-area] AD review of draft-ietf-intarea-gue

(evyncke) Sent: Monday, October 5, 2020 9:38 AM To: t...@herbertland.com; lucy_y...@yahoo.com; osa...@microsoft.com Cc: Suresh Krishnan; Erik Kline; fred.l.temp...@boeing.com; Wassim Haddad; Juan Carlos Zuniga; int-area; Black, David; Gorry Fairhurst Subject: AD review of draft-ietf-intarea-gue

[Int-area] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

This email announces a limited-scope 3rd TSVWG Working Group Last Call (WGLC) on: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols draft-ietf-tsvwg-transport-encrypt-15

[Int-area] draft-ietf-tsvwg-transport-encrypt-15: Conclusion of 3rd WGLC

This email reports the conclusion of the third (limited scope) WGLC on: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols draft-ietf-tsvwg-transport-encrypt-15

Re: [Int-area] Proxy function for PTB messages on the tunnel end

Hi Eduard, >>- links NEVER *generate* ICMPs >>- routers and hosts *generate* ICMPs > Why virtual link could not send ICMP PTB (like on a physical link)? The short answer (IMHO) is "yes, but the host or router generates the ICMP PTB." There's a subtle distinction here

Re: [Int-area] Proxy function for PTB messages on the tunnel end

Inline … Thanks, --David From: Vasilenko Eduard Sent: Thursday, March 25, 2021 5:52 AM To: Black, David; Joseph Touch Cc: v6...@ietf.org; int-area Subject: RE: Proxy function for PTB messages on the tunnel end [EXTERNAL EMAIL] Hi David, 1. Any real tunneling implementation does check