From nobody Thu May 5 09:23:28 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42812D708 for ; Thu, 5 May 2016 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pG5m0OQagHq for ; Thu, 5 May 2016 09:23:23 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C9E12B03E for ; Thu, 5 May 2016 09:22:45 -0700 (PDT) Received: from 113.27.199.146.dyn.plus.net ([146.199.27.113]:46457 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ayM30-0001FY-BC; Thu, 05 May 2016 17:22:43 +0100 To: "Black, David" , Spencer Dawkins at IETF References: <571E716A.6050609@isi.edu> <571E94F3.2090505@isi.edu> From: Bob Briscoe Message-ID: <572B7351.10901@bobbriscoe.net> Date: Thu, 5 May 2016 17:22:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090209080103030606010101" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "tsv-art@ietf.org" Subject: Re: [Tsv-art] Common TSV issues X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 16:23:26 -0000 This is a multi-part message in MIME format. --------------090209080103030606010101 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Folks, +1 re Joe's comment about reordering the list a bit after the deadline. Some bullet points that might prompt others to have ideas, written in haste - I'll try to generalise them and add more/better RFC refs when I add them to the wiki later - once I've finished what I'm meant to be doing: * Forward compatibility - for CU or Reserved fields/codepoints, ensure behaviour is defined if a field value is not as specified. * Path traversal of protocol updates - {detection of | resilience against| fallback from} middlebox interference, asymmetric interference, etc. RFC6824#section-6, other RFC(s)? - offload hardware * Units - byte vs pkt congestion rfc7141 - ? * Diffserv - codepoint scarcity - path traversal assumptions * propagation of transport-related fields on tunnel encap/decap (RFC2983, RFC6040) * Shared use of experimental option values [RFC6994] * Scarce (TCP) option space * Collisions / wrap of fields [RFC4963, RFC6864] * Design for low latency - optimistic negotiation, etc Bob On 29/04/16 19:13, Black, David wrote: > > I’ve added my relevant suggestions from this thread. > > Thanks, --David > > *From:*Joe Touch [mailto:touch@isi.edu] > *Sent:* Monday, April 25, 2016 6:07 PM > *To:* Spencer Dawkins at IETF; Black, David > *Cc:* touch@isi.edu; tsv-art@ietf.org > *Subject:* Re: [Tsv-art] Common TSV issues > > Also, it might be good to consider reorganzing the list into some sort > of taxonomy. I had a draft of this sort of thing I had been preparing > for TSV-AREA at one point. Let me know if it would be useful to dig out. > > Joe > > On 4/25/2016 12:35 PM, Joe Touch wrote: > > FWIW - I added a handful of things this AM... > > Joe > > On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote: > > Hi, David, > > On Mon, Apr 25, 2016 at 1:19 PM, Black, David > > wrote: > > Hi Spencer, > > Here are a few suggestions: > > -- Use of UDP > > I’d reference the rfc5405bis draft for which publication has > been requested in addition to RFC 5405, as it contains a lot > of added content (this should be “instead of RFC 5405” after > IESG approval of the bis draft). There are a lot of things in > this draft that could be called out e.g., reinvention of > congestion control is strongly discouraged. > > Thanks for the other suggestions, too, but 5405bis was so > obvious that I feel like a moron for not updating the > checklist to include it :-) > > Others? > > Spencer > > We now recognize “Controlled Environments” as restricted > deployment/applicability scenarios where general Internet > requirements (e.g., for congestion control) may be relaxed > under suitable (e.g., operator) control - see section 3.6 > of the rfc5405bis draft for discussion and RFC 7510 > (MPLS/UDP) for a worked example. > > Use of zero UDP checksums with IPv6 is subtle and requires > design attention - see RFC 6935 and 6936. Note that these > two RFCs contain design requirements, so it’s insufficient > to just normatively reference those two RFCs and impose > their requirements - an explanation of how the protocol > design (for zero UDP checksums with IPv6 meets those > requirements is needed). RFC 7510 is also a worked > example here, and its content on this topic is not short. > > -- PDU Sizes > > I’d add a discussion of PMTUD and PLPMTUD, including > noting that use of the latter needs to include an > explanation of how. Use of the former needs to be > cognizant of the general unreliability of ICMP Packet Too > Big notifications, especially when sent upstream from > within a tunnel (may not propagate across ingress). > > -- Multicast > > Many of the concerns may be exacerbated by multicast - > perhaps someone who spends more time on multicast than I > do could come up with a short list of things to watch out for. > > Thanks, --David > > *From:*Tsv-art [mailto:tsv-art-bounces@ietf.org > ] *On Behalf Of *Spencer > Dawkins at IETF > *Sent:* Monday, April 25, 2016 10:29 AM > *To:* tsv-art@ietf.org > *Subject:* [Tsv-art] Common TSV issues > > Dear TSV-ART, > > So, Mirja and I would like to let the community know what > common TSV issues the TSV-ART will be looking for, and > we'd like to get your feedback on the current issues list, > which is at > http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, > before we send that out. > > If you could take a look at the current TSV issues, list, > and let us know if you think changes are needed by May 9, > that would be great! > > Thanks, > > Spencer and Mirja > > > > > _______________________________________________ > > Tsv-art mailing list > > Tsv-art@ietf.org > > https://www.ietf.org/mailman/listinfo/tsv-art > > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------090209080103030606010101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

+1 re Joe's comment about reordering the list a bit after the deadline.

Some bullet points that might prompt others to have ideas, written in haste - I'll try to generalise them and add more/better RFC refs when I add them to the wiki later - once I've finished what I'm meant to be doing:
* Forward compatibility
  - for CU or Reserved fields/codepoints, ensure behaviour is defined if a field value is not as specified.
* Path traversal of protocol updates
  - {detection of | resilience against| fallback from} middlebox interference, asymmetric interference, etc. RFC6824#section-6, other RFC(s)?
  - offload hardware
* Units
  - byte vs pkt congestion rfc7141
  - ?
* Diffserv
  - codepoint scarcity
  - path traversal assumptions
* propagation of transport-related fields on tunnel encap/decap (RFC2983, RFC6040)
* Shared use of experimental option values [RFC6994]
* Scarce (TCP) option space
* Collisions / wrap of fields [RFC4963, RFC6864]
* Design for low latency
  - optimistic negotiation, etc



Bob

On 29/04/16 19:13, Black, David wrote:

I’ve added my relevant suggestions from this thread.

 

Thanks, --David

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Monday, April 25, 2016 6:07 PM
To: Spencer Dawkins at IETF; Black, David
Cc: touch@isi.edu; tsv-art@ietf.org
Subject: Re: [Tsv-art] Common TSV issues

 

Also, it might be good to consider reorganzing the list into some sort of taxonomy. I had a draft of this sort of thing I had been preparing for TSV-AREA at one point. Let me know if it would be useful to dig out.

Joe

On 4/25/2016 12:35 PM, Joe Touch wrote:

FWIW - I added a handful of things this AM...

Joe

On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote:

Hi, David,

 

On Mon, Apr 25, 2016 at 1:19 PM, Black, David <david.black@emc.com> wrote:

Hi Spencer,

 

Here are a few suggestions:

 

-- Use of UDP

 

I’d reference the rfc5405bis draft for which publication has been requested in addition to RFC 5405, as it contains a lot of added content (this should be “instead of RFC 5405” after IESG approval of the bis draft).  There are a lot of things in this draft that could be called out e.g., reinvention of congestion control is strongly discouraged.

 

Thanks for the other suggestions, too, but 5405bis was so obvious that I feel like a moron for not updating the checklist to include it :-)

 

Others?

 

Spencer

 

We now recognize “Controlled Environments” as restricted deployment/applicability scenarios where general Internet requirements (e.g., for congestion control) may be relaxed under suitable (e.g., operator) control - see section 3.6 of the rfc5405bis draft for discussion and RFC 7510 (MPLS/UDP) for a worked example.

 

Use of zero UDP checksums with IPv6 is subtle and requires design attention - see RFC 6935 and 6936.  Note that these two RFCs contain design requirements, so it’s insufficient to just normatively reference those two RFCs and impose their requirements - an explanation of how the protocol design (for zero UDP checksums with IPv6 meets those requirements is needed).  RFC 7510 is also a worked example here, and its content on this topic is not short.

 

-- PDU Sizes

 

I’d add a discussion of PMTUD and PLPMTUD, including noting that use of the latter needs to include an explanation of how.  Use of the former needs to be cognizant of the general unreliability of ICMP Packet Too Big notifications, especially when sent upstream from within a tunnel (may not propagate across ingress).

 

-- Multicast

 

Many of the concerns may be exacerbated by multicast - perhaps someone who spends more time on multicast than I do could come up with a short list of things to watch out for.

 

Thanks, --David

 

From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, April 25, 2016 10:29 AM
To: tsv-art@ietf.org
Subject: [Tsv-art] Common TSV issues

 

Dear TSV-ART,

 

So, Mirja and I would like to let the community know what common TSV issues the TSV-ART will be looking for, and we'd like to get your feedback on the current issues list, which is at http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, before we send that out.

 

If you could take a look at the current TSV issues, list, and let us know if you think changes are needed by May 9, that would be great!

 

Thanks,

 

Spencer and Mirja

 




_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

 

 



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------090209080103030606010101-- From nobody Thu May 5 14:56:05 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A212D147 for ; Thu, 5 May 2016 14:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oltQ68OkqJSF for ; Thu, 5 May 2016 14:56:01 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ECA12D13F for ; Thu, 5 May 2016 14:56:01 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u45LsjDZ027363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 May 2016 14:54:47 -0700 (PDT) To: Bob Briscoe , "Black, David" , Spencer Dawkins at IETF References: <571E716A.6050609@isi.edu> <571E94F3.2090505@isi.edu> <572B7351.10901@bobbriscoe.net> From: Joe Touch Message-ID: <572BC123.2030701@isi.edu> Date: Thu, 5 May 2016 14:54:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572B7351.10901@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------060405000801070204020202" X-MailScanner-ID: u45LsjDZ027363 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-art@ietf.org" Subject: Re: [Tsv-art] Common TSV issues X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:56:03 -0000 This is a multi-part message in MIME format. --------------060405000801070204020202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 5/5/2016 9:22 AM, Bob Briscoe wrote: > Folks, > > +1 re Joe's comment about reordering the list a bit after the deadline. > > Some bullet points that might prompt others to have ideas, written in > haste - I'll try to generalise them and add more/better RFC refs when > I add them to the wiki later - once I've finished what I'm meant to be > doing: > * Forward compatibility > - for CU or Reserved fields/codepoints, ensure behaviour is defined > if a field value is not as specified. Good point - these are relevant to all protocol designs: - all reserved fields need to have current behavior defined sender - set as a fixed value or set arbitrarily receiver - validate as a fixed value until otherwise defined or ignore i.e., truly reserved fields are "set arbitrarily, ignore on receipt" flags intended for back-compatible info are more frequently "set as 0, ignore on receipt" flags intended for non-back-compatible are "set as 0, validate as 0 on receipt" there are other variations > * Path traversal of protocol updates > - {detection of | resilience against| fallback from} middlebox > interference, asymmetric interference, etc. RFC6824#section-6, other > RFC(s)? > - offload hardware Interactions with offload processing > * Units > - byte vs pkt congestion rfc7141 > - ? > * Diffserv > - codepoint scarcity > - path traversal assumptions > * propagation of transport-related fields on tunnel encap/decap > (RFC2983, RFC6040) > * Shared use of experimental option values [RFC6994] > * Scarce (TCP) option space BCP165 (both docs) > * Collisions / wrap of fields [RFC4963, RFC6864] > * Design for low latency > - optimistic negotiation, etc > > > > Bob > > On 29/04/16 19:13, Black, David wrote: >> >> Ive added my relevant suggestions from this thread. >> >> >> >> Thanks, --David >> >> >> >> *From:*Joe Touch [mailto:touch@isi.edu] >> *Sent:* Monday, April 25, 2016 6:07 PM >> *To:* Spencer Dawkins at IETF; Black, David >> *Cc:* touch@isi.edu; tsv-art@ietf.org >> *Subject:* Re: [Tsv-art] Common TSV issues >> >> >> >> Also, it might be good to consider reorganzing the list into some >> sort of taxonomy. I had a draft of this sort of thing I had been >> preparing for TSV-AREA at one point. Let me know if it would be >> useful to dig out. >> >> Joe >> >> On 4/25/2016 12:35 PM, Joe Touch wrote: >> >> FWIW - I added a handful of things this AM... >> >> Joe >> >> On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote: >> >> Hi, David, >> >> >> >> On Mon, Apr 25, 2016 at 1:19 PM, Black, David >> > wrote: >> >> Hi Spencer, >> >> >> >> Here are a few suggestions: >> >> >> >> -- Use of UDP >> >> >> >> Id reference the rfc5405bis draft for which publication has >> been requested in addition to RFC 5405, as it contains a lot >> of added content (this should be instead of RFC 5405 after >> IESG approval of the bis draft). There are a lot of things >> in this draft that could be called out e.g., reinvention of >> congestion control is strongly discouraged. >> >> >> >> Thanks for the other suggestions, too, but 5405bis was so >> obvious that I feel like a moron for not updating the >> checklist to include it :-) >> >> >> >> Others? >> >> >> >> Spencer >> >> >> >> We now recognize Controlled Environments as restricted >> deployment/applicability scenarios where general Internet >> requirements (e.g., for congestion control) may be >> relaxed under suitable (e.g., operator) control - see >> section 3.6 of the rfc5405bis draft for discussion and >> RFC 7510 (MPLS/UDP) for a worked example. >> >> >> >> Use of zero UDP checksums with IPv6 is subtle and >> requires design attention - see RFC 6935 and 6936. Note >> that these two RFCs contain design requirements, so its >> insufficient to just normatively reference those two RFCs >> and impose their requirements - an explanation of how the >> protocol design (for zero UDP checksums with IPv6 meets >> those requirements is needed). RFC 7510 is also a worked >> example here, and its content on this topic is not short. >> >> >> >> -- PDU Sizes >> >> >> >> Id add a discussion of PMTUD and PLPMTUD, including >> noting that use of the latter needs to include an >> explanation of how. Use of the former needs to be >> cognizant of the general unreliability of ICMP Packet Too >> Big notifications, especially when sent upstream from >> within a tunnel (may not propagate across ingress). >> >> >> >> -- Multicast >> >> >> >> Many of the concerns may be exacerbated by multicast - >> perhaps someone who spends more time on multicast than I >> do could come up with a short list of things to watch out >> for. >> >> >> >> Thanks, --David >> >> >> >> *From:*Tsv-art [mailto:tsv-art-bounces@ietf.org] *On >> Behalf Of *Spencer Dawkins at IETF >> *Sent:* Monday, April 25, 2016 10:29 AM >> *To:* tsv-art@ietf.org >> *Subject:* [Tsv-art] Common TSV issues >> >> >> >> Dear TSV-ART, >> >> >> >> So, Mirja and I would like to let the community know what >> common TSV issues the TSV-ART will be looking for, and >> we'd like to get your feedback on the current issues >> list, which is >> at http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, >> before we send that out. >> >> >> >> If you could take a look at the current TSV issues, list, >> and let us know if you think changes are needed by May 9, >> that would be great! >> >> >> >> Thanks, >> >> >> >> Spencer and Mirja >> >> >> >> >> >> >> _______________________________________________ >> >> Tsv-art mailing list >> >> Tsv-art@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tsv-art >> >> >> >> >> >> >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > This body part will be downloaded on demand. --------------060405000801070204020202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 5/5/2016 9:22 AM, Bob Briscoe wrote:
Folks,

+1 re Joe's comment about reordering the list a bit after the deadline.

Some bullet points that might prompt others to have ideas, written in haste - I'll try to generalise them and add more/better RFC refs when I add them to the wiki later - once I've finished what I'm meant to be doing:
* Forward compatibility
- for CU or Reserved fields/codepoints, ensure behaviour is defined if a field value is not as specified.

Good point - these are relevant to all protocol designs:

- all reserved fields need to have current behavior defined
sender - set as a fixed value or set arbitrarily
receiver - validate as a fixed value until otherwise defined or ignore

i.e., truly reserved fields are "set arbitrarily, ignore on receipt"
flags intended for back-compatible info are more frequently "set as 0, ignore on receipt"
flags intended for non-back-compatible are "set as 0, validate as 0 on receipt"
there are other variations

* Path traversal of protocol updates
- {detection of | resilience against| fallback from} middlebox interference, asymmetric interference, etc. RFC6824#section-6, other RFC(s)?
- offload hardware

Interactions with offload processing

* Units
- byte vs pkt congestion rfc7141
- ?
* Diffserv
- codepoint scarcity
- path traversal assumptions
* propagation of transport-related fields on tunnel encap/decap (RFC2983, RFC6040)
* Shared use of experimental option values [RFC6994]
* Scarce (TCP) option space

BCP165 (both docs)

* Collisions / wrap of fields [RFC4963, RFC6864]
* Design for low latency
- optimistic negotiation, etc



Bob

On 29/04/16 19:13, Black, David wrote:

Ive added my relevant suggestions from this thread.

Thanks, --David

From: Joe Touch [mailto:touch@isi.edu]
Sent: Monday, April 25, 2016 6:07 PM
To: Spencer Dawkins at IETF; Black, David
Cc: touch@isi.edu; tsv-art@ietf.org
Subject: Re: [Tsv-art] Common TSV issues

Also, it might be good to consider reorganzing the list into some sort of taxonomy. I had a draft of this sort of thing I had been preparing for TSV-AREA at one point. Let me know if it would be useful to dig out.

Joe

On 4/25/2016 12:35 PM, Joe Touch wrote:

FWIW - I added a handful of things this AM...

Joe

On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote:

Hi, David,

On Mon, Apr 25, 2016 at 1:19 PM, Black, David <david.black@emc.com> wrote:

Hi Spencer,

Here are a few suggestions:

-- Use of UDP

Id reference the rfc5405bis draft for which publication has been requested in addition to RFC 5405, as it contains a lot of added content (this should be instead of RFC 5405 after IESG approval of the bis draft). There are a lot of things in this draft that could be called out e.g., reinvention of congestion control is strongly discouraged.

Thanks for the other suggestions, too, but 5405bis was so obvious that I feel like a moron for not updating the checklist to include it :-)

Others?

Spencer

We now recognize Controlled Environments as restricted deployment/applicability scenarios where general Internet requirements (e.g., for congestion control) may be relaxed under suitable (e.g., operator) control - see section 3.6 of the rfc5405bis draft for discussion and RFC 7510 (MPLS/UDP) for a worked example.

Use of zero UDP checksums with IPv6 is subtle and requires design attention - see RFC 6935 and 6936. Note that these two RFCs contain design requirements, so its insufficient to just normatively reference those two RFCs and impose their requirements - an explanation of how the protocol design (for zero UDP checksums with IPv6 meets those requirements is needed). RFC 7510 is also a worked example here, and its content on this topic is not short.

-- PDU Sizes

Id add a discussion of PMTUD and PLPMTUD, including noting that use of the latter needs to include an explanation of how. Use of the former needs to be cognizant of the general unreliability of ICMP Packet Too Big notifications, especially when sent upstream from within a tunnel (may not propagate across ingress).

-- Multicast

Many of the concerns may be exacerbated by multicast - perhaps someone who spends more time on multicast than I do could come up with a short list of things to watch out for.

Thanks, --David

From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, April 25, 2016 10:29 AM
To: tsv-art@ietf.org
Subject: [Tsv-art] Common TSV issues

Dear TSV-ART,

So, Mirja and I would like to let the community know what common TSV issues the TSV-ART will be looking for, and we'd like to get your feedback on the current issues list, which is athttp://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, before we send that out.

If you could take a look at the current TSV issues, list, and let us know if you think changes are needed by May 9, that would be great!

Thanks,

Spencer and Mirja




_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


This body part will be downloaded on demand.

--------------060405000801070204020202-- From nobody Fri May 6 03:06:17 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A0B12B00D for ; Fri, 6 May 2016 03:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOhGgoTsojF6 for ; Fri, 6 May 2016 03:06:08 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1130E12D943 for ; Fri, 6 May 2016 03:06:06 -0700 (PDT) Received: from 113.27.199.146.dyn.plus.net ([146.199.27.113]:36907 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ayce3-0007nI-Sl; Fri, 06 May 2016 11:06:04 +0100 To: Joe Touch , "Black, David" , Spencer Dawkins at IETF References: <571E716A.6050609@isi.edu> <571E94F3.2090505@isi.edu> <572B7351.10901@bobbriscoe.net> <572BC123.2030701@isi.edu> From: Bob Briscoe Message-ID: <572C6C8B.3070805@bobbriscoe.net> Date: Fri, 6 May 2016 11:06:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572BC123.2030701@isi.edu> Content-Type: multipart/alternative; boundary="------------060605030900090400040203" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "tsv-art@ietf.org" Subject: Re: [Tsv-art] Common TSV issues X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 10:06:16 -0000 This is a multi-part message in MIME format. --------------060605030900090400040203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Joe, one addition inline... On 05/05/16 22:54, Joe Touch wrote: > > > On 5/5/2016 9:22 AM, Bob Briscoe wrote: >> Folks, >> >> +1 re Joe's comment about reordering the list a bit after the deadline. >> >> Some bullet points that might prompt others to have ideas, written in >> haste - I'll try to generalise them and add more/better RFC refs when >> I add them to the wiki later - once I've finished what I'm meant to >> be doing: >> * Forward compatibility >> - for CU or Reserved fields/codepoints, ensure behaviour is defined >> if a field value is not as specified. > > Good point - these are relevant to all protocol designs: > > - all reserved fields need to have current behavior defined > sender - set as a fixed value or set arbitrarily > receiver - validate as a fixed value until otherwise defined or ignore > > i.e., truly reserved fields are "set arbitrarily, ignore on receipt" > flags intended for back-compatible info are more frequently "set as 0, > ignore on receipt" > flags intended for non-back-compatible are "set as 0, validate as 0 on > receipt" ...and for all: "ignore (i.e. do not 'correct') when forwarding" Bob > there are other variations > >> * Path traversal of protocol updates >> - {detection of | resilience against| fallback from} middlebox >> interference, asymmetric interference, etc. RFC6824#section-6, other >> RFC(s)? >> - offload hardware > > Interactions with offload processing > >> * Units >> - byte vs pkt congestion rfc7141 >> - ? >> * Diffserv >> - codepoint scarcity >> - path traversal assumptions >> * propagation of transport-related fields on tunnel encap/decap >> (RFC2983, RFC6040) >> * Shared use of experimental option values [RFC6994] >> * Scarce (TCP) option space > > BCP165 (both docs) > >> * Collisions / wrap of fields [RFC4963, RFC6864] >> * Design for low latency >> - optimistic negotiation, etc >> >> >> >> Bob >> >> On 29/04/16 19:13, Black, David wrote: >>> >>> I’ve added my relevant suggestions from this thread. >>> >>> Thanks, --David >>> >>> *From:*Joe Touch [mailto:touch@isi.edu] >>> *Sent:* Monday, April 25, 2016 6:07 PM >>> *To:* Spencer Dawkins at IETF; Black, David >>> *Cc:* touch@isi.edu; tsv-art@ietf.org >>> *Subject:* Re: [Tsv-art] Common TSV issues >>> >>> Also, it might be good to consider reorganzing the list into some >>> sort of taxonomy. I had a draft of this sort of thing I had been >>> preparing for TSV-AREA at one point. Let me know if it would be >>> useful to dig out. >>> >>> Joe >>> >>> On 4/25/2016 12:35 PM, Joe Touch wrote: >>> >>> FWIW - I added a handful of things this AM... >>> >>> Joe >>> >>> On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote: >>> >>> Hi, David, >>> >>> On Mon, Apr 25, 2016 at 1:19 PM, Black, David >>> > wrote: >>> >>> Hi Spencer, >>> >>> Here are a few suggestions: >>> >>> -- Use of UDP >>> >>> I’d reference the rfc5405bis draft for which publication has >>> been requested in addition to RFC 5405, as it contains a lot >>> of added content (this should be “instead of RFC 5405” after >>> IESG approval of the bis draft). There are a lot of things >>> in this draft that could be called out e.g., reinvention of >>> congestion control is strongly discouraged. >>> >>> Thanks for the other suggestions, too, but 5405bis was so >>> obvious that I feel like a moron for not updating the >>> checklist to include it :-) >>> >>> Others? >>> >>> Spencer >>> >>> We now recognize “Controlled Environments” as restricted >>> deployment/applicability scenarios where general >>> Internet requirements (e.g., for congestion control) may >>> be relaxed under suitable (e.g., operator) control - see >>> section 3.6 of the rfc5405bis draft for discussion and >>> RFC 7510 (MPLS/UDP) for a worked example. >>> >>> Use of zero UDP checksums with IPv6 is subtle and >>> requires design attention - see RFC 6935 and 6936. Note >>> that these two RFCs contain design requirements, so it’s >>> insufficient to just normatively reference those two >>> RFCs and impose their requirements - an explanation of >>> how the protocol design (for zero UDP checksums with >>> IPv6 meets those requirements is needed). RFC 7510 is >>> also a worked example here, and its content on this >>> topic is not short. >>> >>> -- PDU Sizes >>> >>> I’d add a discussion of PMTUD and PLPMTUD, including >>> noting that use of the latter needs to include an >>> explanation of how. Use of the former needs to be >>> cognizant of the general unreliability of ICMP Packet >>> Too Big notifications, especially when sent upstream >>> from within a tunnel (may not propagate across ingress). >>> >>> -- Multicast >>> >>> Many of the concerns may be exacerbated by multicast - >>> perhaps someone who spends more time on multicast than I >>> do could come up with a short list of things to watch >>> out for. >>> >>> Thanks, --David >>> >>> *From:*Tsv-art [mailto:tsv-art-bounces@ietf.org] *On >>> Behalf Of *Spencer Dawkins at IETF >>> *Sent:* Monday, April 25, 2016 10:29 AM >>> *To:* tsv-art@ietf.org >>> *Subject:* [Tsv-art] Common TSV issues >>> >>> Dear TSV-ART, >>> >>> So, Mirja and I would like to let the community know >>> what common TSV issues the TSV-ART will be looking for, >>> and we'd like to get your feedback on the current issues >>> list, which is at >>> http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, >>> before we send that out. >>> >>> If you could take a look at the current TSV issues, >>> list, and let us know if you think changes are needed by >>> May 9, that would be great! >>> >>> Thanks, >>> >>> Spencer and Mirja >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Tsv-art mailing list >>> >>> Tsv-art@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/tsv-art >>> >>> >>> >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> >> This body part will be downloaded on demand. > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------060605030900090400040203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Joe, one addition inline...

On 05/05/16 22:54, Joe Touch wrote:


On 5/5/2016 9:22 AM, Bob Briscoe wrote:
Folks,

+1 re Joe's comment about reordering the list a bit after the deadline.

Some bullet points that might prompt others to have ideas, written in haste - I'll try to generalise them and add more/better RFC refs when I add them to the wiki later - once I've finished what I'm meant to be doing:
* Forward compatibility
  - for CU or Reserved fields/codepoints, ensure behaviour is defined if a field value is not as specified.

Good point - these are relevant to all protocol designs:

- all reserved fields need to have current behavior defined
    sender - set as a fixed value or set arbitrarily
    receiver - validate as a fixed value until otherwise defined or ignore

i.e., truly reserved fields are "set arbitrarily, ignore on receipt"
flags intended for back-compatible info are more frequently "set as 0, ignore on receipt"
flags intended for non-back-compatible are "set as 0, validate as 0 on receipt"
...and for all: "ignore (i.e. do not 'correct') when forwarding"


Bob
there are other variations

* Path traversal of protocol updates
  - {detection of | resilience against| fallback from} middlebox interference, asymmetric interference, etc. RFC6824#section-6, other RFC(s)?
  - offload hardware

Interactions with offload processing

* Units
  - byte vs pkt congestion rfc7141
  - ?
* Diffserv
  - codepoint scarcity
  - path traversal assumptions
* propagation of transport-related fields on tunnel encap/decap (RFC2983, RFC6040)
* Shared use of experimental option values [RFC6994]
* Scarce (TCP) option space

BCP165 (both docs)

* Collisions / wrap of fields [RFC4963, RFC6864]
* Design for low latency
  - optimistic negotiation, etc



Bob

On 29/04/16 19:13, Black, David wrote:

I’ve added my relevant suggestions from this thread.

 

Thanks, --David

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Monday, April 25, 2016 6:07 PM
To: Spencer Dawkins at IETF; Black, David
Cc: touch@isi.edu; tsv-art@ietf.org
Subject: Re: [Tsv-art] Common TSV issues

 

Also, it might be good to consider reorganzing the list into some sort of taxonomy. I had a draft of this sort of thing I had been preparing for TSV-AREA at one point. Let me know if it would be useful to dig out.

Joe

On 4/25/2016 12:35 PM, Joe Touch wrote:

FWIW - I added a handful of things this AM...

Joe

On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote:

Hi, David,

 

On Mon, Apr 25, 2016 at 1:19 PM, Black, David <david.black@emc.com> wrote:

Hi Spencer,

 

Here are a few suggestions:

 

-- Use of UDP

 

I’d reference the rfc5405bis draft for which publication has been requested in addition to RFC 5405, as it contains a lot of added content (this should be “instead of RFC 5405” after IESG approval of the bis draft).  There are a lot of things in this draft that could be called out e.g., reinvention of congestion control is strongly discouraged.

 

Thanks for the other suggestions, too, but 5405bis was so obvious that I feel like a moron for not updating the checklist to include it :-)

 

Others?

 

Spencer

 

We now recognize “Controlled Environments” as restricted deployment/applicability scenarios where general Internet requirements (e.g., for congestion control) may be relaxed under suitable (e.g., operator) control - see section 3.6 of the rfc5405bis draft for discussion and RFC 7510 (MPLS/UDP) for a worked example.

 

Use of zero UDP checksums with IPv6 is subtle and requires design attention - see RFC 6935 and 6936.  Note that these two RFCs contain design requirements, so it’s insufficient to just normatively reference those two RFCs and impose their requirements - an explanation of how the protocol design (for zero UDP checksums with IPv6 meets those requirements is needed).  RFC 7510 is also a worked example here, and its content on this topic is not short.

 

-- PDU Sizes

 

I’d add a discussion of PMTUD and PLPMTUD, including noting that use of the latter needs to include an explanation of how.  Use of the former needs to be cognizant of the general unreliability of ICMP Packet Too Big notifications, especially when sent upstream from within a tunnel (may not propagate across ingress).

 

-- Multicast

 

Many of the concerns may be exacerbated by multicast - perhaps someone who spends more time on multicast than I do could come up with a short list of things to watch out for.

 

Thanks, --David

 

From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, April 25, 2016 10:29 AM
To: tsv-art@ietf.org
Subject: [Tsv-art] Common TSV issues

 

Dear TSV-ART,

 

So, Mirja and I would like to let the community know what common TSV issues the TSV-ART will be looking for, and we'd like to get your feedback on the current issues list, which is at http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, before we send that out.

 

If you could take a look at the current TSV issues, list, and let us know if you think changes are needed by May 9, that would be great!

 

Thanks,

 

Spencer and Mirja

 




_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

 

 



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


This body part will be downloaded on demand.


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------060605030900090400040203-- From nobody Fri May 6 10:38:00 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDF912D666 for ; Fri, 6 May 2016 10:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.885 X-Spam-Level: X-Spam-Status: No, score=-7.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woprYHz6STg3 for ; Fri, 6 May 2016 10:37:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDE712D6A1 for ; Fri, 6 May 2016 10:37:56 -0700 (PDT) Received: from [128.9.184.143] ([128.9.184.143]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u46Haj3I023459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 May 2016 10:36:46 -0700 (PDT) To: Bob Briscoe , "Black, David" , Spencer Dawkins at IETF References: <571E716A.6050609@isi.edu> <571E94F3.2090505@isi.edu> <572B7351.10901@bobbriscoe.net> <572BC123.2030701@isi.edu> <572C6C8B.3070805@bobbriscoe.net> From: Joe Touch Message-ID: <572CD62C.3030008@isi.edu> Date: Fri, 6 May 2016 10:36:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572C6C8B.3070805@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------000300050109030909080209" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-art@ietf.org" Subject: Re: [Tsv-art] Common TSV issues X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 17:37:59 -0000 This is a multi-part message in MIME format. --------------000300050109030909080209 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Agreed -- I would be very happy if we tracked and pushed back on both levels: a) transport info must not me modified except by the endpoints b) transport info should not be examined except by the endpoints or their designated agents (the latter allows for stateful port demux at an enterprise ingress or port filtering there, but warns against doing that in the core) Joe On 5/6/2016 3:06 AM, Bob Briscoe wrote: > Joe, one addition inline... > > On 05/05/16 22:54, Joe Touch wrote: >> >> >> On 5/5/2016 9:22 AM, Bob Briscoe wrote: >>> Folks, >>> >>> +1 re Joe's comment about reordering the list a bit after the deadline. >>> >>> Some bullet points that might prompt others to have ideas, written >>> in haste - I'll try to generalise them and add more/better RFC refs >>> when I add them to the wiki later - once I've finished what I'm >>> meant to be doing: >>> * Forward compatibility >>> - for CU or Reserved fields/codepoints, ensure behaviour is >>> defined if a field value is not as specified. >> >> Good point - these are relevant to all protocol designs: >> >> - all reserved fields need to have current behavior defined >> sender - set as a fixed value or set arbitrarily >> receiver - validate as a fixed value until otherwise defined or >> ignore >> >> i.e., truly reserved fields are "set arbitrarily, ignore on receipt" >> flags intended for back-compatible info are more frequently "set as >> 0, ignore on receipt" >> flags intended for non-back-compatible are "set as 0, validate as 0 >> on receipt" > ...and for all: "ignore (i.e. do not 'correct') when forwarding" > > > Bob >> there are other variations >> >>> * Path traversal of protocol updates >>> - {detection of | resilience against| fallback from} middlebox >>> interference, asymmetric interference, etc. RFC6824#section-6, other >>> RFC(s)? >>> - offload hardware >> >> Interactions with offload processing >> >>> * Units >>> - byte vs pkt congestion rfc7141 >>> - ? >>> * Diffserv >>> - codepoint scarcity >>> - path traversal assumptions >>> * propagation of transport-related fields on tunnel encap/decap >>> (RFC2983, RFC6040) >>> * Shared use of experimental option values [RFC6994] >>> * Scarce (TCP) option space >> >> BCP165 (both docs) >> >>> * Collisions / wrap of fields [RFC4963, RFC6864] >>> * Design for low latency >>> - optimistic negotiation, etc >>> >>> >>> >>> Bob >>> >>> On 29/04/16 19:13, Black, David wrote: >>>> >>>> I’ve added my relevant suggestions from this thread. >>>> >>>> >>>> >>>> Thanks, --David >>>> >>>> >>>> >>>> *From:*Joe Touch [mailto:touch@isi.edu] >>>> *Sent:* Monday, April 25, 2016 6:07 PM >>>> *To:* Spencer Dawkins at IETF; Black, David >>>> *Cc:* touch@isi.edu; tsv-art@ietf.org >>>> *Subject:* Re: [Tsv-art] Common TSV issues >>>> >>>> >>>> >>>> Also, it might be good to consider reorganzing the list into some >>>> sort of taxonomy. I had a draft of this sort of thing I had been >>>> preparing for TSV-AREA at one point. Let me know if it would be >>>> useful to dig out. >>>> >>>> Joe >>>> >>>> On 4/25/2016 12:35 PM, Joe Touch wrote: >>>> >>>> FWIW - I added a handful of things this AM... >>>> >>>> Joe >>>> >>>> On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote: >>>> >>>> Hi, David, >>>> >>>> >>>> >>>> On Mon, Apr 25, 2016 at 1:19 PM, Black, David >>>> wrote: >>>> >>>> Hi Spencer, >>>> >>>> >>>> >>>> Here are a few suggestions: >>>> >>>> >>>> >>>> -- Use of UDP >>>> >>>> >>>> >>>> I’d reference the rfc5405bis draft for which publication >>>> has been requested in addition to RFC 5405, as it contains >>>> a lot of added content (this should be “instead of RFC >>>> 5405” after IESG approval of the bis draft). There are a >>>> lot of things in this draft that could be called out e.g., >>>> reinvention of congestion control is strongly discouraged. >>>> >>>> >>>> >>>> Thanks for the other suggestions, too, but 5405bis was so >>>> obvious that I feel like a moron for not updating the >>>> checklist to include it :-) >>>> >>>> >>>> >>>> Others? >>>> >>>> >>>> >>>> Spencer >>>> >>>> >>>> >>>> We now recognize “Controlled Environments” as >>>> restricted deployment/applicability scenarios where >>>> general Internet requirements (e.g., for congestion >>>> control) may be relaxed under suitable (e.g., operator) >>>> control - see section 3.6 of the rfc5405bis draft for >>>> discussion and RFC 7510 (MPLS/UDP) for a worked example. >>>> >>>> >>>> >>>> Use of zero UDP checksums with IPv6 is subtle and >>>> requires design attention - see RFC 6935 and 6936. >>>> Note that these two RFCs contain design requirements, >>>> so it’s insufficient to just normatively reference >>>> those two RFCs and impose their requirements - an >>>> explanation of how the protocol design (for zero UDP >>>> checksums with IPv6 meets those requirements is >>>> needed). RFC 7510 is also a worked example here, and >>>> its content on this topic is not short. >>>> >>>> >>>> >>>> -- PDU Sizes >>>> >>>> >>>> >>>> I’d add a discussion of PMTUD and PLPMTUD, including >>>> noting that use of the latter needs to include an >>>> explanation of how. Use of the former needs to be >>>> cognizant of the general unreliability of ICMP Packet >>>> Too Big notifications, especially when sent upstream >>>> from within a tunnel (may not propagate across ingress). >>>> >>>> >>>> >>>> -- Multicast >>>> >>>> >>>> >>>> Many of the concerns may be exacerbated by multicast - >>>> perhaps someone who spends more time on multicast than >>>> I do could come up with a short list of things to watch >>>> out for. >>>> >>>> >>>> >>>> Thanks, --David >>>> >>>> >>>> >>>> *From:*Tsv-art [mailto:tsv-art-bounces@ietf.org] *On >>>> Behalf Of *Spencer Dawkins at IETF >>>> *Sent:* Monday, April 25, 2016 10:29 AM >>>> *To:* tsv-art@ietf.org >>>> *Subject:* [Tsv-art] Common TSV issues >>>> >>>> >>>> >>>> Dear TSV-ART, >>>> >>>> >>>> >>>> So, Mirja and I would like to let the community know >>>> what common TSV issues the TSV-ART will be looking for, >>>> and we'd like to get your feedback on the current >>>> issues list, which is >>>> at http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, >>>> before we send that out. >>>> >>>> >>>> >>>> If you could take a look at the current TSV issues, >>>> list, and let us know if you think changes are needed >>>> by May 9, that would be great! >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Spencer and Mirja >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Tsv-art mailing list >>>> >>>> Tsv-art@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/tsv-art >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Tsv-art mailing list >>>> Tsv-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tsv-art >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>> >>> >>> This body part will be downloaded on demand. >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------000300050109030909080209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Agreed  -- I would be very happy if we tracked and pushed back on both levels:

a) transport info must not me modified except by the endpoints

b) transport info should not be examined except by the endpoints or their designated agents
(the latter allows for stateful port demux at an enterprise ingress or port filtering there, but warns against doing that in the core)

Joe

On 5/6/2016 3:06 AM, Bob Briscoe wrote:
Joe, one addition inline...

On 05/05/16 22:54, Joe Touch wrote:


On 5/5/2016 9:22 AM, Bob Briscoe wrote:
Folks,

+1 re Joe's comment about reordering the list a bit after the deadline.

Some bullet points that might prompt others to have ideas, written in haste - I'll try to generalise them and add more/better RFC refs when I add them to the wiki later - once I've finished what I'm meant to be doing:
* Forward compatibility
  - for CU or Reserved fields/codepoints, ensure behaviour is defined if a field value is not as specified.

Good point - these are relevant to all protocol designs:

- all reserved fields need to have current behavior defined
    sender - set as a fixed value or set arbitrarily
    receiver - validate as a fixed value until otherwise defined or ignore

i.e., truly reserved fields are "set arbitrarily, ignore on receipt"
flags intended for back-compatible info are more frequently "set as 0, ignore on receipt"
flags intended for non-back-compatible are "set as 0, validate as 0 on receipt"
...and for all: "ignore (i.e. do not 'correct') when forwarding"


Bob
there are other variations

* Path traversal of protocol updates
  - {detection of | resilience against| fallback from} middlebox interference, asymmetric interference, etc. RFC6824#section-6, other RFC(s)?
  - offload hardware

Interactions with offload processing

* Units
  - byte vs pkt congestion rfc7141
  - ?
* Diffserv
  - codepoint scarcity
  - path traversal assumptions
* propagation of transport-related fields on tunnel encap/decap (RFC2983, RFC6040)
* Shared use of experimental option values [RFC6994]
* Scarce (TCP) option space

BCP165 (both docs)

* Collisions / wrap of fields [RFC4963, RFC6864]
* Design for low latency
  - optimistic negotiation, etc



Bob

On 29/04/16 19:13, Black, David wrote:

I’ve added my relevant suggestions from this thread.

 

Thanks, --David

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Monday, April 25, 2016 6:07 PM
To: Spencer Dawkins at IETF; Black, David
Cc: touch@isi.edu; tsv-art@ietf.org
Subject: Re: [Tsv-art] Common TSV issues

 

Also, it might be good to consider reorganzing the list into some sort of taxonomy. I had a draft of this sort of thing I had been preparing for TSV-AREA at one point. Let me know if it would be useful to dig out.

Joe

On 4/25/2016 12:35 PM, Joe Touch wrote:

FWIW - I added a handful of things this AM...

Joe

On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote:

Hi, David,

 

On Mon, Apr 25, 2016 at 1:19 PM, Black, David <david.black@emc.com> wrote:

Hi Spencer,

 

Here are a few suggestions:

 

-- Use of UDP

 

I’d reference the rfc5405bis draft for which publication has been requested in addition to RFC 5405, as it contains a lot of added content (this should be “instead of RFC 5405” after IESG approval of the bis draft).  There are a lot of things in this draft that could be called out e.g., reinvention of congestion control is strongly discouraged.

 

Thanks for the other suggestions, too, but 5405bis was so obvious that I feel like a moron for not updating the checklist to include it :-)

 

Others?

 

Spencer

 

We now recognize “Controlled Environments” as restricted deployment/applicability scenarios where general Internet requirements (e.g., for congestion control) may be relaxed under suitable (e.g., operator) control - see section 3.6 of the rfc5405bis draft for discussion and RFC 7510 (MPLS/UDP) for a worked example.

 

Use of zero UDP checksums with IPv6 is subtle and requires design attention - see RFC 6935 and 6936.  Note that these two RFCs contain design requirements, so it’s insufficient to just normatively reference those two RFCs and impose their requirements - an explanation of how the protocol design (for zero UDP checksums with IPv6 meets those requirements is needed).  RFC 7510 is also a worked example here, and its content on this topic is not short.

 

-- PDU Sizes

 

I’d add a discussion of PMTUD and PLPMTUD, including noting that use of the latter needs to include an explanation of how.  Use of the former needs to be cognizant of the general unreliability of ICMP Packet Too Big notifications, especially when sent upstream from within a tunnel (may not propagate across ingress).

 

-- Multicast

 

Many of the concerns may be exacerbated by multicast - perhaps someone who spends more time on multicast than I do could come up with a short list of things to watch out for.

 

Thanks, --David

 

From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, April 25, 2016 10:29 AM
To: tsv-art@ietf.org
Subject: [Tsv-art] Common TSV issues

 

Dear TSV-ART,

 

So, Mirja and I would like to let the community know what common TSV issues the TSV-ART will be looking for, and we'd like to get your feedback on the current issues list, which is at http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues, before we send that out.

 

If you could take a look at the current TSV issues, list, and let us know if you think changes are needed by May 9, that would be great!

 

Thanks,

 

Spencer and Mirja

 




_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

 

 



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


This body part will be downloaded on demand.


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

--------------000300050109030909080209--