From nobody Wed May 3 10:51:37 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355FF129BCC for ; Wed, 3 May 2017 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 WId_TsPWe0jg for ; Wed, 3 May 2017 10:51:34 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 88D09129BF3 for ; Wed, 3 May 2017 10:48:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v43Hmwu6036692; Wed, 3 May 2017 10:48:59 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v43Hml3Z036445 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 3 May 2017 10:48:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 10:48:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 3 May 2017 10:48:47 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKA= Date: Wed, 3 May 2017 17:48:46 +0000 Message-ID: <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> In-Reply-To: <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:51:36 -0000 Hi Joe, Sorry for the extended delay - see below for responses: Thanks - Fred > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, March 29, 2017 3:06 PM > To: Templin, Fred L > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >=20 > Hi, Fred, >=20 > I think we're agreed except for PMTUD and PLMTUD. See below about the > latter (AFAICT, if it black holes, then the PLMTUD would detect a > failure to make forward progress). Black-holing in PMTUD is known and > not something this (or any other doc) is fixing, but also a known standar= d. >=20 > Joe >=20 >=20 > On 3/29/2017 2:18 PM, Templin, Fred L wrote: > > ... > >>> 10) Section 4.2.1, bulleted list toward bottom of section, tunnel > >>> "atom" is a very strange word to me. Tunnel "cell"? > >> The concept of an atomic packet was defined in RFC 6864. This is deriv= ed > >> from that. Cell would be introducing a new term, one that is overloade= d > >> with ATM, which we want to avoid. > > OK, but then please find a way to call it an "atomic packet". >=20 > Agreed. OK. > > ... > >>> 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU > >>> probing cannot be used by tunnels due to ECMP because the probe > >>> packets may take a different path than the data packets. That > >>> is why AERO no longer uses RFC4821 probing. > >> Regarding ECMP issues, I think we need to wrap this issue up. Here's > >> what I propose: > >> > >> - point out that ECMP causes problems with PMTUD (and can cause proble= ms > >> with PLMTUD). > >> - an interface has two choices: > >> - keep track of PMTU based on other packet context (flowID or next > >> header info) > >> - merge PMTU feedback, taking the MIN of reported values > > The problem is that some paths in the multipath may fail to deliver > > the ICMPs. So there is no way to know whether the MIN has been > > determined. >=20 > That's no different from the multicast case, though. In terms of PMTUD, you are right that in a certain sense unicast destinatio= ns with ECMP are like multicast. In other words, a single destination with mul= tiple paths - some of which may not deliver ICMPs. But (unlike unicast) the Internet community seems to be OK with the fact that some multicast group members might not receive multicasts due to an MTU black hole. For unicast destinations, it can be a real problem if there is an MTU black hole along one or more paths of the multipath.=20 > > Also the ingress may be handling transit packets sourced > > by a very large number of original sources each of which produce > > a very large number of distinct flows. So, there is no way for the > > ingress to cache all of the flow information it handles. > Min requires maintaining the same information as any interface would keep= . I was referring to PLPMTUD here. For PLPMTUD, the probes sent by the tunnel ingress may take a very different path of the multipath than most data packets will take. So, there is no way for the ingress to definitely determine the Min MTU. > >> There's no magic here. It's a lot like multicast - either keep track i= n > >> a way that you *think* correlates to the different PMTU feedback or ta= ke > >> the MIN. > > It only works if all paths on the mutlipath can be counted on to delive= r > > the ICMPs. If any paths in the multipath fail to deliver the ICMPs, it > > black holes. And, this is a known problem. > Again, same as multicast, and frankly also the same as unicast when the > ICMPs are blocked. That's a known problem with PMTUD. As above, in some sense it is like multicast. But, the Internet community has deemed it OK for multicast to black hole for some group members. For unicast, the behavior has to be deterministic and neither PMTUD nor PLPMTUD can guarantee that for tunnels. > >> The current doc does need a scrub to make this point clearly and > >> consistently. > > It doesn't work, regardless of the amount of scrubbing. >=20 > If your point is that PMTUD doesn't work and should never be used, > that's clearly not accurate and unlikely to get WG consensus. You're > welcome to try, though. However, 1981bis is on its way to increased > standards maturity as we speak. Multipath really is problematic for both PMTUD and PLPMTUD *for tunnels* - that is aside from any considerations for promoting RFC1981bis to standards-track in the more general sense. > > ... > >>> 17) Section 4.2.3 cites RFC4821, but PLPMTUD cannot be used by > >>> tunnels due to ECMP. > >> I disagree; it can, but the system needs to either take the MIN or hav= e > >> a way to decouple discovered PMTUs in way that can be trusted to > >> reasonably correspond to the ECMP splitting. > > It doesn't work in the generalized case. The ECMP might split into a > > multitude of distinct paths, and there is no way for the ingress to > > known which of the paths have been tested. And, all it takes is > > one un-tested path in the multipath and there is potential for a > > black hole. > If PLPMTUD thinks the protocol is making forward progress, then it is > not a black hole. "Making forward progress" over some paths of the multipath does not guarantee progress over all paths - some paths might black hole. > > > >>> 20) Section 4.3.3, fourth paragraph, "A multipoint tunnel MUST > >>> have support for broadcast and multicast" - I think this > >>> would be better as a "SHOULD". RFC2529 and AERO support > >>> multicast, but RFC5214 does not yet it is widely deployed. > >> Multicast or its equivalent. Otherwise, you can't support IPv6 > >> multicast, which is a required capability of IPv6. > > Large NBMA links can connect many nodes - thousands or more. > > So, for link-scoped multicast, serialized multicast (i.e., multicast > > via iterative unicast) would not scale. >=20 > Serial multicast is not the only equivalent. LANE pushed broadcast ARPs > to a unicast ARP server. Yes, and NBMA had the MARS proposal. > And yes, that won't scale to millions of links, but then if/when it > doesn't scale, then you cease to be able to claim this is a valid IP > link. Multicast is not an optional protocol for IPv6 in particular. RFC5214 and AERO work fine with IPv6. > > That is why some large NBMA links (e.g., RFC5214, AERO) use unicast > > NS/NA/RS/RA instead of link-scoped multicast, as permitted by RFC4861. > > Link-scoped multicast service discovery (e.g., DHCPv6 discovery) is > > supported via multicast mapping to a unicast link-layer address. > Essentially like LANE. Unlike LANE, AERO links are link-local-only (i.e., there are no on-link subnets). AERO links connect only routers and/or hosts that act like routers. > >>> 23) Section 5.1, first sub-bullet under "Tunnels must obey core IP > >>> requirements", Are you meaning to talk about IPv4 DF=3D1? > >> Yes, and that should be made more explicit. Also honoring the EMTU_R > >> limits until told otherwise. > > OK. > > > > One other comment. I agree with figures 12 and 13 but (and I think this= is > > a crucial point) I think they need a supporting sentence or two explain= ing > > why the procedure is "fragment then encapsulate" and not "encapsulate > > then fragment". > Agreed. Good. > > This is the difference between tunnel fragmentation > > and ordinary outer fragmentation, where your document is correctly > > advocating tunnel fragmentation. To the best of my knowledge, this was > > first documented in Section 3.1.7 of RFC2764 and should be cited as suc= h. > > At least, that is what Bob B. suggested to me about 10yrs ago. > I'll check that... Please see the final paragraph of Section 3.12 of the AERO spec for example text. Thanks - Fred fred.l.templin@boeing.com > ---- From nobody Wed May 3 11:49:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BF212957C for ; Wed, 3 May 2017 11:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 hm4CwpXzctIu for ; Wed, 3 May 2017 11:49:21 -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 D2BB1129A97 for ; Wed, 3 May 2017 11:47:35 -0700 (PDT) Received: from [128.9.184.18] ([128.9.184.18]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v43IlDPS027295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 May 2017 11:47:13 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> Date: Wed, 3 May 2017 11:47:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-MailScanner-ID: v43IlDPS027295 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:49:24 -0000 Hi, Fred, Your response keeps raising the same issues that I think we agree upon: - PMTUD always has the possibility of creating black holes (whether in the presence of multipath or not) - PLPMTUD can generate cases where the MIN isn't actually detected and some claims with which I disagree: - that PMPMTUD probes travel different paths than the data However, PLPMTUD probes are generated by transport or higher layers, using the same transport protocol and port pairs as the data (they ARE the data). Those probes should be used to determine an MTU only for a given flow; the potential hazards of sharing that information across flows is already discussed in that RFC. The entire point of PMPMTUD is that the probes travel the same path as the data - and yes, any multipath system could give false information, but should eventually converge on a useful minimum as long as data packets get through. - that tunnels behave differently than unicast links in this regard I don't yet see any explanation as to why this would be true. So I'm left with the following, which I propose as the way forward: - the text will be clear about the potential issues for multipath potentially taking a long time to converge - the text will be clear about the potential issues for black-holing However, in both cases, I don't see a good reason to flag how a tunnel behaves as unique. Does that work? If not, why not? Joe On 5/3/2017 10:48 AM, Templin, Fred L wrote: > Hi Joe, > > Sorry for the extended delay - see below for responses: > > Thanks - Fred > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Wednesday, March 29, 2017 3:06 PM >> To: Templin, Fred L >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> Hi, Fred, >> >> I think we're agreed except for PMTUD and PLMTUD. See below about the >> latter (AFAICT, if it black holes, then the PLMTUD would detect a >> failure to make forward progress). Black-holing in PMTUD is known and >> not something this (or any other doc) is fixing, but also a known standard. >> >> Joe >> >> >> On 3/29/2017 2:18 PM, Templin, Fred L wrote: >>> ... >>>>> 10) Section 4.2.1, bulleted list toward bottom of section, tunnel >>>>> "atom" is a very strange word to me. Tunnel "cell"? >>>> The concept of an atomic packet was defined in RFC 6864. This is derived >>>> from that. Cell would be introducing a new term, one that is overloaded >>>> with ATM, which we want to avoid. >>> OK, but then please find a way to call it an "atomic packet". >> Agreed. > OK. > >>> ... >>>>> 13) Section 4.2.2, final sentence is incorrect. RFC4821-style MTU >>>>> probing cannot be used by tunnels due to ECMP because the probe >>>>> packets may take a different path than the data packets. That >>>>> is why AERO no longer uses RFC4821 probing. >>>> Regarding ECMP issues, I think we need to wrap this issue up. Here's >>>> what I propose: >>>> >>>> - point out that ECMP causes problems with PMTUD (and can cause problems >>>> with PLMTUD). >>>> - an interface has two choices: >>>> - keep track of PMTU based on other packet context (flowID or next >>>> header info) >>>> - merge PMTU feedback, taking the MIN of reported values >>> The problem is that some paths in the multipath may fail to deliver >>> the ICMPs. So there is no way to know whether the MIN has been >>> determined. >> That's no different from the multicast case, though. > In terms of PMTUD, you are right that in a certain sense unicast destinations > with ECMP are like multicast. In other words, a single destination with multiple > paths - some of which may not deliver ICMPs. > > But (unlike unicast) the Internet community seems to be OK with the fact > that some multicast group members might not receive multicasts due to > an MTU black hole. For unicast destinations, it can be a real problem if > there is an MTU black hole along one or more paths of the multipath. > >>> Also the ingress may be handling transit packets sourced >>> by a very large number of original sources each of which produce >>> a very large number of distinct flows. So, there is no way for the >>> ingress to cache all of the flow information it handles. >> Min requires maintaining the same information as any interface would keep. > I was referring to PLPMTUD here. For PLPMTUD, the probes sent by the > tunnel ingress may take a very different path of the multipath than most > data packets will take. So, there is no way for the ingress to definitely > determine the Min MTU. > >>>> There's no magic here. It's a lot like multicast - either keep track in >>>> a way that you *think* correlates to the different PMTU feedback or take >>>> the MIN. >>> It only works if all paths on the mutlipath can be counted on to deliver >>> the ICMPs. If any paths in the multipath fail to deliver the ICMPs, it >>> black holes. And, this is a known problem. >> Again, same as multicast, and frankly also the same as unicast when the >> ICMPs are blocked. That's a known problem with PMTUD. > As above, in some sense it is like multicast. But, the Internet community > has deemed it OK for multicast to black hole for some group members. > For unicast, the behavior has to be deterministic and neither PMTUD > nor PLPMTUD can guarantee that for tunnels. > >>>> The current doc does need a scrub to make this point clearly and >>>> consistently. >>> It doesn't work, regardless of the amount of scrubbing. >> If your point is that PMTUD doesn't work and should never be used, >> that's clearly not accurate and unlikely to get WG consensus. You're >> welcome to try, though. However, 1981bis is on its way to increased >> standards maturity as we speak. > Multipath really is problematic for both PMTUD and PLPMTUD *for > tunnels* - that is aside from any considerations for promoting > RFC1981bis to standards-track in the more general sense. > >>> ... >>>>> 17) Section 4.2.3 cites RFC4821, but PLPMTUD cannot be used by >>>>> tunnels due to ECMP. >>>> I disagree; it can, but the system needs to either take the MIN or have >>>> a way to decouple discovered PMTUs in way that can be trusted to >>>> reasonably correspond to the ECMP splitting. >>> It doesn't work in the generalized case. The ECMP might split into a >>> multitude of distinct paths, and there is no way for the ingress to >>> known which of the paths have been tested. And, all it takes is >>> one un-tested path in the multipath and there is potential for a >>> black hole. >> If PLPMTUD thinks the protocol is making forward progress, then it is >> not a black hole. > "Making forward progress" over some paths of the multipath does not > guarantee progress over all paths - some paths might black hole. > >>>>> 20) Section 4.3.3, fourth paragraph, "A multipoint tunnel MUST >>>>> have support for broadcast and multicast" - I think this >>>>> would be better as a "SHOULD". RFC2529 and AERO support >>>>> multicast, but RFC5214 does not yet it is widely deployed. >>>> Multicast or its equivalent. Otherwise, you can't support IPv6 >>>> multicast, which is a required capability of IPv6. >>> Large NBMA links can connect many nodes - thousands or more. >>> So, for link-scoped multicast, serialized multicast (i.e., multicast >>> via iterative unicast) would not scale. >> Serial multicast is not the only equivalent. LANE pushed broadcast ARPs >> to a unicast ARP server. > Yes, and NBMA had the MARS proposal. > >> And yes, that won't scale to millions of links, but then if/when it >> doesn't scale, then you cease to be able to claim this is a valid IP >> link. Multicast is not an optional protocol for IPv6 in particular. > RFC5214 and AERO work fine with IPv6. > >>> That is why some large NBMA links (e.g., RFC5214, AERO) use unicast >>> NS/NA/RS/RA instead of link-scoped multicast, as permitted by RFC4861. >>> Link-scoped multicast service discovery (e.g., DHCPv6 discovery) is >>> supported via multicast mapping to a unicast link-layer address. >> Essentially like LANE. > Unlike LANE, AERO links are link-local-only (i.e., there are no on-link > subnets). AERO links connect only routers and/or hosts that act like > routers. > >>>>> 23) Section 5.1, first sub-bullet under "Tunnels must obey core IP >>>>> requirements", Are you meaning to talk about IPv4 DF=1? >>>> Yes, and that should be made more explicit. Also honoring the EMTU_R >>>> limits until told otherwise. >>> OK. >>> >>> One other comment. I agree with figures 12 and 13 but (and I think this is >>> a crucial point) I think they need a supporting sentence or two explaining >>> why the procedure is "fragment then encapsulate" and not "encapsulate >>> then fragment". >> Agreed. > Good. > >>> This is the difference between tunnel fragmentation >>> and ordinary outer fragmentation, where your document is correctly >>> advocating tunnel fragmentation. To the best of my knowledge, this was >>> first documented in Section 3.1.7 of RFC2764 and should be cited as such. >>> At least, that is what Bob B. suggested to me about 10yrs ago. >> I'll check that... > Please see the final paragraph of Section 3.12 of the AERO spec for example > text. > > Thanks - Fred > fred.l.templin@boeing.com > >> ---- > From nobody Wed May 3 13:10:02 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B4129C6B for ; Wed, 3 May 2017 13:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 PFmrS8P2OGlR for ; Wed, 3 May 2017 13:09:58 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 08438129B8C for ; Wed, 3 May 2017 13:07:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v43K7o0A052076; Wed, 3 May 2017 13:07:50 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v43K7jNA052024 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 3 May 2017 13:07:46 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 13:07:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 3 May 2017 13:07:45 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKCAAI2TgP//mgIg Date: Wed, 3 May 2017 20:07:44 +0000 Message-ID: References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> In-Reply-To: <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:10:01 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAzLCAyMDE3 IDExOjQ3IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+DQo+IENjOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNS50eHQNCj4gDQo+IEhpLCBG cmVkLA0KPiANCj4gWW91ciByZXNwb25zZSBrZWVwcyByYWlzaW5nIHRoZSBzYW1lIGlzc3VlcyB0 aGF0IEkgdGhpbmsgd2UgYWdyZWUgdXBvbjoNCj4gDQo+ICAgICAtIFBNVFVEIGFsd2F5cyBoYXMg dGhlIHBvc3NpYmlsaXR5IG9mIGNyZWF0aW5nIGJsYWNrIGhvbGVzICh3aGV0aGVyDQo+IGluIHRo ZSBwcmVzZW5jZSBvZiBtdWx0aXBhdGggb3Igbm90KQ0KPiANCj4gICAgIC0gUExQTVRVRCBjYW4g Z2VuZXJhdGUgY2FzZXMgd2hlcmUgdGhlIE1JTiBpc24ndCBhY3R1YWxseSBkZXRlY3RlZA0KPiAN Cj4gYW5kIHNvbWUgY2xhaW1zIHdpdGggd2hpY2ggSSBkaXNhZ3JlZToNCj4gDQo+ICAgICAtIHRo YXQgUE1QTVRVRCBwcm9iZXMgdHJhdmVsIGRpZmZlcmVudCBwYXRocyB0aGFuIHRoZSBkYXRhDQoN CkkgdGhpbmsgSSBoYXZlIGFscmVhZHkgc2FpZCB0aGlzIG1hbnkgdGltZXMsIGJ1dCBsZXQgbWUg dHJ5IGFnYWluLiBUaGUNCnR1bm5lbCBpbmdyZXNzIGlzIG5vdCB0aGUgc291cmNlIG9mIHRoZSB0 cmFuc2l0IHBhY2tldDsgaXQgaXMgb25seSB0aGUNCnNvdXJjZSBvZiB0aGUgdHVubmVsIHBhY2tl dC4gQW5kLCB0aGUgaW5ncmVzcyBtYXkgaGF2ZSB0byB0dW5uZWwNCmEgd2lkZSB2YXJpZXR5IG9m IHRyYW5zaXQgcGFja2V0cyBzb3VyY2VkIGJ5IG1hbnkgb3JpZ2luYWwgc291cmNlcy4NClNvLCBp ZiBFQ01QIHNvbWV3aGVyZSB3aXRoaW4gdGhlIHR1bm5lbCBwZWVrcyBhdCB0aGUgdHJhbnNpdA0K cGFja2V0LCB0aGVuIHRoZSBwYWNrZXQgY291bGQgdGFrZSBhIHZlcnkgZGlmZmVyZW50IHBhdGgg d2l0aGluDQp0aGUgdHVubmVsIHRoYW4gdGhlIGluZ3Jlc3MnIFBMUE1UVUQgcHJvYmVzIHRvb2su IA0KDQo+IEhvd2V2ZXIsIFBMUE1UVUQgcHJvYmVzIGFyZSBnZW5lcmF0ZWQgYnkgdHJhbnNwb3J0 IG9yIGhpZ2hlciBsYXllcnMsDQo+IHVzaW5nIHRoZSBzYW1lIHRyYW5zcG9ydCBwcm90b2NvbCBh bmQgcG9ydCBwYWlycyBhcyB0aGUgZGF0YSAodGhleSBBUkUNCj4gdGhlIGRhdGEpLg0KDQpNYXli ZSB3ZSBhcmUgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIgLSBJIHRob3VnaHQgdGhlIGRvY3VtZW50 IHdhcw0KYXNraW5nIHRoZSB0dW5uZWwgaW5ncmVzcyB0byBhY3QgYXMgYSBwYWNrZXRpemF0aW9u IGxheWVyIGFuZCBzZW5kDQpQTE1UVUQgcHJvYmVzIGFzIGlmIGl0IHdlcmUgYSB0cmFuc3BvcnQg b3IgaGlnaGVyIGxheWVyPw0KDQo+IFRob3NlIHByb2JlcyBzaG91bGQgYmUgdXNlZCB0byBkZXRl cm1pbmUgYW4gTVRVIG9ubHkgZm9yIGENCj4gZ2l2ZW4gZmxvdzsgdGhlIHBvdGVudGlhbCBoYXph cmRzIG9mIHNoYXJpbmcgdGhhdCBpbmZvcm1hdGlvbiBhY3Jvc3MNCj4gZmxvd3MgaXMgYWxyZWFk eSBkaXNjdXNzZWQgaW4gdGhhdCBSRkMuDQoNCkkgZG9uJ3QgdGhpbmsgUkZDNDgyMSBkb2VzIGVu b3VnaCB0byB0YWtlIEVDTVAgaW50byBhY2NvdW50IHdoZW4gaXQNCnRhbGtzIGFib3V0IHN0b3Jp bmcgYW5kIHNoYXJpbmcgZGlzY292ZXJlZCBNVFVzLg0KIA0KPiBUaGUgZW50aXJlIHBvaW50IG9m IFBNUE1UVUQgaXMNCj4gdGhhdCB0aGUgcHJvYmVzIHRyYXZlbCB0aGUgc2FtZSBwYXRoIGFzIHRo ZSBkYXRhIC0gYW5kIHllcywgYW55DQo+IG11bHRpcGF0aCBzeXN0ZW0gY291bGQgZ2l2ZSBmYWxz ZSBpbmZvcm1hdGlvbiwgYnV0IHNob3VsZCBldmVudHVhbGx5DQo+IGNvbnZlcmdlIG9uIGEgdXNl ZnVsIG1pbmltdW0gYXMgbG9uZyBhcyBkYXRhIHBhY2tldHMgZ2V0IHRocm91Z2guDQoNCklmIHRo ZSBwcm9iZXMgbG9vayBleGFjdGx5IGxpa2UgdGhlIGRhdGEsIHRoZW4gdGhlIHByb2JlcyB3aWxs IHRyYXZlbCB0aGUNCnNhbWUgRUNNUCBwYXRoIGFzIHRoZSBkYXRhIGFuZCB3aWxsIGRpc2NvdmVy IGEgdmFsaWQgTVRVIHllcy4gVGhlDQp0cm91YmxlIHdpdGggdHVubmVscyBpcyB0aGF0IHRoZXJl IGlzIG5vIHdheSBmb3IgdGhlIGluZ3Jlc3MgdG8gc2VuZCBhDQpwcm9iZSBmb3IgZWFjaCBhbmQg ZXZlcnkgdHJhbnNpdCBwYWNrZXQgZmxvdyAtIGFuZCwgaWYgYSBmbG93IGFycml2ZXMNCnRoYXQg aGFzIG5vdCBiZWVuIHByb2JlZCBpdCBjYW4gYmxhY2sgaG9sZS4NCg0KPiAgICAgLSB0aGF0IHR1 bm5lbHMgYmVoYXZlIGRpZmZlcmVudGx5IHRoYW4gdW5pY2FzdCBsaW5rcyBpbiB0aGlzIHJlZ2Fy ZA0KDQpZb3Ugd29uJ3QgZ2V0IG1lIHRvIG1ha2UgdGhpcyBhcmd1bWVudCAtIEkgYW0gY29udmlu Y2VkIHRoYXQgdHVubmVscw0KYXJlIGxpbmtzLg0KDQo+IEkgZG9uJ3QgeWV0IHNlZSBhbnkgZXhw bGFuYXRpb24gYXMgdG8gd2h5IHRoaXMgd291bGQgYmUgdHJ1ZS4NCj4gDQo+IFNvIEknbSBsZWZ0 IHdpdGggdGhlIGZvbGxvd2luZywgd2hpY2ggSSBwcm9wb3NlIGFzIHRoZSB3YXkgZm9yd2FyZDoN Cj4gDQo+ICAgICAtIHRoZSB0ZXh0IHdpbGwgYmUgY2xlYXIgYWJvdXQgdGhlIHBvdGVudGlhbCBp c3N1ZXMgZm9yIG11bHRpcGF0aA0KPiBwb3RlbnRpYWxseSB0YWtpbmcgYSBsb25nIHRpbWUgdG8g Y29udmVyZ2UNCg0KSXQncyBub3QgdGhhdCBpdCBjb3VsZCB0YWtlIGEgbG9uZyB0aW1lIHRvIGNv bnZlcmdlIC0gaXQgaXMgdGhhdCBpdCBtaWdodA0KbmV2ZXIgY29udmVyZ2UgaWYgc29tZSBwYXRo cyBvZiB0aGUgbXVsdGlwYXRoIGJsb2NrIElDTVBzLg0KDQo+ICAgICAtIHRoZSB0ZXh0IHdpbGwg YmUgY2xlYXIgYWJvdXQgdGhlIHBvdGVudGlhbCBpc3N1ZXMgZm9yIGJsYWNrLWhvbGluZw0KPiAN Cj4gSG93ZXZlciwgaW4gYm90aCBjYXNlcywgSSBkb24ndCBzZWUgYSBnb29kIHJlYXNvbiB0byBm bGFnIGhvdyBhIHR1bm5lbA0KPiBiZWhhdmVzIGFzIHVuaXF1ZS4NCj4gDQo+IERvZXMgdGhhdCB3 b3JrPw0KPiANCj4gSWYgbm90LCB3aHkgbm90Pw0KDQpUaGUgdHVubmVsIGluZ3Jlc3MgaXMgb25s eSB0aGUgc291cmNlIG9mIHRoZSB0dW5uZWwgcGFja2V0czsgaXQgaXMgbm90IHRoZQ0Kc291cmNl IG9mIHRoZSB0cmFuc2l0IHBhY2tldHMuIFRoZSBvbmx5IHdheSBmb3IgUExQTVRVRCB0byBmdW5j dGlvbg0KcHJvcGVybHkgaW4gdGhlIHByZXNlbmNlIG9mIEVDTVAgd291bGQgYmUgZm9yIHRoZSBz b3VyY2Ugb2YgdGhlIHRyYW5zaXQNCnBhY2tldHMgdG8gZG8gdGhlIFJGQzQ4MjEgcHJvYmluZyAt IG5vdCB0aGUgdHVubmVsIGluZ3Jlc3MuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGlu QGJvZWluZy5jb20NCg0KPiBKb2UNCj4gDQo+IA0KPiANCj4gT24gNS8zLzIwMTcgMTA6NDggQU0s IFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBIaSBKb2UsDQo+ID4NCj4gPiBTb3JyeSBmb3Ig dGhlIGV4dGVuZGVkIGRlbGF5IC0gc2VlIGJlbG93IGZvciByZXNwb25zZXM6DQo+ID4NCj4gPiBU aGFua3MgLSBGcmVkDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPj4gU2VudDogV2VkbmVz ZGF5LCBNYXJjaCAyOSwgMjAxNyAzOjA2IFBNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4+IENjOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiA+ PiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEt dHVubmVscy0wNS50eHQNCj4gPj4NCj4gPj4gSGksIEZyZWQsDQo+ID4+DQo+ID4+IEkgdGhpbmsg d2UncmUgYWdyZWVkIGV4Y2VwdCBmb3IgUE1UVUQgYW5kIFBMTVRVRC4gU2VlIGJlbG93IGFib3V0 IHRoZQ0KPiA+PiBsYXR0ZXIgKEFGQUlDVCwgaWYgaXQgYmxhY2sgaG9sZXMsIHRoZW4gdGhlIFBM TVRVRCB3b3VsZCBkZXRlY3QgYQ0KPiA+PiBmYWlsdXJlIHRvIG1ha2UgZm9yd2FyZCBwcm9ncmVz cykuIEJsYWNrLWhvbGluZyBpbiBQTVRVRCBpcyBrbm93biBhbmQNCj4gPj4gbm90IHNvbWV0aGlu ZyB0aGlzIChvciBhbnkgb3RoZXIgZG9jKSBpcyBmaXhpbmcsIGJ1dCBhbHNvIGEga25vd24gc3Rh bmRhcmQuDQo+ID4+DQo+ID4+IEpvZQ0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiAzLzI5LzIwMTcgMjox OCBQTSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+Pj4gLi4uDQo+ID4+Pj4+IDEwKSBTZWN0 aW9uIDQuMi4xLCBidWxsZXRlZCBsaXN0IHRvd2FyZCBib3R0b20gb2Ygc2VjdGlvbiwgdHVubmVs DQo+ID4+Pj4+ICAgICJhdG9tIiBpcyBhIHZlcnkgc3RyYW5nZSB3b3JkIHRvIG1lLiBUdW5uZWwg ImNlbGwiPw0KPiA+Pj4+IFRoZSBjb25jZXB0IG9mIGFuIGF0b21pYyBwYWNrZXQgd2FzIGRlZmlu ZWQgaW4gUkZDIDY4NjQuIFRoaXMgaXMgZGVyaXZlZA0KPiA+Pj4+IGZyb20gdGhhdC4gQ2VsbCB3 b3VsZCBiZSBpbnRyb2R1Y2luZyBhIG5ldyB0ZXJtLCBvbmUgdGhhdCBpcyBvdmVybG9hZGVkDQo+ ID4+Pj4gd2l0aCBBVE0sIHdoaWNoIHdlIHdhbnQgdG8gYXZvaWQuDQo+ID4+PiBPSywgYnV0IHRo ZW4gcGxlYXNlIGZpbmQgYSB3YXkgdG8gY2FsbCBpdCBhbiAiYXRvbWljIHBhY2tldCIuDQo+ID4+ IEFncmVlZC4NCj4gPiBPSy4NCj4gPg0KPiA+Pj4gLi4uDQo+ID4+Pj4+IDEzKSBTZWN0aW9uIDQu Mi4yLCBmaW5hbCBzZW50ZW5jZSBpcyBpbmNvcnJlY3QuIFJGQzQ4MjEtc3R5bGUgTVRVDQo+ID4+ Pj4+ICAgICBwcm9iaW5nIGNhbm5vdCBiZSB1c2VkIGJ5IHR1bm5lbHMgZHVlIHRvIEVDTVAgYmVj YXVzZSB0aGUgcHJvYmUNCj4gPj4+Pj4gICAgIHBhY2tldHMgbWF5IHRha2UgYSBkaWZmZXJlbnQg cGF0aCB0aGFuIHRoZSBkYXRhIHBhY2tldHMuIFRoYXQNCj4gPj4+Pj4gICAgIGlzIHdoeSBBRVJP IG5vIGxvbmdlciB1c2VzIFJGQzQ4MjEgcHJvYmluZy4NCj4gPj4+PiBSZWdhcmRpbmcgRUNNUCBp c3N1ZXMsIEkgdGhpbmsgd2UgbmVlZCB0byB3cmFwIHRoaXMgaXNzdWUgdXAuIEhlcmUncw0KPiA+ Pj4+IHdoYXQgSSBwcm9wb3NlOg0KPiA+Pj4+DQo+ID4+Pj4gLSBwb2ludCBvdXQgdGhhdCBFQ01Q IGNhdXNlcyBwcm9ibGVtcyB3aXRoIFBNVFVEIChhbmQgY2FuIGNhdXNlIHByb2JsZW1zDQo+ID4+ Pj4gd2l0aCBQTE1UVUQpLg0KPiA+Pj4+IC0gYW4gaW50ZXJmYWNlIGhhcyB0d28gY2hvaWNlczoN Cj4gPj4+PiAgICAgLSBrZWVwIHRyYWNrIG9mIFBNVFUgYmFzZWQgb24gb3RoZXIgcGFja2V0IGNv bnRleHQgKGZsb3dJRCBvciBuZXh0DQo+ID4+Pj4gaGVhZGVyIGluZm8pDQo+ID4+Pj4gICAgIC0g bWVyZ2UgUE1UVSBmZWVkYmFjaywgdGFraW5nIHRoZSBNSU4gb2YgcmVwb3J0ZWQgdmFsdWVzDQo+ ID4+PiBUaGUgcHJvYmxlbSBpcyB0aGF0IHNvbWUgcGF0aHMgaW4gdGhlIG11bHRpcGF0aCBtYXkg ZmFpbCB0byBkZWxpdmVyDQo+ID4+PiB0aGUgSUNNUHMuIFNvIHRoZXJlIGlzIG5vIHdheSB0byBr bm93IHdoZXRoZXIgdGhlIE1JTiBoYXMgYmVlbg0KPiA+Pj4gZGV0ZXJtaW5lZC4NCj4gPj4gVGhh dCdzIG5vIGRpZmZlcmVudCBmcm9tIHRoZSBtdWx0aWNhc3QgY2FzZSwgdGhvdWdoLg0KPiA+IElu IHRlcm1zIG9mIFBNVFVELCB5b3UgYXJlIHJpZ2h0IHRoYXQgaW4gYSBjZXJ0YWluIHNlbnNlIHVu aWNhc3QgZGVzdGluYXRpb25zDQo+ID4gd2l0aCBFQ01QIGFyZSBsaWtlIG11bHRpY2FzdC4gSW4g b3RoZXIgd29yZHMsIGEgc2luZ2xlIGRlc3RpbmF0aW9uIHdpdGggbXVsdGlwbGUNCj4gPiBwYXRo cyAtIHNvbWUgb2Ygd2hpY2ggbWF5IG5vdCBkZWxpdmVyIElDTVBzLg0KPiA+DQo+ID4gQnV0ICh1 bmxpa2UgdW5pY2FzdCkgdGhlIEludGVybmV0IGNvbW11bml0eSBzZWVtcyB0byBiZSBPSyB3aXRo IHRoZSBmYWN0DQo+ID4gdGhhdCBzb21lIG11bHRpY2FzdCBncm91cCBtZW1iZXJzIG1pZ2h0IG5v dCByZWNlaXZlIG11bHRpY2FzdHMgZHVlIHRvDQo+ID4gYW4gTVRVIGJsYWNrIGhvbGUuIEZvciB1 bmljYXN0IGRlc3RpbmF0aW9ucywgaXQgY2FuIGJlIGEgcmVhbCBwcm9ibGVtICBpZg0KPiA+IHRo ZXJlIGlzIGFuIE1UVSBibGFjayBob2xlIGFsb25nIG9uZSBvciBtb3JlIHBhdGhzIG9mIHRoZSBt dWx0aXBhdGguDQo+ID4NCj4gPj4+ICBBbHNvIHRoZSBpbmdyZXNzIG1heSBiZSBoYW5kbGluZyB0 cmFuc2l0IHBhY2tldHMgc291cmNlZA0KPiA+Pj4gYnkgYSB2ZXJ5IGxhcmdlIG51bWJlciBvZiBv cmlnaW5hbCBzb3VyY2VzIGVhY2ggb2Ygd2hpY2ggcHJvZHVjZQ0KPiA+Pj4gYSB2ZXJ5IGxhcmdl IG51bWJlciBvZiBkaXN0aW5jdCBmbG93cy4gU28sIHRoZXJlIGlzIG5vIHdheSBmb3IgdGhlDQo+ ID4+PiBpbmdyZXNzIHRvIGNhY2hlIGFsbCBvZiB0aGUgZmxvdyBpbmZvcm1hdGlvbiBpdCBoYW5k bGVzLg0KPiA+PiBNaW4gcmVxdWlyZXMgbWFpbnRhaW5pbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24g YXMgYW55IGludGVyZmFjZSB3b3VsZCBrZWVwLg0KPiA+IEkgd2FzIHJlZmVycmluZyB0byBQTFBN VFVEIGhlcmUuIEZvciBQTFBNVFVELCB0aGUgcHJvYmVzIHNlbnQgYnkgdGhlDQo+ID4gdHVubmVs IGluZ3Jlc3MgbWF5IHRha2UgYSB2ZXJ5IGRpZmZlcmVudCBwYXRoIG9mIHRoZSBtdWx0aXBhdGgg dGhhbiBtb3N0DQo+ID4gZGF0YSBwYWNrZXRzIHdpbGwgdGFrZS4gU28sIHRoZXJlIGlzIG5vIHdh eSBmb3IgdGhlIGluZ3Jlc3MgdG8gZGVmaW5pdGVseQ0KPiA+IGRldGVybWluZSB0aGUgTWluIE1U VS4NCj4gPg0KPiA+Pj4+IFRoZXJlJ3Mgbm8gbWFnaWMgaGVyZS4gSXQncyBhIGxvdCBsaWtlIG11 bHRpY2FzdCAtIGVpdGhlciBrZWVwIHRyYWNrIGluDQo+ID4+Pj4gYSB3YXkgdGhhdCB5b3UgKnRo aW5rKiBjb3JyZWxhdGVzIHRvIHRoZSBkaWZmZXJlbnQgUE1UVSBmZWVkYmFjayBvciB0YWtlDQo+ ID4+Pj4gdGhlIE1JTi4NCj4gPj4+IEl0IG9ubHkgd29ya3MgaWYgYWxsIHBhdGhzIG9uIHRoZSBt dXRsaXBhdGggY2FuIGJlIGNvdW50ZWQgb24gdG8gZGVsaXZlcg0KPiA+Pj4gdGhlIElDTVBzLiBJ ZiBhbnkgcGF0aHMgaW4gdGhlIG11bHRpcGF0aCBmYWlsIHRvIGRlbGl2ZXIgdGhlIElDTVBzLCBp dA0KPiA+Pj4gYmxhY2sgaG9sZXMuIEFuZCwgdGhpcyBpcyBhIGtub3duIHByb2JsZW0uDQo+ID4+ IEFnYWluLCBzYW1lIGFzIG11bHRpY2FzdCwgYW5kIGZyYW5rbHkgYWxzbyB0aGUgc2FtZSBhcyB1 bmljYXN0IHdoZW4gdGhlDQo+ID4+IElDTVBzIGFyZSBibG9ja2VkLiBUaGF0J3MgYSBrbm93biBw cm9ibGVtIHdpdGggUE1UVUQuDQo+ID4gQXMgYWJvdmUsIGluIHNvbWUgc2Vuc2UgaXQgaXMgbGlr ZSBtdWx0aWNhc3QuIEJ1dCwgdGhlIEludGVybmV0IGNvbW11bml0eQ0KPiA+IGhhcyBkZWVtZWQg aXQgT0sgZm9yIG11bHRpY2FzdCB0byBibGFjayBob2xlIGZvciBzb21lIGdyb3VwIG1lbWJlcnMu DQo+ID4gRm9yIHVuaWNhc3QsIHRoZSBiZWhhdmlvciBoYXMgdG8gYmUgZGV0ZXJtaW5pc3RpYyBh bmQgbmVpdGhlciBQTVRVRA0KPiA+IG5vciBQTFBNVFVEIGNhbiBndWFyYW50ZWUgdGhhdCBmb3Ig dHVubmVscy4NCj4gPg0KPiA+Pj4+IFRoZSBjdXJyZW50IGRvYyBkb2VzIG5lZWQgYSBzY3J1YiB0 byBtYWtlIHRoaXMgcG9pbnQgY2xlYXJseSBhbmQNCj4gPj4+PiBjb25zaXN0ZW50bHkuDQo+ID4+ PiBJdCBkb2Vzbid0IHdvcmssIHJlZ2FyZGxlc3Mgb2YgdGhlIGFtb3VudCBvZiBzY3J1YmJpbmcu DQo+ID4+IElmIHlvdXIgcG9pbnQgaXMgdGhhdCBQTVRVRCBkb2Vzbid0IHdvcmsgYW5kIHNob3Vs ZCBuZXZlciBiZSB1c2VkLA0KPiA+PiB0aGF0J3MgY2xlYXJseSBub3QgYWNjdXJhdGUgYW5kIHVu bGlrZWx5IHRvIGdldCBXRyBjb25zZW5zdXMuIFlvdSdyZQ0KPiA+PiB3ZWxjb21lIHRvIHRyeSwg dGhvdWdoLiBIb3dldmVyLCAxOTgxYmlzIGlzIG9uIGl0cyB3YXkgdG8gaW5jcmVhc2VkDQo+ID4+ IHN0YW5kYXJkcyBtYXR1cml0eSBhcyB3ZSBzcGVhay4NCj4gPiBNdWx0aXBhdGggcmVhbGx5IGlz IHByb2JsZW1hdGljIGZvciBib3RoIFBNVFVEIGFuZCBQTFBNVFVEICpmb3INCj4gPiB0dW5uZWxz KiAtIHRoYXQgaXMgYXNpZGUgZnJvbSBhbnkgY29uc2lkZXJhdGlvbnMgZm9yIHByb21vdGluZw0K PiA+IFJGQzE5ODFiaXMgdG8gc3RhbmRhcmRzLXRyYWNrIGluIHRoZSBtb3JlIGdlbmVyYWwgc2Vu c2UuDQo+ID4NCj4gPj4+IC4uLg0KPiA+Pj4+PiAxNykgU2VjdGlvbiA0LjIuMyBjaXRlcyBSRkM0 ODIxLCBidXQgUExQTVRVRCBjYW5ub3QgYmUgdXNlZCBieQ0KPiA+Pj4+PiAgICAgdHVubmVscyBk dWUgdG8gRUNNUC4NCj4gPj4+PiBJIGRpc2FncmVlOyBpdCBjYW4sIGJ1dCB0aGUgc3lzdGVtIG5l ZWRzIHRvIGVpdGhlciB0YWtlIHRoZSBNSU4gb3IgaGF2ZQ0KPiA+Pj4+IGEgd2F5IHRvIGRlY291 cGxlIGRpc2NvdmVyZWQgUE1UVXMgaW4gd2F5IHRoYXQgY2FuIGJlIHRydXN0ZWQgdG8NCj4gPj4+ PiByZWFzb25hYmx5IGNvcnJlc3BvbmQgdG8gdGhlIEVDTVAgc3BsaXR0aW5nLg0KPiA+Pj4gSXQg ZG9lc24ndCB3b3JrIGluIHRoZSBnZW5lcmFsaXplZCBjYXNlLiBUaGUgRUNNUCBtaWdodCBzcGxp dCBpbnRvIGENCj4gPj4+IG11bHRpdHVkZSBvZiBkaXN0aW5jdCBwYXRocywgYW5kIHRoZXJlIGlz IG5vIHdheSBmb3IgdGhlIGluZ3Jlc3MgdG8NCj4gPj4+IGtub3duIHdoaWNoIG9mIHRoZSBwYXRo cyBoYXZlIGJlZW4gdGVzdGVkLiBBbmQsIGFsbCBpdCB0YWtlcyBpcw0KPiA+Pj4gb25lIHVuLXRl c3RlZCBwYXRoIGluIHRoZSBtdWx0aXBhdGggYW5kIHRoZXJlIGlzIHBvdGVudGlhbCBmb3IgYQ0K PiA+Pj4gYmxhY2sgaG9sZS4NCj4gPj4gSWYgUExQTVRVRCB0aGlua3MgdGhlIHByb3RvY29sIGlz IG1ha2luZyBmb3J3YXJkIHByb2dyZXNzLCB0aGVuIGl0IGlzDQo+ID4+IG5vdCBhIGJsYWNrIGhv bGUuDQo+ID4gIk1ha2luZyBmb3J3YXJkIHByb2dyZXNzIiBvdmVyIHNvbWUgcGF0aHMgb2YgdGhl IG11bHRpcGF0aCBkb2VzIG5vdA0KPiA+IGd1YXJhbnRlZSBwcm9ncmVzcyBvdmVyIGFsbCBwYXRo cyAtIHNvbWUgcGF0aHMgbWlnaHQgYmxhY2sgaG9sZS4NCj4gPg0KPiA+Pj4+PiAyMCkgU2VjdGlv biA0LjMuMywgZm91cnRoIHBhcmFncmFwaCwgIkEgbXVsdGlwb2ludCB0dW5uZWwgTVVTVA0KPiA+ Pj4+PiAgICAgaGF2ZSBzdXBwb3J0IGZvciBicm9hZGNhc3QgYW5kIG11bHRpY2FzdCIgLSBJIHRo aW5rIHRoaXMNCj4gPj4+Pj4gICAgIHdvdWxkIGJlIGJldHRlciBhcyBhICJTSE9VTEQiLiBSRkMy NTI5IGFuZCBBRVJPIHN1cHBvcnQNCj4gPj4+Pj4gICAgIG11bHRpY2FzdCwgYnV0IFJGQzUyMTQg ZG9lcyBub3QgeWV0IGl0IGlzIHdpZGVseSBkZXBsb3llZC4NCj4gPj4+PiBNdWx0aWNhc3Qgb3Ig aXRzIGVxdWl2YWxlbnQuIE90aGVyd2lzZSwgeW91IGNhbid0IHN1cHBvcnQgSVB2Ng0KPiA+Pj4+ IG11bHRpY2FzdCwgd2hpY2ggaXMgYSByZXF1aXJlZCBjYXBhYmlsaXR5IG9mIElQdjYuDQo+ID4+ PiBMYXJnZSBOQk1BIGxpbmtzIGNhbiBjb25uZWN0IG1hbnkgbm9kZXMgLSB0aG91c2FuZHMgb3Ig bW9yZS4NCj4gPj4+IFNvLCBmb3IgbGluay1zY29wZWQgbXVsdGljYXN0LCBzZXJpYWxpemVkIG11 bHRpY2FzdCAoaS5lLiwgbXVsdGljYXN0DQo+ID4+PiB2aWEgaXRlcmF0aXZlIHVuaWNhc3QpIHdv dWxkIG5vdCBzY2FsZS4NCj4gPj4gU2VyaWFsIG11bHRpY2FzdCBpcyBub3QgdGhlIG9ubHkgZXF1 aXZhbGVudC4gTEFORSBwdXNoZWQgYnJvYWRjYXN0IEFSUHMNCj4gPj4gdG8gYSB1bmljYXN0IEFS UCBzZXJ2ZXIuDQo+ID4gWWVzLCBhbmQgTkJNQSBoYWQgdGhlIE1BUlMgcHJvcG9zYWwuDQo+ID4N Cj4gPj4gQW5kIHllcywgdGhhdCB3b24ndCBzY2FsZSB0byBtaWxsaW9ucyBvZiBsaW5rcywgYnV0 IHRoZW4gaWYvd2hlbiBpdA0KPiA+PiBkb2Vzbid0IHNjYWxlLCB0aGVuIHlvdSBjZWFzZSB0byBi ZSBhYmxlIHRvIGNsYWltIHRoaXMgaXMgYSB2YWxpZCBJUA0KPiA+PiBsaW5rLiBNdWx0aWNhc3Qg aXMgbm90IGFuIG9wdGlvbmFsIHByb3RvY29sIGZvciBJUHY2IGluIHBhcnRpY3VsYXIuDQo+ID4g UkZDNTIxNCBhbmQgQUVSTyB3b3JrIGZpbmUgd2l0aCBJUHY2Lg0KPiA+DQo+ID4+PiBUaGF0IGlz IHdoeSBzb21lIGxhcmdlIE5CTUEgbGlua3MgKGUuZy4sIFJGQzUyMTQsIEFFUk8pIHVzZSB1bmlj YXN0DQo+ID4+PiBOUy9OQS9SUy9SQSBpbnN0ZWFkIG9mIGxpbmstc2NvcGVkIG11bHRpY2FzdCwg YXMgcGVybWl0dGVkIGJ5IFJGQzQ4NjEuDQo+ID4+PiBMaW5rLXNjb3BlZCBtdWx0aWNhc3Qgc2Vy dmljZSBkaXNjb3ZlcnkgKGUuZy4sIERIQ1B2NiBkaXNjb3ZlcnkpIGlzDQo+ID4+PiBzdXBwb3J0 ZWQgdmlhIG11bHRpY2FzdCBtYXBwaW5nIHRvIGEgdW5pY2FzdCBsaW5rLWxheWVyIGFkZHJlc3Mu DQo+ID4+IEVzc2VudGlhbGx5IGxpa2UgTEFORS4NCj4gPiBVbmxpa2UgTEFORSwgQUVSTyBsaW5r cyBhcmUgbGluay1sb2NhbC1vbmx5IChpLmUuLCB0aGVyZSBhcmUgbm8gb24tbGluaw0KPiA+IHN1 Ym5ldHMpLiBBRVJPIGxpbmtzIGNvbm5lY3Qgb25seSByb3V0ZXJzIGFuZC9vciBob3N0cyB0aGF0 IGFjdCBsaWtlDQo+ID4gcm91dGVycy4NCj4gPg0KPiA+Pj4+PiAyMykgU2VjdGlvbiA1LjEsIGZp cnN0IHN1Yi1idWxsZXQgdW5kZXIgIlR1bm5lbHMgbXVzdCBvYmV5IGNvcmUgSVANCj4gPj4+Pj4g ICAgIHJlcXVpcmVtZW50cyIsIEFyZSB5b3UgbWVhbmluZyB0byB0YWxrIGFib3V0IElQdjQgREY9 MT8NCj4gPj4+PiBZZXMsIGFuZCB0aGF0IHNob3VsZCBiZSBtYWRlIG1vcmUgZXhwbGljaXQuIEFs c28gaG9ub3JpbmcgdGhlIEVNVFVfUg0KPiA+Pj4+IGxpbWl0cyB1bnRpbCB0b2xkIG90aGVyd2lz ZS4NCj4gPj4+IE9LLg0KPiA+Pj4NCj4gPj4+IE9uZSBvdGhlciBjb21tZW50LiBJIGFncmVlIHdp dGggZmlndXJlcyAxMiBhbmQgMTMgYnV0IChhbmQgSSB0aGluayB0aGlzIGlzDQo+ID4+PiBhIGNy dWNpYWwgcG9pbnQpIEkgdGhpbmsgdGhleSBuZWVkIGEgc3VwcG9ydGluZyBzZW50ZW5jZSBvciB0 d28gZXhwbGFpbmluZw0KPiA+Pj4gd2h5IHRoZSBwcm9jZWR1cmUgaXMgImZyYWdtZW50IHRoZW4g ZW5jYXBzdWxhdGUiIGFuZCBub3QgImVuY2Fwc3VsYXRlDQo+ID4+PiB0aGVuIGZyYWdtZW50Ii4N Cj4gPj4gQWdyZWVkLg0KPiA+IEdvb2QuDQo+ID4NCj4gPj4+IFRoaXMgaXMgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiB0dW5uZWwgZnJhZ21lbnRhdGlvbg0KPiA+Pj4gYW5kIG9yZGluYXJ5IG91dGVy IGZyYWdtZW50YXRpb24sIHdoZXJlIHlvdXIgZG9jdW1lbnQgaXMgY29ycmVjdGx5DQo+ID4+PiBh ZHZvY2F0aW5nIHR1bm5lbCBmcmFnbWVudGF0aW9uLiBUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVk Z2UsIHRoaXMgd2FzDQo+ID4+PiBmaXJzdCBkb2N1bWVudGVkIGluIFNlY3Rpb24gMy4xLjcgb2Yg UkZDMjc2NCBhbmQgc2hvdWxkIGJlIGNpdGVkIGFzIHN1Y2guDQo+ID4+PiBBdCBsZWFzdCwgdGhh dCBpcyB3aGF0IEJvYiBCLiBzdWdnZXN0ZWQgdG8gbWUgYWJvdXQgMTB5cnMgYWdvLg0KPiA+PiBJ J2xsIGNoZWNrIHRoYXQuLi4NCj4gPiBQbGVhc2Ugc2VlIHRoZSBmaW5hbCBwYXJhZ3JhcGggb2Yg U2VjdGlvbiAzLjEyIG9mIHRoZSBBRVJPIHNwZWMgZm9yIGV4YW1wbGUNCj4gPiB0ZXh0Lg0KPiA+ DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0K PiA+PiAtLS0tDQo+ID4NCj4gDQoNCg== From nobody Wed May 3 13:40:51 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9199129B4C for ; Wed, 3 May 2017 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 2_reehbcnToh for ; Wed, 3 May 2017 13:40:49 -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 8B5CD129C62 for ; Wed, 3 May 2017 13:38:44 -0700 (PDT) Received: from [128.9.184.18] ([128.9.184.18]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v43KcQER000848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 May 2017 13:38:26 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> From: Joe Touch Message-ID: <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> Date: Wed, 3 May 2017 13:38:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-MailScanner-ID: v43KcQER000848 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:40:51 -0000 HI, Fred, On 5/3/2017 1:07 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Wednesday, May 03, 2017 11:47 AM >> To: Templin, Fred L >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> Hi, Fred, >> >> Your response keeps raising the same issues that I think we agree upon: >> >> - PMTUD always has the possibility of creating black holes (whether >> in the presence of multipath or not) >> >> - PLPMTUD can generate cases where the MIN isn't actually detected >> >> and some claims with which I disagree: >> >> - that PMPMTUD probes travel different paths than the data > I think I have already said this many times, but let me try again. The > tunnel ingress is not the source of the transit packet; it is only the > source of the tunnel packet. And, the ingress may have to tunnel > a wide variety of transit packets sourced by many original sources. > So, if ECMP somewhere within the tunnel peeks at the transit > packet, then the packet could take a very different path within > the tunnel than the ingress' PLPMTUD probes took. OK, so we have to separate things out. PLPMTUD E2E will still work fine - or not - and isn't affected by the presence of a tunnel per se. The same is true for PMTUD E2E. The issue is how the tunnel itself figures out MTU values larger than the required minimums for transit to the egress. There are two cases: - for egress reassembly, a tunnel protocol can communicate that reassembly MTU explicitly (and the MIN taken for multipoint tunnels, as with multicast) - for transit between ingress and egress, the tunnel would need to either use PMTUD (and be susceptible to black holes) or PLPMTUD - if it uses PLPMTUD, then steps need to be taken to either establish the ingress-egress as a single flow (so that ECMP would treat it as such) or to somehow try to manage subsets of arriving flows as a single flow and any such method needs to be careful to ensure that the probe packets are not distinguishable from non-probes, or could create false information Would that be sufficient? ... > >> Those probes should be used to determine an MTU only for a >> given flow; the potential hazards of sharing that information across >> flows is already discussed in that RFC. > I don't think RFC4821 does enough to take ECMP into account when it > talks about storing and sharing discovered MTUs. While I agree, this document is not intended to update that nor to account for its deficiencies, so I'm not sure what to add other than as stated above. ... > >> I don't yet see any explanation as to why this would be true. >> >> So I'm left with the following, which I propose as the way forward: >> >> - the text will be clear about the potential issues for multipath >> potentially taking a long time to converge > It's not that it could take a long time to converge - it is that it might > never converge if some paths of the multipath block ICMPs. If the path can't differentiate data and probes (see above), I can't see how they can be prevented from converging. ... > ... > The tunnel ingress is only the source of the tunnel packets; it is not the > source of the transit packets. The only way for PLPMTUD to function > properly in the presence of ECMP would be for the source of the transit > packets to do the RFC4821 probing - not the tunnel ingress. Agreed - the only reason the ingress would want to do PLPMTUD probing is to increase the size of the chunks sent to the egress. Joe From nobody Wed May 3 14:26:27 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DA7129B34 for ; Wed, 3 May 2017 14:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 6Zp71Pg-d1vd for ; Wed, 3 May 2017 14:26:24 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 7BA2E129B4F for ; Wed, 3 May 2017 14:24:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v43LOnXM015603; Wed, 3 May 2017 14:24:50 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v43LOdSS015537 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 3 May 2017 14:24:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 14:24:38 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 3 May 2017 14:24:38 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKCAAI2TgP//mgIggACFEQD//4vQgA== Date: Wed, 3 May 2017 21:24:38 +0000 Message-ID: References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> In-Reply-To: <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:26:26 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAzLCAyMDE3 IDE6MzggUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bT4NCj4gQ2M6IGludC1hcmVhQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA1LnR4dA0KPiANCj4gSEksIEZy ZWQsDQo+IA0KPiBPbiA1LzMvMjAxNyAxOjA3IFBNLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ ID4gSGkgSm9lLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+IFNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDAzLCAyMDE3IDExOjQ3IEFNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4+IENjOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiA+PiBT dWJqZWN0OiBSZTogW0ludC1hcmVhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVu bmVscy0wNS50eHQNCj4gPj4NCj4gPj4gSGksIEZyZWQsDQo+ID4+DQo+ID4+IFlvdXIgcmVzcG9u c2Uga2VlcHMgcmFpc2luZyB0aGUgc2FtZSBpc3N1ZXMgdGhhdCBJIHRoaW5rIHdlIGFncmVlIHVw b246DQo+ID4+DQo+ID4+ICAgICAtIFBNVFVEIGFsd2F5cyBoYXMgdGhlIHBvc3NpYmlsaXR5IG9m IGNyZWF0aW5nIGJsYWNrIGhvbGVzICh3aGV0aGVyDQo+ID4+IGluIHRoZSBwcmVzZW5jZSBvZiBt dWx0aXBhdGggb3Igbm90KQ0KPiA+Pg0KPiA+PiAgICAgLSBQTFBNVFVEIGNhbiBnZW5lcmF0ZSBj YXNlcyB3aGVyZSB0aGUgTUlOIGlzbid0IGFjdHVhbGx5IGRldGVjdGVkDQo+ID4+DQo+ID4+IGFu ZCBzb21lIGNsYWltcyB3aXRoIHdoaWNoIEkgZGlzYWdyZWU6DQo+ID4+DQo+ID4+ICAgICAtIHRo YXQgUE1QTVRVRCBwcm9iZXMgdHJhdmVsIGRpZmZlcmVudCBwYXRocyB0aGFuIHRoZSBkYXRhDQo+ ID4gSSB0aGluayBJIGhhdmUgYWxyZWFkeSBzYWlkIHRoaXMgbWFueSB0aW1lcywgYnV0IGxldCBt ZSB0cnkgYWdhaW4uIFRoZQ0KPiA+IHR1bm5lbCBpbmdyZXNzIGlzIG5vdCB0aGUgc291cmNlIG9m IHRoZSB0cmFuc2l0IHBhY2tldDsgaXQgaXMgb25seSB0aGUNCj4gPiBzb3VyY2Ugb2YgdGhlIHR1 bm5lbCBwYWNrZXQuIEFuZCwgdGhlIGluZ3Jlc3MgbWF5IGhhdmUgdG8gdHVubmVsDQo+ID4gYSB3 aWRlIHZhcmlldHkgb2YgdHJhbnNpdCBwYWNrZXRzIHNvdXJjZWQgYnkgbWFueSBvcmlnaW5hbCBz b3VyY2VzLg0KPiA+IFNvLCBpZiBFQ01QIHNvbWV3aGVyZSB3aXRoaW4gdGhlIHR1bm5lbCBwZWVr cyBhdCB0aGUgdHJhbnNpdA0KPiA+IHBhY2tldCwgdGhlbiB0aGUgcGFja2V0IGNvdWxkIHRha2Ug YSB2ZXJ5IGRpZmZlcmVudCBwYXRoIHdpdGhpbg0KPiA+IHRoZSB0dW5uZWwgdGhhbiB0aGUgaW5n cmVzcycgUExQTVRVRCBwcm9iZXMgdG9vay4NCj4gT0ssIHNvIHdlIGhhdmUgdG8gc2VwYXJhdGUg dGhpbmdzIG91dC4NCj4gDQo+IFBMUE1UVUQgRTJFIHdpbGwgc3RpbGwgd29yayBmaW5lIC0gb3Ig bm90IC0gYW5kIGlzbid0IGFmZmVjdGVkIGJ5IHRoZQ0KPiBwcmVzZW5jZSBvZiBhIHR1bm5lbCBw ZXIgc2UuDQoNCkFncmVlZCAtIEUyRSBmcm9tIHRyYW5zaXQgcGFja2V0IHNvdXJjZSB0byB0cmFu c2l0IHBhY2tldCBkZXN0aW5hdGlvbiBpcw0Kbm90IGFmZmVjdGVkIGJ5IHRoZSBwcmVzZW5jZSBv ZiB0aGUgdHVubmVsLg0KIA0KPiBUaGUgc2FtZSBpcyB0cnVlIGZvciBQTVRVRCBFMkUuDQoNCk9L Lg0KDQo+IFRoZSBpc3N1ZSBpcyBob3cgdGhlICB0dW5uZWwgaXRzZWxmIGZpZ3VyZXMgb3V0IE1U VSB2YWx1ZXMgbGFyZ2VyIHRoYW4NCj4gdGhlIHJlcXVpcmVkIG1pbmltdW1zIGZvciB0cmFuc2l0 IHRvIHRoZSBlZ3Jlc3MuIFRoZXJlIGFyZSB0d28gY2FzZXM6DQo+ICAgICAtIGZvciBlZ3Jlc3Mg cmVhc3NlbWJseSwgYSB0dW5uZWwgcHJvdG9jb2wgY2FuIGNvbW11bmljYXRlIHRoYXQNCj4gcmVh c3NlbWJseSBNVFUgZXhwbGljaXRseSAoYW5kIHRoZSBNSU4gdGFrZW4gZm9yIG11bHRpcG9pbnQg dHVubmVscywgYXMNCj4gd2l0aCBtdWx0aWNhc3QpDQoNCkkgdGhvdWdodCBmb3IgbXVsdGlwb2lu dCB0dW5uZWxzIGFsbCBlZ3Jlc3MnIGhhZCB0byBoYXZlIHRoZSBzYW1lIHJlYXNzZW1ibHkNCk1U VT8gT3IsIGlmIHRha2luZyB0aGUgbWluaW11bSwgdGhhdCBtaW5pbXVtIHZhbHVlIGNvdWxkIGJl IGNvbnZleWVkIGluDQp0aGUgTVRVIG9wdGlvbiBpbiBhIFJvdXRlciBBZHZlcnRpc2VtZW50IG1l c3NhZ2UuDQoNCj4gICAgIC0gZm9yIHRyYW5zaXQgYmV0d2VlbiBpbmdyZXNzIGFuZCBlZ3Jlc3Ms IHRoZSB0dW5uZWwgd291bGQgbmVlZCB0bw0KPiBlaXRoZXIgdXNlIFBNVFVEIChhbmQgYmUgc3Vz Y2VwdGlibGUgdG8gYmxhY2sgaG9sZXMpDQoNClllcy4NCg0KPiBvciBQTFBNVFVEDQo+ICAgICAg ICAgLSBpZiBpdCB1c2VzIFBMUE1UVUQsIHRoZW4gc3RlcHMgbmVlZCB0byBiZSB0YWtlbiB0byBl aXRoZXINCj4gZXN0YWJsaXNoIHRoZSBpbmdyZXNzLWVncmVzcyBhcyBhIHNpbmdsZSBmbG93IChz byB0aGF0IEVDTVAgd291bGQgdHJlYXQNCj4gaXQgYXMgc3VjaCkgb3IgdG8gc29tZWhvdyB0cnkg dG8gbWFuYWdlIHN1YnNldHMgb2YgYXJyaXZpbmcgZmxvd3MgYXMgYQ0KPiBzaW5nbGUgZmxvdw0K DQpUaGUgInBpcGUgbW9kZWwiLCB5ZXMuIFRoZSBvbmx5IHByb2JsZW0gaXMgdGhhdCBhbiBFQ01Q IGRldmljZSBjb3VsZCBzdGlsbA0KZG8gZGVlcC1wYWNrZXQgaW5zcGVjdGlvbiBhbmQgbWFrZSBt dWx0aXBhdGggZGVjaXNpb25zIGJhc2VkIG9uIHRoZQ0KdHJhbnNpdCBwYWNrZXQuDQoNCj4gICAg ICAgICAgICAgYW5kIGFueSBzdWNoIG1ldGhvZCBuZWVkcyB0byBiZSBjYXJlZnVsIHRvIGVuc3Vy ZSB0aGF0IHRoZQ0KPiBwcm9iZSBwYWNrZXRzIGFyZSBub3QgZGlzdGluZ3Vpc2hhYmxlIGZyb20g bm9uLXByb2Jlcywgb3IgY291bGQgY3JlYXRlDQo+IGZhbHNlIGluZm9ybWF0aW9uDQo+IA0KPiBX b3VsZCB0aGF0IGJlIHN1ZmZpY2llbnQ/DQoNCkkgdGhpbmsgc29tZSB3b3VsZCBzdGlsbCBzYXkg dGhhdCBhbiBFQ01QIGRldmljZSB0aGF0IGRvZXMgZGVlcCBwYWNrZXQNCmluc3BlY3Rpb24gY291 bGQgc3RpbGwgdHJpZ2dlciBtdWx0aXBhdGggYmFzZWQgb24gdGhlIHRyYW5zaXQgcGFja2V0Lg0K DQo+ID4+IFRob3NlIHByb2JlcyBzaG91bGQgYmUgdXNlZCB0byBkZXRlcm1pbmUgYW4gTVRVIG9u bHkgZm9yIGENCj4gPj4gZ2l2ZW4gZmxvdzsgdGhlIHBvdGVudGlhbCBoYXphcmRzIG9mIHNoYXJp bmcgdGhhdCBpbmZvcm1hdGlvbiBhY3Jvc3MNCj4gPj4gZmxvd3MgaXMgYWxyZWFkeSBkaXNjdXNz ZWQgaW4gdGhhdCBSRkMuDQo+ID4gSSBkb24ndCB0aGluayBSRkM0ODIxIGRvZXMgZW5vdWdoIHRv IHRha2UgRUNNUCBpbnRvIGFjY291bnQgd2hlbiBpdA0KPiA+IHRhbGtzIGFib3V0IHN0b3Jpbmcg YW5kIHNoYXJpbmcgZGlzY292ZXJlZCBNVFVzLg0KPiBXaGlsZSBJIGFncmVlLCB0aGlzIGRvY3Vt ZW50IGlzIG5vdCBpbnRlbmRlZCB0byB1cGRhdGUgdGhhdCBub3IgdG8NCj4gYWNjb3VudCBmb3Ig aXRzIGRlZmljaWVuY2llcywgc28gSSdtIG5vdCBzdXJlIHdoYXQgdG8gYWRkIG90aGVyIHRoYW4g YXMNCj4gc3RhdGVkIGFib3ZlLg0KDQpBZ3JlZWQsIHRoaXMgaXMgYW4gUkZDNDgyMSBpc3N1ZSBh bmQgcG90ZW50aWFsbHkgc3ViamVjdCBmb3IgYW4gZXJyYXR1bQ0KZm9yIHRoYXQgZG9jdW1lbnQg KG5vdCB0aGlzIG9uZSkuDQoNCj4gLi4uDQo+ID4NCj4gPj4gSSBkb24ndCB5ZXQgc2VlIGFueSBl eHBsYW5hdGlvbiBhcyB0byB3aHkgdGhpcyB3b3VsZCBiZSB0cnVlLg0KPiA+Pg0KPiA+PiBTbyBJ J20gbGVmdCB3aXRoIHRoZSBmb2xsb3dpbmcsIHdoaWNoIEkgcHJvcG9zZSBhcyB0aGUgd2F5IGZv cndhcmQ6DQo+ID4+DQo+ID4+ICAgICAtIHRoZSB0ZXh0IHdpbGwgYmUgY2xlYXIgYWJvdXQgdGhl IHBvdGVudGlhbCBpc3N1ZXMgZm9yIG11bHRpcGF0aA0KPiA+PiBwb3RlbnRpYWxseSB0YWtpbmcg YSBsb25nIHRpbWUgdG8gY29udmVyZ2UNCj4gPiBJdCdzIG5vdCB0aGF0IGl0IGNvdWxkIHRha2Ug YSBsb25nIHRpbWUgdG8gY29udmVyZ2UgLSBpdCBpcyB0aGF0IGl0IG1pZ2h0DQo+ID4gbmV2ZXIg Y29udmVyZ2UgaWYgc29tZSBwYXRocyBvZiB0aGUgbXVsdGlwYXRoIGJsb2NrIElDTVBzLg0KPiBJ ZiB0aGUgcGF0aCBjYW4ndCBkaWZmZXJlbnRpYXRlIGRhdGEgYW5kIHByb2JlcyAoc2VlIGFib3Zl KSwgSSBjYW4ndCBzZWUNCj4gaG93IHRoZXkgY2FuIGJlIHByZXZlbnRlZCBmcm9tIGNvbnZlcmdp bmcuDQoNCklmIHRoZSB0cmFuc2l0IHBhY2tldCBpcyB2aXNpYmxlIGluLXRoZS1jbGVhciwgdGhl biBzb21lIGRlZXAtcGFja2V0DQppbnNwZWN0aW5nIEVDTVAgZGV2aWNlIGNvdWxkIHN0aWxsIGlu dm9rZSBtdWx0aXBhdGguIEJ1dCwgaXQganVzdCBvY2N1cnJlZA0KdG8gbWUgdGhhdCBpZiB0aGUg dHJhbnNpdCBwYWNrZXQgaXMgZW5jcnlwdGVkIHRoZW4gRUNNUCBkZXZpY2VzIHdvdWxkDQpvbmx5 IHNlZSB0aGUgdHVubmVsIHBhY2tldCBoZWFkZXJzIGFuZCBub3QgdGhlIHRyYW5zaXQuIFNvLCBt YXliZSB0aGUNCnR1bm5lbCBjYW4gaW1wbGVtZW50IHRoZSBSRkM0ODIxIHBpcGUgbW9kZWwgZm9y IElQc2VjL1RMUz8NCg0KPiA+IC4uLg0KPiA+IFRoZSB0dW5uZWwgaW5ncmVzcyBpcyBvbmx5IHRo ZSBzb3VyY2Ugb2YgdGhlIHR1bm5lbCBwYWNrZXRzOyBpdCBpcyBub3QgdGhlDQo+ID4gc291cmNl IG9mIHRoZSB0cmFuc2l0IHBhY2tldHMuIFRoZSBvbmx5IHdheSBmb3IgUExQTVRVRCB0byBmdW5j dGlvbg0KPiA+IHByb3Blcmx5IGluIHRoZSBwcmVzZW5jZSBvZiBFQ01QIHdvdWxkIGJlIGZvciB0 aGUgc291cmNlIG9mIHRoZSB0cmFuc2l0DQo+ID4gcGFja2V0cyB0byBkbyB0aGUgUkZDNDgyMSBw cm9iaW5nIC0gbm90IHRoZSB0dW5uZWwgaW5ncmVzcy4NCj4gQWdyZWVkIC0gdGhlIG9ubHkgcmVh c29uIHRoZSBpbmdyZXNzIHdvdWxkIHdhbnQgdG8gZG8gUExQTVRVRCBwcm9iaW5nIGlzDQo+IHRv IGluY3JlYXNlIHRoZSBzaXplIG9mIHRoZSBjaHVua3Mgc2VudCB0byB0aGUgZWdyZXNzLg0KDQpJ IHRoaW5rIGl0IHN0aWxsIHdvdWxkIGhhdmUgcHJvYmxlbXMuIEZvciBpbnN0YW5jZSwgaWYgaXQg ZGlzY292ZXJlZCB0aGF0IGENCjE0MDBieXRlIGNodW5rIGNvdWxkIGZpdCBvdmVyIG9uZSBwYXRo IGluIHRoZSBtdWx0aXBhdGgsIGFub3RoZXIgcGF0aA0KY291bGQgYmUgY29uc3RyYWluZWQgdG8g b25seSAxMzk5IGJ5dGVzIGFuZCBFQ01QIGNvdWxkIGJpdGUgeW91IGFnYWluLg0KDQpUaGFua3Mg LSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gSm9lDQoNCg== From nobody Wed May 3 14:40:13 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471CB127775 for ; Wed, 3 May 2017 14:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 zaZyPCBSRu4H for ; Wed, 3 May 2017 14:40:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 75F3A129484 for ; Wed, 3 May 2017 14:38:40 -0700 (PDT) Received: from [128.9.184.18] ([128.9.184.18]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v43LcObX012882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 May 2017 14:38:25 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> From: Joe Touch Message-ID: <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu> Date: Wed, 3 May 2017 14:38:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:40:11 -0000 Winnowing down... I think we're converging. Let me know if not... Joe On 5/3/2017 2:24 PM, Templin, Fred L wrote: > ... > I thought for multipoint tunnels all egress' had to have the same reassembly > MTU? Or, if taking the minimum, that minimum value could be conveyed in > the MTU option in a Router Advertisement message. The egresses could theoretically convey different reassembly MTUs, but the ingress would take the min. If you have a control protocol that has all the information, you can push that operation there. > >> or PLPMTUD >> - if it uses PLPMTUD, then steps need to be taken to either >> establish the ingress-egress as a single flow (so that ECMP would treat >> it as such) or to somehow try to manage subsets of arriving flows as a >> single flow > The "pipe model", yes. The only problem is that an ECMP device could still > do deep-packet inspection and make multipath decisions based on the > transit packet. See next response... >> and any such method needs to be careful to ensure that the >> probe packets are not distinguishable from non-probes, or could create >> false information >> >> Would that be sufficient? > I think some would still say that an ECMP device that does deep packet > inspection could still trigger multipath based on the transit packet. I think I already cover that in saying "not distinguishable" (e.g., either by encryption or mimicry) > >> ... >>>> I don't yet see any explanation as to why this would be true. >>>> >>>> So I'm left with the following, which I propose as the way forward: >>>> >>>> - the text will be clear about the potential issues for multipath >>>> potentially taking a long time to converge >>> It's not that it could take a long time to converge - it is that it might >>> never converge if some paths of the multipath block ICMPs. >> If the path can't differentiate data and probes (see above), I can't see >> how they can be prevented from converging. > If the transit packet is visible in-the-clear, then some deep-packet > inspecting ECMP device could still invoke multipath. But, it just occurred > to me that if the transit packet is encrypted then ECMP devices would > only see the tunnel packet headers and not the transit. So, maybe the > tunnel can implement the RFC4821 pipe model for IPsec/TLS? Encryption is one approach. Some sort of mimicry is another - e.g., if the ingress encapsulation includes both net and transport, with ports assigned per "flow group" (such that a single incoming flow belongs to only one tunneled flow). >>> ... >>> The tunnel ingress is only the source of the tunnel packets; it is not the >>> source of the transit packets. The only way for PLPMTUD to function >>> properly in the presence of ECMP would be for the source of the transit >>> packets to do the RFC4821 probing - not the tunnel ingress. >> Agreed - the only reason the ingress would want to do PLPMTUD probing is >> to increase the size of the chunks sent to the egress. > I think it still would have problems. For instance, if it discovered that a > 1400byte chunk could fit over one path in the multipath, another path > could be constrained to only 1399 bytes and ECMP could bite you again. If that happens, PLPMTUD would learn it and adapt. Either enough packets would get through or the ingress would adapt. Joe From nobody Wed May 3 15:01:22 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57103126D05 for ; Wed, 3 May 2017 15:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Tr12tzxc2PVM for ; Wed, 3 May 2017 15:01:19 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 567F01293F5 for ; Wed, 3 May 2017 14:59:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v43LxYY9002488; Wed, 3 May 2017 14:59:35 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v43LxQNC002425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 3 May 2017 14:59:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 3 May 2017 14:59:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 3 May 2017 14:59:26 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKCAAI2TgP//mgIggACFEQD//4vQgIAAhPEA//+PBIA= Date: Wed, 3 May 2017 21:59:25 +0000 Message-ID: <17638cfa5cfe403b80071162ddc4bd17@XCH15-06-08.nw.nos.boeing.com> References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu> In-Reply-To: <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:01:21 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAzLCAyMDE3 IDI6MzggUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bT4NCj4gQ2M6IGludC1hcmVhQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA1LnR4dA0KPiANCj4gV2lubm93 aW5nIGRvd24uLi4gSSB0aGluayB3ZSdyZSBjb252ZXJnaW5nLiBMZXQgbWUga25vdyBpZiBub3Qu Li4NCj4gDQo+IEpvZQ0KPiANCj4gDQo+IE9uIDUvMy8yMDE3IDI6MjQgUE0sIFRlbXBsaW4sIEZy ZWQgTCB3cm90ZToNCj4gPiAuLi4NCj4gPiBJIHRob3VnaHQgZm9yIG11bHRpcG9pbnQgdHVubmVs cyBhbGwgZWdyZXNzJyBoYWQgdG8gaGF2ZSB0aGUgc2FtZSByZWFzc2VtYmx5DQo+ID4gTVRVPyBP ciwgaWYgdGFraW5nIHRoZSBtaW5pbXVtLCB0aGF0IG1pbmltdW0gdmFsdWUgY291bGQgYmUgY29u dmV5ZWQgaW4NCj4gPiB0aGUgTVRVIG9wdGlvbiBpbiBhIFJvdXRlciBBZHZlcnRpc2VtZW50IG1l c3NhZ2UuDQo+IFRoZSBlZ3Jlc3NlcyBjb3VsZCB0aGVvcmV0aWNhbGx5IGNvbnZleSBkaWZmZXJl bnQgcmVhc3NlbWJseSBNVFVzLCBidXQNCj4gdGhlIGluZ3Jlc3Mgd291bGQgdGFrZSB0aGUgbWlu LiBJZiB5b3UgaGF2ZSAgYSBjb250cm9sIHByb3RvY29sIHRoYXQgaGFzDQo+IGFsbCB0aGUgaW5m b3JtYXRpb24sIHlvdSBjYW4gcHVzaCB0aGF0IG9wZXJhdGlvbiB0aGVyZS4NCg0KU291bmRzIE9L Lg0KDQo+ID4+IG9yIFBMUE1UVUQNCj4gPj4gICAgICAgICAtIGlmIGl0IHVzZXMgUExQTVRVRCwg dGhlbiBzdGVwcyBuZWVkIHRvIGJlIHRha2VuIHRvIGVpdGhlcg0KPiA+PiBlc3RhYmxpc2ggdGhl IGluZ3Jlc3MtZWdyZXNzIGFzIGEgc2luZ2xlIGZsb3cgKHNvIHRoYXQgRUNNUCB3b3VsZCB0cmVh dA0KPiA+PiBpdCBhcyBzdWNoKSBvciB0byBzb21laG93IHRyeSB0byBtYW5hZ2Ugc3Vic2V0cyBv ZiBhcnJpdmluZyBmbG93cyBhcyBhDQo+ID4+IHNpbmdsZSBmbG93DQo+ID4gVGhlICJwaXBlIG1v ZGVsIiwgeWVzLiBUaGUgb25seSBwcm9ibGVtIGlzIHRoYXQgYW4gRUNNUCBkZXZpY2UgY291bGQg c3RpbGwNCj4gPiBkbyBkZWVwLXBhY2tldCBpbnNwZWN0aW9uIGFuZCBtYWtlIG11bHRpcGF0aCBk ZWNpc2lvbnMgYmFzZWQgb24gdGhlDQo+ID4gdHJhbnNpdCBwYWNrZXQuDQo+IFNlZSBuZXh0IHJl c3BvbnNlLi4uDQo+ID4+ICAgICAgICAgICAgIGFuZCBhbnkgc3VjaCBtZXRob2QgbmVlZHMgdG8g YmUgY2FyZWZ1bCB0byBlbnN1cmUgdGhhdCB0aGUNCj4gPj4gcHJvYmUgcGFja2V0cyBhcmUgbm90 IGRpc3Rpbmd1aXNoYWJsZSBmcm9tIG5vbi1wcm9iZXMsIG9yIGNvdWxkIGNyZWF0ZQ0KPiA+PiBm YWxzZSBpbmZvcm1hdGlvbg0KPiA+Pg0KPiA+PiBXb3VsZCB0aGF0IGJlIHN1ZmZpY2llbnQ/DQo+ ID4gSSB0aGluayBzb21lIHdvdWxkIHN0aWxsIHNheSB0aGF0IGFuIEVDTVAgZGV2aWNlIHRoYXQg ZG9lcyBkZWVwIHBhY2tldA0KPiA+IGluc3BlY3Rpb24gY291bGQgc3RpbGwgdHJpZ2dlciBtdWx0 aXBhdGggYmFzZWQgb24gdGhlIHRyYW5zaXQgcGFja2V0Lg0KPiANCj4gSSB0aGluayBJIGFscmVh ZHkgY292ZXIgdGhhdCBpbiBzYXlpbmcgIm5vdCBkaXN0aW5ndWlzaGFibGUiIChlLmcuLA0KPiBl aXRoZXIgYnkgZW5jcnlwdGlvbiBvciBtaW1pY3J5KQ0KDQpFbmNyeXB0aW9uIGZvciBzdXJlLCB5 ZXMuIEJ1dCwgSSdtIG5vdCBzdXJlIGFib3V0IG1pbWljcnkuDQoNCj4gPg0KPiA+PiAuLi4NCj4g Pj4+PiBJIGRvbid0IHlldCBzZWUgYW55IGV4cGxhbmF0aW9uIGFzIHRvIHdoeSB0aGlzIHdvdWxk IGJlIHRydWUuDQo+ID4+Pj4NCj4gPj4+PiBTbyBJJ20gbGVmdCB3aXRoIHRoZSBmb2xsb3dpbmcs IHdoaWNoIEkgcHJvcG9zZSBhcyB0aGUgd2F5IGZvcndhcmQ6DQo+ID4+Pj4NCj4gPj4+PiAgICAg LSB0aGUgdGV4dCB3aWxsIGJlIGNsZWFyIGFib3V0IHRoZSBwb3RlbnRpYWwgaXNzdWVzIGZvciBt dWx0aXBhdGgNCj4gPj4+PiBwb3RlbnRpYWxseSB0YWtpbmcgYSBsb25nIHRpbWUgdG8gY29udmVy Z2UNCj4gPj4+IEl0J3Mgbm90IHRoYXQgaXQgY291bGQgdGFrZSBhIGxvbmcgdGltZSB0byBjb252 ZXJnZSAtIGl0IGlzIHRoYXQgaXQgbWlnaHQNCj4gPj4+IG5ldmVyIGNvbnZlcmdlIGlmIHNvbWUg cGF0aHMgb2YgdGhlIG11bHRpcGF0aCBibG9jayBJQ01Qcy4NCj4gPj4gSWYgdGhlIHBhdGggY2Fu J3QgZGlmZmVyZW50aWF0ZSBkYXRhIGFuZCBwcm9iZXMgKHNlZSBhYm92ZSksIEkgY2FuJ3Qgc2Vl DQo+ID4+IGhvdyB0aGV5IGNhbiBiZSBwcmV2ZW50ZWQgZnJvbSBjb252ZXJnaW5nLg0KPiA+IElm IHRoZSB0cmFuc2l0IHBhY2tldCBpcyB2aXNpYmxlIGluLXRoZS1jbGVhciwgdGhlbiBzb21lIGRl ZXAtcGFja2V0DQo+ID4gaW5zcGVjdGluZyBFQ01QIGRldmljZSBjb3VsZCBzdGlsbCBpbnZva2Ug bXVsdGlwYXRoLiBCdXQsIGl0IGp1c3Qgb2NjdXJyZWQNCj4gPiB0byBtZSB0aGF0IGlmIHRoZSB0 cmFuc2l0IHBhY2tldCBpcyBlbmNyeXB0ZWQgdGhlbiBFQ01QIGRldmljZXMgd291bGQNCj4gPiBv bmx5IHNlZSB0aGUgdHVubmVsIHBhY2tldCBoZWFkZXJzIGFuZCBub3QgdGhlIHRyYW5zaXQuIFNv LCBtYXliZSB0aGUNCj4gPiB0dW5uZWwgY2FuIGltcGxlbWVudCB0aGUgUkZDNDgyMSBwaXBlIG1v ZGVsIGZvciBJUHNlYy9UTFM/DQo+IEVuY3J5cHRpb24gaXMgb25lIGFwcHJvYWNoLg0KDQpSaWdo dC4NCg0KPiBTb21lIHNvcnQgb2YgbWltaWNyeSBpcyBhbm90aGVyIC0gZS5nLiwgaWYNCj4gdGhl IGluZ3Jlc3MgZW5jYXBzdWxhdGlvbiBpbmNsdWRlcyBib3RoIG5ldCBhbmQgdHJhbnNwb3J0LCB3 aXRoIHBvcnRzDQo+IGFzc2lnbmVkIHBlciAiZmxvdyBncm91cCIgKHN1Y2ggdGhhdCBhIHNpbmds ZSBpbmNvbWluZyBmbG93IGJlbG9uZ3MgdG8NCj4gb25seSBvbmUgdHVubmVsZWQgZmxvdykuDQoN CkkgdGhpbmsgdGhpcyBkZXBlbmRzIG9uIGhvdyBkZWVwIHRoZSBFQ01QIGRldmljZSBjb3VsZCBp bnNwZWN0LiBJZiBpdA0KZ29lcyBwYXN0IGFsbCBvZiB0aGUgdHVubmVsIGhlYWRlcnMgYW5kIGlu c3BlY3RzIHRoZSB0cmFuc2l0IHBhY2tldCB0aGVuDQpFQ01QIHByb2JsZW1zIGNhbiBvY2N1ci4N Cg0KPiA+Pj4gLi4uDQo+ID4+PiBUaGUgdHVubmVsIGluZ3Jlc3MgaXMgb25seSB0aGUgc291cmNl IG9mIHRoZSB0dW5uZWwgcGFja2V0czsgaXQgaXMgbm90IHRoZQ0KPiA+Pj4gc291cmNlIG9mIHRo ZSB0cmFuc2l0IHBhY2tldHMuIFRoZSBvbmx5IHdheSBmb3IgUExQTVRVRCB0byBmdW5jdGlvbg0K PiA+Pj4gcHJvcGVybHkgaW4gdGhlIHByZXNlbmNlIG9mIEVDTVAgd291bGQgYmUgZm9yIHRoZSBz b3VyY2Ugb2YgdGhlIHRyYW5zaXQNCj4gPj4+IHBhY2tldHMgdG8gZG8gdGhlIFJGQzQ4MjEgcHJv YmluZyAtIG5vdCB0aGUgdHVubmVsIGluZ3Jlc3MuDQo+ID4+IEFncmVlZCAtIHRoZSBvbmx5IHJl YXNvbiB0aGUgaW5ncmVzcyB3b3VsZCB3YW50IHRvIGRvIFBMUE1UVUQgcHJvYmluZyBpcw0KPiA+ PiB0byBpbmNyZWFzZSB0aGUgc2l6ZSBvZiB0aGUgY2h1bmtzIHNlbnQgdG8gdGhlIGVncmVzcy4N Cj4gPiBJIHRoaW5rIGl0IHN0aWxsIHdvdWxkIGhhdmUgcHJvYmxlbXMuIEZvciBpbnN0YW5jZSwg aWYgaXQgZGlzY292ZXJlZCB0aGF0IGENCj4gPiAxNDAwYnl0ZSBjaHVuayBjb3VsZCBmaXQgb3Zl ciBvbmUgcGF0aCBpbiB0aGUgbXVsdGlwYXRoLCBhbm90aGVyIHBhdGgNCj4gPiBjb3VsZCBiZSBj b25zdHJhaW5lZCB0byBvbmx5IDEzOTkgYnl0ZXMgYW5kIEVDTVAgY291bGQgYml0ZSB5b3UgYWdh aW4uDQo+IElmIHRoYXQgaGFwcGVucywgUExQTVRVRCB3b3VsZCBsZWFybiBpdCBhbmQgYWRhcHQu IEVpdGhlciBlbm91Z2ggcGFja2V0cw0KPiB3b3VsZCBnZXQgdGhyb3VnaCBvciB0aGUgaW5ncmVz cyB3b3VsZCBhZGFwdC4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCBpZiB0aGVyZSBhcmUgTiBwYXRo cyBpbiB0aGUgbXVsdGlwYXRoIHRoZSBpbmdyZXNzIGhhcw0Kbm8gd2F5IG9mIGtub3dpbmcgdGhh dCBpdCBoYXMgcHJvYmVkIGFsbCBOIG9mIHRoZW0uIEFuZCwgaWYgYSB0cmFuc2l0DQpwYWNrZXQg YXJyaXZlcyB0aGF0IHdvdWxkIGJlIHR1bm5lbGVkIG92ZXIgYSBwYXRoIHRoYXQgaGFzIG5vdCBi ZWVuDQpwcm9iZWQsIGl0IGNvdWxkIGJsYWNrIGhvbGUgaWYgdGhlIE1UVSBpcyB0b28gc21hbGwu DQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBKb2UNCg0K From nobody Wed May 3 15:05:55 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D562129537 for ; Wed, 3 May 2017 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 blENBCBtlMxg for ; Wed, 3 May 2017 15:05:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 94E60129566 for ; Wed, 3 May 2017 15:04:40 -0700 (PDT) Received: from [128.9.184.18] ([128.9.184.18]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v43M4CI8024293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 May 2017 15:04:13 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu> <17638cfa5cfe403b80071162ddc4bd17@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <00d01e30-4a38-25c6-0833-bb99fb2ead33@isi.edu> Date: Wed, 3 May 2017 15:04:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <17638cfa5cfe403b80071162ddc4bd17@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 22:05:53 -0000 Winding down to the last part: (I agree that encryption or mimicry is useful only when it works, but not much more can be said than that) On 5/3/2017 2:59 PM, Templin, Fred L wrote: > The problem is that if there are N paths in the multipath the ingress has > no way of knowing that it has probed all N of them. And, if a transit > packet arrives that would be tunneled over a path that has not been > probed, it could black hole if the MTU is too small. That's correct - PLPMTUD can fail at any time if the PMTU changes and becomes smaller (for any reason, including link reconfiguration, path changes, multipath selection). That's why it keeps retrying. Again, this isn't new or unique to tunnels. Joe From nobody Thu May 4 10:28:34 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D906124BFA for ; Thu, 4 May 2017 10:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 EeXdWkwZOI_z for ; Thu, 4 May 2017 10:28:31 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 D93D6129B02 for ; Thu, 4 May 2017 10:28:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v44HSQZ7043601; Thu, 4 May 2017 10:28:26 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v44HSOTI043595 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 4 May 2017 10:28:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 May 2017 10:28:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 4 May 2017 10:28:24 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIAAjvoAgDY8cKCAAI2TgP//mgIggACFEQD//4vQgIAAhPEA//+PBIAADwZFAAAZ3XRQ Date: Thu, 4 May 2017 17:28:24 +0000 Message-ID: <818637d87a754aa3b276a3d6fdb53882@XCH15-06-08.nw.nos.boeing.com> References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> <5a8c5001421e45d086107f208f08f2d2@XCH15-06-08.nw.nos.boeing.com> <03f6765b-a2c9-ae67-2aba-08c7f5e22a9c@isi.edu> <09d9f8ab-0d2b-c1d8-d075-e0c36d4669cf@isi.edu> <09203e2e-f72d-1ded-2bd5-8f2ed1041e32@isi.edu> <17638cfa5cfe403b80071162ddc4bd17@XCH15-06-08.nw.nos.boeing.com> <00d01e30-4a38-25c6-0833-bb99fb2ead33@isi.edu> In-Reply-To: <00d01e30-4a38-25c6-0833-bb99fb2ead33@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:28:32 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAzLCAyMDE3 IDM6MDQgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bT4NCj4gQ2M6IGludC1hcmVhQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA1LnR4dA0KPiANCj4gV2luZGlu ZyBkb3duIHRvIHRoZSBsYXN0IHBhcnQ6DQo+IA0KPiAoSSBhZ3JlZSB0aGF0IGVuY3J5cHRpb24g b3IgbWltaWNyeSBpcyB1c2VmdWwgb25seSB3aGVuIGl0IHdvcmtzLCBidXQNCj4gbm90IG11Y2gg bW9yZSBjYW4gYmUgc2FpZCB0aGFuIHRoYXQpDQo+IA0KPiANCj4gT24gNS8zLzIwMTcgMjo1OSBQ TSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IFRoZSBwcm9ibGVtIGlzIHRoYXQgaWYgdGhl cmUgYXJlIE4gcGF0aHMgaW4gdGhlIG11bHRpcGF0aCB0aGUgaW5ncmVzcyBoYXMNCj4gPiBubyB3 YXkgb2Yga25vd2luZyB0aGF0IGl0IGhhcyBwcm9iZWQgYWxsIE4gb2YgdGhlbS4gQW5kLCBpZiBh IHRyYW5zaXQNCj4gPiBwYWNrZXQgYXJyaXZlcyB0aGF0IHdvdWxkIGJlIHR1bm5lbGVkIG92ZXIg YSBwYXRoIHRoYXQgaGFzIG5vdCBiZWVuDQo+ID4gcHJvYmVkLCBpdCBjb3VsZCBibGFjayBob2xl IGlmIHRoZSBNVFUgaXMgdG9vIHNtYWxsLg0KPiANCj4gVGhhdCdzIGNvcnJlY3QgLSBQTFBNVFVE IGNhbiBmYWlsIGF0IGFueSB0aW1lIGlmIHRoZSBQTVRVIGNoYW5nZXMgYW5kDQo+IGJlY29tZXMg c21hbGxlciAoZm9yIGFueSByZWFzb24sIGluY2x1ZGluZyBsaW5rIHJlY29uZmlndXJhdGlvbiwg cGF0aA0KPiBjaGFuZ2VzLCBtdWx0aXBhdGggc2VsZWN0aW9uKS4NCj4gDQo+IFRoYXQncyB3aHkg aXQga2VlcHMgcmV0cnlpbmcuIEFnYWluLCB0aGlzIGlzbid0IG5ldyBvciB1bmlxdWUgdG8gdHVu bmVscy4NCg0KV2hhdCBpcyBkaWZmZXJlbnQgYWJvdXQgdHVubmVscyBpcyB0aGF0IHRoZXkgYXJl IHRoZSBzb3VyY2VzIG9mIHRoZSB0dW5uZWwNCnBhY2tldHMgYnV0IGFyZSBub3QgdGhlIHNvdXJj ZXMgb2YgdGhlIHRyYW5zaXQgcGFja2V0cy4gQW5kLCBleGNlcHQgZm9yDQpzb21lIHR1bm5lbC1p bnNlcnRlZCBvYmZ1c2NhdGlvbiBzdWNoIGFzIGVuY3J5cHRpb24sIHRoZXJlIGlzIG5vIHdheQ0K Zm9yIHRoZSB0dW5uZWwgdG8gYWN0IGxpa2UgaXQgaXMgdGhlIHNvdXJjZSBvZiB0aGUgdHJhbnNp dCBwYWNrZXRzLg0KDQpUaGF0IHNhaWQsIGl0IHNvdW5kcyBsaWtlIHlvdSBtYXkgaGF2ZSBzb21l IGlkZWFzIG9uIGhvdyB0byByZS1mb3JtdWxhdGUNCnNvbWUgb2YgdGhlIHRleHQuIElmIHlvdSB3 YW50IHRvIGRvIHRoYXQgYW5kIHRoZW4gaGF2ZSBtZSByZS1yZXZpZXcgaXQNCkkgY291bGQgZG8g dGhhdC4NCg0KVGhhbmtzIC0gRnJlZCANCg0KPiBKb2UNCj4gDQoNCg== From nobody Thu May 4 13:58:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A833A124C27 for ; Thu, 4 May 2017 13:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 1L84kufKWdgy for ; Thu, 4 May 2017 13:58:22 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 28997127977 for ; Thu, 4 May 2017 13:58:21 -0700 (PDT) X-AuditID: c6180641-813b39a000000cb9-e6-590b4f8fbcb3 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id A5.7D.03257.F8F4B095; Thu, 4 May 2017 17:58:08 +0200 (CEST) Received: from [155.53.28.77] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.92) with Microsoft SMTP Server id 14.3.339.0; Thu, 4 May 2017 16:58:18 -0400 From: Wassim Haddad Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-ID: Date: Thu, 4 May 2017 13:58:17 -0700 To: "int-area@ietf.org" X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZXLonSneCP3ekwe0t3BY3Zt1ksZhxaT+L A5PH0wkHmTyWLPnJFMAUxWWTkpqTWZZapG+XwJWxq7eDrWAbU8WX63uYGhh/MnYxcnJICJhI nL3zh6mLkYtDSOAoo8TETc9YIZw1jBL3Wk4xg1SxCRhIfF1+FijBwcEsoCmxfpc+SJhZQFti 2cLXYCW8AvoSr3b/ZAcpERYIlrg4JQwibC8x9f4WVhCbRUBFYsaZ9WwQrcESPSses4DYIkBj 9j85wAJxj6zErdmXwEYKCahLTLk1gWUCI98shMWzkCyehWTxAkbmVYwcpcUFObnpRoabGIGB dEyCzXEH495ez0OMAhyMSjy8D4y5I4VYE8uKK3MPMUpwMCuJ8F6YABTiTUmsrEotyo8vKs1J LT7EKM3BoiTO+678QoSQQHpiSWp2ampBahFMlomDU6qBsfF5fpfb0Z6sRRO4hMVrGUNtJE2f smRUqm4p+ZXG2jaPKWyJ8uWTLdm7+J/m3IxSKVQWitx05+OWzwbsaQKNXvdO1Jb/qP7HuJVJ +3BKvJrRMbPkw1nl2RO5HG2r4gQV2osrBBdNFM78dMjxlHdxhRNLYXiZxtV1+ZPmdxtOcPcX eud677cSS3FGoqEWc1FxIgAKBLNZIAIAAA== Archived-At: Subject: [Int-area] Conclusion of adoption call for draft-bonica-intarea-eping-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 20:58:24 -0000 Hello, After reviewing all responses sent to the int-area ML, we see support = for adoption of draft-bonica-intarea-eping-04 (=E2=80=9CExtended Ping = (Xping)=E2=80=9D) as a working group document. Authors, please resubmit = as draft-ietf-intarea-eping-00 Thanks, Juan Carlos and Wassim From nobody Wed May 10 12:25:36 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9CF12EAA4; Wed, 10 May 2017 12:25:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149444431473.16715.902623725713451425@ietfa.amsl.com> Date: Wed, 10 May 2017 12:25:14 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-gue-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:25:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Generic UDP Encapsulation Authors : Tom Herbert Lucy Yong Osama Zia Filename : draft-ietf-intarea-gue-03.txt Pages : 38 Date : 2017-05-10 Abstract: This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-gue-03 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 10 19:16:19 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A50F12EA55; Wed, 10 May 2017 19:16:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149446897115.16699.15653429356800177408@ietfa.amsl.com> Date: Wed, 10 May 2017 19:16:11 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-gue-extensions-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 02:16:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Extensions for Generic UDP Encapsulation Authors : Tom Herbert Lucy Yong Fred L. Templin Filename : draft-ietf-intarea-gue-extensions-00.txt Pages : 30 Date : 2017-05-10 Abstract: This specification defines a set of the fundamental optional extensions for Generic UDP Encapsulation (GUE). The extensions defined in this specification are the group identifier, security option, payload transform option, checksum option, fragmentation option, and the remote checksum offload option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions-00 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-extensions-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 13 10:45:26 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B32126B7E for ; Sat, 13 May 2017 10:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 Y2pik7ze2tJO for ; Sat, 13 May 2017 10:45:23 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 C9848126D05 for ; Sat, 13 May 2017 10:42:46 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id u75so68730809qka.3 for ; Sat, 13 May 2017 10:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=P5FYBKZuVPwMJQ7f3K02I+bDBW9uerJAWj0DxndCLH4=; b=Chooje5cWjANIw73mp8mjil0mjObQ48h6n+PSmMfAkAhInCj0RxS7kYrHIt63OXDk3 JzwFf1onRdzxq5emqmGtpgn/hEre105bfifuptJVMmGPzADMRAVvKDfEbXl6yClPEF9w oKdpFx+N1FjEU4VIKCcQdrdkoFzqaa6eeT9bZV6W2wI2giOWJvsuw3yrOfFQZuCBMFJ+ e5kCyXCmN80LAJsbs8hIoyoODZR8mDER3STatRvskLHRbcMu1QtSrojgDvbWgfYwFzr2 84IP5AsrlyMoQWtKnnFABeGaf9dyWMYzcR4l+jAMJGLtmLJ1wtaggfay7EHJ3laqyafo bYlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=P5FYBKZuVPwMJQ7f3K02I+bDBW9uerJAWj0DxndCLH4=; b=BAi0YlZNt0GbFSsvvmeFMnbyz7MsqGbV3mMCpAXQ9K+4xxs8wbpix/AtMu0r6xmiAg giLU4tbQu+hF4dUxtpmoVvJhDXEG3vTpxafGLDNfbyiAuT0mmJApQ5LA84Ur5xzVy86R 41R/sZkUSnb8g33aOUI1SI6wO8rP2OnD2K+pxb2uMrKU4X3I6j5ioqPJioFhZtETKLnC M63W7A5d0HyZdJNR5kNdGYCaM6mypmi6nuX7DDiKwbU8uXPmV05Ws1W5B85KaxU6kOgy J+5juWqmGkMvGTqUAubiHDoeuUpnqkH0xkQmf0assyvr3Jf7ijd17i3sMjtZKSavLtlM Bxsw== X-Gm-Message-State: AODbwcDrLHQrZpdejf8qDf92f9ZJbj9UpYosRKjjyqNph8XquIIpzWn0 6BqfxDqbDzIIhBTUzPSB8knUYij1Ew== X-Received: by 10.55.197.92 with SMTP id p89mr8536049qki.34.1494697365872; Sat, 13 May 2017 10:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Sat, 13 May 2017 10:42:45 -0700 (PDT) From: Tom Herbert Date: Sat, 13 May 2017 10:42:45 -0700 Message-ID: To: "int-area@ietf.org" Cc: Petr Lapukhov Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 17:45:25 -0000 Hello, At the Chicago WG meeting I made a request that ILA be taken up as a WG item in int-area. The WG chairs and AD requested that we raise a discussion on the list about what else is needed to be done for ILA (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The question was also raised if int-area is the right WG for ILA or if it should have a BOF. The current draft of ILA describes the data plane and addressing, a model for ILA for ILA routing and network topology, several use case scenarios on how ILA might be applied, a format for identifiers to allow different types of identifiers and checksum neutral mapping. As I mentioned we intend to make the last one optional so that administrators can choose how structure the 64 bit identifiers as they see fit-- this will be reflected in the next version of the draft. The draft explicitly does not define a specific control plane (e.g. routing protocol) for ILA and I don't think that it should. IMO ILA would be better served to allow various methods that are protocol generic where ILA could be a use case of those mechanisms. For instance, draft-lapukhov-bgp-ila-afi-02 describes and extension for BGP. Similarly, if a protocol agnostic control plane is developed in IDEAS or in nvo3, then ILA could be one use case for those. I would think the control plane seems more appropriate to be in routing area than int-area. As for what is still missing in the core ILA draft, besides making typed identifiers optional, I think it is fairly complete for the data plane description. It is being deployed in a least on datacenter for network virtualization, and it is being discussed as part of a solution to support IP mobility (see 5GandIP discussions). Tom From nobody Sat May 13 11:06:18 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAD129411 for ; Sat, 13 May 2017 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 I7gHqj8fdvFs for ; Sat, 13 May 2017 11:06:15 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 CF0A8129ADC for ; Sat, 13 May 2017 11:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id B2289D40329; Sat, 13 May 2017 11:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1494698592; bh=221/jjz0SEzOEY0jFS9fRasvKmET9GihEuNe43gB/m0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A5V9n3UHphcYNb4J9Ov7SAx87L+1YcHnkjXcZhm4+VUPFijxBnlWZH4bzpOD+nvSN Ol10kQ76ZPZkzlnOg+XceOf2IL36gwtek39XIW0KeSje2NKe+XV/RZigXOEcXmIF7T CND5OOrXyiyVxyySZjwsOoCLzJ1U5LVMmeETjkSk= X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 1A83DD401AE; Sat, 13 May 2017 11:03:11 -0700 (PDT) To: Tom Herbert , "int-area@ietf.org" References: Cc: Petr Lapukhov From: "Joel M. Halpern" Message-ID: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> Date: Sat, 13 May 2017 14:03:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 18:06:17 -0000 It appears to me that there are contexts in which it is likely that ILA is useful. Using the example of the progression of LISP, I have concern with the current approach of NOT spelling out how and where it would be used. LISP started out as experimental in significant part because it was not clear where it would be useful. We re now progressing it to PS with a clear context. And that context is NOT Internet-wide deployment for Internet scaling. Because that deployment problem is REALLY challenging. As such, if ILA wants to either be developed for the data center context or be developed as an interesting experiment across a range of potential uses, I can not object. I do have problems moving it forward towards standards track for some unspecified but general use in its current form. The dependence of the data plane protocol on the information distribution is so strong that I do not see how the general case can be treated. Yours, Joel On 5/13/17 1:42 PM, Tom Herbert wrote: > Hello, > > At the Chicago WG meeting I made a request that ILA be taken up as a > WG item in int-area. The WG chairs and AD requested that we raise a > discussion on the list about what else is needed to be done for ILA > (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The > question was also raised if int-area is the right WG for ILA or if it > should have a BOF. > > The current draft of ILA describes the data plane and addressing, a > model for ILA for ILA routing and network topology, several use case > scenarios on how ILA might be applied, a format for identifiers to > allow different types of identifiers and checksum neutral mapping. As > I mentioned we intend to make the last one optional so that > administrators can choose how structure the 64 bit identifiers as they > see fit-- this will be reflected in the next version of the draft. > > The draft explicitly does not define a specific control plane (e.g. > routing protocol) for ILA and I don't think that it should. IMO ILA > would be better served to allow various methods that are protocol > generic where ILA could be a use case of those mechanisms. For > instance, draft-lapukhov-bgp-ila-afi-02 describes and extension for > BGP. Similarly, if a protocol agnostic control plane is developed in > IDEAS or in nvo3, then ILA could be one use case for those. I would > think the control plane seems more appropriate to be in routing area > than int-area. > > As for what is still missing in the core ILA draft, besides making > typed identifiers optional, I think it is fairly complete for the data > plane description. It is being deployed in a least on datacenter for > network virtualization, and it is being discussed as part of a > solution to support IP mobility (see 5GandIP discussions). > > Tom > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Sat May 13 11:24:07 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA681129B16 for ; Sat, 13 May 2017 11:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 QgSl7Ywc_8Fw for ; Sat, 13 May 2017 11:24:04 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 16C7C129BDB for ; Sat, 13 May 2017 11:21:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id y201so69341927qka.0 for ; Sat, 13 May 2017 11:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JbHDR5C3E51vVlPosQIZdymUi9RzL6FzbD/nOy/aLR8=; b=PvYwFUtjlRo3xsKjXEpxZ7BoS7y66mu+t9InF77CTj6KBCRTPv8sndI1SFxnEsGBU4 8+yQUnPTQJKZqSVFnKLQlI3SZUPCE0us0Fp+DqpsabKP4tU2Y/hMGN/oY5mjjRI92/cz oohnXeYNh05mz8VKTlnH//WPMGvDhIllQIcJk40w70WFxmPvEywPcEQS65NX+35R48f9 eqhc7fFYwe2X94aBIzxYbT5UtqS5lPfWqz9tJtLpzaMk9Upuq+qW6uSL1fQ2i5td6ZAE Ca+oiEtFRPQ1mQI6h9KrQiLJorDDr9bGvkgkzE3m86VoDoa2zFiJUzIkPaXuYGjU+o+7 m3Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JbHDR5C3E51vVlPosQIZdymUi9RzL6FzbD/nOy/aLR8=; b=THXAC29cblYSMcbgUkQLL1fTVMDSCP513KU6TYI6jTm5+KH98RrtdM9yr/Pk+bC19u 6eGhGaHODbga3H9c3hi6bB7ScM7nIF406jzJfpjWZGhqIaDMSw6rvuzvmf1yS86pesiP wrGo5RRbicNyMm3E7SxMw1pGT3rqLlWaMtX9YcUjZ/HHjWtiLIap8UEcGfDtB1mU5okh fVRl4e51+4CPTIswgvUuO8UWUs6Wyp1xhWrDv3Fy2BL48yeT83bkk9BpFKcxh4MVV/Y1 37bJavdtcS6iCPF0yM6SqgznkDaZn3YFB8GsSGKTn4LBUdSCxS0kOvUbRtbywtIPvDrG Rsig== X-Gm-Message-State: AODbwcBVpSf2z8DJ8bPcaYZ7mg8W+uwgRgoK8vxzezdt8P/sh6VEFlwS 3YryDBQ9/i5eI98wbGeCHk1K8yBBKA== X-Received: by 10.55.138.1 with SMTP id m1mr9585347qkd.270.1494699672203; Sat, 13 May 2017 11:21:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Sat, 13 May 2017 11:21:11 -0700 (PDT) In-Reply-To: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> From: Tom Herbert Date: Sat, 13 May 2017 11:21:11 -0700 Message-ID: To: "Joel M. Halpern" Cc: "int-area@ietf.org" , Petr Lapukhov Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 18:24:06 -0000 On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern wrote: > It appears to me that there are contexts in which it is likely that ILA is > useful. > > Using the example of the progression of LISP, I have concern with the > current approach of NOT spelling out how and where it would be used. LISP > started out as experimental in significant part because it was not clear > where it would be useful. We re now progressing it to PS with a clear > context. And that context is NOT Internet-wide deployment for Internet > scaling. Because that deployment problem is REALLY challenging. > > As such, if ILA wants to either be developed for the data center context or > be developed as an interesting experiment across a range of potential uses, > I can not object. > > I do have problems moving it forward towards standards track for some > unspecified but general use in its current form. The dependence of the data > plane protocol on the information distribution is so strong that I do not > see how the general case can be treated. > Hi Joel, Intended status is listed as informational if that helps. I tend to think that the relationship between an ILA data plane and control plane is analogous to the relationship between the IP protocol and routing protocols. Yes, there is a strong dependency on having a control plane, but mandating a specific control plane as part of the core protocol reduces flexibility and extensibility. Tom > Yours, > Joel > > > On 5/13/17 1:42 PM, Tom Herbert wrote: >> >> Hello, >> >> At the Chicago WG meeting I made a request that ILA be taken up as a >> WG item in int-area. The WG chairs and AD requested that we raise a >> discussion on the list about what else is needed to be done for ILA >> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The >> question was also raised if int-area is the right WG for ILA or if it >> should have a BOF. >> >> The current draft of ILA describes the data plane and addressing, a >> model for ILA for ILA routing and network topology, several use case >> scenarios on how ILA might be applied, a format for identifiers to >> allow different types of identifiers and checksum neutral mapping. As >> I mentioned we intend to make the last one optional so that >> administrators can choose how structure the 64 bit identifiers as they >> see fit-- this will be reflected in the next version of the draft. >> >> The draft explicitly does not define a specific control plane (e.g. >> routing protocol) for ILA and I don't think that it should. IMO ILA >> would be better served to allow various methods that are protocol >> generic where ILA could be a use case of those mechanisms. For >> instance, draft-lapukhov-bgp-ila-afi-02 describes and extension for >> BGP. Similarly, if a protocol agnostic control plane is developed in >> IDEAS or in nvo3, then ILA could be one use case for those. I would >> think the control plane seems more appropriate to be in routing area >> than int-area. >> >> As for what is still missing in the core ILA draft, besides making >> typed identifiers optional, I think it is fairly complete for the data >> plane description. It is being deployed in a least on datacenter for >> network virtualization, and it is being discussed as part of a >> solution to support IP mobility (see 5GandIP discussions). >> >> Tom >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > From nobody Tue May 16 16:17:48 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067A8129601 for ; Tue, 16 May 2017 16:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 DhfQnhLwQEbE for ; Tue, 16 May 2017 16:17:45 -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 2BABE12EC0D for ; Tue, 16 May 2017 16:13:42 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4GNDFWT025849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 16:13:15 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <820fa41d-84d0-d835-93a1-caf11187bd11@isi.edu> Date: Tue, 16 May 2017 16:13:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:17:46 -0000 HI Fred, I'm in the process of the next update, and wanted to clarify the following: On 3/28/2017 9:36 AM, Templin, Fred L wrote: > 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as > well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define > an NBMA multipoint tunnel framework that has been around a > lot longer than the other examples cited. That section doesn't list examples of multipoint tunnels per se. It lists systems that use multipoint tunnels (LISP, TRILL) and discusses mechanisms that support multipoint tunnels (LANE, etc.). I'm not sure there's a clearly good, original ref for multipoint tunnels - the concept has been around in some form since basically the notion of a tunnel. Joe From nobody Tue May 16 16:21:21 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69942129B18 for ; Tue, 16 May 2017 16:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 tCYjxYqW8m6h for ; Tue, 16 May 2017 16:21:16 -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 81C8B12751F for ; Tue, 16 May 2017 16:17:18 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4GNGhL3026890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 16:16:43 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <6573ad04-a1a6-3f2c-8470-c2babaf36110@isi.edu> Date: Tue, 16 May 2017 16:16:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:21:17 -0000 Fred, Regarding the following point: On 3/28/2017 9:36 AM, Templin, Fred L wrote: > 19) Section 4.3.3, third paragraph, I thought it was said earlier > that all ingress/egress pairs must support the same MTU. I > thought we agreed earlier on that that multi-MTU subnets > don't work. So, I think it should say that all ingress pairs > MUST support a uniform MTU. The cited section allows for ingress/egress pairs that don't support the same MTU, but then says that the MTU used for that set is the minimum of those MTUs. There's no way (short of configuration management) to ensure that ingress/egress pairs MUST support the same MTU, but no real value to requiring that - AFAICT, we just use the min across that set (which is what that section says to do). So yes, we do not *use* different MTUs per-destination, but we don't need to require it AFAICT. Joe From nobody Tue May 16 16:28:51 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA313013D for ; Tue, 16 May 2017 16:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 t-OiEIGRYPJc for ; Tue, 16 May 2017 16:28:48 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 70F5712EB6D for ; Tue, 16 May 2017 16:24:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4GNOefl055278; Tue, 16 May 2017 16:24:40 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4GNOWTs055251 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 16 May 2017 16:24:33 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 16 May 2017 16:24:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 16 May 2017 16:24:31 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggE3obID//4uTsA== Date: Tue, 16 May 2017 23:24:31 +0000 Message-ID: <75148a50c6304ebc975cc2298abb73cd@XCH15-06-08.nw.nos.boeing.com> References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <820fa41d-84d0-d835-93a1-caf11187bd11@isi.edu> In-Reply-To: <820fa41d-84d0-d835-93a1-caf11187bd11@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:28:50 -0000 SW50ZXJlc3RpbmcgdGltaW5nIG9uIHRoaXMgbWVzc2FnZSwgYnV0IHNlZSBiZWxvdzoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3Vj aEBpc2kuZWR1XQ0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMTYsIDIwMTcgNDoxMyBQTQ0KPiBUbzog VGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiBDYzogaW50LWFy ZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDUudHh0DQo+IA0KPiBISSBGcmVkLA0KPiANCj4gSSdtIGlu IHRoZSBwcm9jZXNzIG9mIHRoZSBuZXh0IHVwZGF0ZSwgYW5kIHdhbnRlZCB0byBjbGFyaWZ5IHRo ZSBmb2xsb3dpbmc6DQo+IA0KPiANCj4gT24gMy8yOC8yMDE3IDk6MzYgQU0sIFRlbXBsaW4sIEZy ZWQgTCB3cm90ZToNCj4gPiAxOCkgU2VjdGlvbiA0LjMuMywgRm9yIE11bHRpcG9pbnQgVHVubmVs cywgcGxlYXNlIGNpdGUgQUVSTywgYXMNCj4gPiAgICAgd2VsbCBhcyBJU0FUQVAgW1JGQzUyMTRd IGFuZCA2b3ZlcjQgW1JGQzI1MjldLiBUaGV5IGRlZmluZQ0KPiA+ICAgICBhbiBOQk1BIG11bHRp cG9pbnQgdHVubmVsIGZyYW1ld29yayB0aGF0IGhhcyBiZWVuIGFyb3VuZCBhDQo+ID4gICAgIGxv dCBsb25nZXIgdGhhbiB0aGUgb3RoZXIgZXhhbXBsZXMgY2l0ZWQuDQo+IFRoYXQgc2VjdGlvbiBk b2Vzbid0IGxpc3QgZXhhbXBsZXMgb2YgbXVsdGlwb2ludCB0dW5uZWxzIHBlciBzZS4gSXQNCj4g bGlzdHMgc3lzdGVtcyB0aGF0IHVzZSBtdWx0aXBvaW50IHR1bm5lbHMgKExJU1AsIFRSSUxMKSBh bmQgZGlzY3Vzc2VzDQo+IG1lY2hhbmlzbXMgdGhhdCBzdXBwb3J0IG11bHRpcG9pbnQgdHVubmVs cyAoTEFORSwgZXRjLikuDQoNCkFFUk8gZW1icmFjZXMgdGhlIHR1bm5lbCBhcyBhIGxpbmsgaW4g dGhlIHNwaXJpdCBvZiB5b3VyIGRvY3VtZW50IHdoaWxlDQpMSVNQIGRvZXMgbm90LiBBRVJPIGRl ZmluZXMgIkFFUk8gaW50ZXJmYWNlIiBhbmQgIkFFUk8gbGluayIgLSBMSVNQIGdvZXMNCm91dCBv ZiBpdHMgd2F5IHRvIGF2b2lkIHNheWluZyBhbnl0aGluZyBhYm91dCBpbnRlcmZhY2VzIG9yIGxp bmtzLg0KDQo+IEknbSBub3Qgc3VyZSB0aGVyZSdzIGEgY2xlYXJseSBnb29kLCBvcmlnaW5hbCBy ZWYgZm9yIG11bHRpcG9pbnQgdHVubmVscw0KPiAtIHRoZSBjb25jZXB0IGhhcyBiZWVuIGFyb3Vu ZCBpbiBzb21lIGZvcm0gc2luY2UgYmFzaWNhbGx5IHRoZSBub3Rpb24gb2YNCj4gYSB0dW5uZWwu DQoNClJGQzI1MjkgaXMgdGhlIGZpcnN0IEkgYW0gYXdhcmUgb2YuDQoNCkZyZWQNCg0KPiBKb2UN Cj4gDQo+IA0KDQo= From nobody Tue May 16 16:35:13 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070D212EC5A for ; Tue, 16 May 2017 16:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 8pvc6gKIazkn for ; Tue, 16 May 2017 16:35:10 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 16DB6129A97 for ; Tue, 16 May 2017 16:31:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4GNVGf0063436; Tue, 16 May 2017 16:31:16 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4GNV6MX063302 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 16 May 2017 16:31:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 16 May 2017 16:31:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 16 May 2017 16:31:05 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggE3pZID//40fUA== Date: Tue, 16 May 2017 23:31:05 +0000 Message-ID: <68f2a2ff5e6647f3837be0c2811120ee@XCH15-06-08.nw.nos.boeing.com> References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <6573ad04-a1a6-3f2c-8470-c2babaf36110@isi.edu> In-Reply-To: <6573ad04-a1a6-3f2c-8470-c2babaf36110@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:35:12 -0000 Sm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3VjaCBb bWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAxNiwgMjAxNyA0OjE3 IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ IENjOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNS50eHQNCj4gDQo+IEZyZWQsDQo+IA0K PiBSZWdhcmRpbmcgdGhlIGZvbGxvd2luZyBwb2ludDoNCj4gDQo+IA0KPiBPbiAzLzI4LzIwMTcg OTozNiBBTSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IDE5KSBTZWN0aW9uIDQuMy4zLCB0 aGlyZCBwYXJhZ3JhcGgsIEkgdGhvdWdodCBpdCB3YXMgc2FpZCBlYXJsaWVyDQo+ID4gICAgIHRo YXQgYWxsIGluZ3Jlc3MvZWdyZXNzIHBhaXJzIG11c3Qgc3VwcG9ydCB0aGUgc2FtZSBNVFUuIEkN Cj4gPiAgICAgdGhvdWdodCB3ZSBhZ3JlZWQgZWFybGllciBvbiB0aGF0IHRoYXQgbXVsdGktTVRV IHN1Ym5ldHMNCj4gPiAgICAgZG9uJ3Qgd29yay4gU28sIEkgdGhpbmsgaXQgc2hvdWxkIHNheSB0 aGF0IGFsbCBpbmdyZXNzIHBhaXJzDQo+ID4gICAgIE1VU1Qgc3VwcG9ydCBhIHVuaWZvcm0gTVRV Lg0KPiBUaGUgY2l0ZWQgc2VjdGlvbiBhbGxvd3MgZm9yIGluZ3Jlc3MvZWdyZXNzIHBhaXJzIHRo YXQgZG9uJ3Qgc3VwcG9ydCB0aGUNCj4gc2FtZSBNVFUsIGJ1dCB0aGVuIHNheXMgdGhhdCB0aGUg TVRVIHVzZWQgZm9yIHRoYXQgc2V0IGlzIHRoZSBtaW5pbXVtIG9mDQo+IHRob3NlIE1UVXMuDQo+ IA0KPiBUaGVyZSdzIG5vIHdheSAoc2hvcnQgb2YgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50KSB0 byBlbnN1cmUgdGhhdA0KPiBpbmdyZXNzL2VncmVzcyBwYWlycyBNVVNUIHN1cHBvcnQgdGhlIHNh bWUgTVRVLCBidXQgbm8gcmVhbCB2YWx1ZSB0bw0KPiByZXF1aXJpbmcgdGhhdCAtIEFGQUlDVCwg d2UganVzdCB1c2UgdGhlIG1pbiBhY3Jvc3MgdGhhdCBzZXQgKHdoaWNoIGlzDQo+IHdoYXQgdGhh dCBzZWN0aW9uIHNheXMgdG8gZG8pLg0KDQpXaGF0IEkgYW0gdHJ5aW5nIHRvIGdldCBhdCBpcyB0 aGUgbmVlZCBmb3IgYW4gaW5ncmVzcyB0byBkZXRlcm1pbmUgdGhlDQptaW5pbXVtIGJlZm9yZSBp dCBzZW5kcyBhIHBhY2tldCB0aGF0IG1heSBiZSB0b28gYmlnIGZvciBvbmUgb2YgdGhlDQptdWx0 aXBvaW50IGxpbmsgZWdyZXNzZXMuIE9uIElQdjYgbGlua3MsIHRoaXMgY291bGQgYmUgdGhyb3Vn aCByZWNlaXB0DQpvZiBhbiBNVFUgb3B0aW9uIGluIGEgUm91dGVyIEFkdmVydGlzZW1lbnQgbWVz c2FnZS4gT3RoZXIgd2F5cw0KYXJlIHBvc3NpYmxlIChlLmcuLCBzdGF0aWMgY29uZmlndXJhdGlv bikgYnV0IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUNCndheSBmb3IgYWxsIGluZ3Jlc3NlcyB0byBk ZXRlcm1pbmUgdGhlIG1pbmltdW0uDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBTbyB5ZXMsIHdlIGRv IG5vdCAqdXNlKiBkaWZmZXJlbnQgTVRVcyBwZXItZGVzdGluYXRpb24sIGJ1dCB3ZSBkb24ndA0K PiBuZWVkIHRvIHJlcXVpcmUgaXQgQUZBSUNULg0KPiANCj4gSm9lDQoNCg== From nobody Tue May 16 16:40:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B26712ECB8 for ; Tue, 16 May 2017 16:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 RXC1GxsLcZTD for ; Tue, 16 May 2017 16:40:23 -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 DD8F712EAF6 for ; Tue, 16 May 2017 16:36:45 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4GNaUlU002793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 16:36:30 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <6573ad04-a1a6-3f2c-8470-c2babaf36110@isi.edu> <68f2a2ff5e6647f3837be0c2811120ee@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: Date: Tue, 16 May 2017 16:36:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <68f2a2ff5e6647f3837be0c2811120ee@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:40:24 -0000 HI, Fred, AOK - I can add that. The point is that *IF* you get multiple answers (regardless of how), you use the min. And the ingress needs to determine that value before sending for sure and there's always the possibility of PMTUD doing odd things if ICMPs are blackholed here - but partial delivery in that case isn't unique to tunnels. I'll mention it, though. joe On 5/16/2017 4:31 PM, Templin, Fred L wrote: > Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 16, 2017 4:17 PM >> To: Templin, Fred L >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> Fred, >> >> Regarding the following point: >> >> >> On 3/28/2017 9:36 AM, Templin, Fred L wrote: >>> 19) Section 4.3.3, third paragraph, I thought it was said earlier >>> that all ingress/egress pairs must support the same MTU. I >>> thought we agreed earlier on that that multi-MTU subnets >>> don't work. So, I think it should say that all ingress pairs >>> MUST support a uniform MTU. >> The cited section allows for ingress/egress pairs that don't support the >> same MTU, but then says that the MTU used for that set is the minimum of >> those MTUs. >> >> There's no way (short of configuration management) to ensure that >> ingress/egress pairs MUST support the same MTU, but no real value to >> requiring that - AFAICT, we just use the min across that set (which is >> what that section says to do). > What I am trying to get at is the need for an ingress to determine the > minimum before it sends a packet that may be too big for one of the > multipoint link egresses. On IPv6 links, this could be through receipt > of an MTU option in a Router Advertisement message. Other ways > are possible (e.g., static configuration) but there needs to be some > way for all ingresses to determine the minimum. > > Thanks - Fred > >> So yes, we do not *use* different MTUs per-destination, but we don't >> need to require it AFAICT. >> >> Joe From nobody Tue May 16 16:59:59 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5191129B5F for ; Tue, 16 May 2017 16:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 fAz9JVw91Tvi for ; Tue, 16 May 2017 16:59:55 -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 7B35F126CE8 for ; Tue, 16 May 2017 16:56:03 -0700 (PDT) Received: from [128.9.184.184] ([128.9.184.184]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4GNsYwY008612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 16:54:34 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <820fa41d-84d0-d835-93a1-caf11187bd11@isi.edu> <75148a50c6304ebc975cc2298abb73cd@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: Date: Tue, 16 May 2017 16:54:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <75148a50c6304ebc975cc2298abb73cd@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 23:59:57 -0000 On 5/16/2017 4:24 PM, Templin, Fred L wrote: > Interesting timing on this message, but see below: > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 16, 2017 4:13 PM >> To: Templin, Fred L >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt >> >> HI Fred, >> >> I'm in the process of the next update, and wanted to clarify the following: >> >> >> On 3/28/2017 9:36 AM, Templin, Fred L wrote: >>> 18) Section 4.3.3, For Multipoint Tunnels, please cite AERO, as >>> well as ISATAP [RFC5214] and 6over4 [RFC2529]. They define >>> an NBMA multipoint tunnel framework that has been around a >>> lot longer than the other examples cited. >> That section doesn't list examples of multipoint tunnels per se. It >> lists systems that use multipoint tunnels (LISP, TRILL) and discusses >> mechanisms that support multipoint tunnels (LANE, etc.). > AERO embraces the tunnel as a link in the spirit of your document while > LISP does not. AERO defines "AERO interface" and "AERO link" - LISP goes > out of its way to avoid saying anything about interfaces or links. > >> I'm not sure there's a clearly good, original ref for multipoint tunnels >> - the concept has been around in some form since basically the notion of >> a tunnel. > RFC2529 is the first I am aware of. AOK - thanks. Joe From nobody Tue May 16 20:28:39 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD61200C5 for ; Tue, 16 May 2017 20:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 3bQTjICEc136 for ; Tue, 16 May 2017 20:28:35 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 CCAB01270A3 for ; Tue, 16 May 2017 20:25:27 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id j17so76477ybj.0 for ; Tue, 16 May 2017 20:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BU0phTt+zoYXSBY4dc2F15vqORBgL3jo9lql5WeyKdU=; b=u5gLYp1gEGte8VCuYRw1PavAuDtO2kaFN47VLw+TIyvHzjw0OlfRY7DFXzgCtyL+NF aUYs18kG3MgjZ/uh0LRmH98ZzIDMzsu4v569H5u1V224/ry9NcQQ5kd3RLaSHdC2Uid+ NnUB5FC1wqNU8ra+howZhR79pXL045r1ZqS0fqtLMAx7L9c6GBmy7C1TxVxEAf5/vGeu MS8i4nhfAi10xHMPAlvxaeP92ZteRBDC2QeF5Onq3dSjDeHAmE353afgGxodVw7SY8Dr A1QZQ/yoQ4Cy0Kc0iCQnGA1QEiX4p78k6l6z7EQ6ItKssYFdF2fKoPPGB1tIEwVpuhi3 5sCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BU0phTt+zoYXSBY4dc2F15vqORBgL3jo9lql5WeyKdU=; b=DzriAHy3SKFO0Z7g3cm3bH501Bl+G5F8YWTcmA/4OTiAgAkNqS39PV6245a9WkVkYb doEKWwN9guwkRNnLriLLJre4a+n6CERmO0R27sK9Pm3egHt5WKb2vxnz+fwjplYvKq57 a90glBVLmf/w4Vb+pP6ZwEN7etVB0JwNDTvERgdHYuITEm0ygjZ0ENcK2RUTofrbcMt7 6BzbYqbp+PMbUvAafCErcltN5lDWhvE/8ouKmYrJceJtF5pZdNb9bV0kD/FQfsd+faVS lfDk1KalKC0Y6L9PocY8Rp/mSohNU14XYsgqPhqyzLrhz5tWJo5cmS7a1TNOvVTVAb8E 15wg== X-Gm-Message-State: AODbwcA4sHHKrDMV7eOoZzLhR/eRrx4qf2w7lUNG+DRoMcrtPjzbSP5G zkwZJxqTOFBN6HGt2BxwOWKcK+Xo4WGy X-Received: by 10.37.173.225 with SMTP id d33mr952510ybe.1.1494991526753; Tue, 16 May 2017 20:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Tue, 16 May 2017 20:25:06 -0700 (PDT) In-Reply-To: References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> From: Erik Kline Date: Wed, 17 May 2017 12:25:06 +0900 Message-ID: To: Tom Herbert Cc: "Joel M. Halpern" , Petr Lapukhov , "int-area@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045eb87aeb7f4a054fafd602" Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 03:28:37 -0000 --f403045eb87aeb7f4a054fafd602 Content-Type: multipart/alternative; boundary="f403045eb87ae5b413054fafd66c" --f403045eb87ae5b413054fafd66c Content-Type: text/plain; charset="UTF-8" On 14 May 2017 at 03:21, Tom Herbert wrote: > On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern > wrote: > > It appears to me that there are contexts in which it is likely that ILA > is > > useful. > > > > Using the example of the progression of LISP, I have concern with the > > current approach of NOT spelling out how and where it would be used. LISP > > started out as experimental in significant part because it was not clear > > where it would be useful. We re now progressing it to PS with a clear > > context. And that context is NOT Internet-wide deployment for Internet > > scaling. Because that deployment problem is REALLY challenging. > > > > As such, if ILA wants to either be developed for the data center context > or > > be developed as an interesting experiment across a range of potential > uses, > > I can not object. > > > > I do have problems moving it forward towards standards track for some > > unspecified but general use in its current form. The dependence of the > data > > plane protocol on the information distribution is so strong that I do not > > see how the general case can be treated. > > > Hi Joel, > > Intended status is listed as informational if that helps. > > I tend to think that the relationship between an ILA data plane and > control plane is analogous to the relationship between the IP protocol > and routing protocols. Yes, there is a strong dependency on having a > control plane, but mandating a specific control plane as part of the > core protocol reduces flexibility and extensibility. Put another way: the domain of applicability is the same as the domain(s) over which the control plane operates. Any ILA packets outside that/ose domain/s should just look like vanilla IPv6. --f403045eb87ae5b413054fafd66c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 May 2017 at 03:21, Tom Herbert <tom@herbertland.com> wrote:
On Sat, May = 13, 2017 at 11:03 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> It appears to me that there are contexts in which it is likely that IL= A is
> useful.
>
> Using the example of the progression of LISP, I have concern with the<= br> > current approach of NOT spelling out how and where it would be used. L= ISP
> started out as experimental in significant part because it was not cle= ar
> where it would be useful.=C2=A0 We re now progressing it to PS with a = clear
> context.=C2=A0 And that context is NOT Internet-wide deployment for In= ternet
> scaling.=C2=A0 Because that deployment problem is REALLY challenging.<= br> >
> As such, if ILA wants to either be developed for the data center conte= xt or
> be developed as an interesting experiment across a range of potential = uses,
> I can not object.
>
> I do have problems moving it forward towards standards track for some<= br> > unspecified but general use in its current form.=C2=A0 The dependence = of the data
> plane protocol on the information distribution is so strong that I do = not
> see how the general case can be treated.
>
Hi Joel,

Intended status is listed as informational if that helps.

I tend to think that the relationship between an ILA data plane and
control plane is analogous to the relationship between the IP protocol
and routing protocols. Yes, there is a strong dependency on having a
control plane, but mandating a specific control plane as part of the
core protocol reduces flexibility and extensibility.

<= /div>
Put another way: the domain of applicability is the same as the d= omain(s) over which the control plane operates.=C2=A0 Any ILA packets outsi= de that/ose domain/s should just look like vanilla IPv6.
<= /div> --f403045eb87ae5b413054fafd66c-- --f403045eb87aeb7f4a054fafd602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg+mOXSwgwDAoaP/t+M7Qj696jqFVqrQeb YGdNCykAuggwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTE3 MDMyNTI3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAK18ui93AfcUqg825rWglg68iR5nlCXd+ocrQylVzUpckOB6Tmn 8/yl9REE4aj355cARzMRLa2II4BtbhO8isxYDTWtdZ1w0AV+hqoxLJSMJbhsRi2q45Tl3SfyVmx1 w9M2att1/1rvGctpeIU5VROQADoSv/jkR570Iwp8zysd6D/hVkz/Ds14aUJF8jFqG7GYkeg/ZAMA kkFjvRh5SbpJuqDFHHv+HUQMvNcHMiLzR+D/MkK8BhcOP0SJganTZq4868JcsBx1WbEN9m3nGJJB BQXd847O5cjd6Nv4ZD00JfGTmih43rtukn1ZqGrmiMyuCXxf1sgPBEPzMI6TXa0= --f403045eb87aeb7f4a054fafd602-- From nobody Tue May 16 20:36:58 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FB712EBE6 for ; Tue, 16 May 2017 20:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 6d_VI9S5Fl6P for ; Tue, 16 May 2017 20:36:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 7026912EC59 for ; Tue, 16 May 2017 20:33:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 57225DC078A; Tue, 16 May 2017 20:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1494992036; bh=BLAfgGWYKWm/OMy1oO7V7wGVlmknh+ouM7OikaFG3uI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A4TVpzNJXMbktUxD6qRy6wN7bGG0dsxsRXTxFPDZ92TBUbeU9pl7EK+BGZWgAhhN9 un1I/+/NCmvVQGpT1Z6/zMsGg1o779WNhKTo6K7izNoPMlZD/CYuzX34OJOAEV7NE0 o04kK64tr3B8yH6AMmpe8/uLOerbvm0ayq+sSv8U= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 64197DC0765; Tue, 16 May 2017 20:33:55 -0700 (PDT) To: Erik Kline , Tom Herbert References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> Cc: Petr Lapukhov , "int-area@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 16 May 2017 23:33:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 03:36:58 -0000 If we want the documents to be informational, then it should be about a context where we understand how to build the surrounding infrastructure. For example, if it were documented for data centers, based on Facebook's experience, I would have trouble objecting to informational publication. If we do not know where it applies, and what to try it out in various contexts with various control setups, then that sounds like experimental RFCs. While I have my doubts about some of the applicability, that should not stop useful experimentation. But an informational document that says that this can be used (roughly speaking) ~anywhere you can figure out a way to control it~ seems a bit odd. Yours, Joel On 5/16/17 11:25 PM, Erik Kline wrote: > > > On 14 May 2017 at 03:21, Tom Herbert > wrote: > > On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern > > wrote: > > It appears to me that there are contexts in which it is likely that ILA is > > useful. > > > > Using the example of the progression of LISP, I have concern with the > > current approach of NOT spelling out how and where it would be used. LISP > > started out as experimental in significant part because it was not clear > > where it would be useful. We re now progressing it to PS with a clear > > context. And that context is NOT Internet-wide deployment for Internet > > scaling. Because that deployment problem is REALLY challenging. > > > > As such, if ILA wants to either be developed for the data center context or > > be developed as an interesting experiment across a range of potential uses, > > I can not object. > > > > I do have problems moving it forward towards standards track for some > > unspecified but general use in its current form. The dependence of the data > > plane protocol on the information distribution is so strong that I do not > > see how the general case can be treated. > > > Hi Joel, > > Intended status is listed as informational if that helps. > > I tend to think that the relationship between an ILA data plane and > control plane is analogous to the relationship between the IP protocol > and routing protocols. Yes, there is a strong dependency on having a > control plane, but mandating a specific control plane as part of the > core protocol reduces flexibility and extensibility. > > > Put another way: the domain of applicability is the same as the > domain(s) over which the control plane operates. Any ILA packets > outside that/ose domain/s should just look like vanilla IPv6. From nobody Tue May 16 22:33:11 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF6A12E3AE for ; Tue, 16 May 2017 22:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CqGMrCqCMo0Y for ; Tue, 16 May 2017 22:33:07 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 A92B9129B82 for ; Tue, 16 May 2017 22:29:47 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id m17so1569117pfg.3 for ; Tue, 16 May 2017 22:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3KjlVVbzJmZYClF1b+T/qs4VNq7jB5kf98RTAGxSosA=; b=KSJiRHTcn/hbec+64bfUAxfBuYgPeUc0zJv7OTCZ4Xq0GIqwBSyyvxk4RW+OorUEly RxSLx5UTGf3b2xUvmIUFZ6lz2VgiMHoOopWhq1HYpPH2KWHXK5Cmq2Gf8K410EbK5sTQ OaqswddPNSk1MZcfrYwcWQyJcpyOhY220k8Df02fbMHRIqBTd10DFDuy51qAX+bRo10c 1/ZMI+Rd7Ki54Mh3mRnoqAuxvS65niDafOJQxADAUz8N1xHJo6w8xnNS+IVJUPtgDgp0 u8V55qyw9xjCoTqXmWFgu+ZQsOr7psYMiucXapZBr3vfABV1PhwDFsCSGIxkchUnPEah nB8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3KjlVVbzJmZYClF1b+T/qs4VNq7jB5kf98RTAGxSosA=; b=d/bQvsaglIEvAgUoT38jWsGStXBCzib9hGAeAB+Yet57JbVJrM93deXBTTjEl0mUlQ Hg7NF5M3PBqV2wq9n5dr+fd1tDqDE5jI3O0FyJH/vK3BTPwSbQQBfEDhO9vbRqME7vO+ 4KZuGCo5SJQT5KpxOywgnXRPxPKn0l6bOdjSeP9X32JdKvJZDcIWeUSZLNZAP1ZYLNbN 9zy07lyUUWU2vruKDQ0YrZsf72YyyfhYANFkLBkHQ0DP+F8w9TH7b1XzZYOJm+pxHJQL m1nSGySHN00NDTpmnkTz/81BSyLmWTd++SLDP2kHbTSGxvrwTkT3KdX2qIbokHeQIoOG WvVw== X-Gm-Message-State: AODbwcB3cLmzv31QEq0C2A9xTtXk8gIva329JHLAnxJVGcYkNtPJrw36 ROk4ZPs+RI3ICA== X-Received: by 10.84.239.23 with SMTP id w23mr2087622plk.73.1494998987267; Tue, 16 May 2017 22:29:47 -0700 (PDT) Received: from [192.168.178.21] ([118.148.118.167]) by smtp.gmail.com with ESMTPSA id 3sm1355406pfp.11.2017.05.16.22.29.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 22:29:46 -0700 (PDT) To: Tom Herbert , "int-area@ietf.org" References: Cc: Petr Lapukhov From: Brian E Carpenter Organization: University of Auckland Message-ID: <79a48d82-014a-f1dc-6fef-a2c9a492281d@gmail.com> Date: Wed, 17 May 2017 17:29:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 05:33:09 -0000 On 14/05/2017 05:42, Tom Herbert wrote: > Hello, > > At the Chicago WG meeting I made a request that ILA be taken up as a > WG item in int-area. The WG chairs and AD requested that we raise a > discussion on the list about what else is needed to be done for ILA > (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The > question was also raised if int-area is the right WG for ILA or if it > should have a BOF. I think it's fine for int-area to take this up, as long as 6man is alerted. A few somewhat random comments: Is there any particular reason you chose a /64 routing prefix, rather than say /72 or /80? I don't see any dependency on SLAAC, so there's no reason to care about /64, right? I assume you would use DHCPv6 or some other method of assigning addresses to VMs. If you used /72 or /80 you'd have flexibility with a ULA prefix to insert a subnet field. > The format of an ILA address with a global unicast locator is: > > |<--------------- Locator --------------->| > |3 bits| N bits | M bits | 61-N-M | 64 bits | > +------+-------------+---------+---------------------------------+ > | 001 | Global prefix | Subnet | Host | Identifier | > +------+---------------+---------+--------+----------------------+ Why is this restricted to 2000::/3? > The format of an ILA address with a unique local IPv6 unicast locator > is: > > |<--------------- Locator --------->| > | 7 bits |1| 40 bits | 16 bits | 64 bits | > +--------+-+------------+-----------+----------------------------+ > | FC00 |L| Global ID | Host | Identifier | > +--------+-+------------+-----------+----------------------------+ The first byte is confusing; presumably you're trying to express fd00::/8 so why not put 11111101 ? I agree that the flow label would be tricky to use for this sort of purpose, but I have a couple of comments anyway: > o The flow label is only twenty bits, this is too small to be a > discriminator in forwarding a virtual packet to a specific > destination. Conceptually, the flow label might be used in a > type of label switching to solve that. Perhaps, but 6man fairly comprehensively rejected that type of usage. In practice it's excluded by section 4 of RFC6437. o The flow label is not considered immutable in transit, intermediate devices may change it. That's not phrased quite right. RFC6437 section 2 says: " Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1. There is no way to verify whether a flow label has been modified en route..." You could in fact have an operational guarantee that within an administrative domain, no middleboxes will change the flow label. So something like this is more accurate: o The flow label is not protected against changes in transit. > o Intermediate devices must not insert extension headers > [RFC2460bis]. I think you could say: o Current specifications do not allow intermediate devices to insert extension headers [RFC2460bis]. Regards Brian From nobody Tue May 16 22:57:10 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E104E12EAF6 for ; Tue, 16 May 2017 22:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 ItgbJGUahsee for ; Tue, 16 May 2017 22:57:07 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 03CF7129C07 for ; Tue, 16 May 2017 22:53:12 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id t26so1729461qtg.0 for ; Tue, 16 May 2017 22:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y6T4ljbdHHbrpbJh5gllMS/UOIU7c850+yvk4xIkG/E=; b=ek0osLMqzK97uVP7O8C+14P9hrOGmJ2kWrQYPCr+rROg/yhM87FWd9+d9gYwm/XYXE dfJQ1Lo6c0SjdX/GkYemXkD8yJpAmLTcbndv5BaoIHvhmaBz/BhQSshE+Y48OxU0tbEN 0wI370xkdSmBD+SkxBpD3fTH1bfr/w6W7GxfyQ0jRnbzeJXqoEQl2PFEiliGSmyr9dsN Mp9rC3Y9mGyCHBcmnAW1f2sKRgHxYm2da7wKFIXpB+t5qz9BezR63V1hsxtXml8qacOf kTyl6oW05uCgGnEI93y16pmeaQW2rlNvII37IJR/P9UYHInaHOxXcx3Qahg9hnpsuTKK /jig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y6T4ljbdHHbrpbJh5gllMS/UOIU7c850+yvk4xIkG/E=; b=q5dqpT2+qSx/NQ3swwt61epDNslReRM1ahwkD4zgfeBA4n/dn3igR4k8ENyT4RVr0D YK1BP+JEBOSWu9gV4wnR7ogYo/xRRVslifZ3XO1m6X/B7ZHMobVKufkqZpK51CQMdV02 r66H1pEoZV6W7apvsaTrfF3EOl7v+dNuvkbsXWCSzd/8EPfwl/6sW40+uguXzkwinnqr TL0OYa/ywm0O91+CtT2A1tcIMuwv6qEOCHzcXfdFbALEK5nnMcySLetnKBdORNnwQtHs rq2paMNtNJ0HTyTsZbnx59+pMZ8LuLHddgCDd94Bv+wZl9r3oUYML9bGHTCsH1QVswqC eLmQ== X-Gm-Message-State: AODbwcBUUmP7ExiC3ysFCdmiBqYSBq6GfbTcUjgvHgdm93flII3z1GVJ ajfbhWwbDk0VJOifgzXh0eR09h8wgfdF X-Received: by 10.237.61.28 with SMTP id g28mr1338097qtf.279.1495000391078; Tue, 16 May 2017 22:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 16 May 2017 22:53:10 -0700 (PDT) In-Reply-To: References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> From: Tom Herbert Date: Tue, 16 May 2017 22:53:10 -0700 Message-ID: To: "Joel M. Halpern" Cc: Erik Kline , Petr Lapukhov , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 05:57:09 -0000 On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern wrote: > If we want the documents to be informational, then it should be about a > context where we understand how to build the surrounding infrastructure. > For example, if it were documented for data centers, based on Facebook's > experience, I would have trouble objecting to informational publication. > > If we do not know where it applies, and what to try it out in various > contexts with various control setups, then that sounds like experimental > RFCs. While I have my doubts about some of the applicability, that should > not stop useful experimentation. > > But an informational document that says that this can be used (roughly > speaking) ~anywhere you can figure out a way to control it~ seems a bit odd. > Okay, thanks for the clarification. It seems like either experimental or standard would be appropriate then. The other aspect that could be relevant is there is no change to on the wire protocol, I'm not sure how that would impact the track status. As far as how to control it, I would point out that neither GRE nor IPIP, probably the two most common encapsulations in use, don't specify an associated control protocol. We are taking that same approach with GUE and I think that same approach is good for ILA. It would be great to see a common control plane for tunneling and virtualization that solves the larger common problem (this is why IDEAS is exciting to me), but even if that existed it would never be the only means to control the dataplane. In some deployments simple configuration is more than sufficient, for example. Thanks, Tom > Yours, > Joel > > On 5/16/17 11:25 PM, Erik Kline wrote: >> >> >> >> On 14 May 2017 at 03:21, Tom Herbert > > wrote: >> >> On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern >> > wrote: >> > It appears to me that there are contexts in which it is likely that >> ILA is >> > useful. >> > >> > Using the example of the progression of LISP, I have concern with >> the >> > current approach of NOT spelling out how and where it would be used. >> LISP >> > started out as experimental in significant part because it was not >> clear >> > where it would be useful. We re now progressing it to PS with a >> clear >> > context. And that context is NOT Internet-wide deployment for >> Internet >> > scaling. Because that deployment problem is REALLY challenging. >> > >> > As such, if ILA wants to either be developed for the data center >> context or >> > be developed as an interesting experiment across a range of >> potential uses, >> > I can not object. >> > >> > I do have problems moving it forward towards standards track for >> some >> > unspecified but general use in its current form. The dependence of >> the data >> > plane protocol on the information distribution is so strong that I >> do not >> > see how the general case can be treated. >> > >> Hi Joel, >> >> Intended status is listed as informational if that helps. >> >> I tend to think that the relationship between an ILA data plane and >> control plane is analogous to the relationship between the IP protocol >> and routing protocols. Yes, there is a strong dependency on having a >> control plane, but mandating a specific control plane as part of the >> core protocol reduces flexibility and extensibility. >> >> >> Put another way: the domain of applicability is the same as the >> domain(s) over which the control plane operates. Any ILA packets >> outside that/ose domain/s should just look like vanilla IPv6. From nobody Wed May 17 02:31:46 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32253129534 for ; Wed, 17 May 2017 02:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C6QJBxoL9IXp for ; Wed, 17 May 2017 02:31:40 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 81E7F12E055 for ; Wed, 17 May 2017 02:27:15 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id v15so9095480wmv.1 for ; Wed, 17 May 2017 02:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CbwUzKoUgWyM/9/ihXaZBi2w0pr75NEuOHcqxpfyApI=; b=fCFabORGjFsVtsN6H6m6N8vlsk7WPCVROPuDHOnetLOTL8/X0uvdoCO/RzWRJXtzNO 1W0+ppmHmgCCgWgZtEEDD+5y6vXKi8exniez3RF9zvFQW5tk+qgKmzECrNBzaEVZcwFP Nckp8Ztk9Ldv0NQan4HprDSaACuQ2PZH0/zJABLZHbYuWXf6kXOUxD2f3+cRfYSCN/oi sv8V6Ks3dzYlR4hEIS0wztxGHNSoy1BmqN6LwfKfDTGsyE4oPgMhIqax6kdr79hFX/vF mCYpM8nPY8H6U2Bf9IF3s6HsvwEdmmsOiNd31Dq8puwyXBEgj/4o/T8zL7ndoD8kgv0G R2cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=CbwUzKoUgWyM/9/ihXaZBi2w0pr75NEuOHcqxpfyApI=; b=dARu/ZBdlkwH0S7PB9xr2Fo6kBoYeg7IVpm6tQ1cEkmFS4DhEL/TpHXEQGCqiuC3Rn 4WzOnGsx6p4+oWyhBO37/xBozEuXaquGwLU38hakNkz82UunqWe/E1zduahkwPGKGgm8 KmF7++iDlR87I8EhHc+tqzElDwJt43ACxoDD7oRCgiCUL4l1Nua63XFi6/vuo+04Bxss UAqvjArMSDbWzadok6wioJ4RrxQQsKlfJCSOQLKHQYdzYyPOmBQxTvgdfOUekLvGOsn9 CKhelwGKUwf6S4xZPGF2cMtf4PXWC4nGyFGYD02O84vM1Nn5lQDBq7H7HL6TkR9iQ6w2 spoA== X-Gm-Message-State: AODbwcBYHfAgxq/Pe3skZgVef6FUOTBv/+UqwPeCLbIDvLUFrxQYyX+B P6okqUcRwKVZWclYV8I8r3ZiV8qGvxBQ X-Received: by 10.28.183.8 with SMTP id h8mr1618128wmf.54.1495013234075; Wed, 17 May 2017 02:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.125 with HTTP; Wed, 17 May 2017 02:27:13 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> From: Behcet Sarikaya Date: Wed, 17 May 2017 04:27:13 -0500 Message-ID: To: Tom Herbert Cc: "Joel M. Halpern" , Petr Lapukhov , "int-area@ietf.org" Content-Type: multipart/alternative; boundary="001a1148f920c06f8d054fb4e465" Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 09:31:44 -0000 --001a1148f920c06f8d054fb4e465 Content-Type: text/plain; charset="UTF-8" On Wed, May 17, 2017 at 12:53 AM, Tom Herbert wrote: > On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern > wrote: > > If we want the documents to be informational, then it should be about a > > context where we understand how to build the surrounding infrastructure. > > For example, if it were documented for data centers, based on Facebook's > > experience, I would have trouble objecting to informational publication. > > > > If we do not know where it applies, and what to try it out in various > > contexts with various control setups, then that sounds like experimental > > RFCs. While I have my doubts about some of the applicability, that > should > > not stop useful experimentation. > > > > But an informational document that says that this can be used (roughly > > speaking) ~anywhere you can figure out a way to control it~ seems a bit > odd. > > > Okay, thanks for the clarification. It seems like either experimental > or standard would be appropriate then. The other aspect that could be > relevant is there is no change to on the wire protocol, I'm not sure > how that would impact the track status. > > As far as how to control it, I would point out that neither GRE nor > IPIP, probably the two most common encapsulations in use, don't > specify an associated control protocol. We are taking that same > approach with GUE and I think that same approach is good for ILA. It > would be great to see a common control plane for tunneling and > virtualization that solves the larger common problem (this is why > IDEAS is exciting to me), but even if that existed it would never be > the only means to control the dataplane. In some deployments simple > configuration is more than sufficient, for example. > > Tom, I think you are confusing what Joel said, i.e. figure out a way to control it with what you have in your mind, i.e. control plane. I think a way to control it means defining a few RADIUS attributes to manage ILA which can be done in an accompanying draft. Regards, Behcet > Thanks, > Tom > > > Yours, > > Joel > > > > On 5/16/17 11:25 PM, Erik Kline wrote: > >> > >> > >> > >> On 14 May 2017 at 03:21, Tom Herbert >> > wrote: > >> > >> On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern > >> > wrote: > >> > It appears to me that there are contexts in which it is likely > that > >> ILA is > >> > useful. > >> > > >> > Using the example of the progression of LISP, I have concern with > >> the > >> > current approach of NOT spelling out how and where it would be > used. > >> LISP > >> > started out as experimental in significant part because it was not > >> clear > >> > where it would be useful. We re now progressing it to PS with a > >> clear > >> > context. And that context is NOT Internet-wide deployment for > >> Internet > >> > scaling. Because that deployment problem is REALLY challenging. > >> > > >> > As such, if ILA wants to either be developed for the data center > >> context or > >> > be developed as an interesting experiment across a range of > >> potential uses, > >> > I can not object. > >> > > >> > I do have problems moving it forward towards standards track for > >> some > >> > unspecified but general use in its current form. The dependence > of > >> the data > >> > plane protocol on the information distribution is so strong that I > >> do not > >> > see how the general case can be treated. > >> > > >> Hi Joel, > >> > >> Intended status is listed as informational if that helps. > >> > >> I tend to think that the relationship between an ILA data plane and > >> control plane is analogous to the relationship between the IP > protocol > >> and routing protocols. Yes, there is a strong dependency on having a > >> control plane, but mandating a specific control plane as part of the > >> core protocol reduces flexibility and extensibility. > >> > >> > >> Put another way: the domain of applicability is the same as the > >> domain(s) over which the control plane operates. Any ILA packets > >> outside that/ose domain/s should just look like vanilla IPv6. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --001a1148f920c06f8d054fb4e465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 17, 2017 at 12:53 AM, Tom Herbert <tom@herbertland.com> wrote:
<= span class=3D"gmail-">On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <= jmh@joelhalpern.com> wrote: > If we want the documents to be informational, then it should be about = a
> context where we understand how to build the surrounding infrastructur= e.
> For example, if it were documented for data centers, based on Facebook= 's
> experience, I would have trouble objecting to informational publicatio= n.
>
> If we do not know where it applies, and what to try it out in various<= br> > contexts with various control setups, then that sounds like experiment= al
> RFCs.=C2=A0 While I have my doubts about some of the applicability, th= at should
> not stop useful experimentation.
>
> But an informational document that says that this can be used (roughly=
> speaking) ~anywhere you can figure out a way to control it~ seems a bi= t odd.
>
Okay, thanks for the clarification. It seems like either experimenta= l
or standard would be appropriate then. The other aspect that could be
relevant is there is no change to on the wire protocol, I'm not sure how that would impact the track status.

As far as how to control it, I would point out that neither GRE nor
IPIP, probably the two most common encapsulations in use, don't
specify an associated control protocol. We are taking that same
approach with GUE and I think that same approach is good for ILA. It
would be great to see a common control plane for tunneling and
virtualization that solves the larger common problem (this is why
IDEAS is exciting to me), but even if that existed it would never be
the only means to control the dataplane. In some deployments simple
configuration is more than sufficient, for example.


Tom, I think you are confusing =C2=A0w= hat Joel said, i.e. =C2=A0figure out a way to control it with what you have= in your mind, i.e. control plane.
I think =C2=A0a way to control= it =C2=A0means defining a few RADIUS attributes to manage ILA which can be= done in an accompanying draft.

Regards,

Behcet
Thanks,
Tom

> Yours,
> Joel
>
> On 5/16/17 11:25 PM, Erik Kline wrote:
>>
>>
>>
>> On 14 May 2017 at 03:21, Tom Herbert <tom@herbertland.com
>> <mailto:tom@herbertland.= com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpe= rn
>>=C2=A0 =C2=A0 =C2=A0<jmh@= joelhalpern.com <mailto:jmh@j= oelhalpern.com>> wrote:
>>=C2=A0 =C2=A0 =C2=A0> It appears to me that there are contexts i= n which it is likely that
>> ILA is
>>=C2=A0 =C2=A0 =C2=A0> useful.
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> Using the example of the progression of LI= SP, I have concern with
>> the
>>=C2=A0 =C2=A0 =C2=A0> current approach of NOT spelling out how a= nd where it would be used.
>> LISP
>>=C2=A0 =C2=A0 =C2=A0> started out as experimental in significant= part because it was not
>> clear
>>=C2=A0 =C2=A0 =C2=A0> where it would be useful.=C2=A0 We re now = progressing it to PS with a
>> clear
>>=C2=A0 =C2=A0 =C2=A0> context.=C2=A0 And that context is NOT Int= ernet-wide deployment for
>> Internet
>>=C2=A0 =C2=A0 =C2=A0> scaling.=C2=A0 Because that deployment pro= blem is REALLY challenging.
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> As such, if ILA wants to either be develop= ed for the data center
>> context or
>>=C2=A0 =C2=A0 =C2=A0> be developed as an interesting experiment = across a range of
>> potential uses,
>>=C2=A0 =C2=A0 =C2=A0> I can not object.
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> I do have problems moving it forward towar= ds standards track for
>> some
>>=C2=A0 =C2=A0 =C2=A0> unspecified but general use in its current= form.=C2=A0 The dependence of
>> the data
>>=C2=A0 =C2=A0 =C2=A0> plane protocol on the information distribu= tion is so strong that I
>> do not
>>=C2=A0 =C2=A0 =C2=A0> see how the general case can be treated. >>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0Hi Joel,
>>
>>=C2=A0 =C2=A0 =C2=A0Intended status is listed as informational if t= hat helps.
>>
>>=C2=A0 =C2=A0 =C2=A0I tend to think that the relationship between a= n ILA data plane and
>>=C2=A0 =C2=A0 =C2=A0control plane is analogous to the relationship = between the IP protocol
>>=C2=A0 =C2=A0 =C2=A0and routing protocols. Yes, there is a strong d= ependency on having a
>>=C2=A0 =C2=A0 =C2=A0control plane, but mandating a specific control= plane as part of the
>>=C2=A0 =C2=A0 =C2=A0core protocol reduces flexibility and extensibi= lity.
>>
>>
>> Put another way: the domain of applicability is the same as the >> domain(s) over which the control plane operates.=C2=A0 Any ILA pac= kets
>> outside that/ose domain/s should just look like vanilla IPv6.

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--001a1148f920c06f8d054fb4e465-- From nobody Wed May 17 06:41:09 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A63212EAD5 for ; Wed, 17 May 2017 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 KCfb3yVulC77 for ; Wed, 17 May 2017 06:41:06 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 C501B126C23 for ; Wed, 17 May 2017 06:35:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ACC08465138; Wed, 17 May 2017 06:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1495028138; bh=ysgmmRC5Tyvja3yU1UB7YbzMIt0/leCpeHFQ+ronpeM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=P1sGWKBQCi2SZ9s0e6hSJvhN7sBzPDXqfDKZdGryo7lMQA8XEqxJb2aoJtR8v7a61 byrxpkT/60TnTawGQZrmyXbAWEpchwKEdKN2W8/yNWb2pNJP0Z/GUQNBxI9sPInfAe iLVIbyIt1tmJ4sGMfnjSqcvcRCanyDkNb73gGutw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 96E73465136; Wed, 17 May 2017 06:35:37 -0700 (PDT) To: Tom Herbert , "Joel M. Halpern" References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> Cc: Erik Kline , Petr Lapukhov , "int-area@ietf.org" From: "Joel M. Halpern" Message-ID: <3428e7ea-ed1b-1418-b160-7db4a72d6557@joelhalpern.com> Date: Wed, 17 May 2017 09:35:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 13:41:08 -0000 I do not think classic Internet tunnels (e.g. IP in IP or GRE) are a good comparison for ILA. The ILA mapping requires dynamic knowledge about the remote end. (One of the things that is important about ILA is its ability to hide dynamics.) GUE at least is proposed specifically for use in data centers. I think you understand my point, so I will not belabour it. Yours, Joel On 5/17/17 1:53 AM, Tom Herbert wrote: > On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern wrote: >> If we want the documents to be informational, then it should be about a >> context where we understand how to build the surrounding infrastructure. >> For example, if it were documented for data centers, based on Facebook's >> experience, I would have trouble objecting to informational publication. >> >> If we do not know where it applies, and what to try it out in various >> contexts with various control setups, then that sounds like experimental >> RFCs. While I have my doubts about some of the applicability, that should >> not stop useful experimentation. >> >> But an informational document that says that this can be used (roughly >> speaking) ~anywhere you can figure out a way to control it~ seems a bit odd. >> > Okay, thanks for the clarification. It seems like either experimental > or standard would be appropriate then. The other aspect that could be > relevant is there is no change to on the wire protocol, I'm not sure > how that would impact the track status. > > As far as how to control it, I would point out that neither GRE nor > IPIP, probably the two most common encapsulations in use, don't > specify an associated control protocol. We are taking that same > approach with GUE and I think that same approach is good for ILA. It > would be great to see a common control plane for tunneling and > virtualization that solves the larger common problem (this is why > IDEAS is exciting to me), but even if that existed it would never be > the only means to control the dataplane. In some deployments simple > configuration is more than sufficient, for example. > > Thanks, > Tom > >> Yours, >> Joel >> >> On 5/16/17 11:25 PM, Erik Kline wrote: >>> >>> >>> >>> On 14 May 2017 at 03:21, Tom Herbert >> > wrote: >>> >>> On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern >>> > wrote: >>> > It appears to me that there are contexts in which it is likely that >>> ILA is >>> > useful. >>> > >>> > Using the example of the progression of LISP, I have concern with >>> the >>> > current approach of NOT spelling out how and where it would be used. >>> LISP >>> > started out as experimental in significant part because it was not >>> clear >>> > where it would be useful. We re now progressing it to PS with a >>> clear >>> > context. And that context is NOT Internet-wide deployment for >>> Internet >>> > scaling. Because that deployment problem is REALLY challenging. >>> > >>> > As such, if ILA wants to either be developed for the data center >>> context or >>> > be developed as an interesting experiment across a range of >>> potential uses, >>> > I can not object. >>> > >>> > I do have problems moving it forward towards standards track for >>> some >>> > unspecified but general use in its current form. The dependence of >>> the data >>> > plane protocol on the information distribution is so strong that I >>> do not >>> > see how the general case can be treated. >>> > >>> Hi Joel, >>> >>> Intended status is listed as informational if that helps. >>> >>> I tend to think that the relationship between an ILA data plane and >>> control plane is analogous to the relationship between the IP protocol >>> and routing protocols. Yes, there is a strong dependency on having a >>> control plane, but mandating a specific control plane as part of the >>> core protocol reduces flexibility and extensibility. >>> >>> >>> Put another way: the domain of applicability is the same as the >>> domain(s) over which the control plane operates. Any ILA packets >>> outside that/ose domain/s should just look like vanilla IPv6. From nobody Wed May 17 08:07:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3580D12EC74 for ; Wed, 17 May 2017 08:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 lQr-Y8cCdXqm for ; Wed, 17 May 2017 08:07:13 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 06C1C12EB3E for ; Wed, 17 May 2017 08:00:21 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id y201so12238108qka.0 for ; Wed, 17 May 2017 08:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c+B0kzw0J3gsDq1yBgLRdAqmFvsszr4JC5TeXoTBHFo=; b=tOefdlLgkhpdhtdzmUibaxX399rp0S5qkVYbX4SLs0pgbNJudpYGNVPCI+uFS9dB9t dvlmtKz/Ws75LMMkL2gT2NWkvghYfUYJIJawcEg0bH5oyj3nNJfVrGlsz7M/LiU3II9k ESbghMHSLXV9S5CR18f03FOCvzX2BsI9OV0QEIXcvkiEQyiKpyNsvmcsQRkB/VQ0CekL i44lzvCfCupFVHQYtL6C1HVFxiaBWTg1TCxdl4EuaHJ593qW+9F6LQltpi95XFElV9ft /KKoVrhzV109Qj2U5DgsDvjK6XmohKpLSeCLPg2nwt5h4kc+/V/nBEfZnJng1o2uXO/k hxYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c+B0kzw0J3gsDq1yBgLRdAqmFvsszr4JC5TeXoTBHFo=; b=afq6ccZnIQ9TLt6vxKeW9Y28+3d5vEV8s4z0OvqRDYn+HDT0KdiXip0wYskQZqmZLu CSTR7GGh5BdPCWD9FzZbt/Syp/jb0hAU+UZjoOT2lT+xY/Xuc1eHlU3l08UwEa8tHcPP ZBEEUEildVPGCQRC+w/nGTtjmysfqQWIBDFdPMUGq5odfcqYk7HZ3Uv/L7Ag7N8UkBvM px8MZzE/08GhdOtsAGHj8U6cefoHoUxXdRbo17xVqzeDw+J1x1RnFNTDakpmFdoUtY3T x65sJMo+HgoNhYNA08TB/gpqIEjEuGcQsTVNbH+pE299u18ULChK7JgKGe3hjjT2yHRk y6QQ== X-Gm-Message-State: AODbwcCrAeWjuktgcL10xQ3LOXI4aG5YYSroGC7RQQZkLK3kn5pu6tAy LCtaHPAOD9PG+Q9mfW5s1bw8SocFnCu1 X-Received: by 10.55.197.92 with SMTP id p89mr3182806qki.34.1495033220032; Wed, 17 May 2017 08:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Wed, 17 May 2017 08:00:19 -0700 (PDT) In-Reply-To: <79a48d82-014a-f1dc-6fef-a2c9a492281d@gmail.com> References: <79a48d82-014a-f1dc-6fef-a2c9a492281d@gmail.com> From: Tom Herbert Date: Wed, 17 May 2017 08:00:19 -0700 Message-ID: To: Brian E Carpenter Cc: "int-area@ietf.org" , Petr Lapukhov Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 15:07:18 -0000 On Tue, May 16, 2017 at 10:29 PM, Brian E Carpenter wrote: > On 14/05/2017 05:42, Tom Herbert wrote: >> Hello, >> >> At the Chicago WG meeting I made a request that ILA be taken up as a >> WG item in int-area. The WG chairs and AD requested that we raise a >> discussion on the list about what else is needed to be done for ILA >> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The >> question was also raised if int-area is the right WG for ILA or if it >> should have a BOF. > > I think it's fine for int-area to take this up, as long as 6man > is alerted. > > A few somewhat random comments: > > Is there any particular reason you chose a /64 routing prefix, > rather than say /72 or /80? I don't see any dependency on SLAAC, > so there's no reason to care about /64, right? I assume you would > use DHCPv6 or some other method of assigning addresses to VMs. > The 64 bit was for convenience since that is what ILNP had and in the DC we wanted enough identifier bits to be able to do identifier assignment based on a timestamp as described in appendix B. There's no hard requirement for it. I think we could just say an ILA domain can define lengths of identifier and locators as they see fit-- as long as its consistent and unambiguous within the domain there shouldn't be an issue. > If you used /72 or /80 you'd have flexibility with a ULA prefix to > insert a subnet field. > >> The format of an ILA address with a global unicast locator is: >> >> |<--------------- Locator --------------->| >> |3 bits| N bits | M bits | 61-N-M | 64 bits | >> +------+-------------+---------+---------------------------------+ >> | 001 | Global prefix | Subnet | Host | Identifier | >> +------+---------------+---------+--------+----------------------+ > > Why is this restricted to 2000::/3? Probably shouldn't be. If locator length isn't fixed like above, then probably should just describe it by properties of being routable to physical hosts. > >> The format of an ILA address with a unique local IPv6 unicast locator >> is: >> >> |<--------------- Locator --------->| >> | 7 bits |1| 40 bits | 16 bits | 64 bits | >> +--------+-+------------+-----------+----------------------------+ >> | FC00 |L| Global ID | Host | Identifier | >> +--------+-+------------+-----------+----------------------------+ > > The first byte is confusing; presumably you're trying to express > fd00::/8 so why not put 11111101 ? > > I agree that the flow label would be tricky to use for this sort of > purpose, but I have a couple of comments anyway: > >> o The flow label is only twenty bits, this is too small to be a >> discriminator in forwarding a virtual packet to a specific >> destination. Conceptually, the flow label might be used in a >> type of label switching to solve that. > > Perhaps, but 6man fairly comprehensively rejected that type of usage. > In practice it's excluded by section 4 of RFC6437. > > o The flow label is not considered immutable in transit, > intermediate devices may change it. > > That's not phrased quite right. RFC6437 section 2 says: > > " Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change it > only for compelling operational security reasons as described in > Section 6.1. > > There is no way to verify whether a flow label has been modified en > route..." > > You could in fact have an operational guarantee that within an > administrative domain, no middleboxes will change the flow label. > So something like this is more accurate: > > o The flow label is not protected against changes in transit. > Yes, the flow label concept came up in some early dicussions. >> o Intermediate devices must not insert extension headers >> [RFC2460bis]. > > I think you could say: > > o Current specifications do not allow intermediate devices to > insert extension headers [RFC2460bis]. > Good point. > Regards > Brian From nobody Wed May 17 11:57:49 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7218E127369 for ; Wed, 17 May 2017 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 M-5xESB3Erkm for ; Wed, 17 May 2017 11:57:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 23721126CD6 for ; Wed, 17 May 2017 11:52:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4HIqF9F009577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 May 2017 11:52:15 -0700 (PDT) To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <1688a61c-7bba-1b61-c16d-ab4620346578@isi.edu> Date: Wed, 17 May 2017 11:52:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 18:57:47 -0000 Hi, Fred, Circling back to this item: On 3/29/2017 2:18 PM, Templin, Fred L wrote: > One other comment. I agree with figures 12 and 13 but (and I think this is > a crucial point) I think they need a supporting sentence or two explaining > why the procedure is "fragment then encapsulate" and not "encapsulate > then fragment". Will do. > This is the difference between tunnel fragmentation > and ordinary outer fragmentation, where your document is correctly > advocating tunnel fragmentation. Yeah, but I was unable to find definitive and RFC citations for those terms ("inner fragmentation" and "outer fragmentation"). 4459 mentions fragmentation of 'inner' and 'outer', but those terms go back to 2003 and before, and I'm not sure warrant a citation. > To the best of my knowledge, this was > first documented in Section 3.1.7 of RFC2764 and should be cited as such. > At least, that is what Bob B. suggested to me about 10yrs ago. The idea of differentiating inner and outer fragmentation goes back to RFC2003 at least, AFAICT. That section of RFC2764 mentions that outer fragmentation avoids fragmentation inside the tunnel, but doesn't recommend it (it just says "alternative"). Further, it claims that none of the existing tunneling protocols support this (even though RFC2003 does). I'm not convinced this is worth tracking down for its origins. Let me know if you feel otherwise, but we'd need stronger evidence AFAICT. Joe From nobody Wed May 17 13:57:25 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299B4124D85 for ; Wed, 17 May 2017 13:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 QQ-WiDKs6vNo for ; Wed, 17 May 2017 13:57:23 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 5F325126BF0 for ; Wed, 17 May 2017 13:57:21 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4HKubh7027803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 May 2017 13:56:38 -0700 (PDT) From: Joe Touch To: "Templin, Fred L" Cc: "int-area@ietf.org" References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> Message-ID: <2e53fdd1-ac00-851a-6112-b0f487789590@isi.edu> Date: Wed, 17 May 2017 13:56:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <340d81c0-8af9-b353-44ec-f40c722745f5@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 20:57:24 -0000 Hi, Fred (et al.), On 3/29/2017 3:06 PM, Joe Touch wrote: > One other comment. I agree with figures 12 and 13 but (and I think this is > a crucial point) I think they need a supporting sentence or two explaining > why the procedure is "fragment then encapsulate" and not "encapsulate > then fragment". It's actually "on-path fragment (during transit processing, if that occurs), then encapsulate then (source) fragment.". Figs 12/13 represent the last two steps; fig 11 describes the first. I've added a paragraph and clarified the pseudocode to make that clear. Joe From nobody Wed May 17 14:28:21 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608112717E; Wed, 17 May 2017 14:28:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149505650017.6670.1022872968633952096@ietfa.amsl.com> Date: Wed, 17 May 2017 14:28:20 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 21:28:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : IP Tunnels in the Internet Architecture Authors : Joe Touch Mark Townsley Filename : draft-ietf-intarea-tunnels-06.txt Pages : 52 Date : 2017-05-17 Abstract: This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document are used to derive recommendations that update MTU and fragment issues in RFC 4459. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-tunnels-06 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 17 14:51:15 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C171A126DD9 for ; Wed, 17 May 2017 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 H0H7rOwhli1K for ; Wed, 17 May 2017 14:51:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 38103126CC7 for ; Wed, 17 May 2017 14:51:11 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4HLohSs005756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 May 2017 14:50:43 -0700 (PDT) To: int-area@ietf.org References: <149505650017.6670.1022872968633952096@ietfa.amsl.com> From: Joe Touch Message-ID: <2fbd3252-c8eb-8a71-4a01-43c0044fe877@isi.edu> Date: Wed, 17 May 2017 14:50:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149505650017.6670.1022872968633952096@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------E7250322632DAFE133D84288" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 21:51:14 -0000 This is a multi-part message in MIME format. --------------E7250322632DAFE133D84288 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, A new version of intarea-tunnels has been posted, as noted below. At this point, I would like to ask the chairs to start a WG call to consider revising the document track, as per below. _*Some history:*_ This document began as a set of discussions at IETF 72 in Philadelphia (2008), where a few ADs approached us to try to integrate a number of emerging tunnel efforts, with the assumption of simply integrating them. The result was an attempt to simply organize the landscape at the time. We started that landscape as an INTAREA WG informational doc in March 2010. It took five years of discussions, both on this list and in other WGs, to realize we needed to start by explaining our understanding of the concept of a tunnel as a link (issues in 2015). At that point we realized that many existing and emerging tunnels were inconsistent with each other and with existing requirements. We came up with an approach which we believe is both correct and consistent with existing core Internet requirements, and highlighted where it differs from current tunnels (standards track, informational, or otherwise) in Section 5. At this point, we believe the core of this document is both stable and represents not only a clear view of tunnels as an architectural component of the Internet, but also represents the current best practices regarding the design and use of tunnels. _*Our request:*_ As a result, we'd like to ask the chairs to initiate a call to change the track of this document from Informational to BCP. The result of this decision will impact how Section 5 is resolved. If this document becomes a BCP, that section will be fleshed out for WG consensus. If this document remains Informational, then the recommendations in Section 5 might not be appropriate, and will likely need to be omitted in whole or part. Joe ------- Summary of 06 changes: - updated ECMP discussion - updated multipoint discussion - updated terminology (atom -> atomic packet) - revised Fig 12 and Fig 13 algorithms (it wasn't clear that this was outer fragmentation) ------ On 5/17/2017 2:28 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : IP Tunnels in the Internet Architecture > Authors : Joe Touch > Mark Townsley > Filename : draft-ietf-intarea-tunnels-06.txt > Pages : 52 > Date : 2017-05-17 > > Abstract: > This document discusses the role of IP tunnels in the Internet > architecture. An IP tunnel transits IP datagrams as payloads in non- > link layer protocols. This document explains the relationship of IP > tunnels to existing protocol layers and the challenges in supporting > IP tunneling, based on the equivalence of tunnels to links. The > implications of this document are used to derive recommendations that > update MTU and fragment issues in RFC 4459. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-06 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --------------E7250322632DAFE133D84288 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, all,

A new version of intarea-tunnels has been posted, as noted below.

At this point, I would like to ask the chairs to start a WG call to consider revising the document track, as per below.

Some history:

This document began as a set of discussions at IETF 72 in Philadelphia (2008), where a few ADs approached us to try to integrate a number of emerging tunnel efforts, with the assumption of simply integrating them. The result was an attempt to simply organize the landscape at the time.

We started that landscape as an INTAREA WG informational doc in March 2010. It took five years of discussions, both on this list and in other WGs, to realize we needed to start by explaining our understanding of the concept of a tunnel as a link (issues in 2015). At that point we realized that many existing and emerging tunnels were inconsistent with each other and with existing requirements.

We came up with an approach which we believe is both correct and consistent with existing core Internet requirements, and highlighted where it differs from current tunnels (standards track, informational, or otherwise) in Section 5. At this point, we believe the core of this document is both stable and represents not only a clear view of tunnels as an architectural component of the Internet, but also represents the current best practices regarding the design and use of tunnels.

Our request:

As a result, we'd like to ask the chairs to initiate a call to change the track of this document from Informational to BCP.

The result of this decision will impact how Section 5 is resolved. If this document becomes a BCP, that section will be fleshed out for WG consensus. If this document remains Informational, then the recommendations in Section 5 might not be appropriate, and will likely need to be omitted in whole or part.

Joe

-------

Summary of 06 changes:

    - updated ECMP discussion

    - updated multipoint discussion

    - updated terminology (atom -> atomic packet)

    - revised Fig 12 and Fig 13 algorithms (it wasn't clear that this was outer fragmentation)

------


On 5/17/2017 2:28 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group of the IETF.

        Title           : IP Tunnels in the Internet Architecture
        Authors         : Joe Touch
                          Mark Townsley
	Filename        : draft-ietf-intarea-tunnels-06.txt
	Pages           : 52
	Date            : 2017-05-17

Abstract:
   This document discusses the role of IP tunnels in the Internet
   architecture. An IP tunnel transits IP datagrams as payloads in non-
   link layer protocols. This document explains the relationship of IP
   tunnels to existing protocol layers and the challenges in supporting
   IP tunneling, based on the equivalence of tunnels to links. The
   implications of this document are used to derive recommendations that
   update MTU and fragment issues in RFC 4459.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-tunnels-06
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-tunnels-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--------------E7250322632DAFE133D84288-- From nobody Wed May 17 18:36:42 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED90129405 for ; Wed, 17 May 2017 18:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9oP9rTZ9Fpl1 for ; Wed, 17 May 2017 18:36:38 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 33DEE129431 for ; Wed, 17 May 2017 18:36:38 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id l50so22686411wrc.3 for ; Wed, 17 May 2017 18:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=b9J7m0EDm99O5uc8so0GF5QRAtKPvjhNPvK32LerXKw=; b=NvdlqykNogiyO9pawnR4bg+27gOXb/CWziqFf2fwQPvtkBZGZptVnbywuVSV8Jjxgj 6EC/K0IXGV5mqGpR79LwZUfqj+gvJVEd+ts8EPt21OSVuISV4INmc4QponVWjkd2ciHX xYrj4s54oOCn9q6lLX0QFsnDVCRYcz10iH26b30GCV5iC8N88oQImF2mmadLH9bZYG39 1iHRK5haB6w7Sc/xwBVCMmldKrXtNF6yEgLNSgOkz0wpGJoHygEuDMqk7FoCvng5G0rJ zA49A9k5Gkt06X7UJbTVgNYm1NRz4Y9OCkFJkI0GifEluOvnCp+tz3WOsq2ifyjBa9/p EzLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=b9J7m0EDm99O5uc8so0GF5QRAtKPvjhNPvK32LerXKw=; b=hSc1awx+iOAwxRsfSS0S+VbA0DT3FsZlZaDmX3m9Tqegdj+Yq5RerAJ9Enjd8pKT7R oOCMoTuseIlahXBHS0CWxQdgib1M+MMvXdt4RdMjR2TueyFSxwYGbrSt8Kg/0HwWRJk8 V8YpjQ/NLWdJMQotgCLIm1VN13YilSwJ7HIZBmaOWA0QouR2tB9XK+oc2ke/H5nHH4YC Axxx7AAnM57Y2k2oCdSAKkEmUXVRD5R6FandaLZNz1VjL75CMku+eiCdm9DnTUva2MCJ 4QqUt4OecT7utOfhMvjVEgJ+RFzT5GXHhaGt9e29EHU6tqK1rD36UQsYbVowY2NnfIpc Kk/Q== X-Gm-Message-State: AODbwcCyba9qbjajLuu8u4Znjtq4XsYIsRnMyIzz5rs6Mqe7r7zxRP9a lWDmLjecTkxVvMesAggofZOvyg73qw== X-Received: by 10.223.172.165 with SMTP id o34mr966752wrc.155.1495071396764; Wed, 17 May 2017 18:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.125 with HTTP; Wed, 17 May 2017 18:36:36 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <3428e7ea-ed1b-1418-b160-7db4a72d6557@joelhalpern.com> References: <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> <3428e7ea-ed1b-1418-b160-7db4a72d6557@joelhalpern.com> From: Behcet Sarikaya Date: Wed, 17 May 2017 20:36:36 -0500 Message-ID: To: "Joel M. Halpern" Cc: Tom Herbert , Petr Lapukhov , "int-area@ietf.org" Content-Type: multipart/alternative; boundary="001a113c456c84a5e3054fc26f50" Archived-At: Subject: Re: [Int-area] ILA and int-area X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 01:36:41 -0000 --001a113c456c84a5e3054fc26f50 Content-Type: text/plain; charset="UTF-8" On Wed, May 17, 2017 at 8:35 AM, Joel M. Halpern wrote: > I do not think classic Internet tunnels (e.g. IP in IP or GRE) are a good > comparison for ILA. The ILA mapping requires dynamic knowledge about the > remote end. (One of the things that is important about ILA is its ability > to hide dynamics.) > GUE at least is proposed specifically for use in data centers. > > I don't think this discussion, i.e. Tom's request to intarea was related to GUE which is already a WG draft. Also GUE is not specifically proposed for data centers, but it could be used in data centers with certain extension headers. I still think that especially if experimental/standard track is used means to manage ILA would be needed. My two cents :) Behcet > I think you understand my point, so I will not belabour it. > > Yours, > Joel > > > On 5/17/17 1:53 AM, Tom Herbert wrote: > >> On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern >> wrote: >> >>> If we want the documents to be informational, then it should be about a >>> context where we understand how to build the surrounding infrastructure. >>> For example, if it were documented for data centers, based on Facebook's >>> experience, I would have trouble objecting to informational publication. >>> >>> If we do not know where it applies, and what to try it out in various >>> contexts with various control setups, then that sounds like experimental >>> RFCs. While I have my doubts about some of the applicability, that >>> should >>> not stop useful experimentation. >>> >>> But an informational document that says that this can be used (roughly >>> speaking) ~anywhere you can figure out a way to control it~ seems a bit >>> odd. >>> >>> Okay, thanks for the clarification. It seems like either experimental >> or standard would be appropriate then. The other aspect that could be >> relevant is there is no change to on the wire protocol, I'm not sure >> how that would impact the track status. >> >> As far as how to control it, I would point out that neither GRE nor >> IPIP, probably the two most common encapsulations in use, don't >> specify an associated control protocol. We are taking that same >> approach with GUE and I think that same approach is good for ILA. It >> would be great to see a common control plane for tunneling and >> virtualization that solves the larger common problem (this is why >> IDEAS is exciting to me), but even if that existed it would never be >> the only means to control the dataplane. In some deployments simple >> configuration is more than sufficient, for example. >> >> Thanks, >> Tom >> >> Yours, >>> Joel >>> >>> On 5/16/17 11:25 PM, Erik Kline wrote: >>> >>>> >>>> >>>> >>>> On 14 May 2017 at 03:21, Tom Herbert >>> > wrote: >>>> >>>> On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern >>>> > wrote: >>>> > It appears to me that there are contexts in which it is likely >>>> that >>>> ILA is >>>> > useful. >>>> > >>>> > Using the example of the progression of LISP, I have concern with >>>> the >>>> > current approach of NOT spelling out how and where it would be >>>> used. >>>> LISP >>>> > started out as experimental in significant part because it was not >>>> clear >>>> > where it would be useful. We re now progressing it to PS with a >>>> clear >>>> > context. And that context is NOT Internet-wide deployment for >>>> Internet >>>> > scaling. Because that deployment problem is REALLY challenging. >>>> > >>>> > As such, if ILA wants to either be developed for the data center >>>> context or >>>> > be developed as an interesting experiment across a range of >>>> potential uses, >>>> > I can not object. >>>> > >>>> > I do have problems moving it forward towards standards track for >>>> some >>>> > unspecified but general use in its current form. The dependence >>>> of >>>> the data >>>> > plane protocol on the information distribution is so strong that I >>>> do not >>>> > see how the general case can be treated. >>>> > >>>> Hi Joel, >>>> >>>> Intended status is listed as informational if that helps. >>>> >>>> I tend to think that the relationship between an ILA data plane and >>>> control plane is analogous to the relationship between the IP >>>> protocol >>>> and routing protocols. Yes, there is a strong dependency on having a >>>> control plane, but mandating a specific control plane as part of the >>>> core protocol reduces flexibility and extensibility. >>>> >>>> >>>> Put another way: the domain of applicability is the same as the >>>> domain(s) over which the control plane operates. Any ILA packets >>>> outside that/ose domain/s should just look like vanilla IPv6. >>>> >>> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --001a113c456c84a5e3054fc26f50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 17, 2017 at 8:35 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
I do not think classic Internet= tunnels (e.g. IP in IP or GRE) are a good comparison for ILA.=C2=A0 The IL= A mapping requires dynamic knowledge about the remote end.=C2=A0 (One of th= e things that is important about ILA is its ability to hide dynamics.)
GUE at least is proposed specifically for use in data centers.


I don't think this discussion, i.e= . Tom's request to intarea was related to GUE which is already a WG dra= ft.
Also GUE is not specifically proposed for data centers, but i= t could be used in data centers with certain extension headers.
<= br>
I still think that especially if experimental/standard track = is used means to manage ILA would be needed.


<= /div>
My two cents :)

Behcet

=C2=A0
I think you understand my point, so I will not belabour it.

Yours,
Joel


On 5/17/17 1:53 AM, Tom Herbert wrote:
On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
If we want the documents to be informational, then it should be about a
context where we understand how to build the surrounding infrastructure. For example, if it were documented for data centers, based on Facebook'= s
experience, I would have trouble objecting to informational publication.
If we do not know where it applies, and what to try it out in various
contexts with various control setups, then that sounds like experimental RFCs.=C2=A0 While I have my doubts about some of the applicability, that sh= ould
not stop useful experimentation.

But an informational document that says that this can be used (roughly
speaking) ~anywhere you can figure out a way to control it~ seems a bit odd= .

Okay, thanks for the clarification. It seems like either experimental
or standard would be appropriate then. The other aspect that could be
relevant is there is no change to on the wire protocol, I'm not sure how that would impact the track status.

As far as how to control it, I would point out that neither GRE nor
IPIP, probably the two most common encapsulations in use, don't
specify an associated control protocol. We are taking that same
approach with GUE and I think that same approach is good for ILA. It
would be great to see a common control plane for tunneling and
virtualization that solves the larger common problem (this is why
IDEAS is exciting to me), but even if that existed it would never be
the only means to control the dataplane. In some deployments simple
configuration is more than sufficient, for example.

Thanks,
Tom

Yours,
Joel

On 5/16/17 11:25 PM, Erik Kline wrote:



On 14 May 2017 at 03:21, Tom Herbert <tom@herbertland.com
<mailto:tom@her= bertland.com>> wrote:

=C2=A0 =C2=A0 On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern
=C2=A0 =C2=A0 <= jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
=C2=A0 =C2=A0 > It appears to me that there are contexts in which it is = likely that
ILA is
=C2=A0 =C2=A0 > useful.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Using the example of the progression of LISP, I have con= cern with
the
=C2=A0 =C2=A0 > current approach of NOT spelling out how and where it wo= uld be used.
LISP
=C2=A0 =C2=A0 > started out as experimental in significant part because = it was not
clear
=C2=A0 =C2=A0 > where it would be useful.=C2=A0 We re now progressing it= to PS with a
clear
=C2=A0 =C2=A0 > context.=C2=A0 And that context is NOT Internet-wide dep= loyment for
Internet
=C2=A0 =C2=A0 > scaling.=C2=A0 Because that deployment problem is REALLY= challenging.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > As such, if ILA wants to either be developed for the dat= a center
context or
=C2=A0 =C2=A0 > be developed as an interesting experiment across a range= of
potential uses,
=C2=A0 =C2=A0 > I can not object.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I do have problems moving it forward towards standards t= rack for
some
=C2=A0 =C2=A0 > unspecified but general use in its current form.=C2=A0 T= he dependence of
the data
=C2=A0 =C2=A0 > plane protocol on the information distribution is so str= ong that I
do not
=C2=A0 =C2=A0 > see how the general case can be treated.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 Hi Joel,

=C2=A0 =C2=A0 Intended status is listed as informational if that helps.

=C2=A0 =C2=A0 I tend to think that the relationship between an ILA data pla= ne and
=C2=A0 =C2=A0 control plane is analogous to the relationship between the IP= protocol
=C2=A0 =C2=A0 and routing protocols. Yes, there is a strong dependency on h= aving a
=C2=A0 =C2=A0 control plane, but mandating a specific control plane as part= of the
=C2=A0 =C2=A0 core protocol reduces flexibility and extensibility.


Put another way: the domain of applicability is the same as the
domain(s) over which the control plane operates.=C2=A0 Any ILA packets
outside that/ose domain/s should just look like vanilla IPv6.

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--001a113c456c84a5e3054fc26f50-- From nobody Wed May 17 19:10:30 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B99129484 for ; Wed, 17 May 2017 19:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 25p1D7M4OU5m for ; Wed, 17 May 2017 19:10:22 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 56D9F129470 for ; Wed, 17 May 2017 19:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4I2AHER019693; Wed, 17 May 2017 19:10:18 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4I2ABe3019679 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 17 May 2017 19:10:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 May 2017 19:10:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 17 May 2017 19:10:11 -0700 From: "Templin, Fred L" To: Joe Touch CC: "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sIBNWwmAgAADDUA= Date: Thu, 18 May 2017 02:10:11 +0000 Message-ID: <50bf8e85647c400b9d17a6fe46954512@XCH15-06-08.nw.nos.boeing.com> References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu> <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com> <1688a61c-7bba-1b61-c16d-ab4620346578@isi.edu> In-Reply-To: <1688a61c-7bba-1b61-c16d-ab4620346578@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 02:10:23 -0000 SGkgSm9lLA0KDQpDYW4ndCBnZXQgdG8gaXQganVzdCBub3csIGJ1dCBJIHByb21pc2UgSSB3aWxs IHJlc3BvbmQgdG8gdGhlc2UgYXMgZWFybHkgYXMgcG9zc2libGUuDQpBYm91dCB0aGlzIHBhcnRp Y3VsYXIgcXVlc3Rpb24sIHlvdSBtYXkga25vdyB0aGF0IEkgaG9sZCBCb2IgQi4gaW4gdGhlIGhp Z2hlc3QNCmVzdGVlbSBhbmQgdG9vayBoaXMgd29yZCBvbiB0aGlzIHN1YmplY3QgYXMgSSB3b3Vs ZCBhIHZvaWNlIGZyb20gdGhlIGhlYXZlbnMuDQoNCkkga25vdyBCb2IgcHJvYmFibHkgcHVsbHMg aGlzIHBhbnRzIG9uIG9uZSBsZWcgYXQgYSB0aW1lIGluIHRoZSBtb3JuaW5nIGp1c3QNCmxpa2Ug d2UgYWxsIGRvLCBidXQgaGlzIGxvbmcgdGVudXJlIGFzIFJGQyBFZGl0b3IgYW5kIGF1dGhvcnNo aXAgb2YgYmVkcm9jaw0KZG9jcyBsaWtlIFJGQzExMjIgaGF2ZSBoZWxkIG1lIGluIGF3ZSBvZiBo aW0uIFRoYXQgaXMgbm90IHRvIHNheSB0aGF0IEkgZG8NCm5vdCBoYXZlIGhpZ2ggcmVnYXJkcyBm b3IgeW91IChJIGRvKSBidXQgdG8gbWUgQm9iIGhhcyBhbHdheXMgYmVlbiAidGhlDQptYW4iLiBJ IGtub3cgLSBJIG5lZWQgdG8gZ2V0IG92ZXIgdGhhdCBhbmQgbW92ZSBvbi4uLg0KDQpUaGFua3Mg LSBGcmVkIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDE3LCAyMDE3 IDExOjUyIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+DQo+IENjOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNS50eHQNCj4gDQo+IEhpLCBG cmVkLA0KPiANCj4gQ2lyY2xpbmcgYmFjayB0byB0aGlzIGl0ZW06DQo+IA0KPiANCj4gT24gMy8y OS8yMDE3IDI6MTggUE0sIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBPbmUgb3RoZXIgY29t bWVudC4gSSBhZ3JlZSB3aXRoIGZpZ3VyZXMgMTIgYW5kIDEzIGJ1dCAoYW5kIEkgdGhpbmsgdGhp cyBpcw0KPiA+IGEgY3J1Y2lhbCBwb2ludCkgSSB0aGluayB0aGV5IG5lZWQgYSBzdXBwb3J0aW5n IHNlbnRlbmNlIG9yIHR3byBleHBsYWluaW5nDQo+ID4gd2h5IHRoZSBwcm9jZWR1cmUgaXMgImZy YWdtZW50IHRoZW4gZW5jYXBzdWxhdGUiIGFuZCBub3QgImVuY2Fwc3VsYXRlDQo+ID4gdGhlbiBm cmFnbWVudCIuDQo+IFdpbGwgZG8uDQo+IA0KPiA+IFRoaXMgaXMgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiB0dW5uZWwgZnJhZ21lbnRhdGlvbg0KPiA+IGFuZCBvcmRpbmFyeSBvdXRlciBmcmFnbWVu dGF0aW9uLCB3aGVyZSB5b3VyIGRvY3VtZW50IGlzIGNvcnJlY3RseQ0KPiA+IGFkdm9jYXRpbmcg dHVubmVsIGZyYWdtZW50YXRpb24uDQo+IFllYWgsIGJ1dCBJIHdhcyB1bmFibGUgdG8gZmluZCBk ZWZpbml0aXZlIGFuZCBSRkMgY2l0YXRpb25zIGZvciB0aG9zZQ0KPiB0ZXJtcyAoImlubmVyIGZy YWdtZW50YXRpb24iIGFuZCAib3V0ZXIgZnJhZ21lbnRhdGlvbiIpLiA0NDU5IG1lbnRpb25zDQo+ IGZyYWdtZW50YXRpb24gb2YgJ2lubmVyJyBhbmQgJ291dGVyJywgYnV0IHRob3NlIHRlcm1zIGdv IGJhY2sgdG8gMjAwMw0KPiBhbmQgYmVmb3JlLCBhbmQgSSdtIG5vdCBzdXJlIHdhcnJhbnQgYSBj aXRhdGlvbi4NCj4gDQo+ID4gVG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCB0aGlzIHdhcw0K PiA+IGZpcnN0IGRvY3VtZW50ZWQgaW4gU2VjdGlvbiAzLjEuNyBvZiBSRkMyNzY0IGFuZCBzaG91 bGQgYmUgY2l0ZWQgYXMgc3VjaC4NCj4gPiBBdCBsZWFzdCwgdGhhdCBpcyB3aGF0IEJvYiBCLiBz dWdnZXN0ZWQgdG8gbWUgYWJvdXQgMTB5cnMgYWdvLg0KPiBUaGUgaWRlYSBvZiBkaWZmZXJlbnRp YXRpbmcgaW5uZXIgYW5kIG91dGVyIGZyYWdtZW50YXRpb24gZ29lcyBiYWNrIHRvDQo+IFJGQzIw MDMgYXQgbGVhc3QsIEFGQUlDVC4NCj4gDQo+IFRoYXQgc2VjdGlvbiBvZiBSRkMyNzY0IG1lbnRp b25zIHRoYXQgb3V0ZXIgZnJhZ21lbnRhdGlvbiBhdm9pZHMNCj4gZnJhZ21lbnRhdGlvbiBpbnNp ZGUgdGhlIHR1bm5lbCwgYnV0IGRvZXNuJ3QgcmVjb21tZW5kIGl0IChpdCBqdXN0IHNheXMNCj4g ImFsdGVybmF0aXZlIikuIEZ1cnRoZXIsIGl0IGNsYWltcyB0aGF0IG5vbmUgb2YgdGhlIGV4aXN0 aW5nIHR1bm5lbGluZw0KPiBwcm90b2NvbHMgc3VwcG9ydCB0aGlzIChldmVuIHRob3VnaCBSRkMy MDAzIGRvZXMpLg0KPiANCj4gSSdtIG5vdCBjb252aW5jZWQgdGhpcyBpcyB3b3J0aCB0cmFja2lu ZyBkb3duIGZvciBpdHMgb3JpZ2lucy4gTGV0IG1lDQo+IGtub3cgaWYgeW91IGZlZWwgb3RoZXJ3 aXNlLCBidXQgd2UnZCBuZWVkIHN0cm9uZ2VyIGV2aWRlbmNlIEFGQUlDVC4NCj4gDQo+IEpvZQ0K DQo= From nobody Thu May 18 15:53:18 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDE912EB04; Thu, 18 May 2017 15:53:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149514799195.6631.3231700013200014494@ietfa.amsl.com> Date: Thu, 18 May 2017 15:53:11 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 22:53:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Generic UDP Encapsulation Authors : Tom Herbert Lucy Yong Osama Zia Filename : draft-ietf-intarea-gue-04.txt Pages : 37 Date : 2017-05-18 Abstract: This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of different IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such as tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-gue-04 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 18 15:55:46 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D565512EAFF; Thu, 18 May 2017 15:55:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149514814482.6622.7980749679376688678@ietfa.amsl.com> Date: Thu, 18 May 2017 15:55:44 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-gue-extensions-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 22:55:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Extensions for Generic UDP Encapsulation Authors : Tom Herbert Lucy Yong Fred L. Templin Filename : draft-ietf-intarea-gue-extensions-01.txt Pages : 31 Date : 2017-05-18 Abstract: This specification defines a set of the fundamental optional extensions for Generic UDP Encapsulation (GUE). The extensions defined in this specification are the group identifier, security option, payload transform option, checksum option, fragmentation option, and the remote checksum offload option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions-01 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-extensions-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-extensions-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 18 16:07:15 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BFF12EB14 for ; Thu, 18 May 2017 16:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 7g30CVAXSyrO for ; Thu, 18 May 2017 16:07:10 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 5E7D6128D16 for ; Thu, 18 May 2017 16:02:09 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f55so46438642qta.3 for ; Thu, 18 May 2017 16:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PgQu6wF8An7zXiZ1rFW+1Z0J00pmKLBeVK3Rad5eKoE=; b=a8HYxKmrwfOlrtK86TU4qoIZS33JMDoOKqkLOME0lR/POrqkFKdUATUqiyCvdcBSk8 xlzgbK/4FSFdFZbVTdNhiDMVEz21MfnKOsbNw6C2I6sMm8rWEVNYguSJLdAXaLlj89/d dmxFK5BaGvh8hJYIbob68m2LU34kPTjwpRTo7sdL1PJsC004ipuTWMLVzvG9OUEBg1w4 68TsSZUlBrSIqMauKlGvORUOs0qAfRHQWm3MOkuFjxHk/OHP4m90daExSlb14Amn4FA7 SvTkLV03wFb7o6khgH1OgVTcLqyGT+khMXAQUF1n7vhLeuZHzciePoVTRd84fEpQYJQV PY7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PgQu6wF8An7zXiZ1rFW+1Z0J00pmKLBeVK3Rad5eKoE=; b=olrhMeqaNdzyqNhDie3d5TRJsaJkZPLkB2UtoAHnnQcMn9IstpcowdwroMbx77eCwf 86pxBNgcbEcTWb3QLm/PnhIZp1OLgYzEO276ZaH8sbYyXCwjQsvZ4u5JrGkuWx8/X91b kSEgIPUHOwUnWgntopjIQYXS5RHzV3Sa5mwEMrJyYfLWv6kOJSh5WJsE6Yu2j7dQ+6G/ nIvStyX2QbBGFpwepGF23OFH38E5aryTeAxsZQvViSbO7IJ9I0awh4VG9FRotz2EXi9z oEzKfR6QVEHH2l0uGLZWRAbm0bMZB8UzTaTAXUhGiayJgX8kwCdET2Pe56zFQqZQJ002 iWXg== X-Gm-Message-State: AODbwcCKCoLGKcio320cJ3iFUUdoxIBgNFMMAOzv+cAEtvSmQWRRdW8y TnnSz+ryxLAJKnpAtF53dHM7Sl61H0ec X-Received: by 10.200.40.193 with SMTP id j1mr6773200qtj.186.1495148528320; Thu, 18 May 2017 16:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Thu, 18 May 2017 16:02:07 -0700 (PDT) In-Reply-To: <149514814482.6622.7980749679376688678@ietfa.amsl.com> References: <149514814482.6622.7980749679376688678@ietfa.amsl.com> From: Tom Herbert Date: Thu, 18 May 2017 16:02:07 -0700 Message-ID: To: "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gue-extensions-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 23:07:14 -0000 Hello, I uploaded a new version of GUE extensions. In this version; - Add option payload coverage to HMAC security. This allows a mean to tie header authentication to the payload - Move IANA request for flag fields to this document since this is where they are. Also uploaded new version of GUE draft with the flag fields request - Fix typos, normative language, and references Thanks, Tom On Thu, May 18, 2017 at 3:55 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : Extensions for Generic UDP Encapsulation > Authors : Tom Herbert > Lucy Yong > Fred L. Templin > Filename : draft-ietf-intarea-gue-extensions-01.txt > Pages : 31 > Date : 2017-05-18 > > Abstract: > This specification defines a set of the fundamental optional > extensions for Generic UDP Encapsulation (GUE). The extensions > defined in this specification are the group identifier, security > option, payload transform option, checksum option, fragmentation > option, and the remote checksum offload option. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-gue-extensions-01 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-extensions-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-extensions-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu May 18 19:58:52 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3C127241 for ; Thu, 18 May 2017 19:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 mXS_Apbkrcsv for ; Thu, 18 May 2017 19:58:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3D6129C0C for ; Thu, 18 May 2017 19:54:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGX04998; Fri, 19 May 2017 02:53:59 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 19 May 2017 03:53:58 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 19 May 2017 10:53:45 +0800 From: Xuxiaohu To: "int-area@ietf.org" Thread-Topic: Is the UDP destination port number resource running out?// re: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt Thread-Index: AQHS0CmnQ/zIrELPwk+iaB2D2b/nV6H63uUg Date: Fri, 19 May 2017 02:53:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> In-Reply-To: <149514799195.6631.3231700013200014494@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.591E5E48.0005, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2d055b51bf1eb07c76d8f48d76950b50 Archived-At: Subject: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 02:58:51 -0000 SGkgYWxsLA0KDQpXaXRoIHJlZ2FyZCB0byBkaXJlY3RseSBlbmNhcHN1bGF0aW5nIElQdnggcGFj a2V0IGluIFVEUCwgSSB0aGluayB0aGUgZm9sbG93aW5nIGFyZ3VtZW50IGZvciB1c2luZyBWZXJz aW9uIDEgb2YgR1VFIGlzIG5vdCB2YWxpZDoNCg0KIlRoaXMgdGVjaG5pcXVlIHNhdmVzIGVuY2Fw c3VsYXRpb24gb3ZlcmhlYWQgb24gY29zdGx5IGxpbmtzDQogICBmb3IgdGhlIGNvbW1vbiB1c2Ug b2YgSVAgZW5jYXBzdWxhdGlvbiwgYW5kIGFsc28gb2J2aWF0ZXMgdGhlIG5lZWQgdG8NCiAgIGFs bG9jYXRlIGEgc2VwYXJhdGUgcG9ydCBudW1iZXIgZm9yIElQLW92ZXItVURQIGVuY2Fwc3VsYXRp b24uIg0KDQpGaXJzdCwgSSBkb24ndCB0aGluayB0aGUgZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCBv ZiA0IGJ5dGVzIGlzIGEgbWF0dGVyLiBIb3dldmVyLCB0aGUgcHJlbWlzZSBpcyB0aGF0IGl0J3Mg bWVhbmluZ2Z1bCBmb3IgdGhlIElFVEYgdG8gZGV2ZWxvcCBzdWNoIGEgR0VORVJJQyBhbmQgQ09W RVJBTEwgZW5jYXBzdWxhdGlvbiBtZXRob2Qgd2hpY2ggaXMgc3RpbGwgbG9va2luZyBmb3IgbmFp bHM6KSAgSWYgSSByZW1lbWJlcmVkIGNvcnJlY3RseSwgdGhpcyBkcmFmdCB3YXMgb3JpZ2luYWxs eSBhZG9wdGVkIGJ5IHRoZSBOVk8zIFdHIHdoaWNoIGlzIGZvY3VzZWQgb24gbXVsdGktdGVuYW5j eSwgYWx0aG91Z2ggdGhpcyBkcmFmdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIG11bHRpLXRlbmFu Y3k6KSBMYXR0ZXIgaXQgYmVjb21lcyBhIElOVEFSRUEgV0cgZHJhZnQuIGJ5IHRoZSB3YXksIGRp ZCBJIG1pc3MgdGhlIFdHIGFkb3B0aW9uIGNhbGwgZm9yIHRoaXMgZHJhZnQgaW4gdGhlIElOVEFS RUEgV0cgb3IgdGhlIFdHIGFkb3B0aW9uIGNhbGwgaXNuJ3Qgb2NjdXJyZWQgYXQgYWxsPw0KDQpT ZWNvbmQsIFVEUCBpdHNlbGYgaGFzIGJlZW4gd2lkZWx5IHVzZWQgYXMgYSB0dW5uZWwgdGVjaG5v bG9neSBkdWUgdG8gaXRzIGxvYWQtYmFsYW5jaW5nIGNhcGFiaWxpdHkuIFNlZSBMSVNQIFtSRkM2 ODMwXSwgVlhMQU4gW1JGQzczNDZdLCBNUExTLWluLVVEUCBbUkZDNzUxMF0sIEdSRS1pbi1VRFAg W1JGQzgwODZdLCBFU1AtaW4tVURQIFtSRkMzOTQ4XSwgVFJJTEwtaW4tVURQLCBOU0gtaW4tVURQ LCBWWExBTi1HUEUsIEdFTkVWRSwgR1VFLCAuLi4gVGhlIGRlc3RpbmF0aW9uIHBvcnQgaXMgdXNl ZCB0byBkaXN0aW5ndWlzaCB0aGVzZSBkaWZmZXJlbnQgVURQIHR1bm5lbCBwYXlsb2FkIHR5cGVz LiBGb3IgSVAtaW4tVURQLCB0aGVyZSBoYXMgYmVlbiBhIGRyYWZ0IChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQteHUtaW50YXJlYS1pcC1pbi11ZHApIHdoaWNoIHdhcyBvcmlnaW5h bGx5IGRpc2N1c3NlZCBpbiBTb2Z0d2lyZSBXRyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXh1LXNvZnR3aXJlLWlwLWluLXVkcCkgLiBJTUhPLCBpdCBzZWVtcyB1Z2x5IHRvIHVz ZSBhIHZlcnNpb24gZmllbGQgd2l0aGluIHRoZSBHVUUgaGVhZGVyIHRvIGRpc3Rpbmd1aXNoIElQ dnggaGVhZGVyIGZyb20gdGhlIEdVRSBoZWFkZXIgaXRzZWxmLiBJcyB0aGUgVURQIGRlc3RpbmF0 aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcgb3V0PyBJZiBzbywgd2h5IG5vdCB1c2Ug R1JFLWluLVVEUCB0byBjYXJyeSBHVUUgc28gYXMgdG8gc2F2ZSBvbmUgbW9yZSBVRFAgZGVzdGlu YXRpb24gcG9ydCBudW1iZXI/IA0KDQpUaGlyZCwgaWYgdGhlIEdVRSBkZXZvdGVzIGl0c2VsZiB0 byBzYXZlIHRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1iZXIgZm9yIHRoZSBpbnRlcmVzdCBv ZiB0aGUgaW50ZXJuZXQgY29tbXVuaXR5LCB0aGUgMi1iaXQgdmVyc2lvbiBmaWVsZCBhYnVzZWQg YXMgYSBwYXlsb2FkIHR5cGUgaW5kaWNhdG9yIGlzIG9idmlvdXNseSBub3QgZW5vdWdoOikNCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7Iyzog SW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiC3osvNyrG85DogMjAxN8TqNdTCMTnI1SA2OjUzDQo+IMrV vP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+ILOty806IGludC1hcmVhQGlldGYub3JnDQo+ INb3zOI6IFtJbnQtYXJlYV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNC50 eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEludGVybmV0IEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N Cj4gDQo+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogR2VuZXJpYyBVRFAgRW5jYXBzdWxhdGlv bg0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRvbSBIZXJiZXJ0DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgTHVjeSBZb25nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgT3Nh bWEgWmlhDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4 dA0KPiAJUGFnZXMgICAgICAgICAgIDogMzcNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMDUt MTgNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIEdl bmVyaWMgVURQIEVuY2Fwc3VsYXRpb24gKEdVRSksIHdoaWNoDQo+ICAgIGlzIGEgc2NoZW1lIGZv ciB1c2luZyBVRFAgdG8gZW5jYXBzdWxhdGUgcGFja2V0cyBvZiBkaWZmZXJlbnQgSVANCj4gICAg cHJvdG9jb2xzIGZvciB0cmFuc3BvcnQgYWNyb3NzIGxheWVyIDMgbmV0d29ya3MuIEJ5IGVuY2Fw c3VsYXRpbmcNCj4gICAgcGFja2V0cyBpbiBVRFAsIHNwZWNpYWxpemVkIGNhcGFiaWxpdGllcyBp biBuZXR3b3JraW5nIGhhcmR3YXJlIGZvcg0KPiAgICBlZmZpY2llbnQgaGFuZGxpbmcgb2YgVURQ IHBhY2tldHMgY2FuIGJlIGxldmVyYWdlZC4gR1VFIHNwZWNpZmllcw0KPiAgICBiYXNpYyBlbmNh cHN1bGF0aW9uIG1ldGhvZHMgdXBvbiB3aGljaCBoaWdoZXIgbGV2ZWwgY29uc3RydWN0cywgc3Vj aA0KPiAgICBhcyB0dW5uZWxzIGFuZCBvdmVybGF5IG5ldHdvcmtzIGZvciBuZXR3b3JrIHZpcnR1 YWxpemF0aW9uLCBjYW4gYmUNCj4gICAgY29uc3RydWN0ZWQuIEdVRSBpcyBleHRlbnNpYmxlIGJ5 IGFsbG93aW5nIG9wdGlvbmFsIGRhdGEgZmllbGRzIGFzDQo+ICAgIHBhcnQgb2YgdGhlIGVuY2Fw c3VsYXRpb24sIGFuZCBpcyBnZW5lcmljIGluIHRoYXQgaXQgY2FuIGVuY2Fwc3VsYXRlDQo+ICAg IHBhY2tldHMgb2YgdmFyaW91cyBJUCBwcm90b2NvbHMuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaW50YXJlYS1ndWUvDQo+IA0KPiBUaGVyZSBh cmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0DQo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNA0KPiANCj4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNA0K PiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEludC1hcmVhIG1haWxpbmcgbGlzdA0K PiBJbnQtYXJlYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ludC1hcmVhDQo= From nobody Fri May 19 07:56:41 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16B1292C5 for ; Fri, 19 May 2017 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 33Naeps6ncHY for ; Fri, 19 May 2017 07:56:38 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 D8062128C81 for ; Fri, 19 May 2017 07:56:37 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id k74so63152871qke.1 for ; Fri, 19 May 2017 07:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Vi23l9W8nMXhFA4XRBIAMtqgDjKIzK1wCj8JuLUeOcQ=; b=NZIEqfP9YqmADdARPhy0LIc2VVxj9kICRSUQSodr033zyFOze/cfw14yELmfSEwbuc d40V0IHiAziai8zlOax8wIpY5qSW7zJYfYWThu1n13e6xEQsoSHXRo8ztbod2CxFltja R+yRydQvUeIGqtp31zSgAvDO+2vvz0SLxN2JUZWTd0Tsp2vPXTmDrmYlSDsAG/5deGDD H48MKa3I81CCIOJYxITcvIiHc0Wpu5lBW40NgqcbR70dQQW5aHFQ2BWaxobqvAG+xuFG W6EzWGR74snH/rrOsi+pVICVnRyTf7ATch718bAKoPrXaiBdFxTvry+hgWN0Q1VAm7Yh 2LoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Vi23l9W8nMXhFA4XRBIAMtqgDjKIzK1wCj8JuLUeOcQ=; b=uboLxbyZwQXZtgrEUbOyB7w0aCoyVd1/V9F7q0PMa7QoU0Fej6A1dcICycqKkeodmF ERrtBZYN/5MWTlAtabE1LYjvcSlMuwCf48ohAGoV0e0eipqdCr2jRELLmWzpgdDdMQIr LacfhhaJ4shoqXoM9OB73957JnwMomOP619qKMe2ezNIy3wpl0w7byQ4A/m8CVD660Y7 z7g3fEfzMoXJbc5pRmy5PVmb8QN2hXoaLcLDU9y7zXP/itcgPGM42UdHmKS0RflKHjUg 5QKop5nfBeSDmGCF3gjyuHzQwpqUv0Hc0Z5Xahs1+xCRSXWg0RouIFphpmuhWtFjP6g0 pUZg== X-Gm-Message-State: AODbwcDtY0JW6bhVwIz5jAig9NN3U5SIfmz3lImQg1ZS4xkiVwo6PQQG ZWFnZJljqm7wuvy1psmT14XsgTi8oUu6ljU= X-Received: by 10.55.146.68 with SMTP id u65mr9295170qkd.77.1495205796844; Fri, 19 May 2017 07:56:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Fri, 19 May 2017 07:56:36 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> From: Tom Herbert Date: Fri, 19 May 2017 07:56:36 -0700 Message-ID: To: Xuxiaohu Cc: "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:56:40 -0000 Hi Xuxiaohu, Thanks for the comments. Some response are inline. On Thu, May 18, 2017 at 7:53 PM, Xuxiaohu wrote: > Hi all, > > With regard to directly encapsulating IPvx packet in UDP, I think the fol= lowing argument for using Version 1 of GUE is not valid: > > "This technique saves encapsulation overhead on costly links > for the common use of IP encapsulation, and also obviates the need to > allocate a separate port number for IP-over-UDP encapsulation." > > First, I don't think the encapsulation overhead of 4 bytes is a matter. I'm not sure everyone would agree with that. The case was made when we were discussing it that the savings would be beneficial for some deployments. > However, the premise is that it's meaningful for the IETF to develop such= a GENERIC and COVERALL encapsulation method which is still looking for nai= ls:) The protocol is called *Generic* UDP Encapsulation for reason. > If I remembered correctly, this draft was originally adopted by the NVO3 = WG which is focused on multi-tenancy, although this draft has nothing to do= with multi-tenancy:) Latter it becomes a INTAREA WG draft. by the way, did= I miss the WG adoption call for this draft in the INTAREA WG or the WG ado= ption call isn't occurred at all? > It was adopted after Seoul IETF. > Second, UDP itself has been widely used as a tunnel technology due to its= load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UD= P [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, NSH-= in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to disting= uish these different UDP tunnel payload types. For IP-in-UDP, there has bee= n a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which wa= s originally discussed in Softwire WG (https://tools.ietf.org/html/draft-xu= -softwire-ip-in-udp) . IMHO, it seems ugly to use a version field within th= e GUE header to distinguish IPvx header from the GUE header itself. Is the = UDP destination port number resource running out? >From RFC7605, section 6 "Conservation": "Assigned port numbers are a limited resource that is globally shared by the entire Internet community. As of 2014, approximately 5850 TCP and 5570 UDP port numbers had been assigned out of a total range of 49151. As a result of past conservation, current assigned port use is small and the current rate of assignment avoids the need for transition to larger number spaces. This conservation also helps avoid the need for IANA to rely on assigned port number reclamation, which is practically impossible even though procedurally permitted [RFC6335]. Also, it's not just the assignment that is a pain, port numbers to need to be managed in networks. If we introduce a new port number in the datacenter management tools, firewalls, packet capture need to be updated. A feature of GUE is that the payload transform option allows DTLS to be done on the payload. This obviates needing to ask for two port numbers (a DTLS variant and non-DTLS variant) as several of the encapsulation methods you listed above have done. > If so, why not use GRE-in-UDP to carry GUE so as to save one more UDP des= tination port number? > Then we'd be talking about having to reserve an Ethertype for GUE. > Third, if the GUE devotes itself to save the UDP destination port number = for the interest of the internet community, the 2-bit version field abused = as a payload type indicator is obviously not enough:) > I'm not sure how it's "obviously not enough". Version 1 handles the currently deployed two IP protocol versions. The technique allows for supporting two more IP protocol versions to be supported without burning another version number. Tom > Best regards, > Xiaohu > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Int-area [mailto:int-area-bounces@ietf.org]= =E4=BB=A3=E8=A1=A8 >> internet-drafts@ietf.org >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8819=E6=97=A5= 6:53 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: i-d-announce@ietf.org >> =E6=8A=84=E9=80=81: int-area@ietf.org >> =E4=B8=BB=E9=A2=98: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Internet Area Working Group of the IETF= . >> >> Title : Generic UDP Encapsulation >> Authors : Tom Herbert >> Lucy Yong >> Osama Zia >> Filename : draft-ietf-intarea-gue-04.txt >> Pages : 37 >> Date : 2017-05-18 >> >> Abstract: >> This specification describes Generic UDP Encapsulation (GUE), which >> is a scheme for using UDP to encapsulate packets of different IP >> protocols for transport across layer 3 networks. By encapsulating >> packets in UDP, specialized capabilities in networking hardware for >> efficient handling of UDP packets can be leveraged. GUE specifies >> basic encapsulation methods upon which higher level constructs, such >> as tunnels and overlay networks for network virtualization, can be >> constructed. GUE is extensible by allowing optional data fields as >> part of the encapsulation, and is generic in that it can encapsulate >> packets of various IP protocols. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-intarea-gue-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-gue-04 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri May 19 14:05:14 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED845129B19 for ; Fri, 19 May 2017 14:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 kR5unlIDJ5iD for ; Fri, 19 May 2017 14:05:11 -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 63BF3129488 for ; Fri, 19 May 2017 14:05:11 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4JL4ZcV024221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 May 2017 14:04:46 -0700 (PDT) To: Tom Herbert , Xuxiaohu Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> From: Joe Touch Message-ID: Date: Fri, 19 May 2017 14:04:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A9729B98EC8081C0AD6B6DE8" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 21:05:13 -0000 This is a multi-part message in MIME format. --------------A9729B98EC8081C0AD6B6DE8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, Speaking as lead of the IANA ports expert review team, and co-author of RFCs 6335 and 7605 on port assignment and use... On 5/19/2017 7:56 AM, Tom Herbert wrote: >> Second, UDP itself has been widely used as a tunnel technology due to its load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to distinguish these different UDP tunnel payload types. For IP-in-UDP, there has been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was originally discussed in Softwire WG (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to use a version field within the GUE header to distinguish IPvx header from the GUE header itself. Is the UDP destination port number resource running out? > >From RFC7605, section 6 "Conservation": Yes, they're a limited, finite resource. No, they're not so critical that we cannot assign one more. However, there is a basic principle that "one" is fine, but "one" that leads to another, then another, etc., generally is not. That's why IANA expects that new assigned ports include version support, so that new versions can reuse an assignment rather than requiring a new one. > Also, it's not just the assignment that is a pain, port numbers to > need to be managed in networks. If we introduce a new port number in > the datacenter management tools, firewalls, packet capture need to be > updated. > > A feature of GUE is that the payload transform option allows DTLS to > be done on the payload. This obviates needing to ask for two port > numbers (a DTLS variant and non-DTLS variant) as several of the > encapsulation methods you listed above have done. See RFC7605: >> New services SHOULD support security capabilities, either directly or via a content protection such as TLS [RFC5246 ] or Datagram TLS (DTLS) [RFC6347 ], or transport protection such as the TCP-AO [RFC5925 ]. Insecure versions of new or existing secure services SHOULD be avoided because of the new vulnerability they create. I.e., something like DTLS support would be expected. A non-DTLS variant might be accommodated on the same port using negotiation, but a separate assignment may no longer be appropriate (even though this was done in the past, esp. where negotiation was not possible). > ... >> Third, if the GUE devotes itself to save the UDP destination port number for the interest of the internet community, the 2-bit version field abused as a payload type indicator is obviously not enough:) >> > I'm not sure how it's "obviously not enough". Version 1 handles the > currently deployed two IP protocol versions. The technique allows for > supporting two more IP protocol versions to be supported without > burning another version number. One of these version numbers could easily indicate a longer or additional version field, which could be extended indefinitely. Joe --------------A9729B98EC8081C0AD6B6DE8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, all,

Speaking as lead of the IANA ports expert review team, and co-author of RFCs 6335 and 7605 on port assignment and use...


On 5/19/2017 7:56 AM, Tom Herbert wrote:
Second, UDP itself has been widely used as a tunnel technology due to its load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to distinguish these different UDP tunnel payload types. For IP-in-UDP, there has been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was originally discussed in Softwire WG (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to use a version field within the GUE header to distinguish IPvx header from the GUE header itself. Is the UDP destination port number resource running out?

>From RFC7605, section 6 "Conservation":
Yes, they're a limited, finite resource.

No, they're not so critical that we cannot assign one  more.

However, there is a basic principle that "one" is fine, but "one" that leads to another, then another, etc., generally is not.

That's why IANA expects that new assigned ports include version support, so that new versions can reuse an assignment rather than requiring a new one.

Also, it's not just the assignment that is a pain, port numbers to
need to be managed in networks. If we introduce a new port number in
the datacenter management tools, firewalls, packet capture need to be
updated.

A feature of GUE is that the payload transform option allows DTLS to
be done on the payload. This obviates needing to ask for two port
numbers (a DTLS variant and non-DTLS variant) as several of the
encapsulation methods you listed above have done.

See RFC7605:
   >> New services SHOULD support security capabilities, either directly
   or via a content protection such as TLS [RFC5246] or Datagram TLS
   (DTLS) [RFC6347], or transport protection such as the TCP-AO
   [RFC5925].  Insecure versions of new or existing secure services
   SHOULD be avoided because of the new vulnerability they create.

I.e., something like DTLS support would be expected. A non-DTLS variant might be accommodated on the same port using negotiation, but a separate assignment may no longer be appropriate (even though this was done in the past, esp. where negotiation was not possible).

...
Third, if the GUE devotes itself to save the UDP destination port number for the interest of the internet community, the 2-bit version field abused as a payload type indicator is obviously not enough:)


I'm not sure how it's "obviously not enough". Version 1 handles the
currently deployed two IP protocol versions. The technique allows for
supporting two more IP protocol versions to be supported without
burning another version number.
One of these version numbers could easily indicate a longer or additional version field, which could be extended indefinitely.

Joe


--------------A9729B98EC8081C0AD6B6DE8-- From nobody Fri May 19 14:41:39 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6B0128656; Fri, 19 May 2017 14:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 GdsNi64gaWnF; Fri, 19 May 2017 14:41:36 -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 3FF471200F1; Fri, 19 May 2017 14:41:36 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4JLfIKd011471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 May 2017 14:41:28 -0700 (PDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: int-area@ietf.org References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> From: Joe Touch Message-ID: <24f2fc9f-7bed-b91c-9aaa-20ccd77454b8@isi.edu> Date: Fri, 19 May 2017 14:41:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149514799195.6631.3231700013200014494@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 21:41:38 -0000 FWIW: It might be useful for this document to be more clear in showing a) the specific header it introduces, before it talks about variations (e.g. in Sec 2 when it is introduced, rather than in subsections) b) examples of that header in the context they would appear in a typical packet, clearly indicating the GUE portion as distinct from that context The current explanation is a bit confusing because it uses atypical terms: - sec 2, what is a UDP/IP header? When we say TCP/IP, we mean the protocol suite, not a header AFAICT, this should show UDP and IP as separate: [IP][UDP][GUE][GUE payload] - sec 3.1, 4.1, and 4.2 present a header format in a confusing way GUE doesn't change the UDP header; it's a header inside UDP, so the UDP part should be omitted (making it consistent with what I expect for sec 2) the representation in 3.1 is confusing in comparison to 3.3.2, which is just the GUE header (again, omitting UDP from 3.1, 4.1, and 4.2 fixes this) Sec 4.1 should make it clear that the fields shown are just that of the IPv4 header - and the fact that the first two bits are 01 is what helps GUE realize that this is a special case. Sec 4.2 should do the same for IPv6. It seems like you also need to address what happens for IPv5, IPv7, and later values of IP (i.e., 00 = GUE, 01=IPv4-7, and what happens for 1x?). Joe On 5/18/2017 3:53 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : Generic UDP Encapsulation > Authors : Tom Herbert > Lucy Yong > Osama Zia > Filename : draft-ietf-intarea-gue-04.txt > Pages : 37 > Date : 2017-05-18 > > Abstract: > This specification describes Generic UDP Encapsulation (GUE), which > is a scheme for using UDP to encapsulate packets of different IP > protocols for transport across layer 3 networks. By encapsulating > packets in UDP, specialized capabilities in networking hardware for > efficient handling of UDP packets can be leveraged. GUE specifies > basic encapsulation methods upon which higher level constructs, such > as tunnels and overlay networks for network virtualization, can be > constructed. GUE is extensible by allowing optional data fields as > part of the encapsulation, and is generic in that it can encapsulate > packets of various IP protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-gue-04 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri May 19 18:39:51 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E57129AD2 for ; Fri, 19 May 2017 18:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Bup6WoCWDr0i for ; Fri, 19 May 2017 18:39:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1041271FD for ; Fri, 19 May 2017 18:39:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNK10503; Sat, 20 May 2017 01:39:43 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 20 May 2017 02:39:42 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 20 May 2017 09:39:37 +0800 From: Xuxiaohu To: Tom Herbert CC: "int-area@ietf.org" Thread-Topic: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt Thread-Index: AQHS0LAkIpK7xvXSTE61Lupl2EaWeKH8YR4A Date: Sat, 20 May 2017 01:39:36 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.591F9E60.002D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 88bc277b96fc45565d00c78e123c7836 Archived-At: Subject: [Int-area] =?utf-8?b?562U5aSNOiAgSXMgdGhlIFVEUCBkZXN0aW5hdGlvbiBw?= =?utf-8?q?ort_number_resource_running_out=3F//_re=3A_I-D_Action=3A_draft-?= =?utf-8?q?ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 01:39:49 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UuIFBsZWFzZSBzZWUgbXkg cmVwbHkgaW5saW5lLg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBU b20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+IOWPkemAgeaXtumXtDog MjAxN+W5tDXmnIgxOeaXpSAyMjo1Nw0KPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTog aW50LWFyZWFAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW0ludC1hcmVhXSBJcyB0aGUgVURQIGRl c3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcgb3V0Py8vDQo+IHJlOiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4dA0KPiANCj4gSGkgWHV4aWFvaHUs DQo+IA0KPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gU29tZSByZXNwb25zZSBhcmUgaW5saW5l Lg0KPiANCj4gT24gVGh1LCBNYXkgMTgsIDIwMTcgYXQgNzo1MyBQTSwgWHV4aWFvaHUgPHh1eGlh b2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFdpdGggcmVnYXJk IHRvIGRpcmVjdGx5IGVuY2Fwc3VsYXRpbmcgSVB2eCBwYWNrZXQgaW4gVURQLCBJIHRoaW5rIHRo ZSBmb2xsb3dpbmcNCj4gYXJndW1lbnQgZm9yIHVzaW5nIFZlcnNpb24gMSBvZiBHVUUgaXMgbm90 IHZhbGlkOg0KPiA+DQo+ID4gIlRoaXMgdGVjaG5pcXVlIHNhdmVzIGVuY2Fwc3VsYXRpb24gb3Zl cmhlYWQgb24gY29zdGx5IGxpbmtzDQo+ID4gICAgZm9yIHRoZSBjb21tb24gdXNlIG9mIElQIGVu Y2Fwc3VsYXRpb24sIGFuZCBhbHNvIG9idmlhdGVzIHRoZSBuZWVkIHRvDQo+ID4gICAgYWxsb2Nh dGUgYSBzZXBhcmF0ZSBwb3J0IG51bWJlciBmb3IgSVAtb3Zlci1VRFAgZW5jYXBzdWxhdGlvbi4i DQo+ID4NCj4gPiBGaXJzdCwgSSBkb24ndCB0aGluayB0aGUgZW5jYXBzdWxhdGlvbiBvdmVyaGVh ZCBvZiA0IGJ5dGVzIGlzIGEgbWF0dGVyLg0KPiANCj4gSSdtIG5vdCBzdXJlIGV2ZXJ5b25lIHdv dWxkIGFncmVlIHdpdGggdGhhdC4gVGhlIGNhc2Ugd2FzIG1hZGUgd2hlbiB3ZSB3ZXJlDQo+IGRp c2N1c3NpbmcgaXQgdGhhdCB0aGUgc2F2aW5ncyB3b3VsZCBiZSBiZW5lZmljaWFsIGZvciBzb21l IGRlcGxveW1lbnRzLg0KDQpJZiB0aGUgc2F2aW5nIGlzIGJlbmVmaWNpYWwsIGl0J2QgYmV0dGVy IHRvIGFzc2lnbiBhIGRlZGljYXRlZCBwb3J0IG51bWJlciBmb3IgZWFjaCBVRFAgcGF5bG9hZCB0 eXBlKCBlLmcuLCBJUCBwYWNrZXQpLCByYXRoZXIgdGhhbiBjb21iaW5pbmcgdGhlIFVEUCBwb3J0 IG51bWJlciBkZWRpY2F0ZWQgZm9yIEdVRSBhbmQgdGhlIHZlcnNpb24gZmllbGQgd2l0aGluIHRo ZSBHVUUgaGVhZGVyIHRvZ2V0aGVyIHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIFVEUCBwYXlsb2Fk IGlzIEdVRSBvciBJUCAob3IgZXZlbiBvdGhlciBwYXlsb2FkIHR5cGUgaWYgdGhlIEdVRSBpcyBk ZXZvdGVkIHRvIGhlbHAgc2F2ZSB0aGUgVURQIHBvcnQgbnVtYmVyIHJlc291cmNlIGZvciB0aGUg SUVURiBjb21tdW5pdHk6KSkgIA0KDQpCVFcsIHdoYXQgaGFwcGVucyBpZiBhbnkgb3RoZXIgR1VF IHBheWxvYWQgaGFzIHRoZSBzYW1lIGRlc2lyZSBvZiBzYXZpbmcgdGhlIDQgYnl0ZSBHVUUgaGVh ZGVyIG92ZXJoZWFkPw0KDQo+ID4gSG93ZXZlciwgdGhlIHByZW1pc2UgaXMgdGhhdCBpdCdzIG1l YW5pbmdmdWwgZm9yIHRoZSBJRVRGIHRvIGRldmVsb3ANCj4gPiBzdWNoIGEgR0VORVJJQyBhbmQg Q09WRVJBTEwgZW5jYXBzdWxhdGlvbiBtZXRob2Qgd2hpY2ggaXMgc3RpbGwNCj4gPiBsb29raW5n IGZvciBuYWlsczopDQo+IA0KPiBUaGUgcHJvdG9jb2wgaXMgY2FsbGVkICpHZW5lcmljKiBVRFAg RW5jYXBzdWxhdGlvbiBmb3IgcmVhc29uLg0KDQpJIGtub3cgdGhhdCB5b3UgYXJlIHRyeWluZyB0 byBzcGVjaWZ5IGEgZ2VuZXJpYyBVRFAgZW5jYXBzdWxhdGlvbi4gSG93ZXZlciwgdGhlcmUgaGFz IGJlZW4gYSBnZW5lcmljIFVEUCBlbmNhcHN1bGF0aW9uIHNjaGVtZSB0aGF0IGlzIEdSRS1pbi1V RFAgW1JGQzgwODZdLiBGdXJ0aGVybW9yZSwgdGhlcmUgaXMgYW5vdGhlciBnZW5lcmljIFVEUCBl bmNhcHN1bGF0aW9uIHNjaGVtZSBjYWxsZWQgR0VORVZFIHRoYXQgdGhlIE5WTzMgZ3JvdXAgaXMg d29ya2luZyBvbi4gSXQncyBiZXR0ZXIgZm9yIHRoZSBJRVRGIGNvbW11bml0eSB0byBhdm9pZCBz cGVjaWZ5aW5nIG11bHRpcGxlIHNpbWlsYXIgZW5jYXBzdWxhdGlvbiBzY2hlbWVzIGFuZCB0aGVy ZWZvcmUgdGhlIE5WbzMgV0cgY28tY2hhaXJzIGFuZCB0aGUgY29ycmVzcG9uZGluZyBBRCB0cnkg dGhlaXIgYmVzdCB0byByZWFjaCBhIGNvbnNlbnN1cyBvZiB3b3JraW5nIHRvZ2V0aGVyIG9uIGEg c2luZ2xlIGVuY2Fwc3VsYXRpb24gb24gdGhlIGJhc2lzIG9mIEdFTkVWRSBhbW9uZyB0aGUgV0cg bWVtYmVycy4gRG8geW91IHN0aWxsIGJlbGlldmUgaXQncyBoZWxwZnVsIGZvciB0aGUgaW5kdXN0 cnkgdG8gc3BlY2lmeSBvbmUgYWRkaXRpb25hbCBnZW5lcmljIGVuY2Fwc3VsYXRpb24gc2NoZW1l IGluIGFub3RoZXIgSUVURiBXRz8NCg0KPiA+IElmIEkgcmVtZW1iZXJlZCBjb3JyZWN0bHksIHRo aXMgZHJhZnQgd2FzIG9yaWdpbmFsbHkgYWRvcHRlZCBieSB0aGUgTlZPMyBXRw0KPiB3aGljaCBp cyBmb2N1c2VkIG9uIG11bHRpLXRlbmFuY3ksIGFsdGhvdWdoIHRoaXMgZHJhZnQgaGFzIG5vdGhp bmcgdG8gZG8gd2l0aA0KPiBtdWx0aS10ZW5hbmN5OikgTGF0dGVyIGl0IGJlY29tZXMgYSBJTlRB UkVBIFdHIGRyYWZ0LiBieSB0aGUgd2F5LCBkaWQgSSBtaXNzDQo+IHRoZSBXRyBhZG9wdGlvbiBj YWxsIGZvciB0aGlzIGRyYWZ0IGluIHRoZSBJTlRBUkVBIFdHIG9yIHRoZSBXRyBhZG9wdGlvbiBj YWxsDQo+IGlzbid0IG9jY3VycmVkIGF0IGFsbD8NCj4gPg0KPiBJdCB3YXMgYWRvcHRlZCBhZnRl ciBTZW91bCBJRVRGLg0KPiANCj4gPiBTZWNvbmQsIFVEUCBpdHNlbGYgaGFzIGJlZW4gd2lkZWx5 IHVzZWQgYXMgYSB0dW5uZWwgdGVjaG5vbG9neSBkdWUgdG8gaXRzDQo+IGxvYWQtYmFsYW5jaW5n IGNhcGFiaWxpdHkuIFNlZSBMSVNQIFtSRkM2ODMwXSwgVlhMQU4gW1JGQzczNDZdLCBNUExTLWlu LVVEUA0KPiBbUkZDNzUxMF0sIEdSRS1pbi1VRFAgW1JGQzgwODZdLCBFU1AtaW4tVURQIFtSRkMz OTQ4XSwgVFJJTEwtaW4tVURQLA0KPiBOU0gtaW4tVURQLCBWWExBTi1HUEUsIEdFTkVWRSwgR1VF LCAuLi4gVGhlIGRlc3RpbmF0aW9uIHBvcnQgaXMgdXNlZCB0bw0KPiBkaXN0aW5ndWlzaCB0aGVz ZSBkaWZmZXJlbnQgVURQIHR1bm5lbCBwYXlsb2FkIHR5cGVzLiBGb3IgSVAtaW4tVURQLCB0aGVy ZSBoYXMNCj4gYmVlbiBhIGRyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eHUtaW50YXJlYS1pcC1pbi11ZHApIHdoaWNoIHdhcw0KPiBvcmlnaW5hbGx5IGRpc2N1c3NlZCBp biBTb2Z0d2lyZSBXRw0KPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNv ZnR3aXJlLWlwLWluLXVkcCkgLiBJTUhPLCBpdCBzZWVtcyB1Z2x5IHRvDQo+IHVzZSBhIHZlcnNp b24gZmllbGQgd2l0aGluIHRoZSBHVUUgaGVhZGVyIHRvIGRpc3Rpbmd1aXNoIElQdnggaGVhZGVy IGZyb20gdGhlDQo+IEdVRSBoZWFkZXIgaXRzZWxmLiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBv cnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcgb3V0Pw0KPiANCj4gRnJvbSBSRkM3NjA1LCBzZWN0 aW9uIDYgIkNvbnNlcnZhdGlvbiI6DQo+IA0KPiAiQXNzaWduZWQgcG9ydCBudW1iZXJzIGFyZSBh IGxpbWl0ZWQgcmVzb3VyY2UgdGhhdCBpcyBnbG9iYWxseSBzaGFyZWQgYnkgdGhlDQo+IGVudGly ZSBJbnRlcm5ldCBjb21tdW5pdHkuICBBcyBvZiAyMDE0LCBhcHByb3hpbWF0ZWx5IDU4NTAgVENQ IGFuZCA1NTcwDQo+IFVEUCBwb3J0IG51bWJlcnMgaGFkIGJlZW4gYXNzaWduZWQgb3V0IG9mIGEg dG90YWwgcmFuZ2Ugb2YgNDkxNTEuICBBcyBhDQo+IHJlc3VsdCBvZiBwYXN0IGNvbnNlcnZhdGlv biwgY3VycmVudCBhc3NpZ25lZCBwb3J0IHVzZSBpcyBzbWFsbCBhbmQgdGhlIGN1cnJlbnQNCj4g cmF0ZSBvZiBhc3NpZ25tZW50IGF2b2lkcyB0aGUgbmVlZCBmb3IgdHJhbnNpdGlvbiB0byBsYXJn ZXIgbnVtYmVyIHNwYWNlcy4gIFRoaXMNCj4gY29uc2VydmF0aW9uIGFsc28gaGVscHMgYXZvaWQg dGhlIG5lZWQgZm9yIElBTkEgdG8gcmVseSBvbiBhc3NpZ25lZCBwb3J0DQo+IG51bWJlciByZWNs YW1hdGlvbiwgd2hpY2ggaXMgcHJhY3RpY2FsbHkgaW1wb3NzaWJsZSBldmVuIHRob3VnaCBwcm9j ZWR1cmFsbHkNCj4gcGVybWl0dGVkIFtSRkM2MzM1XS4NCg0KSWYgdGhlIHBvcnQgbnVtYmVyIHJl c291cmNlIHdhcyBzY2FyY2UsIGl0J2QgYmV0dGVyIGZvciB0aGUgSUVURiB0byByZWNvbW1lbmQg dXNpbmcgdGhlIEdSRS1pbi1VRFAgW1JGQzgwODZdIGZvciBhbnkgbmV3IHBheWxvYWQgdHlwZSB3 aGljaCBpcyBkZXNpcmVkIHRvIGJlIHRyYW5zcG9ydGVkIG92ZXIgVURQIFVOSUZPUk1MWSByYXRo ZXIgdGhhbiBTRUxFQ1RJVkVMWSwgSU1ITy4NCg0KPiBBbHNvLCBpdCdzIG5vdCBqdXN0IHRoZSBh c3NpZ25tZW50IHRoYXQgaXMgYSBwYWluLCBwb3J0IG51bWJlcnMgdG8gbmVlZCB0byBiZQ0KPiBt YW5hZ2VkIGluIG5ldHdvcmtzLiBJZiB3ZSBpbnRyb2R1Y2UgYSBuZXcgcG9ydCBudW1iZXIgaW4g dGhlIGRhdGFjZW50ZXINCj4gbWFuYWdlbWVudCB0b29scywgZmlyZXdhbGxzLCBwYWNrZXQgY2Fw dHVyZSBuZWVkIHRvIGJlIHVwZGF0ZWQuDQoNClRoZSB2ZXJzaW9uIG51bWJlcnMgbmVlZCB0byBi ZSBtYW5hZ2VkIGFzIHdlbGw6KQ0KDQo+IEEgZmVhdHVyZSBvZiBHVUUgaXMgdGhhdCB0aGUgcGF5 bG9hZCB0cmFuc2Zvcm0gb3B0aW9uIGFsbG93cyBEVExTIHRvIGJlIGRvbmUNCj4gb24gdGhlIHBh eWxvYWQuIFRoaXMgb2J2aWF0ZXMgbmVlZGluZyB0byBhc2sgZm9yIHR3byBwb3J0IG51bWJlcnMg KGEgRFRMUw0KPiB2YXJpYW50IGFuZCBub24tRFRMUyB2YXJpYW50KSBhcyBzZXZlcmFsIG9mIHRo ZSBlbmNhcHN1bGF0aW9uIG1ldGhvZHMgeW91DQo+IGxpc3RlZCBhYm92ZSBoYXZlIGRvbmUuDQo+ IA0KPiA+IElmIHNvLCB3aHkgbm90IHVzZSBHUkUtaW4tVURQIHRvIGNhcnJ5IEdVRSBzbyBhcyB0 byBzYXZlIG9uZSBtb3JlIFVEUA0KPiBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcj8NCj4gPg0KPiBU aGVuIHdlJ2QgYmUgdGFsa2luZyBhYm91dCBoYXZpbmcgdG8gcmVzZXJ2ZSBhbiBFdGhlcnR5cGUg Zm9yIEdVRS4NCg0KRXRoZXJUeXBlIGlzIGEgdHdvLW9jdGV0IGZpZWxkIHdoaWNoIGhhcyB0aGUg c2FtZSBsZW5ndGggYXMgdGhlIFVEUCBwb3J0IG51bWJlci4gRm9ydHVuYXRlbHksIGl0IHNlZW1z IHRoYXQgdGhlIElFRUUgZG9lc24ndCBzY2FudCB0aGUgYXNzaWdubWVudCBvZiB0aGUgRXRoZXJ0 eXBlIGNvZGUgcmVzb3VyY2UuIEhlbmNlIHlvdSBkb24ndCBuZWVkIHRvIHdvcnJ5IGFib3V0IGl0 Lg0KIA0KPiA+IFRoaXJkLCBpZiB0aGUgR1VFIGRldm90ZXMgaXRzZWxmIHRvIHNhdmUgdGhlIFVE UCBkZXN0aW5hdGlvbiBwb3J0DQo+ID4gbnVtYmVyIGZvciB0aGUgaW50ZXJlc3Qgb2YgdGhlIGlu dGVybmV0IGNvbW11bml0eSwgdGhlIDItYml0IHZlcnNpb24NCj4gPiBmaWVsZCBhYnVzZWQgYXMg YSBwYXlsb2FkIHR5cGUgaW5kaWNhdG9yIGlzIG9idmlvdXNseSBub3QgZW5vdWdoOikNCj4gPg0K PiBJJ20gbm90IHN1cmUgaG93IGl0J3MgIm9idmlvdXNseSBub3QgZW5vdWdoIi4gVmVyc2lvbiAx IGhhbmRsZXMgdGhlIGN1cnJlbnRseQ0KPiBkZXBsb3llZCB0d28gSVAgcHJvdG9jb2wgdmVyc2lv bnMuIFRoZSB0ZWNobmlxdWUgYWxsb3dzIGZvciBzdXBwb3J0aW5nIHR3bw0KPiBtb3JlIElQIHBy b3RvY29sIHZlcnNpb25zIHRvIGJlIHN1cHBvcnRlZCB3aXRob3V0IGJ1cm5pbmcgYW5vdGhlciB2 ZXJzaW9uDQo+IG51bWJlci4NCg0KSXQgc2VlbXMgdGhhdCB5b3VyIGFyZSBhdHRlbXB0aW5nIHRv IHJlcGVhdCB0aGUgbm90b3Jpb3VzIGZpcnN0IG5pYmJsZSBpc3N1ZSBhc3NvY2lhdGVkIHdpdGgg TVBMUyAoZm9yIG1vcmUgZGV0YWlscyBhYm91dCB0aGUgZmlyc3QgbmliYmxlIGlzc3VlLCBwbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtcGF5 bG9hZC1wcm90b2NvbC1pZGVudGlmaWVyLTAyKSBpbiB5b3VyIEdVRSBkZXNpZ24uDQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KDQo+IFRvbQ0KPiANCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlh b2h1DQo+ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+PiDlj5Hku7bkuro6IElu dC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+ID4+IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+PiDlj5HpgIHml7bpl7Q6IDIwMTflubQ15pyIMTnm l6UgNjo1Mw0KPiA+PiDmlLbku7bkuro6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+PiDmioTp gIE6IGludC1hcmVhQGlldGYub3JnDQo+ID4+IOS4u+mimDogW0ludC1hcmVhXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuDQo+ID4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElu dGVybmV0IEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPj4NCj4gPj4gICAgICAg ICBUaXRsZSAgICAgICAgICAgOiBHZW5lcmljIFVEUCBFbmNhcHN1bGF0aW9uDQo+ID4+ICAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogVG9tIEhlcmJlcnQNCj4gPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBMdWN5IFlvbmcNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBPc2FtYSBa aWENCj4gPj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0w NC50eHQNCj4gPj4gICAgICAgUGFnZXMgICAgICAgICAgIDogMzcNCj4gPj4gICAgICAgRGF0ZSAg ICAgICAgICAgIDogMjAxNy0wNS0xOA0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgVGhp cyBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyBHZW5lcmljIFVEUCBFbmNhcHN1bGF0aW9uIChHVUUp LCB3aGljaA0KPiA+PiAgICBpcyBhIHNjaGVtZSBmb3IgdXNpbmcgVURQIHRvIGVuY2Fwc3VsYXRl IHBhY2tldHMgb2YgZGlmZmVyZW50IElQDQo+ID4+ICAgIHByb3RvY29scyBmb3IgdHJhbnNwb3J0 IGFjcm9zcyBsYXllciAzIG5ldHdvcmtzLiBCeSBlbmNhcHN1bGF0aW5nDQo+ID4+ICAgIHBhY2tl dHMgaW4gVURQLCBzcGVjaWFsaXplZCBjYXBhYmlsaXRpZXMgaW4gbmV0d29ya2luZyBoYXJkd2Fy ZSBmb3INCj4gPj4gICAgZWZmaWNpZW50IGhhbmRsaW5nIG9mIFVEUCBwYWNrZXRzIGNhbiBiZSBs ZXZlcmFnZWQuIEdVRSBzcGVjaWZpZXMNCj4gPj4gICAgYmFzaWMgZW5jYXBzdWxhdGlvbiBtZXRo b2RzIHVwb24gd2hpY2ggaGlnaGVyIGxldmVsIGNvbnN0cnVjdHMsIHN1Y2gNCj4gPj4gICAgYXMg dHVubmVscyBhbmQgb3ZlcmxheSBuZXR3b3JrcyBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbiwg Y2FuIGJlDQo+ID4+ICAgIGNvbnN0cnVjdGVkLiBHVUUgaXMgZXh0ZW5zaWJsZSBieSBhbGxvd2lu ZyBvcHRpb25hbCBkYXRhIGZpZWxkcyBhcw0KPiA+PiAgICBwYXJ0IG9mIHRoZSBlbmNhcHN1bGF0 aW9uLCBhbmQgaXMgZ2VuZXJpYyBpbiB0aGF0IGl0IGNhbiBlbmNhcHN1bGF0ZQ0KPiA+PiAgICBw YWNrZXRzIG9mIHZhcmlvdXMgSVAgcHJvdG9jb2xzLg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS8NCj4gPj4N Cj4gPj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+ PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNA0K PiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaW50 YXJlYS1ndWUtMDQNCj4gPj4NCj4gPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNA0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+ PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4+DQo+ID4+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gSW50LWFyZWEgbWFpbGluZyBsaXN0DQo+ID4+ IEludC1hcmVhQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaW50LWFyZWENCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IEludC1hcmVhIG1haWxpbmcgbGlzdA0KPiA+IEludC1hcmVhQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0K From nobody Fri May 19 20:42:04 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B471293F4 for ; Fri, 19 May 2017 20:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 ozlSr0rqodoh for ; Fri, 19 May 2017 20:42:01 -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 940A6124D68 for ; Fri, 19 May 2017 20:42:01 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4K3fNCc016940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 May 2017 20:41:33 -0700 (PDT) To: Xuxiaohu , Tom Herbert Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> From: Joe Touch Message-ID: Date: Fri, 19 May 2017 20:41:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9u?= =?utf-8?q?_port_number_resource_running_out=3F//_re=3A_I-D_Action=3A_draf?= =?utf-8?q?t-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 03:42:02 -0000 On 5/19/2017 6:39 PM, Xuxiaohu wrote: > If the saving is beneficial, it'd better to assign a dedicated port number for each UDP payload type( e.g., IP packet), rather than combining the UDP port number dedicated for GUE and the version field within the GUE header together to indicate whether the UDP payload is GUE or IP (or even other payload type if the GUE is devoted to help save the UDP port number resource for the IETF community:)) FWIW, IANA strives to assign one port for a service. Services are expected to have version fields and subtype demultiplexing indicators, to so that all message variants of current and future versions can use a single port number. Joe From nobody Fri May 19 20:58:02 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B45A1294F5 for ; Fri, 19 May 2017 20:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 PbmO4kXGBvPW for ; Fri, 19 May 2017 20:58:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B662129464 for ; Fri, 19 May 2017 20:57:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGY64474; Sat, 20 May 2017 03:57:57 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 20 May 2017 04:57:56 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 20 May 2017 11:57:49 +0800 From: Xuxiaohu To: Joe Touch , Tom Herbert CC: "int-area@ietf.org" Thread-Topic: =?utf-8?B?W0ludC1hcmVhXSDnrZTlpI06IElzIHRoZSBVRFAgZGVzdGluYXRpb24gcG9y?= =?utf-8?B?dCBudW1iZXIgcmVzb3VyY2UgcnVubmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rp?= =?utf-8?Q?on:_draft-ietf-intarea-gue-04.txt?= Thread-Index: AQHS0RsMnyvO0qVuZEOz5xejzfeIJKH8l23w Date: Sat, 20 May 2017 03:57:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.591FBEC5.005C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ecba1e192b3aa802aa2cb6432b75690 Archived-At: Subject: [Int-area] =?utf-8?b?562U5aSNOiAg562U5aSNOiBJcyB0aGUgVURQIGRlc3Rp?= =?utf-8?q?nation_port_number_resource_running_out=3F//_re=3A_I-D_Action?= =?utf-8?q?=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 03:58:01 -0000 SGkgSm9lLA0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBKb2UgVG91 Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTflubQ15pyIMjDm l6UgMTE6NDENCj4g5pS25Lu25Lq6OiBYdXhpYW9odTsgVG9tIEhlcmJlcnQNCj4g5oqE6YCBOiBp bnQtYXJlYUBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbSW50LWFyZWFdIOetlOWkjTogSXMgdGhl IFVEUCBkZXN0aW5hdGlvbiBwb3J0IG51bWJlciByZXNvdXJjZSBydW5uaW5nDQo+IG91dD8vLyBy ZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNC50eHQNCj4gDQo+IA0KPiAN Cj4gT24gNS8xOS8yMDE3IDY6MzkgUE0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+IElmIHRoZSBzYXZp bmcgaXMgYmVuZWZpY2lhbCwgaXQnZCBiZXR0ZXIgdG8gYXNzaWduIGEgZGVkaWNhdGVkIHBvcnQN Cj4gPiBudW1iZXIgZm9yIGVhY2ggVURQIHBheWxvYWQgdHlwZSggZS5nLiwgSVAgcGFja2V0KSwg cmF0aGVyIHRoYW4NCj4gPiBjb21iaW5pbmcgdGhlIFVEUCBwb3J0IG51bWJlciBkZWRpY2F0ZWQg Zm9yIEdVRSBhbmQgdGhlIHZlcnNpb24gZmllbGQNCj4gPiB3aXRoaW4gdGhlIEdVRSBoZWFkZXIg dG9nZXRoZXIgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgVURQIHBheWxvYWQgaXMNCj4gPiBHVUUg b3IgSVAgKG9yIGV2ZW4gb3RoZXIgcGF5bG9hZCB0eXBlIGlmIHRoZSBHVUUgaXMgZGV2b3RlZCB0 byBoZWxwDQo+ID4gc2F2ZSB0aGUgVURQIHBvcnQgbnVtYmVyIHJlc291cmNlIGZvciB0aGUgSUVU RiBjb21tdW5pdHk6KSkNCj4gRldJVywgSUFOQSBzdHJpdmVzIHRvIGFzc2lnbiBvbmUgcG9ydCBm b3IgYSBzZXJ2aWNlLg0KDQpHcmVhdC4gSGVuY2UgSVB2eCBzaG91bGQgYmUgdGFrZW4gYXMgYSBz ZXJ2aWNlIHJhdGhlciB0aGFuIHRha2luZyBJUHZ4IGFuZCBHVUUgYXMgYSBzZXJ2aWNlLCBJTU8u DQoNCj4gU2VydmljZXMgYXJlIGV4cGVjdGVkIHRvIGhhdmUgdmVyc2lvbiBmaWVsZHMgYW5kIHN1 YnR5cGUgZGVtdWx0aXBsZXhpbmcNCj4gaW5kaWNhdG9ycywgdG8gc28gdGhhdCBhbGwgbWVzc2Fn ZSB2YXJpYW50cyBvZiBjdXJyZW50IGFuZCBmdXR1cmUgdmVyc2lvbnMgY2FuIHVzZQ0KPiBhIHNp bmdsZSBwb3J0IG51bWJlci4NCg0KU3VyZSwgdGhlIHZlcnNpb24gZmllbGQgd2l0aGluIHRoZSBJ UHZ4IHBhY2tldCBjb3VsZCBiZSB1c2VkIGZvciBkZW11bHRpcGxleGluZyBwdXJwb3NlLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBKb2UNCg== From nobody Fri May 19 21:15:56 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEEE129AD5 for ; Fri, 19 May 2017 21:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 HGLOMecXhPKG for ; Fri, 19 May 2017 21:15:53 -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 848CE129649 for ; Fri, 19 May 2017 21:15:53 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4K4F2bG000053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 May 2017 21:15:12 -0700 (PDT) To: Xuxiaohu , Tom Herbert Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> From: Joe Touch Message-ID: <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> Date: Fri, 19 May 2017 21:15:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiAg562U5aSNOiBJcyB0aGUgVURQIGRl?= =?utf-8?q?stination_port_number_resource_running_out=3F//_re=3A_I-D_Actio?= =?utf-8?q?n=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 04:15:54 -0000 On 5/19/2017 8:57 PM, Xuxiaohu wrote: > Hi Joe, > >> -----邮件原件----- >> 发件人: Joe Touch [mailto:touch@isi.edu] >> 发送时间: 2017年5月20日 11:41 >> 收件人: Xuxiaohu; Tom Herbert >> 抄送: int-area@ietf.org >> 主题: Re: [Int-area] 答复: Is the UDP destination port number resource running >> out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> >> On 5/19/2017 6:39 PM, Xuxiaohu wrote: >>> If the saving is beneficial, it'd better to assign a dedicated port >>> number for each UDP payload type( e.g., IP packet), rather than >>> combining the UDP port number dedicated for GUE and the version field >>> within the GUE header together to indicate whether the UDP payload is >>> GUE or IP (or even other payload type if the GUE is devoted to help >>> save the UDP port number resource for the IETF community:)) >> FWIW, IANA strives to assign one port for a service. > Great. Hence IPvx should be taken as a service rather than taking IPvx and GUE as a service, IMO. GUE is supposed to be both signalling and content (data), where the data are IP packets. Take away the IP part and GUE isn't an E anymore. >> Services are expected to have version fields and subtype demultiplexing >> indicators, to so that all message variants of current and future versions can use >> a single port number. > Sure, the version field within the IPvx packet could be used for demultiplexing purpose. That demultiplexes within IPvx. There still needs to be a way to demultiplex non-IPvx packets (control) from IPvx. Joe From nobody Fri May 19 23:10:02 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D4212950B for ; Fri, 19 May 2017 23:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 IHAReeEjiGyK for ; Fri, 19 May 2017 23:09:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF25129562 for ; Fri, 19 May 2017 23:09:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNK33549; Sat, 20 May 2017 06:09:56 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 20 May 2017 07:09:55 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 20 May 2017 14:09:46 +0800 From: Xuxiaohu To: Joe Touch , Tom Herbert CC: "int-area@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiBbSW50LWFyZWFdIOetlOWkjTogSXMgdGhlIFVEUCBkZXN0aW5h?= =?utf-8?B?dGlvbiBwb3J0IG51bWJlciByZXNvdXJjZSBydW5uaW5nIG91dD8vLyByZTog?= =?utf-8?Q?I-D_Action:_draft-ietf-intarea-gue-04.txt?= Thread-Index: AQHS0RsMnyvO0qVuZEOz5xejzfeIJKH8l23w//9/jYCAAKQ8oA== Date: Sat, 20 May 2017 06:09:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> In-Reply-To: <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.591FDDB4.00D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d9d8394fc79cf86328e0f95df3728cd9 Archived-At: Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRoZSBV?= =?utf-8?q?DP_destination_port_number_resource_running_out=3F//_re=3A_I-D_?= =?utf-8?q?Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 06:10:01 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEpvZSBUb3VjaCBbbWFp bHRvOnRvdWNoQGlzaS5lZHVdDQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDXmnIgyMOaXpSAxMjox NQ0KPiDmlLbku7bkuro6IFh1eGlhb2h1OyBUb20gSGVyYmVydA0KPiDmioTpgIE6IGludC1hcmVh QGlldGYub3JnDQo+IOS4u+mimDogUmU6IOetlOWkjTogW0ludC1hcmVhXSDnrZTlpI06IElzIHRo ZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1iZXIgcmVzb3VyY2UNCj4gcnVubmluZyBvdXQ/Ly8g cmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS1ndWUtMDQudHh0DQo+IA0KPiANCj4g DQo+IE9uIDUvMTkvMjAxNyA4OjU3IFBNLCBYdXhpYW9odSB3cm90ZToNCj4gPiBIaSBKb2UsDQo+ ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+PiDlj5Hku7bkuro6IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+IOWPkemAgeaXtumXtDogMjAxN+W5tDXmnIgy MOaXpSAxMTo0MQ0KPiA+PiDmlLbku7bkuro6IFh1eGlhb2h1OyBUb20gSGVyYmVydA0KPiA+PiDm ioTpgIE6IGludC1hcmVhQGlldGYub3JnDQo+ID4+IOS4u+mimDogUmU6IFtJbnQtYXJlYV0g562U 5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlDQo+ID4+IHJ1 bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4 dA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiA1LzE5LzIwMTcgNjozOSBQTSwgWHV4aWFvaHUg d3JvdGU6DQo+ID4+PiBJZiB0aGUgc2F2aW5nIGlzIGJlbmVmaWNpYWwsIGl0J2QgYmV0dGVyIHRv IGFzc2lnbiBhIGRlZGljYXRlZCBwb3J0DQo+ID4+PiBudW1iZXIgZm9yIGVhY2ggVURQIHBheWxv YWQgdHlwZSggZS5nLiwgSVAgcGFja2V0KSwgcmF0aGVyIHRoYW4NCj4gPj4+IGNvbWJpbmluZyB0 aGUgVURQIHBvcnQgbnVtYmVyIGRlZGljYXRlZCBmb3IgR1VFIGFuZCB0aGUgdmVyc2lvbg0KPiA+ Pj4gZmllbGQgd2l0aGluIHRoZSBHVUUgaGVhZGVyIHRvZ2V0aGVyIHRvIGluZGljYXRlIHdoZXRo ZXIgdGhlIFVEUA0KPiA+Pj4gcGF5bG9hZCBpcyBHVUUgb3IgSVAgKG9yIGV2ZW4gb3RoZXIgcGF5 bG9hZCB0eXBlIGlmIHRoZSBHVUUgaXMNCj4gPj4+IGRldm90ZWQgdG8gaGVscCBzYXZlIHRoZSBV RFAgcG9ydCBudW1iZXIgcmVzb3VyY2UgZm9yIHRoZSBJRVRGDQo+ID4+PiBjb21tdW5pdHk6KSkN Cj4gPj4gRldJVywgSUFOQSBzdHJpdmVzIHRvIGFzc2lnbiBvbmUgcG9ydCBmb3IgYSBzZXJ2aWNl Lg0KPiA+IEdyZWF0LiBIZW5jZSBJUHZ4IHNob3VsZCBiZSB0YWtlbiBhcyBhIHNlcnZpY2UgcmF0 aGVyIHRoYW4gdGFraW5nIElQdnggYW5kDQo+IEdVRSBhcyBhIHNlcnZpY2UsIElNTy4NCj4gR1VF IGlzIHN1cHBvc2VkIHRvIGJlIGJvdGggc2lnbmFsbGluZyBhbmQgY29udGVudCAoZGF0YSksIHdo ZXJlIHRoZSBkYXRhIGFyZSBJUA0KPiBwYWNrZXRzLg0KDQpTaW5jZSBJQU5BIHN0cml2ZXMgdG8g YXNzaWduIG9uZSBwb3J0IGZvciBhIHNlcnZpY2UsIElQIHBhY2tldCB3aXRoaW4gdGhlIFVEUCB0 dW5uZWwgc2hvdWxkIGJlIGFzc2lnbmVkIGEgZGVkaWNhdGVkIHBvcnQuIEluIG90aGVyIHdvcmRz LCBHVUUgYW5kIElQLWluLVVEUCBhcmUgZGlzdGluZ3Vpc2hlZCBieSB0aGUgZGlmZmVyZW50IHBv cnQgbnVtYmVycy4gDQoNCj4gVGFrZSBhd2F5IHRoZSBJUCBwYXJ0IGFuZCBHVUUgaXNuJ3QgYW4g RSBhbnltb3JlLg0KPiA+PiBTZXJ2aWNlcyBhcmUgZXhwZWN0ZWQgdG8gaGF2ZSB2ZXJzaW9uIGZp ZWxkcyBhbmQgc3VidHlwZQ0KPiA+PiBkZW11bHRpcGxleGluZyBpbmRpY2F0b3JzLCB0byBzbyB0 aGF0IGFsbCBtZXNzYWdlIHZhcmlhbnRzIG9mIGN1cnJlbnQNCj4gPj4gYW5kIGZ1dHVyZSB2ZXJz aW9ucyBjYW4gdXNlIGEgc2luZ2xlIHBvcnQgbnVtYmVyLg0KPiA+IFN1cmUsIHRoZSB2ZXJzaW9u IGZpZWxkIHdpdGhpbiB0aGUgSVB2eCBwYWNrZXQgY291bGQgYmUgdXNlZCBmb3IgZGVtdWx0aXBs ZXhpbmcNCj4gcHVycG9zZS4NCj4gDQo+IFRoYXQgZGVtdWx0aXBsZXhlcyB3aXRoaW4gSVB2eC4g VGhlcmUgc3RpbGwgbmVlZHMgdG8gYmUgYSB3YXkgdG8gZGVtdWx0aXBsZXgNCj4gbm9uLUlQdngg cGFja2V0cyAoY29udHJvbCkgZnJvbSBJUHZ4Lg0KDQpTaW5jZSBHVUUgYW5kIElQLWluLVVEUCBo YXZlIGRpZmZlcmVudCBVRFAgcG9ydCBudW1iZXJzLCBJIGRvbid0IGtub3cgd2h5IHRoZXJlIGlz IHN0aWxsIGEgbmVlZCB0byBkZW11bHRpcGxleCBHVUUgYW5kIElQLWluLVVEUC4NCg0KWGlhb2h1 DQoNCj4gSm9lDQo= From nobody Sat May 20 08:45:51 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A91128B8F for ; Sat, 20 May 2017 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 paWKJgiOWpmW for ; Sat, 20 May 2017 08:45:49 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 CDA4F128B51 for ; Sat, 20 May 2017 08:45:48 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id y201so80707015qka.0 for ; Sat, 20 May 2017 08:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=994D1fAO1I67zLfj8wu7LsF4IynV0tifRXV8EkFzxzo=; b=o94mfm3ZH6+Xcw9g6wYekWZUHxTVyfPQ0VedZBBPpkb/vNt+Co8sPVuXv8FDUHL6VF tz3mpS7obu5GODyhMRWE8vr+ysGLbLM2mjxuouZ7aGaEB3lhkKFXxF2kxt9qBIDRxZL7 dYCBMgNUMbx07zJ+nfizYoWP0a8WJRGGsGW0I22u7ShdH02Id8VgnsyNTP9i2NlADsAJ +nQFbSLF5FqXnILWuiZjAmXWkDIdNafqwkObKdUsU0LdaE7GS7L9kX/8aeDQg3Rw2kGK lMQ9CXcP1MV70MeCQNTM6BPk+DylqEBqb8BrU7ZGyKkPfLy1jBqsjmrI0l352SJ1L8AO vOmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=994D1fAO1I67zLfj8wu7LsF4IynV0tifRXV8EkFzxzo=; b=XIodm0eU8kdBlerMwYvyoIL2fSgexOEajPt6m7O7QOq9CEQparMk1uqPUVL/Z2nAtd BF+T6DMRVqbYXPBid63jTfLJtglrngRQ7f8aP9NMMcmewrkcCzicPNFa3CK3zgFqiC97 oxZ2prMIQxD2u3ElYLAj1oHFbJ+SDt7HGYnSZaYh7rmZVBdl3OcL1ceF9ufzfoWkuuKE QSaXODk+JOqrxFuCaxg5M0iz781SO9MF6i7sbCZxXzR9kcqTb8qO1gT14G2VDuTnbPMq rgdNV7sWJGwnRAOwhuQCbMccrSvKNefipUdG2s1kLjgUeoLg8j3yh2ZxIlwTzMQU5GFM AXXg== X-Gm-Message-State: AODbwcCu/YQTiRfEsR4etRvRv1Yvu3qPVJ1byvReXjZqk6EvoZcoqccy MLB/9sMMi9j5RP4cD9QKGii5TQiLgoqt X-Received: by 10.55.197.92 with SMTP id p89mr12928478qki.34.1495295147947; Sat, 20 May 2017 08:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Sat, 20 May 2017 08:45:47 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> From: Tom Herbert Date: Sat, 20 May 2017 08:45:47 -0700 Message-ID: To: Xuxiaohu Cc: "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiAgSXMgdGhlIFVEUCBkZXN0aW5hdGlv?= =?utf-8?q?n_port_number_resource_running_out=3F//_re=3A_I-D_Action=3A_dra?= =?utf-8?q?ft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 15:45:50 -0000 On Fri, May 19, 2017 at 6:39 PM, Xuxiaohu wrote: > Hi Tom, > > Thanks for your quick response. Please see my reply inline. > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Tom Herbert [mailto:tom@herbertland.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8819=E6=97=A5= 22:57 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> =E6=8A=84=E9=80=81: int-area@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [Int-area] Is the UDP destination port number re= source running out?// >> re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> Hi Xuxiaohu, >> >> Thanks for the comments. Some response are inline. >> >> On Thu, May 18, 2017 at 7:53 PM, Xuxiaohu wrote: >> > Hi all, >> > >> > With regard to directly encapsulating IPvx packet in UDP, I think the = following >> argument for using Version 1 of GUE is not valid: >> > >> > "This technique saves encapsulation overhead on costly links >> > for the common use of IP encapsulation, and also obviates the need = to >> > allocate a separate port number for IP-over-UDP encapsulation." >> > >> > First, I don't think the encapsulation overhead of 4 bytes is a matter= . >> >> I'm not sure everyone would agree with that. The case was made when we w= ere >> discussing it that the savings would be beneficial for some deployments. > > If the saving is beneficial, it'd better to assign a dedicated port numbe= r for each UDP payload type( e.g., IP packet), rather than combining the UD= P port number dedicated for GUE and the version field within the GUE header= together to indicate whether the UDP payload is GUE or IP (or even other p= ayload type if the GUE is devoted to help save the UDP port number resource= for the IETF community:)) Xuxiaohu, We have already implemented the facility to directly encapsulate an IP protocol directly in UDP. This is FOU-over-UDP (FOU) and in fact GRE-in-UDP is just one sub case of the implementation. I know people are using FOU for various protocols in their networks, however I doubt we get very far if we requested 256 ports to directly encapsulate each IP protocol! It might make sense to document FOU as informational. > > BTW, what happens if any other GUE payload has the same desire of saving = the 4 byte GUE header overhead? The only other candidate beyond IPv4 and IPv6 that has been suggested is Ethernet which would be EtherIP. That is pretty feasible to support if there is enough desire. > >> > However, the premise is that it's meaningful for the IETF to develop >> > such a GENERIC and COVERALL encapsulation method which is still >> > looking for nails:) >> >> The protocol is called *Generic* UDP Encapsulation for reason. > > I know that you are trying to specify a generic UDP encapsulation. Howeve= r, there has been a generic UDP encapsulation scheme that is GRE-in-UDP [RF= C8086]. Furthermore, there is another generic UDP encapsulation scheme call= ed GENEVE that the NVO3 group is working on. It's better for the IETF commu= nity to avoid specifying multiple similar encapsulation schemes and therefo= re the NVo3 WG co-chairs and the corresponding AD try their best to reach a= consensus of working together on a single encapsulation on the basis of GE= NEVE among the WG members. Do you still believe it's helpful for the indust= ry to specify one additional generic encapsulation scheme in another IETF W= G? > Yes. The reason we needed to define GUE is that no other encapsulation protocol satisfies the requirements. GRE comes close, and in fact GUE is based on GRE. We love GRE for the datacenter. It's generic, extensible, simple, flag-fields are super efficient, and all hardware we tested works well with it. The downside of GRE is that it's extensibility is quite limited; we can only get 12 bytes for fields. That's just not enough. The particular need we had was to add security to authenticate the header. We actually we're able to "find" 64 bits of in the fields by overloading checksum and sequence number, but that is really not enough for security. Besides that, there are other needs for extensibility like fragmentation, checksum, payload transform. We'll only ever need a handful of such extensions, but it's more than can be fit into GRE. So GUE is an answer. It has the same efficiency of GRE but is more extensible. Since it is a new protocol we are able to add a few other nice to have features like header length, encap by IP protocol, and private data block. Section 6 in the draft gives a motivation for GUE. Tom From nobody Sat May 20 09:00:40 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E63129431 for ; Sat, 20 May 2017 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 03WgZ024E3Rc for ; Sat, 20 May 2017 09:00:37 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 002E3129401 for ; Sat, 20 May 2017 09:00:36 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id v27so77274876qtg.2 for ; Sat, 20 May 2017 09:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BB1gu4cVnIwl6q3wMvvsYiVuRfaBxjwOveotNnk8HqU=; b=AS0UeTK4tQDwS+1bj29XJxaQ70+LvB4JyoknaQlJQ2gOHD8l5JhmcqLO1lD8z6WpVz Siyplw4slYYhy1jsqAeckMP5cFlzXyzspG+uLbpxqfU9nk+sKVngt2JtLC9GUr0PT7qP pU+hjrEG2mSCCP0JpoNMTUdWjfhhBX90FgknoAMR8VjORknSYfBv9bGSBiEsVElMxBc1 o8J2eJRw5U3r3bzVKkSaj1sOuJmdREH+HL425RoKsom026ct9r/wqeU6gxT0kLfFyNmY LdF4HFAkoUR33eDe0o99grn0fPDcruyfGyWtjoyrj3H1cTamrGUNlIlh92Ft4PZYICgu +F+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BB1gu4cVnIwl6q3wMvvsYiVuRfaBxjwOveotNnk8HqU=; b=VtpHKkGZMtZLdAfepbaKVl41UThk11MZGYvpJUUbGqVash51yDLt+y3QP+Ow52YaNx 43WTW6WGNbNcyLoSa8jevjqkopccHhlu860wJEeii4C7q9Vx/lYrvMJKPC4lZFUoLjgU vfqWPUDsoA0KmMTG8GqvIMS844EFgnQa2DZRLRGiyXefklYiQasQI4NXXf1whvuiKpNM J9GlAiViCWLDjDQYVdLOfJa0uLhBRD3J1ZAHsCdXCMgy6uzW4ZUIZa6NXwcCnjhlzEZo wegxQAgN0rUCn23fnhyunwKFDKETJnwuM2/qnrAJmdumExqQBlzQLli5JD21FRmhgGI8 Eykg== X-Gm-Message-State: AODbwcCH7aKdX/Udi69ZZRlt3SpbMjtfjMAizqL917AN8xloAJj9BN6S TYXICN6GSx6zh6WqUr4GEpCybKVAN4PM X-Received: by 10.200.43.33 with SMTP id 30mr13907253qtu.210.1495296036114; Sat, 20 May 2017 09:00:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Sat, 20 May 2017 09:00:35 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> From: Tom Herbert Date: Sat, 20 May 2017 09:00:35 -0700 Message-ID: To: Xuxiaohu Cc: Joe Touch , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRo?= =?utf-8?q?e_UDP_destination_port_number_resource_running_out=3F//_re=3A_I?= =?utf-8?q?-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 16:00:38 -0000 On Fri, May 19, 2017 at 11:09 PM, Xuxiaohu wrote: > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:touch@isi.edu] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8820=E6=97=A5= 12:15 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Tom Herbert >> =E6=8A=84=E9=80=81: int-area@ietf.org >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [Int-area] =E7=AD=94=E5=A4= =8D: Is the UDP destination port number resource >> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> >> On 5/19/2017 8:57 PM, Xuxiaohu wrote: >> > Hi Joe, >> > >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:touch@isi.edu] >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8820=E6=97= =A5 11:41 >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Tom Herbert >> >> =E6=8A=84=E9=80=81: int-area@ietf.org >> >> =E4=B8=BB=E9=A2=98: Re: [Int-area] =E7=AD=94=E5=A4=8D: Is the UDP des= tination port number resource >> >> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> >> >> >> >> >> On 5/19/2017 6:39 PM, Xuxiaohu wrote: >> >>> If the saving is beneficial, it'd better to assign a dedicated port >> >>> number for each UDP payload type( e.g., IP packet), rather than >> >>> combining the UDP port number dedicated for GUE and the version >> >>> field within the GUE header together to indicate whether the UDP >> >>> payload is GUE or IP (or even other payload type if the GUE is >> >>> devoted to help save the UDP port number resource for the IETF >> >>> community:)) >> >> FWIW, IANA strives to assign one port for a service. >> > Great. Hence IPvx should be taken as a service rather than taking IPvx= and >> GUE as a service, IMO. >> GUE is supposed to be both signalling and content (data), where the data= are IP >> packets. > > Since IANA strives to assign one port for a service, IP packet within the= UDP tunnel should be assigned a dedicated port. In other words, GUE and IP= -in-UDP are distinguished by the different port numbers. > >> Take away the IP part and GUE isn't an E anymore. >> >> Services are expected to have version fields and subtype >> >> demultiplexing indicators, to so that all message variants of current >> >> and future versions can use a single port number. >> > Sure, the version field within the IPvx packet could be used for demul= tiplexing >> purpose. >> >> That demultiplexes within IPvx. There still needs to be a way to demulti= plex >> non-IPvx packets (control) from IPvx. > > Since GUE and IP-in-UDP have different UDP port numbers, I don't know why= there is still a need to demultiplex GUE and IP-in-UDP. > It's header compression. Consider a scenario that GUE is tunneling IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel ingress. So some packets will have a fragmentation option and some won't. For unfragmented packets with no GUE options, they can be sent in direct encapsulation of IP. This could be done as version 1 of GUE or in IP-in-UDP as you're suggesting. The problem with the latter is that it doubles the number of flows in the network. So instead of punching one hole for a tunnel in a firewall we need two (the fragment tunnel and non-fragment UDP ports). Packets in individual flows now can take different paths depending on whether they're fragmented so this introduces OOO. Tom > Xiaohu > >> Joe From nobody Sat May 20 16:18:04 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DC9129601 for ; Sat, 20 May 2017 16:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 eV67FHvG9O9H for ; Sat, 20 May 2017 16:18:02 -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 60DC5128656 for ; Sat, 20 May 2017 16:18:02 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4KNGorC013485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 May 2017 16:17:13 -0700 (PDT) To: Xuxiaohu , Tom Herbert Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> From: Joe Touch Message-ID: <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu> Date: Sat, 20 May 2017 16:16:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------3957FB09AE2DB674DF555076" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRo?= =?utf-8?q?e_UDP_destination_port_number_resource_running_out=3F//_re=3A_I?= =?utf-8?q?-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 23:18:04 -0000 This is a multi-part message in MIME format. --------------3957FB09AE2DB674DF555076 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/19/2017 11:09 PM, Xuxiaohu wrote: >> GUE is supposed to be both signalling and content (data), where the data are IP >> packets. > Since IANA strives to assign one port for a service, IP packet within the UDP tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP are distinguished by the different port numbers. GUE is one service that includes both encapsulation of IP packets and signaling. Frankly, it seems like it would work anywhere IP works - where IPv0 is defined as the signalling channel (which is sufficient because IPv0 isn't defined). In that case, the first field after v0 needs to be a signal channel version number, to allow for future updates. > >> Take away the IP part and GUE isn't an E anymore. >>>> Services are expected to have version fields and subtype >>>> demultiplexing indicators, to so that all message variants of current >>>> and future versions can use a single port number. >>> Sure, the version field within the IPvx packet could be used for demultiplexing >> purpose. >> >> That demultiplexes within IPvx. There still needs to be a way to demultiplex >> non-IPvx packets (control) from IPvx. > Since GUE and IP-in-UDP have different UDP port numbers, They don't and they shouldn't. That would complicate forwarding - a single service needs to use a single port. Using separate ports complicates configurations - this is a case where you want "fate sharing" (either both IP encapsulation and the signal channel work or neither do). > I don't know why there is still a need to demultiplex GUE and IP-in-UDP. The point of GUE is an IP encapsulation channel with in-band signalling. That is a single service, IMO. Note - AFAICT, GUE could work anywhere an IP packet works. IP packets always start with a version number, and v0 isn't really defined. Defining v0 as the signal channel is the same thing as how GUE is currently specified. Joe --------------3957FB09AE2DB674DF555076 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 5/19/2017 11:09 PM, Xuxiaohu wrote:
GUE is supposed to be both signalling and content (data), where the data are IP
packets.

Since IANA strives to assign one port for a service, IP packet within the UDP tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP are distinguished by the different port numbers.
GUE is one service that includes both encapsulation of IP packets and signaling.
Frankly, it seems like it would work anywhere IP works - where IPv0 is defined as the signalling channel (which is sufficient because IPv0 isn't defined).

In that case, the first field after v0 needs to be a signal channel version number, to allow for future updates.


Take away the IP part and GUE isn't an E anymore.

Services are expected to have version fields and subtype
demultiplexing indicators, to so that all message variants of current
and future versions can use a single port number.

Sure, the version field within the IPvx packet could be used for demultiplexing

purpose.

That demultiplexes within IPvx. There still needs to be a way to demultiplex
non-IPvx packets (control) from IPvx.

Since GUE and IP-in-UDP have different UDP port numbers,
They don't and they shouldn't. That would complicate forwarding - a single service needs to use a single port. Using separate ports complicates configurations - this is a case where you want "fate sharing" (either both IP encapsulation and the signal channel work or neither do).

I don't know why there is still a need to demultiplex GUE and IP-in-UDP.
The point of GUE is an IP encapsulation channel with in-band signalling. That is a single service, IMO.

Note - AFAICT, GUE could work anywhere an IP packet works. IP packets always start with a version number, and v0 isn't really defined. Defining v0 as the signal channel is the same thing as how GUE is currently specified.

Joe

--------------3957FB09AE2DB674DF555076-- From nobody Sat May 20 17:08:55 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1D129AB8 for ; Sat, 20 May 2017 17:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 rDH7KRdhkPVg for ; Sat, 20 May 2017 17:08:51 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 B94A5129AB6 for ; Sat, 20 May 2017 17:08:51 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id k74so84527548qke.1 for ; Sat, 20 May 2017 17:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aJZk/+bz6Gh0v67SELFmEB1cb7o1GOPMPr8B4aAUNXM=; b=T0VK8UTlBOcuwD57O6QGnUBi9hsxfn5fq0OaTw9Y5+Fza0d+xP6A5Pdp4YKeVQkcKX GV7meFTVZk2yJv/7ejVYjfgyo9H0kPBv4Cv0CeWNs1byU2oRPn74vPRURveoriXIcz8W i6iiSaeSqE3IZ0Y49NN0pSjyCj2TpokHwbR5zQgFSE9Y1Jjt+speDCLKaNYltgRW/4B/ akZXy3d6vd18znCqjf9GQVmJkeX6vBu57dU0en6qZA82SXHXgjn+lUiigydkgu+bxUFP 7PB2yGw8fyOOviUK8tW67O3mKMQIuayyetofZT8mRE0kHD2lybG+1FBB45zkb05AvCj5 0cAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aJZk/+bz6Gh0v67SELFmEB1cb7o1GOPMPr8B4aAUNXM=; b=oaiSjo84aRtyiZPGevJChf9l71FhAr+EwOFziTgg23o1j2Yc3K2e72CaBuLcWoZYqp 2+dwnQzSnyrHpDk8VDzy3AwZ/BRlrb7UFF2I0xkY8I6gpcD88uN1NTuks/i+FG4bXMpH ir2E6rkIRe3z5uc59a+7mT+nFtYteKACtpRVlV9NYFIkK613WoRQCimZStZ9g/M0OAHE g+osxCGmgf8cmoPgvnzvC1LiBuF14r8z0VyEHE7CkrUpeivbcbM473iynABWUfceHDOM uzwmXt6/9LjEU6DOHg7yrwheTXg/7my7077sS5xj80vCJW5QG0ZH9af1LqmMTmS5UNd3 fXGA== X-Gm-Message-State: AODbwcDFMxVWwSj2N5PSLABEh2R4bGHp1EjtE7ZTQOHdguTleCV6P4xk pqDhdlvh3OubROVzSjvHcJ5mYpKVffgz X-Received: by 10.55.92.199 with SMTP id q190mr12373635qkb.286.1495325330785; Sat, 20 May 2017 17:08:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Sat, 20 May 2017 17:08:50 -0700 (PDT) In-Reply-To: <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu> From: Tom Herbert Date: Sat, 20 May 2017 17:08:50 -0700 Message-ID: To: Joe Touch Cc: Xuxiaohu , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRo?= =?utf-8?q?e_UDP_destination_port_number_resource_running_out=3F//_re=3A_I?= =?utf-8?q?-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 00:08:53 -0000 On Sat, May 20, 2017 at 4:16 PM, Joe Touch wrote: > > > On 5/19/2017 11:09 PM, Xuxiaohu wrote: > > GUE is supposed to be both signalling and content (data), where the data are > IP > packets. > > Since IANA strives to assign one port for a service, IP packet within the > UDP tunnel should be assigned a dedicated port. In other words, GUE and > IP-in-UDP are distinguished by the different port numbers. > > GUE is one service that includes both encapsulation of IP packets and > signaling. > Frankly, it seems like it would work anywhere IP works - where IPv0 is > defined as the signalling channel (which is sufficient because IPv0 isn't > defined). > > In that case, the first field after v0 needs to be a signal channel version > number, to allow for future updates. > > > Take away the IP part and GUE isn't an E anymore. > > Services are expected to have version fields and subtype > demultiplexing indicators, to so that all message variants of current > and future versions can use a single port number. > > Sure, the version field within the IPvx packet could be used for > demultiplexing > > purpose. > > That demultiplexes within IPvx. There still needs to be a way to demultiplex > non-IPvx packets (control) from IPvx. > > Since GUE and IP-in-UDP have different UDP port numbers, > > They don't and they shouldn't. That would complicate forwarding - a single > service needs to use a single port. Using separate ports complicates > configurations - this is a case where you want "fate sharing" (either both > IP encapsulation and the signal channel work or neither do). > > I don't know why there is still a need to demultiplex GUE and IP-in-UDP. > > The point of GUE is an IP encapsulation channel with in-band signalling. > That is a single service, IMO. > > Note - AFAICT, GUE could work anywhere an IP packet works. IP packets always > start with a version number, and v0 isn't really defined. Defining v0 as the > signal channel is the same thing as how GUE is currently specified. > Joe, I'm not sure I understand your point about IPv0. GUE v0 encapsulates packets of any IP prolocol number (IP, GRE, MPLS, EtherIP. ...) and allows for data messages as well as control messages. GUE v1 directly encapsulates IPv4 and IPv6 in a form of header compression. Where would we use IPv0? Tom > Joe > From nobody Sat May 20 17:41:03 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADAD129ADD for ; Sat, 20 May 2017 17:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 LF7ncXO2JV9i for ; Sat, 20 May 2017 17:41:01 -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 1EEBA126B6E for ; Sat, 20 May 2017 17:41:01 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4L0eUCI011269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 May 2017 17:40:40 -0700 (PDT) To: Tom Herbert Cc: Xuxiaohu , "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu> From: Joe Touch Message-ID: <8ac04a6b-75a9-e39a-0a94-c345182f99cd@isi.edu> Date: Sat, 20 May 2017 17:40:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRo?= =?utf-8?q?e_UDP_destination_port_number_resource_running_out=3F//_re=3A_I?= =?utf-8?q?-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2017 00:41:02 -0000 On 5/20/2017 5:08 PM, Tom Herbert wrote: > Joe, I'm not sure I understand your point about IPv0. GUE v0 > encapsulates packets of any IP prolocol number (IP, GRE, MPLS, > EtherIP. ...) and allows for data messages as well as control > messages. GUE v1 directly encapsulates IPv4 and IPv6 in a form of > header compression. Where would we use IPv0? > > Tom When we look at the first 2 bits of a GUE packet, we see: 00 = GUE version 0 01 = IPv4 or IPv6 10 = undefined 11 = undefined That's nearly the same as looking at the first 4 bits as simply the IP version number, and defining some of the unused IP versions as control: 0000 (IPv0) = GUE control 0001 (IPv1) = GUE control 0010 (IPv2) = GUE encapsulation using the GUE header 0011 (IPv3) = GUE encapsulation using the GUE header 0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE header 0101 (IPv5) = direct encapsulation of IPv5 (ST), with no intervening GUE header 0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE header 0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no intervening GUE header 1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no intervening GUE header 1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no intervening GUE header 1010 (IPv10) = direct encapsulation of IPv10, when assigned 1010 (IPv11) = direct encapsulation of IPv11, when assigned 1010 (IPv12) = direct encapsulation of IPv12, when assigned 1010 (IPv13) = direct encapsulation of IPv13, when assigned 1010 (IPv14) = direct encapsulation of IPv14, when assigned 1010 (IPv15) = direct encapsulation of IPv15, when assigned I.e., all you're basically doing is defining the first four version numbers of IP as your control plane. Unless we come back and assign them in the future, any mechanism that encapsulates IP packets (which should, IMO, be able to handle ALL IP versions, by definition) should be able to include GUE-style signaling. IMO, it's simpler to explain this all using this fixed-field demultiplexer - in which case, you could even use just the IPv0 pattern for control and the IPv1 pattern for encapsulation using the GUE header, leaving the IPv2 and IPv3 equivalent patterns for future expansion. Joe From nobody Mon May 22 08:23:45 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B5E1200C5 for ; Mon, 22 May 2017 08:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] 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 BzRaQXrlrCXQ for ; Mon, 22 May 2017 08:23:41 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 1AB6A120046 for ; Mon, 22 May 2017 08:23:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4MFNdHu036672; Mon, 22 May 2017 08:23:40 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4MFNYRQ036580 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 22 May 2017 08:23:34 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 22 May 2017 08:23:33 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 22 May 2017 08:23:33 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt Thread-Index: AQHSz1SLC+nA9wp6X0aFrl8vL8qeuqH5hfOAgAIvjYA= Date: Mon, 22 May 2017 15:23:33 +0000 Message-ID: References: <149505650017.6670.1022872968633952096@ietfa.amsl.com> <2fbd3252-c8eb-8a71-4a01-43c0044fe877@isi.edu> In-Reply-To: <2fbd3252-c8eb-8a71-4a01-43c0044fe877@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_ae1f0827169f470b8e4c1df4a4ae4dacXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:23:43 -0000 --_000_ae1f0827169f470b8e4c1df4a4ae4dacXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpJIHJlYWQgdGhlIHdob2xlIGRvY3VtZW50LCBhbmQgSSB0aGluayBpcyByZWFk eSBmb3IgYWR2YW5jZW1lbnQgaW4gaXRzIGN1cnJlbnQgZm9ybQ0KbW9kdWxvIHRoZSBJbmZvcm1h dGlvbmFsIC0+IEJDUCBkZWNpc2lvbi4gSSBzdXBwb3J0IGNoYW5naW5nIHRoZSBkb2N1bWVudCB0 cmFjaw0KZnJvbSBJbmZvcm1hdGlvbmFsIHRvIEJDUCwgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0 aGF0IG1vcmUgd29yayB3aWxsIGJlIG5lZWRlZA0KaW4gU2VjdGlvbiA1IGlmIHRoYXQgd291bGQg YmUgdGhlIGNhc2UuIFRoYW5rcyBmb3IgdGhpcyB3b3JrLg0KDQpGcmVkDQpmcmVkLmwudGVtcGxp bkBib2VpbmcuY29tDQoNCkZyb206IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZSBUb3VjaA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTcs IDIwMTcgMjo1MSBQTQ0KVG86IGludC1hcmVhQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0ludC1h cmVhXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNi50eHQNCg0KDQpI aSwgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIGludGFyZWEtdHVubmVscyBoYXMgYmVlbiBwb3N0 ZWQsIGFzIG5vdGVkIGJlbG93Lg0KDQpBdCB0aGlzIHBvaW50LCBJIHdvdWxkIGxpa2UgdG8gYXNr IHRoZSBjaGFpcnMgdG8gc3RhcnQgYSBXRyBjYWxsIHRvIGNvbnNpZGVyIHJldmlzaW5nIHRoZSBk b2N1bWVudCB0cmFjaywgYXMgcGVyIGJlbG93Lg0KDQpTb21lIGhpc3Rvcnk6DQoNClRoaXMgZG9j dW1lbnQgYmVnYW4gYXMgYSBzZXQgb2YgZGlzY3Vzc2lvbnMgYXQgSUVURiA3MiBpbiBQaGlsYWRl bHBoaWEgKDIwMDgpLCB3aGVyZSBhIGZldyBBRHMgYXBwcm9hY2hlZCB1cyB0byB0cnkgdG8gaW50 ZWdyYXRlIGEgbnVtYmVyIG9mIGVtZXJnaW5nIHR1bm5lbCBlZmZvcnRzLCB3aXRoIHRoZSBhc3N1 bXB0aW9uIG9mIHNpbXBseSBpbnRlZ3JhdGluZyB0aGVtLiBUaGUgcmVzdWx0IHdhcyBhbiBhdHRl bXB0IHRvIHNpbXBseSBvcmdhbml6ZSB0aGUgbGFuZHNjYXBlIGF0IHRoZSB0aW1lLg0KDQpXZSBz dGFydGVkIHRoYXQgbGFuZHNjYXBlIGFzIGFuIElOVEFSRUEgV0cgaW5mb3JtYXRpb25hbCBkb2Mg aW4gTWFyY2ggMjAxMC4gSXQgdG9vayBmaXZlIHllYXJzIG9mIGRpc2N1c3Npb25zLCBib3RoIG9u IHRoaXMgbGlzdCBhbmQgaW4gb3RoZXIgV0dzLCB0byByZWFsaXplIHdlIG5lZWRlZCB0byBzdGFy dCBieSBleHBsYWluaW5nIG91ciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb25jZXB0IG9mIGEgdHVu bmVsIGFzIGEgbGluayAoaXNzdWVzIGluIDIwMTUpLiBBdCB0aGF0IHBvaW50IHdlIHJlYWxpemVk IHRoYXQgbWFueSBleGlzdGluZyBhbmQgZW1lcmdpbmcgdHVubmVscyB3ZXJlIGluY29uc2lzdGVu dCB3aXRoIGVhY2ggb3RoZXIgYW5kIHdpdGggZXhpc3RpbmcgcmVxdWlyZW1lbnRzLg0KDQpXZSBj YW1lIHVwIHdpdGggYW4gYXBwcm9hY2ggd2hpY2ggd2UgYmVsaWV2ZSBpcyBib3RoIGNvcnJlY3Qg YW5kIGNvbnNpc3RlbnQgd2l0aCBleGlzdGluZyBjb3JlIEludGVybmV0IHJlcXVpcmVtZW50cywg YW5kIGhpZ2hsaWdodGVkIHdoZXJlIGl0IGRpZmZlcnMgZnJvbSBjdXJyZW50IHR1bm5lbHMgKHN0 YW5kYXJkcyB0cmFjaywgaW5mb3JtYXRpb25hbCwgb3Igb3RoZXJ3aXNlKSBpbiBTZWN0aW9uIDUu IEF0IHRoaXMgcG9pbnQsIHdlIGJlbGlldmUgdGhlIGNvcmUgb2YgdGhpcyBkb2N1bWVudCBpcyBi b3RoIHN0YWJsZSBhbmQgcmVwcmVzZW50cyBub3Qgb25seSBhIGNsZWFyIHZpZXcgb2YgdHVubmVs cyBhcyBhbiBhcmNoaXRlY3R1cmFsIGNvbXBvbmVudCBvZiB0aGUgSW50ZXJuZXQsIGJ1dCBhbHNv IHJlcHJlc2VudHMgdGhlIGN1cnJlbnQgYmVzdCBwcmFjdGljZXMgcmVnYXJkaW5nIHRoZSBkZXNp Z24gYW5kIHVzZSBvZiB0dW5uZWxzLg0KDQpPdXIgcmVxdWVzdDoNCg0KQXMgYSByZXN1bHQsIHdl J2QgbGlrZSB0byBhc2sgdGhlIGNoYWlycyB0byBpbml0aWF0ZSBhIGNhbGwgdG8gY2hhbmdlIHRo ZSB0cmFjayBvZiB0aGlzIGRvY3VtZW50IGZyb20gSW5mb3JtYXRpb25hbCB0byBCQ1AuDQoNClRo ZSByZXN1bHQgb2YgdGhpcyBkZWNpc2lvbiB3aWxsIGltcGFjdCBob3cgU2VjdGlvbiA1IGlzIHJl c29sdmVkLiBJZiB0aGlzIGRvY3VtZW50IGJlY29tZXMgYSBCQ1AsIHRoYXQgc2VjdGlvbiB3aWxs IGJlIGZsZXNoZWQgb3V0IGZvciBXRyBjb25zZW5zdXMuIElmIHRoaXMgZG9jdW1lbnQgcmVtYWlu cyBJbmZvcm1hdGlvbmFsLCB0aGVuIHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gU2VjdGlvbiA1IG1p Z2h0IG5vdCBiZSBhcHByb3ByaWF0ZSwgYW5kIHdpbGwgbGlrZWx5IG5lZWQgdG8gYmUgb21pdHRl ZCBpbiB3aG9sZSBvciBwYXJ0Lg0KSm9lDQoNCi0tLS0tLS0NCg0KU3VtbWFyeSBvZiAwNiBjaGFu Z2VzOg0KDQogICAgLSB1cGRhdGVkIEVDTVAgZGlzY3Vzc2lvbg0KDQogICAgLSB1cGRhdGVkIG11 bHRpcG9pbnQgZGlzY3Vzc2lvbg0KDQogICAgLSB1cGRhdGVkIHRlcm1pbm9sb2d5IChhdG9tIC0+ IGF0b21pYyBwYWNrZXQpDQoNCiAgICAtIHJldmlzZWQgRmlnIDEyIGFuZCBGaWcgMTMgYWxnb3Jp dGhtcyAoaXQgd2Fzbid0IGNsZWFyIHRoYXQgdGhpcyB3YXMgb3V0ZXIgZnJhZ21lbnRhdGlvbikN Cg0KLS0tLS0tDQoNCk9uIDUvMTcvMjAxNyAyOjI4IFBNLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KDQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuDQoNClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVy bmV0IEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KDQoNCiAgICAgICAgVGl0bGUg ICAgICAgICAgIDogSVAgVHVubmVscyBpbiB0aGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlDQoNCiAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogSm9lIFRvdWNoDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgTWFyayBUb3duc2xleQ0KDQogRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pbnRh cmVhLXR1bm5lbHMtMDYudHh0DQoNCiBQYWdlcyAgICAgICAgICAgOiA1Mg0KDQogRGF0ZSAgICAg ICAgICAgIDogMjAxNy0wNS0xNw0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQg ZGlzY3Vzc2VzIHRoZSByb2xlIG9mIElQIHR1bm5lbHMgaW4gdGhlIEludGVybmV0DQoNCiAgIGFy Y2hpdGVjdHVyZS4gQW4gSVAgdHVubmVsIHRyYW5zaXRzIElQIGRhdGFncmFtcyBhcyBwYXlsb2Fk cyBpbiBub24tDQoNCiAgIGxpbmsgbGF5ZXIgcHJvdG9jb2xzLiBUaGlzIGRvY3VtZW50IGV4cGxh aW5zIHRoZSByZWxhdGlvbnNoaXAgb2YgSVANCg0KICAgdHVubmVscyB0byBleGlzdGluZyBwcm90 b2NvbCBsYXllcnMgYW5kIHRoZSBjaGFsbGVuZ2VzIGluIHN1cHBvcnRpbmcNCg0KICAgSVAgdHVu bmVsaW5nLCBiYXNlZCBvbiB0aGUgZXF1aXZhbGVuY2Ugb2YgdHVubmVscyB0byBsaW5rcy4gVGhl DQoNCiAgIGltcGxpY2F0aW9ucyBvZiB0aGlzIGRvY3VtZW50IGFyZSB1c2VkIHRvIGRlcml2ZSBy ZWNvbW1lbmRhdGlvbnMgdGhhdA0KDQogICB1cGRhdGUgTVRVIGFuZCBmcmFnbWVudCBpc3N1ZXMg aW4gUkZDIDQ0NTkuDQoNCg0KDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLw0KDQoNCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNg0KDQoNCg0KQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYNCg0KDQoN Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQoNCmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCg0KSW50 LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOkludC1hcmVhQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhDQoNCg== --_000_ae1f0827169f470b8e4c1df4a4ae4dacXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IaSBKb2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIHJlYWQgdGhlIHdob2xlIGRvY3VtZW50LCBhbmQgSSB0aGluayBpcyByZWFk eSBmb3IgYWR2YW5jZW1lbnQgaW4gaXRzIGN1cnJlbnQgZm9ybTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5t b2R1bG8gdGhlIEluZm9ybWF0aW9uYWwgLSZndDsgQkNQIGRlY2lzaW9uLiBJIHN1cHBvcnQgY2hh bmdpbmcgdGhlIGRvY3VtZW50IHRyYWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZyb20gSW5mb3JtYXRp b25hbCB0byBCQ1AsIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCBtb3JlIHdvcmsgd2lsbCBi ZSBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aW4gU2VjdGlvbiA1IGlmIHRoYXQgd291bGQgYmUg dGhlIGNhc2UuIFRoYW5rcyBmb3IgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5mcmVkLmwudGVtcGxpbkBi b2VpbmcuY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IElu dC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Sm9lIFRvdWNoPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWF5IDE3LCAyMDE3 IDI6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IGludC1hcmVhQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbSW50LWFyZWFdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5u ZWxzLTA2LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhpLCBhbGwsPG86cD48L286 cD48L3A+DQo8cD5BIG5ldyB2ZXJzaW9uIG9mIGludGFyZWEtdHVubmVscyBoYXMgYmVlbiBwb3N0 ZWQsIGFzIG5vdGVkIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHA+QXQgdGhpcyBwb2ludCwgSSB3 b3VsZCBsaWtlIHRvIGFzayB0aGUgY2hhaXJzIHRvIHN0YXJ0IGEgV0cgY2FsbCB0byBjb25zaWRl ciByZXZpc2luZyB0aGUgZG9jdW1lbnQgdHJhY2ssIGFzIHBlciBiZWxvdy48bzpwPjwvbzpwPjwv cD4NCjxwPjxiPjx1PlNvbWUgaGlzdG9yeTo8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhp cyBkb2N1bWVudCBiZWdhbiBhcyBhIHNldCBvZiBkaXNjdXNzaW9ucyBhdCBJRVRGIDcyIGluIFBo aWxhZGVscGhpYSAoMjAwOCksIHdoZXJlIGEgZmV3IEFEcyBhcHByb2FjaGVkIHVzIHRvIHRyeSB0 byBpbnRlZ3JhdGUgYSBudW1iZXIgb2YgZW1lcmdpbmcgdHVubmVsIGVmZm9ydHMsIHdpdGggdGhl IGFzc3VtcHRpb24gb2Ygc2ltcGx5IGludGVncmF0aW5nIHRoZW0uIFRoZSByZXN1bHQgd2FzIGFu IGF0dGVtcHQgdG8gc2ltcGx5IG9yZ2FuaXplDQogdGhlIGxhbmRzY2FwZSBhdCB0aGUgdGltZS48 bzpwPjwvbzpwPjwvcD4NCjxwPldlIHN0YXJ0ZWQgdGhhdCBsYW5kc2NhcGUgYXMgYW4gSU5UQVJF QSBXRyBpbmZvcm1hdGlvbmFsIGRvYyBpbiBNYXJjaCAyMDEwLiBJdCB0b29rIGZpdmUgeWVhcnMg b2YgZGlzY3Vzc2lvbnMsIGJvdGggb24gdGhpcyBsaXN0IGFuZCBpbiBvdGhlciBXR3MsIHRvIHJl YWxpemUgd2UgbmVlZGVkIHRvIHN0YXJ0IGJ5IGV4cGxhaW5pbmcgb3VyIHVuZGVyc3RhbmRpbmcg b2YgdGhlIGNvbmNlcHQgb2YgYSB0dW5uZWwgYXMgYSBsaW5rIChpc3N1ZXMNCiBpbiAyMDE1KS4g QXQgdGhhdCBwb2ludCB3ZSByZWFsaXplZCB0aGF0IG1hbnkgZXhpc3RpbmcgYW5kIGVtZXJnaW5n IHR1bm5lbHMgd2VyZSBpbmNvbnNpc3RlbnQgd2l0aCBlYWNoIG90aGVyIGFuZCB3aXRoIGV4aXN0 aW5nIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwPldlIGNhbWUgdXAgd2l0aCBhbiBh cHByb2FjaCB3aGljaCB3ZSBiZWxpZXZlIGlzIGJvdGggY29ycmVjdCBhbmQgY29uc2lzdGVudCB3 aXRoIGV4aXN0aW5nIGNvcmUgSW50ZXJuZXQgcmVxdWlyZW1lbnRzLCBhbmQgaGlnaGxpZ2h0ZWQg d2hlcmUgaXQgZGlmZmVycyBmcm9tIGN1cnJlbnQgdHVubmVscyAoc3RhbmRhcmRzIHRyYWNrLCBp bmZvcm1hdGlvbmFsLCBvciBvdGhlcndpc2UpIGluIFNlY3Rpb24gNS4gQXQgdGhpcyBwb2ludCwg d2UgYmVsaWV2ZQ0KIHRoZSBjb3JlIG9mIHRoaXMgZG9jdW1lbnQgaXMgYm90aCBzdGFibGUgYW5k IHJlcHJlc2VudHMgbm90IG9ubHkgYSBjbGVhciB2aWV3IG9mIHR1bm5lbHMgYXMgYW4gYXJjaGl0 ZWN0dXJhbCBjb21wb25lbnQgb2YgdGhlIEludGVybmV0LCBidXQgYWxzbyByZXByZXNlbnRzIHRo ZSBjdXJyZW50IGJlc3QgcHJhY3RpY2VzIHJlZ2FyZGluZyB0aGUgZGVzaWduIGFuZCB1c2Ugb2Yg dHVubmVscy48bzpwPjwvbzpwPjwvcD4NCjxwPjxiPjx1Pk91ciByZXF1ZXN0OjwvdT48L2I+PG86 cD48L286cD48L3A+DQo8cD5BcyBhIHJlc3VsdCwgd2UnZCBsaWtlIHRvIGFzayB0aGUgY2hhaXJz IHRvIGluaXRpYXRlIGEgY2FsbCB0byBjaGFuZ2UgdGhlIHRyYWNrIG9mIHRoaXMgZG9jdW1lbnQg ZnJvbSBJbmZvcm1hdGlvbmFsIHRvIEJDUC48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSByZXN1bHQg b2YgdGhpcyBkZWNpc2lvbiB3aWxsIGltcGFjdCBob3cgU2VjdGlvbiA1IGlzIHJlc29sdmVkLiBJ ZiB0aGlzIGRvY3VtZW50IGJlY29tZXMgYSBCQ1AsIHRoYXQgc2VjdGlvbiB3aWxsIGJlIGZsZXNo ZWQgb3V0IGZvciBXRyBjb25zZW5zdXMuIElmIHRoaXMgZG9jdW1lbnQgcmVtYWlucyBJbmZvcm1h dGlvbmFsLCB0aGVuIHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gU2VjdGlvbiA1IG1pZ2h0IG5vdCBi ZSBhcHByb3ByaWF0ZSwNCiBhbmQgd2lsbCBsaWtlbHkgbmVlZCB0byBiZSBvbWl0dGVkIGluIHdo b2xlIG9yIHBhcnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8YnI+ DQo8YnI+DQotLS0tLS0tPG86cD48L286cD48L3A+DQo8cD5TdW1tYXJ5IG9mIDA2IGNoYW5nZXM6 PG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsgLSB1cGRhdGVkIEVDTVAgZGlz Y3Vzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gdXBkYXRlZCBt dWx0aXBvaW50IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNw OyAtIHVwZGF0ZWQgdGVybWlub2xvZ3kgKGF0b20gLSZndDsgYXRvbWljIHBhY2tldCk8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyAtIHJldmlzZWQgRmlnIDEyIGFuZCBGaWcg MTMgYWxnb3JpdGhtcyAoaXQgd2Fzbid0IGNsZWFyIHRoYXQgdGhpcyB3YXMgb3V0ZXIgZnJhZ21l bnRhdGlvbik8bzpwPjwvbzpwPjwvcD4NCjxwPi0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gNS8xNy8yMDE3IDI6MjggUE0sIDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciPg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRlcm5ldCBBcmVhIFdvcmtpbmcgR3JvdXAgb2YgdGhl IElFVEYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDog SVAgVHVubmVscyBpbiB0aGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcnMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBKb2UgVG91 Y2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTWFyayBUb3duc2xleTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBGaWxlbmFtZSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IGRyYWZ0LWlldGYtaW50YXJl YS10dW5uZWxzLTA2LnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBQYWdlcyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDUyPG86 cD48L286cD48L3ByZT4NCjxwcmU+IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE3LTA1LTE3PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWJzdHJhY3Q6PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2Vz IHRoZSByb2xlIG9mIElQIHR1bm5lbHMgaW4gdGhlIEludGVybmV0PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGFyY2hpdGVjdHVyZS4gQW4gSVAgdHVubmVsIHRyYW5zaXRzIElQ IGRhdGFncmFtcyBhcyBwYXlsb2FkcyBpbiBub24tPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IGxpbmsgbGF5ZXIgcHJvdG9jb2xzLiBUaGlzIGRvY3VtZW50IGV4cGxhaW5zIHRo ZSByZWxhdGlvbnNoaXAgb2YgSVA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg dHVubmVscyB0byBleGlzdGluZyBwcm90b2NvbCBsYXllcnMgYW5kIHRoZSBjaGFsbGVuZ2VzIGlu IHN1cHBvcnRpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgSVAgdHVubmVs aW5nLCBiYXNlZCBvbiB0aGUgZXF1aXZhbGVuY2Ugb2YgdHVubmVscyB0byBsaW5rcy4gVGhlPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGltcGxpY2F0aW9ucyBvZiB0aGlzIGRv Y3VtZW50IGFyZSB1c2VkIHRvIGRlcml2ZSByZWNvbW1lbmRhdGlvbnMgdGhhdDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB1cGRhdGUgTVRVIGFuZCBmcmFnbWVudCBpc3N1ZXMg aW4gUkZDIDQ0NTkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pbnRh cmVhLXR1bm5lbHMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWludGFyZWEtdHVubmVscy88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxh YmxlIGF0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2PC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDY8L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LWludGFyZWEtdHVubmVscy0wNiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5J bnQtYXJlYSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWls dG86SW50LWFyZWFAaWV0Zi5vcmciPkludC1hcmVhQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aW50LWFyZWEiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWE8 L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_ae1f0827169f470b8e4c1df4a4ae4dacXCH150608nwnosboeingcom_-- From nobody Mon May 22 08:56:18 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475CD12EAFF for ; Mon, 22 May 2017 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=p6FvWSKl; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=gVBmJ6xp 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 MCG8cYUZPH7q for ; Mon, 22 May 2017 08:56:13 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 BA1BC12EB07 for ; Mon, 22 May 2017 08:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1495468573; x=1527004573; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5GKOo317bRnjyOlqgEKWviRb830sC3PliIX538ZEbdc=; b=p6FvWSKlp4QbMHe+93N43fQg13lW4cLmXF/oY8aQwBRhbOIMi3pnDVSH hjXBFSKo8Lp8PCaGLV0bfeHmOZwBwkKHNqn+gVHfuFOlwaeFCg+9Hc48p 1eIqEf8bXwczFxjKiWHLFqAl5gdLE9X9UhLp1DqdzdnL7nqW8IXOcl835 Q=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2017 10:56:13 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2017 21:55:28 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v4MFu9sA012556 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 11:56:11 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v4MFu9sA012556 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1495468571; bh=yBDIcXLsWYzHrVx+ajNaF39lFyQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=gVBmJ6xpL5QyoESecRtxyNsyb5CMifOzFI+6J8THfQTXmfrZLaRbrbvJ/g0t5BzQd hLPQ1OAS8FNT3xB7eKJx8lctgy8YsHWEcczN8fZrs0mvzRW3sDg4caeyTmniJRAA6+ hfcyF+geyLCBceDoTifcvq7jXnOL5mYuu0S/l/X8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v4MFu9sA012556 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 22 May 2017 11:54:01 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v4MFu2CY016860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 22 May 2017 11:56:02 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0266.001; Mon, 22 May 2017 11:56:02 -0400 To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt Thread-Index: AQHSz1SG1cQ2zACXBUueBYQ1qtYIT6H5U6iAgAdvfID//8TwUA== Date: Mon, 22 May 2017 15:56:02 +0000 Message-ID: References: <149505650017.6670.1022872968633952096@ietfa.amsl.com> <2fbd3252-c8eb-8a71-4a01-43c0044fe877@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FA9793AMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-06.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 15:56:16 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FA9793AMX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEg4oCTIEkgY29uY3VyIHdpdGggRnJlZCB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIGJlY29tZSBh IEJDUC4gIFRoZSBjb25jZXB0IG9mIGEgdHVubmVsIGFzIGEgbGluayBpcyBmdW5kYW1lbnRhbCBh bmQgc2hvdWxkIGJlIGEgZm91bmRhdGlvbmFsIHByaW5jaXBsZSBmb3IgaG93IHR1bm5lbHMgYXJl IGRlc2lnbmVkL3NwZWNpZmllZC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCkZyb206IEludC1hcmVh IFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlbXBsaW4s IEZyZWQgTA0KU2VudDogTW9uZGF5LCBNYXkgMjIsIDIwMTcgMTE6MjQgQU0NClRvOiBKb2UgVG91 Y2ggPHRvdWNoQGlzaS5lZHU+OyBpbnQtYXJlYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJbnQt YXJlYV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYudHh0DQoNCkhp IEpvZSwNCg0KSSByZWFkIHRoZSB3aG9sZSBkb2N1bWVudCwgYW5kIEkgdGhpbmsgaXMgcmVhZHkg Zm9yIGFkdmFuY2VtZW50IGluIGl0cyBjdXJyZW50IGZvcm0NCm1vZHVsbyB0aGUgSW5mb3JtYXRp b25hbCAtPiBCQ1AgZGVjaXNpb24uIEkgc3VwcG9ydCBjaGFuZ2luZyB0aGUgZG9jdW1lbnQgdHJh Y2sNCmZyb20gSW5mb3JtYXRpb25hbCB0byBCQ1AsIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgdGhh dCBtb3JlIHdvcmsgd2lsbCBiZSBuZWVkZWQNCmluIFNlY3Rpb24gNSBpZiB0aGF0IHdvdWxkIGJl IHRoZSBjYXNlLiBUaGFua3MgZm9yIHRoaXMgd29yay4NCg0KRnJlZA0KZnJlZC5sLnRlbXBsaW5A Ym9laW5nLmNvbTxtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbT4NCg0KRnJvbTogSW50 LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9l IFRvdWNoDQpTZW50OiBXZWRuZXNkYXksIE1heSAxNywgMjAxNyAyOjUxIFBNDQpUbzogaW50LWFy ZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJbnQt YXJlYV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYudHh0DQoNCg0K SGksIGFsbCwNCg0KQSBuZXcgdmVyc2lvbiBvZiBpbnRhcmVhLXR1bm5lbHMgaGFzIGJlZW4gcG9z dGVkLCBhcyBub3RlZCBiZWxvdy4NCg0KQXQgdGhpcyBwb2ludCwgSSB3b3VsZCBsaWtlIHRvIGFz ayB0aGUgY2hhaXJzIHRvIHN0YXJ0IGEgV0cgY2FsbCB0byBjb25zaWRlciByZXZpc2luZyB0aGUg ZG9jdW1lbnQgdHJhY2ssIGFzIHBlciBiZWxvdy4NCg0KU29tZSBoaXN0b3J5Og0KDQpUaGlzIGRv Y3VtZW50IGJlZ2FuIGFzIGEgc2V0IG9mIGRpc2N1c3Npb25zIGF0IElFVEYgNzIgaW4gUGhpbGFk ZWxwaGlhICgyMDA4KSwgd2hlcmUgYSBmZXcgQURzIGFwcHJvYWNoZWQgdXMgdG8gdHJ5IHRvIGlu dGVncmF0ZSBhIG51bWJlciBvZiBlbWVyZ2luZyB0dW5uZWwgZWZmb3J0cywgd2l0aCB0aGUgYXNz dW1wdGlvbiBvZiBzaW1wbHkgaW50ZWdyYXRpbmcgdGhlbS4gVGhlIHJlc3VsdCB3YXMgYW4gYXR0 ZW1wdCB0byBzaW1wbHkgb3JnYW5pemUgdGhlIGxhbmRzY2FwZSBhdCB0aGUgdGltZS4NCg0KV2Ug c3RhcnRlZCB0aGF0IGxhbmRzY2FwZSBhcyBhbiBJTlRBUkVBIFdHIGluZm9ybWF0aW9uYWwgZG9j IGluIE1hcmNoIDIwMTAuIEl0IHRvb2sgZml2ZSB5ZWFycyBvZiBkaXNjdXNzaW9ucywgYm90aCBv biB0aGlzIGxpc3QgYW5kIGluIG90aGVyIFdHcywgdG8gcmVhbGl6ZSB3ZSBuZWVkZWQgdG8gc3Rh cnQgYnkgZXhwbGFpbmluZyBvdXIgdW5kZXJzdGFuZGluZyBvZiB0aGUgY29uY2VwdCBvZiBhIHR1 bm5lbCBhcyBhIGxpbmsgKGlzc3VlcyBpbiAyMDE1KS4gQXQgdGhhdCBwb2ludCB3ZSByZWFsaXpl ZCB0aGF0IG1hbnkgZXhpc3RpbmcgYW5kIGVtZXJnaW5nIHR1bm5lbHMgd2VyZSBpbmNvbnNpc3Rl bnQgd2l0aCBlYWNoIG90aGVyIGFuZCB3aXRoIGV4aXN0aW5nIHJlcXVpcmVtZW50cy4NCg0KV2Ug Y2FtZSB1cCB3aXRoIGFuIGFwcHJvYWNoIHdoaWNoIHdlIGJlbGlldmUgaXMgYm90aCBjb3JyZWN0 IGFuZCBjb25zaXN0ZW50IHdpdGggZXhpc3RpbmcgY29yZSBJbnRlcm5ldCByZXF1aXJlbWVudHMs IGFuZCBoaWdobGlnaHRlZCB3aGVyZSBpdCBkaWZmZXJzIGZyb20gY3VycmVudCB0dW5uZWxzIChz dGFuZGFyZHMgdHJhY2ssIGluZm9ybWF0aW9uYWwsIG9yIG90aGVyd2lzZSkgaW4gU2VjdGlvbiA1 LiBBdCB0aGlzIHBvaW50LCB3ZSBiZWxpZXZlIHRoZSBjb3JlIG9mIHRoaXMgZG9jdW1lbnQgaXMg Ym90aCBzdGFibGUgYW5kIHJlcHJlc2VudHMgbm90IG9ubHkgYSBjbGVhciB2aWV3IG9mIHR1bm5l bHMgYXMgYW4gYXJjaGl0ZWN0dXJhbCBjb21wb25lbnQgb2YgdGhlIEludGVybmV0LCBidXQgYWxz byByZXByZXNlbnRzIHRoZSBjdXJyZW50IGJlc3QgcHJhY3RpY2VzIHJlZ2FyZGluZyB0aGUgZGVz aWduIGFuZCB1c2Ugb2YgdHVubmVscy4NCg0KT3VyIHJlcXVlc3Q6DQoNCkFzIGEgcmVzdWx0LCB3 ZSdkIGxpa2UgdG8gYXNrIHRoZSBjaGFpcnMgdG8gaW5pdGlhdGUgYSBjYWxsIHRvIGNoYW5nZSB0 aGUgdHJhY2sgb2YgdGhpcyBkb2N1bWVudCBmcm9tIEluZm9ybWF0aW9uYWwgdG8gQkNQLg0KDQpU aGUgcmVzdWx0IG9mIHRoaXMgZGVjaXNpb24gd2lsbCBpbXBhY3QgaG93IFNlY3Rpb24gNSBpcyBy ZXNvbHZlZC4gSWYgdGhpcyBkb2N1bWVudCBiZWNvbWVzIGEgQkNQLCB0aGF0IHNlY3Rpb24gd2ls bCBiZSBmbGVzaGVkIG91dCBmb3IgV0cgY29uc2Vuc3VzLiBJZiB0aGlzIGRvY3VtZW50IHJlbWFp bnMgSW5mb3JtYXRpb25hbCwgdGhlbiB0aGUgcmVjb21tZW5kYXRpb25zIGluIFNlY3Rpb24gNSBt aWdodCBub3QgYmUgYXBwcm9wcmlhdGUsIGFuZCB3aWxsIGxpa2VseSBuZWVkIHRvIGJlIG9taXR0 ZWQgaW4gd2hvbGUgb3IgcGFydC4NCkpvZQ0KDQotLS0tLS0tDQoNClN1bW1hcnkgb2YgMDYgY2hh bmdlczoNCg0KICAgIC0gdXBkYXRlZCBFQ01QIGRpc2N1c3Npb24NCg0KICAgIC0gdXBkYXRlZCBt dWx0aXBvaW50IGRpc2N1c3Npb24NCg0KICAgIC0gdXBkYXRlZCB0ZXJtaW5vbG9neSAoYXRvbSAt PiBhdG9taWMgcGFja2V0KQ0KDQogICAgLSByZXZpc2VkIEZpZyAxMiBhbmQgRmlnIDEzIGFsZ29y aXRobXMgKGl0IHdhc24ndCBjbGVhciB0aGF0IHRoaXMgd2FzIG91dGVyIGZyYWdtZW50YXRpb24p DQoNCi0tLS0tLQ0KDQpPbiA1LzE3LzIwMTcgMjoyOCBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCg0KQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLg0KDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJbnRl cm5ldCBBcmVhIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCg0KDQogICAgICAgIFRpdGxl ICAgICAgICAgICA6IElQIFR1bm5lbHMgaW4gdGhlIEludGVybmV0IEFyY2hpdGVjdHVyZQ0KDQog ICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpvZSBUb3VjaA0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgIE1hcmsgVG93bnNsZXkNCg0KIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaW50 YXJlYS10dW5uZWxzLTA2LnR4dA0KDQogUGFnZXMgICAgICAgICAgIDogNTINCg0KIERhdGUgICAg ICAgICAgICA6IDIwMTctMDUtMTcNCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50 IGRpc2N1c3NlcyB0aGUgcm9sZSBvZiBJUCB0dW5uZWxzIGluIHRoZSBJbnRlcm5ldA0KDQogICBh cmNoaXRlY3R1cmUuIEFuIElQIHR1bm5lbCB0cmFuc2l0cyBJUCBkYXRhZ3JhbXMgYXMgcGF5bG9h ZHMgaW4gbm9uLQ0KDQogICBsaW5rIGxheWVyIHByb3RvY29scy4gVGhpcyBkb2N1bWVudCBleHBs YWlucyB0aGUgcmVsYXRpb25zaGlwIG9mIElQDQoNCiAgIHR1bm5lbHMgdG8gZXhpc3RpbmcgcHJv dG9jb2wgbGF5ZXJzIGFuZCB0aGUgY2hhbGxlbmdlcyBpbiBzdXBwb3J0aW5nDQoNCiAgIElQIHR1 bm5lbGluZywgYmFzZWQgb24gdGhlIGVxdWl2YWxlbmNlIG9mIHR1bm5lbHMgdG8gbGlua3MuIFRo ZQ0KDQogICBpbXBsaWNhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBhcmUgdXNlZCB0byBkZXJpdmUg cmVjb21tZW5kYXRpb25zIHRoYXQNCg0KICAgdXBkYXRlIE1UVSBhbmQgZnJhZ21lbnQgaXNzdWVz IGluIFJGQyA0NDU5Lg0KDQoNCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWludGFyZWEtdHVubmVscy8NCg0KDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYNCg0KDQoNCkEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2DQoNCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQoNCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KDQpmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KSW50LWFyZWEgbWFpbGluZyBsaXN0DQoNCklu dC1hcmVhQGlldGYub3JnPG1haWx0bzpJbnQtYXJlYUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0KDQo= --_000_CE03DB3D7B45C245BCA0D243277949362FA9793AMX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6Izk5MzM2Njt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPiYjNDM7MSDigJMgSSBjb25jdXIgd2l0aCBGcmVk IHRoYXQgdGhpcyBkcmFmdCBzaG91bGQgYmVjb21lIGEgQkNQLiZuYnNwOyBUaGUgY29uY2VwdCBv ZiBhIHR1bm5lbCBhcyBhIGxpbmsgaXMgZnVuZGFtZW50YWwgYW5kIHNob3VsZCBiZSBhIGZvdW5k YXRpb25hbA0KIHByaW5jaXBsZSBmb3IgaG93IHR1bm5lbHMgYXJlIGRlc2lnbmVkL3NwZWNpZmll ZC48bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzM2NiI+ VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij4gSW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5UZW1wbGluLCBGcmVkIEw8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBNYXkgMjIsIDIwMTcgMTE6MjQgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvZSBUb3VjaCAmbHQ7 dG91Y2hAaXNpLmVkdSZndDs7IGludC1hcmVhQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbSW50LWFyZWFdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLTA2 LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBKb2UsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIHJlYWQgdGhlIHdob2xlIGRvY3VtZW50LCBhbmQgSSB0aGlu ayBpcyByZWFkeSBmb3IgYWR2YW5jZW1lbnQgaW4gaXRzIGN1cnJlbnQgZm9ybTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5tb2R1bG8gdGhlIEluZm9ybWF0aW9uYWwgLSZndDsgQkNQIGRlY2lzaW9uLiBJIHN1 cHBvcnQgY2hhbmdpbmcgdGhlIGRvY3VtZW50IHRyYWNrPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZyb20g SW5mb3JtYXRpb25hbCB0byBCQ1AsIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCBtb3JlIHdv cmsgd2lsbCBiZSBuZWVkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aW4gU2VjdGlvbiA1IGlmIHRoYXQg d291bGQgYmUgdGhlIGNhc2UuIFRoYW5rcyBmb3IgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVm PSJtYWlsdG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSI+ZnJlZC5sLnRlbXBsaW5AYm9laW5n LmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSW50 LWFyZWEgWzxhIGhyZWY9Im1haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvZSBU b3VjaDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1heSAxNywgMjAxNyAyOjUxIFBNPGJy Pg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmciPmludC1hcmVh QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0ludC1hcmVhXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cD5IaSwgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHA+QSBuZXcgdmVyc2lvbiBvZiBp bnRhcmVhLXR1bm5lbHMgaGFzIGJlZW4gcG9zdGVkLCBhcyBub3RlZCBiZWxvdy48bzpwPjwvbzpw PjwvcD4NCjxwPkF0IHRoaXMgcG9pbnQsIEkgd291bGQgbGlrZSB0byBhc2sgdGhlIGNoYWlycyB0 byBzdGFydCBhIFdHIGNhbGwgdG8gY29uc2lkZXIgcmV2aXNpbmcgdGhlIGRvY3VtZW50IHRyYWNr LCBhcyBwZXIgYmVsb3cuPG86cD48L286cD48L3A+DQo8cD48Yj48dT5Tb21lIGhpc3Rvcnk6PC91 PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgZG9jdW1lbnQgYmVnYW4gYXMgYSBzZXQgb2Yg ZGlzY3Vzc2lvbnMgYXQgSUVURiA3MiBpbiBQaGlsYWRlbHBoaWEgKDIwMDgpLCB3aGVyZSBhIGZl dyBBRHMgYXBwcm9hY2hlZCB1cyB0byB0cnkgdG8gaW50ZWdyYXRlIGEgbnVtYmVyIG9mIGVtZXJn aW5nIHR1bm5lbCBlZmZvcnRzLCB3aXRoIHRoZSBhc3N1bXB0aW9uIG9mIHNpbXBseSBpbnRlZ3Jh dGluZyB0aGVtLiBUaGUgcmVzdWx0IHdhcyBhbiBhdHRlbXB0IHRvIHNpbXBseSBvcmdhbml6ZQ0K IHRoZSBsYW5kc2NhcGUgYXQgdGhlIHRpbWUuPG86cD48L286cD48L3A+DQo8cD5XZSBzdGFydGVk IHRoYXQgbGFuZHNjYXBlIGFzIGFuIElOVEFSRUEgV0cgaW5mb3JtYXRpb25hbCBkb2MgaW4gTWFy Y2ggMjAxMC4gSXQgdG9vayBmaXZlIHllYXJzIG9mIGRpc2N1c3Npb25zLCBib3RoIG9uIHRoaXMg bGlzdCBhbmQgaW4gb3RoZXIgV0dzLCB0byByZWFsaXplIHdlIG5lZWRlZCB0byBzdGFydCBieSBl eHBsYWluaW5nIG91ciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb25jZXB0IG9mIGEgdHVubmVsIGFz IGEgbGluayAoaXNzdWVzDQogaW4gMjAxNSkuIEF0IHRoYXQgcG9pbnQgd2UgcmVhbGl6ZWQgdGhh dCBtYW55IGV4aXN0aW5nIGFuZCBlbWVyZ2luZyB0dW5uZWxzIHdlcmUgaW5jb25zaXN0ZW50IHdp dGggZWFjaCBvdGhlciBhbmQgd2l0aCBleGlzdGluZyByZXF1aXJlbWVudHMuPG86cD48L286cD48 L3A+DQo8cD5XZSBjYW1lIHVwIHdpdGggYW4gYXBwcm9hY2ggd2hpY2ggd2UgYmVsaWV2ZSBpcyBi b3RoIGNvcnJlY3QgYW5kIGNvbnNpc3RlbnQgd2l0aCBleGlzdGluZyBjb3JlIEludGVybmV0IHJl cXVpcmVtZW50cywgYW5kIGhpZ2hsaWdodGVkIHdoZXJlIGl0IGRpZmZlcnMgZnJvbSBjdXJyZW50 IHR1bm5lbHMgKHN0YW5kYXJkcyB0cmFjaywgaW5mb3JtYXRpb25hbCwgb3Igb3RoZXJ3aXNlKSBp biBTZWN0aW9uIDUuIEF0IHRoaXMgcG9pbnQsIHdlIGJlbGlldmUNCiB0aGUgY29yZSBvZiB0aGlz IGRvY3VtZW50IGlzIGJvdGggc3RhYmxlIGFuZCByZXByZXNlbnRzIG5vdCBvbmx5IGEgY2xlYXIg dmlldyBvZiB0dW5uZWxzIGFzIGFuIGFyY2hpdGVjdHVyYWwgY29tcG9uZW50IG9mIHRoZSBJbnRl cm5ldCwgYnV0IGFsc28gcmVwcmVzZW50cyB0aGUgY3VycmVudCBiZXN0IHByYWN0aWNlcyByZWdh cmRpbmcgdGhlIGRlc2lnbiBhbmQgdXNlIG9mIHR1bm5lbHMuPG86cD48L286cD48L3A+DQo8cD48 Yj48dT5PdXIgcmVxdWVzdDo8L3U+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHA+QXMgYSByZXN1bHQs IHdlJ2QgbGlrZSB0byBhc2sgdGhlIGNoYWlycyB0byBpbml0aWF0ZSBhIGNhbGwgdG8gY2hhbmdl IHRoZSB0cmFjayBvZiB0aGlzIGRvY3VtZW50IGZyb20gSW5mb3JtYXRpb25hbCB0byBCQ1AuPG86 cD48L286cD48L3A+DQo8cD5UaGUgcmVzdWx0IG9mIHRoaXMgZGVjaXNpb24gd2lsbCBpbXBhY3Qg aG93IFNlY3Rpb24gNSBpcyByZXNvbHZlZC4gSWYgdGhpcyBkb2N1bWVudCBiZWNvbWVzIGEgQkNQ LCB0aGF0IHNlY3Rpb24gd2lsbCBiZSBmbGVzaGVkIG91dCBmb3IgV0cgY29uc2Vuc3VzLiBJZiB0 aGlzIGRvY3VtZW50IHJlbWFpbnMgSW5mb3JtYXRpb25hbCwgdGhlbiB0aGUgcmVjb21tZW5kYXRp b25zIGluIFNlY3Rpb24gNSBtaWdodCBub3QgYmUgYXBwcm9wcmlhdGUsDQogYW5kIHdpbGwgbGlr ZWx5IG5lZWQgdG8gYmUgb21pdHRlZCBpbiB3aG9sZSBvciBwYXJ0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9lPGJyPg0KPGJyPg0KLS0tLS0tLTxvOnA+PC9vOnA+PC9w Pg0KPHA+U3VtbWFyeSBvZiAwNiBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0gdXBkYXRlZCBFQ01QIGRpc2N1c3Npb248bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOyZuYnNwOyZuYnNwOyAtIHVwZGF0ZWQgbXVsdGlwb2ludCBkaXNjdXNzaW9uPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsgLSB1cGRhdGVkIHRlcm1pbm9sb2d5IChhdG9t IC0mZ3Q7IGF0b21pYyBwYWNrZXQpPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJz cDsgLSByZXZpc2VkIEZpZyAxMiBhbmQgRmlnIDEzIGFsZ29yaXRobXMgKGl0IHdhc24ndCBjbGVh ciB0aGF0IHRoaXMgd2FzIG91dGVyIGZyYWdtZW50YXRpb24pPG86cD48L286cD48L3A+DQo8cD4t LS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDUvMTcvMjAxNyAyOjI4IFBN LCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj4NCmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPG86cD48 L286cD48L3ByZT4NCjxwcmU+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJu ZXQgQXJlYSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IElQIFR1bm5lbHMgaW4gdGhlIEludGVybmV0IEFy Y2hpdGVjdHVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSm9lIFRvdWNoPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1hcmsgVG93bnNsZXk8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4gRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgOiBkcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNi50eHQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4gUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgOiA1MjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBEYXRlJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogMjAxNy0wNS0xNzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgcm9sZSBvZiBJUCB0dW5uZWxzIGluIHRo ZSBJbnRlcm5ldDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhcmNoaXRlY3R1 cmUuIEFuIElQIHR1bm5lbCB0cmFuc2l0cyBJUCBkYXRhZ3JhbXMgYXMgcGF5bG9hZHMgaW4gbm9u LTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBsaW5rIGxheWVyIHByb3RvY29s cy4gVGhpcyBkb2N1bWVudCBleHBsYWlucyB0aGUgcmVsYXRpb25zaGlwIG9mIElQPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHR1bm5lbHMgdG8gZXhpc3RpbmcgcHJvdG9jb2wg bGF5ZXJzIGFuZCB0aGUgY2hhbGxlbmdlcyBpbiBzdXBwb3J0aW5nPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IElQIHR1bm5lbGluZywgYmFzZWQgb24gdGhlIGVxdWl2YWxlbmNl IG9mIHR1bm5lbHMgdG8gbGlua3MuIFRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBpbXBsaWNhdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBhcmUgdXNlZCB0byBkZXJpdmUgcmVj b21tZW5kYXRpb25zIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdXBk YXRlIE1UVSBhbmQgZnJhZ21lbnQgaXNzdWVzIGluIFJGQyA0NDU5LjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzLyI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMvPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZXJlIGFyZSBh bHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pbnRhcmVh LXR1bm5lbHMtMDYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWludGFy ZWEtdHVubmVscy0wNjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxz LTA2Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaW50 YXJlYS10dW5uZWxzLTA2PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pbnRhcmVhLXR1bm5lbHMtMDYiPmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWludGFyZWEtdHVubmVscy0wNjwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286 cD48L3ByZT4NCjxwcmU+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3ByZT4NCjxwcmU+SW50LWFyZWEgbWFpbGluZyBsaXN0PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOkludC1hcmVhQGlldGYub3JnIj5JbnQtYXJl YUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D243277949362FA9793AMX307CL04corpem_-- From nobody Mon May 22 15:55:12 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674B7129409; Mon, 22 May 2017 15:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 Sr9W_mLTQw-1; Mon, 22 May 2017 15:55:08 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-oln040092065054.outbound.protection.outlook.com [40.92.65.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DF81293EC; Mon, 22 May 2017 15:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fo/Tj07ESbQ/wv8abMIV6piJ4j+FlLcICaG61ZP293Q=; b=srSlMcmBSyTaoSZ6lgdQ8nXBDmKDqG7kBrD1reqaW8u2OogaLovNg4VdYfQTFMxXaZtly3MwxEnIYBwYvWc9tirEnJlupS5Lqu9jgPP4/Wr25tI4xta+w5qEkPjMxRyTSe3av11VoRp60dXVKQ3foHTHAXCPcM2TzWj8zTYvG9Y6KbjsBN17kQ4CAEN5YTITfKQrb3UJsKpWl43K0rbb3qzMaUkQIIhe8c6qcBV4cBHMV1eCYqhizDOMJR6R0LvSVAr/VgIY36uW6r6+cCluXTJSWZZpWH2vg7RSFnlEFCq/aLBhZLvUPScly81esWOQRMVyb2VR7kKXdJ+F+k7oFA== Received: from HE1EUR01FT052.eop-EUR01.prod.protection.outlook.com (10.152.0.56) by HE1EUR01HT049.eop-EUR01.prod.protection.outlook.com (10.152.0.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Mon, 22 May 2017 22:55:03 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.0.60) by HE1EUR01FT052.mail.protection.outlook.com (10.152.1.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Mon, 22 May 2017 22:55:02 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::a819:bed0:ee53:c0c3]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::a819:bed0:ee53:c0c3%18]) with mapi id 15.01.1101.019; Mon, 22 May 2017 22:55:02 +0000 From: Khaled Omar To: "ietf-draft-submission@ietf.org" CC: "int-area@ietf.org" , "ietf@ietf.org" , "intarea-ads@ietf.org" , "intarea-chairs@ietf.org" , IETF Chair Thread-Topic: IPv10, KRP, and RRP IDs Removal. Thread-Index: AdLTTNVDoZlTmip5SbKkUmpfy2efXw== Date: Mon, 22 May 2017 22:55:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:3F7AD9629AABC4BAB96DF11CFE7C94F5C89229B18171566CA0BB2BC033C2B488; UpperCasedChecksum:1806E559115941986D4C3F86EA049597C21EBEA61DA4501CD31D8F64AA18A130; SizeAsReceived:8306; Count:43 x-tmn: [rnuJQE62ZtMebF+vxoUJbY73yaLkxIIB] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR01HT049; 5:w2zJDy+85Ra3LGw7qBRSKptMIGNHOk34wcfphYCzaVBQua0Jf21ZA9gShnRtA5akeicGr2olxZ397ZDpfc1PvsN2vPldQTFYz2wZztMHtUKppKv1Qer2RQay71K7EGnnqBT1VPuNrja4cZGlVnJoIw==; 24:wfts/Dg9A/0m133+ooGOeO+RHWQvHNSdpEHCVqZKfUQ1dM4d2W+e94Lhg0hw1l1KMlBDShNbUTuX3AmUi4G2sOYG4iraS6m1hNDkyYPwNqA=; 7:Yh1HGOQCabKCG5whyp3jWjup8ny93sp/iow2Yp0nBlwFxV7bdTJipgaNuZJ5CEO7xwhU/r0r+3msyxIbkXid4OaHrZYg9d6hMCPol3OukvTnXNJX91+DR3c2t9pPI1rssue4qOAg9RNPn08FAmhpqRJzv1sL/cxI71KRLZXPeUic34P1RYqHJSgwM78IrlVrYEwSWWZA2Q+jzVnJqSmHmEBU4eySpF/hwzh5bJG7iSvozIvsXUQoiA3OOKRFXOcRGulVxneziAprSniVB8isuoZxORxEYzTih65mzvERdzrJY+SlhysShAycNVQb+YWZ x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR01HT049; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 67667bbe-14a2-4822-fc3f-08d4a16594f0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:HE1EUR01HT049; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HE1EUR01HT049; BCL:0; PCL:0; RULEID:; SRVR:HE1EUR01HT049; x-forefront-prvs: 03152A99FF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB2241731801FD7F70B2DD246FBDF80AM4PR0401MB2241_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 22:55:02.7681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT049 Archived-At: Subject: [Int-area] IPv10, KRP, and RRP IDs Removal. X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 22:55:10 -0000 --_000_AM4PR0401MB2241731801FD7F70B2DD246FBDF80AM4PR0401MB2241_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jasmine, As I'm the only author of the following IDs: 1) Internet Protocol version 10 (IPv10): https://datatracker.ietf.org/= doc/draft-omar-ipv10/ 2) KHALED Routing Protocol (KRP): https://datatracker.ietf.org/doc/dra= ft-omar-krp/ 3) Regional Routing Protocol (RRP): https://datatracker.ietf.org/doc/d= raft-omar-rrp/ Please remove them all from the ietf database or repository. If the ideas explained on these drafts will be used, discussed or published= by the ietf, legal actions will be taken. Regards, Khaled Omar --_000_AM4PR0401MB2241731801FD7F70B2DD246FBDF80AM4PR0401MB2241_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jasmine,

 

As I’m the only author of the following IDs:

 

1)      Internet Protocol version = 10 (IPv10): https://data= tracker.ietf.org/doc/draft-omar-ipv10/

 

2)      KHALED Routing Protocol (K= RP): https://datatracker.ietf.org/doc/draft-omar-krp/

 

3)      Regional Routing Protocol = (RRP): https://datatracker.ietf.org/doc/draft-omar-rrp/

 

 

Please remove them all from the ietf database or rep= ository.

 

If the ideas explained on these drafts will be used,= discussed or published by the ietf, legal actions will be taken.

 

Regards,

 

Khaled Omar   

--_000_AM4PR0401MB2241731801FD7F70B2DD246FBDF80AM4PR0401MB2241_-- From nobody Mon May 22 16:29:50 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB11129473; Mon, 22 May 2017 16:29:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149549578857.21441.7947575401937604803.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 16:29:48 -0700 Archived-At: Subject: [Int-area] The INTAREA WG has placed draft-bonica-intarea-eping in state "Adopted by a WG" X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 23:29:49 -0000 The INTAREA WG has placed draft-bonica-intarea-eping in state Adopted by a WG (entered by Wassim Haddad) The document is available at https://datatracker.ietf.org/doc/draft-bonica-intarea-eping/ From nobody Mon May 22 19:50:16 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C9E1294A1 for ; Mon, 22 May 2017 19:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 faTFjkvsV2WK for ; Mon, 22 May 2017 19:50:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BC3129469 for ; Mon, 22 May 2017 19:50:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHC89065; Tue, 23 May 2017 02:50:10 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 03:50:09 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 23 May 2017 10:49:48 +0800 From: Xuxiaohu To: Tom Herbert CC: Joe Touch , "int-area@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IFtJbnQtYXJlYV0g562U5aSNOiBJcyB0aGUgVURQ?= =?utf-8?B?IGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcgb3V0?= =?utf-8?B?Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0?= =?utf-8?Q?.txt?= Thread-Index: AQHS0RsMnyvO0qVuZEOz5xejzfeIJKH8l23w//9/jYCAAKQ8oIAAIOaAgARdqYA= Date: Tue, 23 May 2017 02:49:47 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5923A363.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 84c208743e9e7b5acb6473db37136984 Archived-At: Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlOWkjTog?= =?utf-8?q?Is_the_UDP_destination_port_number_resource_running_out=3F//_re?= =?utf-8?q?=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 02:50:15 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IFRvbSBIZXJiZXJ0IFtt YWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0NeaciDIx 5pelIDA6MDENCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IEpvZSBUb3VjaDsgaW50 LWFyZWFAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTog562U5aSNOiDnrZTlpI06IFtJbnQtYXJlYV0g 562U5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyDQo+IHJlc291cmNlIHJ1 bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4 dA0KPiANCj4gT24gRnJpLCBNYXkgMTksIDIwMTcgYXQgMTE6MDkgUE0sIFh1eGlhb2h1IDx4dXhp YW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCj4gPj4g5Y+R5Lu25Lq6OiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0K PiA+PiDlj5HpgIHml7bpl7Q6IDIwMTflubQ15pyIMjDml6UgMTI6MTUNCj4gPj4g5pS25Lu25Lq6 OiBYdXhpYW9odTsgVG9tIEhlcmJlcnQNCj4gPj4g5oqE6YCBOiBpbnQtYXJlYUBpZXRmLm9yZw0K PiA+PiDkuLvpopg6IFJlOiDnrZTlpI06IFtJbnQtYXJlYV0g562U5aSNOiBJcyB0aGUgVURQIGRl c3RpbmF0aW9uIHBvcnQgbnVtYmVyDQo+ID4+IHJlc291cmNlIHJ1bm5pbmcgb3V0Py8vIHJlOiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4dA0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiBPbiA1LzE5LzIwMTcgODo1NyBQTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4+ID4gSGkg Sm9lLA0KPiA+PiA+DQo+ID4+ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPj4gPj4g5Y+R 5Lu25Lq6OiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiA+PiA+PiDlj5HpgIHm l7bpl7Q6IDIwMTflubQ15pyIMjDml6UgMTE6NDENCj4gPj4gPj4g5pS25Lu25Lq6OiBYdXhpYW9o dTsgVG9tIEhlcmJlcnQNCj4gPj4gPj4g5oqE6YCBOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiA+PiA+ PiDkuLvpopg6IFJlOiBbSW50LWFyZWFdIOetlOWkjTogSXMgdGhlIFVEUCBkZXN0aW5hdGlvbiBw b3J0IG51bWJlciByZXNvdXJjZQ0KPiA+PiA+PiBydW5uaW5nIG91dD8vLyByZTogSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNC50eHQNCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4g Pj4NCj4gPj4gPj4gT24gNS8xOS8yMDE3IDY6MzkgUE0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+PiA+ Pj4gSWYgdGhlIHNhdmluZyBpcyBiZW5lZmljaWFsLCBpdCdkIGJldHRlciB0byBhc3NpZ24gYSBk ZWRpY2F0ZWQNCj4gPj4gPj4+IHBvcnQgbnVtYmVyIGZvciBlYWNoIFVEUCBwYXlsb2FkIHR5cGUo IGUuZy4sIElQIHBhY2tldCksIHJhdGhlcg0KPiA+PiA+Pj4gdGhhbiBjb21iaW5pbmcgdGhlIFVE UCBwb3J0IG51bWJlciBkZWRpY2F0ZWQgZm9yIEdVRSBhbmQgdGhlDQo+ID4+ID4+PiB2ZXJzaW9u IGZpZWxkIHdpdGhpbiB0aGUgR1VFIGhlYWRlciB0b2dldGhlciB0byBpbmRpY2F0ZSB3aGV0aGVy DQo+ID4+ID4+PiB0aGUgVURQIHBheWxvYWQgaXMgR1VFIG9yIElQIChvciBldmVuIG90aGVyIHBh eWxvYWQgdHlwZSBpZiB0aGUNCj4gPj4gPj4+IEdVRSBpcyBkZXZvdGVkIHRvIGhlbHAgc2F2ZSB0 aGUgVURQIHBvcnQgbnVtYmVyIHJlc291cmNlIGZvciB0aGUNCj4gPj4gPj4+IElFVEYNCj4gPj4g Pj4+IGNvbW11bml0eTopKQ0KPiA+PiA+PiBGV0lXLCBJQU5BIHN0cml2ZXMgdG8gYXNzaWduIG9u ZSBwb3J0IGZvciBhIHNlcnZpY2UuDQo+ID4+ID4gR3JlYXQuIEhlbmNlIElQdnggc2hvdWxkIGJl IHRha2VuIGFzIGEgc2VydmljZSByYXRoZXIgdGhhbiB0YWtpbmcNCj4gPj4gPiBJUHZ4IGFuZA0K PiA+PiBHVUUgYXMgYSBzZXJ2aWNlLCBJTU8uDQo+ID4+IEdVRSBpcyBzdXBwb3NlZCB0byBiZSBi b3RoIHNpZ25hbGxpbmcgYW5kIGNvbnRlbnQgKGRhdGEpLCB3aGVyZSB0aGUNCj4gPj4gZGF0YSBh cmUgSVAgcGFja2V0cy4NCj4gPg0KPiA+IFNpbmNlIElBTkEgc3RyaXZlcyB0byBhc3NpZ24gb25l IHBvcnQgZm9yIGEgc2VydmljZSwgSVAgcGFja2V0IHdpdGhpbiB0aGUgVURQDQo+IHR1bm5lbCBz aG91bGQgYmUgYXNzaWduZWQgYSBkZWRpY2F0ZWQgcG9ydC4gSW4gb3RoZXIgd29yZHMsIEdVRSBh bmQgSVAtaW4tVURQDQo+IGFyZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZSBkaWZmZXJlbnQgcG9ydCBu dW1iZXJzLg0KPiA+DQo+ID4+IFRha2UgYXdheSB0aGUgSVAgcGFydCBhbmQgR1VFIGlzbid0IGFu IEUgYW55bW9yZS4NCj4gPj4gPj4gU2VydmljZXMgYXJlIGV4cGVjdGVkIHRvIGhhdmUgdmVyc2lv biBmaWVsZHMgYW5kIHN1YnR5cGUNCj4gPj4gPj4gZGVtdWx0aXBsZXhpbmcgaW5kaWNhdG9ycywg dG8gc28gdGhhdCBhbGwgbWVzc2FnZSB2YXJpYW50cyBvZg0KPiA+PiA+PiBjdXJyZW50IGFuZCBm dXR1cmUgdmVyc2lvbnMgY2FuIHVzZSBhIHNpbmdsZSBwb3J0IG51bWJlci4NCj4gPj4gPiBTdXJl LCB0aGUgdmVyc2lvbiBmaWVsZCB3aXRoaW4gdGhlIElQdnggcGFja2V0IGNvdWxkIGJlIHVzZWQg Zm9yDQo+ID4+ID4gZGVtdWx0aXBsZXhpbmcNCj4gPj4gcHVycG9zZS4NCj4gPj4NCj4gPj4gVGhh dCBkZW11bHRpcGxleGVzIHdpdGhpbiBJUHZ4LiBUaGVyZSBzdGlsbCBuZWVkcyB0byBiZSBhIHdh eSB0bw0KPiA+PiBkZW11bHRpcGxleCBub24tSVB2eCBwYWNrZXRzIChjb250cm9sKSBmcm9tIElQ dnguDQo+ID4NCj4gPiBTaW5jZSBHVUUgYW5kIElQLWluLVVEUCBoYXZlIGRpZmZlcmVudCBVRFAg cG9ydCBudW1iZXJzLCBJIGRvbid0IGtub3cgd2h5DQo+IHRoZXJlIGlzIHN0aWxsIGEgbmVlZCB0 byBkZW11bHRpcGxleCBHVUUgYW5kIElQLWluLVVEUC4NCj4gPg0KPiBJdCdzIGhlYWRlciBjb21w cmVzc2lvbi4gQ29uc2lkZXIgYSBzY2VuYXJpbyB0aGF0IEdVRSBpcyB0dW5uZWxpbmcNCj4gSVB2 NiBhbmQgSVB2NCBhbmQgd2lsbCBkbyBHVUUgZnJhZ21lbnRhdGlvbiBpZiBuZWNlc3Nhcnkgb24g dHVubmVsIGluZ3Jlc3MuDQo+IFNvIHNvbWUgcGFja2V0cyB3aWxsIGhhdmUgYSBmcmFnbWVudGF0 aW9uIG9wdGlvbiBhbmQgc29tZSB3b24ndC4gRm9yDQo+IHVuZnJhZ21lbnRlZCBwYWNrZXRzIHdp dGggbm8gR1VFIG9wdGlvbnMsIHRoZXkgY2FuIGJlIHNlbnQgaW4gZGlyZWN0DQo+IGVuY2Fwc3Vs YXRpb24gb2YgSVAuIFRoaXMgY291bGQgYmUgZG9uZSBhcyB2ZXJzaW9uIDEgb2YgR1VFIG9yIGlu IElQLWluLVVEUCBhcw0KPiB5b3UncmUgc3VnZ2VzdGluZy4gVGhlIHByb2JsZW0gd2l0aCB0aGUg bGF0dGVyIGlzIHRoYXQgaXQgZG91YmxlcyB0aGUgbnVtYmVyIG9mDQo+IGZsb3dzIGluIHRoZSBu ZXR3b3JrLiBTbyBpbnN0ZWFkIG9mIHB1bmNoaW5nIG9uZSBob2xlIGZvciBhIHR1bm5lbCBpbiBh IGZpcmV3YWxsDQo+IHdlIG5lZWQgdHdvICh0aGUgZnJhZ21lbnQgdHVubmVsIGFuZCBub24tZnJh Z21lbnQgVURQIHBvcnRzKS4gUGFja2V0cyBpbg0KPiBpbmRpdmlkdWFsIGZsb3dzIG5vdyBjYW4g dGFrZSBkaWZmZXJlbnQgcGF0aHMgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhleSdyZQ0KPiBmcmFn bWVudGVkIHNvIHRoaXMgaW50cm9kdWNlcyBPT08uDQoNClNpbmNlIEdVRSBpcyBpbnRlbmRlZCB0 byBiZSBhIGdlbmVyaWMgVURQIGVuY2Fwc3VsYXRpb24sIG5vdyBsZXQncyBhc3N1bWUgR1VFIGlz IHR1bm5lbGluZyBNUExTLCBOU0ggb3IgQklFUi4gUGxlYXNlIGNvbnRpbnVlIHlvdXIgcmF0aW9u YWxlIG9uY2UgdGhvc2UgZW5jYXBzdWxhdGlvbnMgaGF2ZSB0aGUgc2FtZSByZXF1aXJlbWVudCBv ZiBzYXZpbmcgdGhlIDQtYnl0ZSBHVUUgYmFzZSBoZWFkZXIgb3ZlcmhlYWQgYXMgdGhlIGVuY2Fw c3VsYXRpb24gb2YgSVAgaW4gVURQLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBUb20N Cj4gDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gSm9lDQo= From nobody Mon May 22 20:22:54 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FCF1243F6; Mon, 22 May 2017 20:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 WkExxx5NyXpC; Mon, 22 May 2017 20:22:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5057B12945F; Mon, 22 May 2017 20:22:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHC92819; Tue, 23 May 2017 03:22:41 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 04:22:40 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 23 May 2017 11:22:34 +0800 From: Xuxiaohu To: Tom Herbert CC: "int-area@ietf.org" , NVO3 Thread-Topic: =?utf-8?B?562U5aSNOiBbSW50LWFyZWFdIElzIHRoZSBVRFAgZGVzdGluYXRpb24gcG9y?= =?utf-8?B?dCBudW1iZXIgcmVzb3VyY2UgcnVubmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rp?= =?utf-8?Q?on:_draft-ietf-intarea-gue-04.txt?= Thread-Index: AQHS0LAkIpK7xvXSTE61Lupl2EaWeKH8YR4AgAB3sYCABGRxEA== Date: Tue, 23 May 2017 03:22:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA9611@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5923AB01.00D8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 219c63f8e912a9e53a52b6c773dbe067 Archived-At: Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJcyB0aGUgVURQIGRlc3Rp?= =?utf-8?q?nation_port_number_resource_running_out=3F//_re=3A_I-D_Action?= =?utf-8?q?=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 03:22:46 -0000 SGkgVG9tLCANCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogVG9tIEhl cmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTfl ubQ15pyIMjDml6UgMjM6NDYNCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IGludC1h cmVhQGlldGYub3JnDQo+IOS4u+mimDogUmU6IOetlOWkjTogW0ludC1hcmVhXSBJcyB0aGUgVURQ IGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcNCj4gb3V0Py8vIHJlOiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0LnR4dA0KPiANCj4gT24gRnJpLCBN YXkgMTksIDIwMTcgYXQgNjozOSBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdy b3RlOg0KPiA+IEhpIFRvbSwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgeW91ciBxdWljayByZXNwb25z ZS4gUGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUuDQo+ID4NCj4gPj4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KPiA+PiDlj5Hku7bkuro6IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRs YW5kLmNvbV0NCj4gPj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0NeaciDE55pelIDIyOjU3DQo+ID4+ IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4gPj4g5oqE6YCBOiBpbnQtYXJlYUBpZXRmLm9yZw0KPiA+ PiDkuLvpopg6IFJlOiBbSW50LWFyZWFdIElzIHRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1i ZXIgcmVzb3VyY2UNCj4gPj4gcnVubmluZyBvdXQ/Ly8NCj4gPj4gcmU6IEktRCBBY3Rpb246IGRy YWZ0LWlldGYtaW50YXJlYS1ndWUtMDQudHh0DQo+ID4+DQo+ID4+IEhpIFh1eGlhb2h1LA0KPiA+ Pg0KPiA+PiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gU29tZSByZXNwb25zZSBhcmUgaW5saW5l Lg0KPiA+Pg0KPiA+PiBPbiBUaHUsIE1heSAxOCwgMjAxNyBhdCA3OjUzIFBNLCBYdXhpYW9odSA8 eHV4aWFvaHVAaHVhd2VpLmNvbT4NCj4gd3JvdGU6DQo+ID4+ID4gSGkgYWxsLA0KPiA+PiA+DQo+ ID4+ID4gV2l0aCByZWdhcmQgdG8gZGlyZWN0bHkgZW5jYXBzdWxhdGluZyBJUHZ4IHBhY2tldCBp biBVRFAsIEkgdGhpbmsNCj4gPj4gPiB0aGUgZm9sbG93aW5nDQo+ID4+IGFyZ3VtZW50IGZvciB1 c2luZyBWZXJzaW9uIDEgb2YgR1VFIGlzIG5vdCB2YWxpZDoNCj4gPj4gPg0KPiA+PiA+ICJUaGlz IHRlY2huaXF1ZSBzYXZlcyBlbmNhcHN1bGF0aW9uIG92ZXJoZWFkIG9uIGNvc3RseSBsaW5rcw0K PiA+PiA+ICAgIGZvciB0aGUgY29tbW9uIHVzZSBvZiBJUCBlbmNhcHN1bGF0aW9uLCBhbmQgYWxz byBvYnZpYXRlcyB0aGUgbmVlZCB0bw0KPiA+PiA+ICAgIGFsbG9jYXRlIGEgc2VwYXJhdGUgcG9y dCBudW1iZXIgZm9yIElQLW92ZXItVURQIGVuY2Fwc3VsYXRpb24uIg0KPiA+PiA+DQo+ID4+ID4g Rmlyc3QsIEkgZG9uJ3QgdGhpbmsgdGhlIGVuY2Fwc3VsYXRpb24gb3ZlcmhlYWQgb2YgNCBieXRl cyBpcyBhIG1hdHRlci4NCj4gPj4NCj4gPj4gSSdtIG5vdCBzdXJlIGV2ZXJ5b25lIHdvdWxkIGFn cmVlIHdpdGggdGhhdC4gVGhlIGNhc2Ugd2FzIG1hZGUgd2hlbg0KPiA+PiB3ZSB3ZXJlIGRpc2N1 c3NpbmcgaXQgdGhhdCB0aGUgc2F2aW5ncyB3b3VsZCBiZSBiZW5lZmljaWFsIGZvciBzb21lDQo+ IGRlcGxveW1lbnRzLg0KPiA+DQo+ID4gSWYgdGhlIHNhdmluZyBpcyBiZW5lZmljaWFsLCBpdCdk IGJldHRlciB0byBhc3NpZ24gYSBkZWRpY2F0ZWQgcG9ydA0KPiA+IG51bWJlciBmb3IgZWFjaCBV RFAgcGF5bG9hZCB0eXBlKCBlLmcuLCBJUCBwYWNrZXQpLCByYXRoZXIgdGhhbg0KPiA+IGNvbWJp bmluZyB0aGUgVURQIHBvcnQgbnVtYmVyIGRlZGljYXRlZCBmb3IgR1VFIGFuZCB0aGUgdmVyc2lv biBmaWVsZA0KPiA+IHdpdGhpbiB0aGUgR1VFIGhlYWRlciB0b2dldGhlciB0byBpbmRpY2F0ZSB3 aGV0aGVyIHRoZSBVRFAgcGF5bG9hZCBpcw0KPiA+IEdVRSBvciBJUCAob3IgZXZlbiBvdGhlciBw YXlsb2FkIHR5cGUgaWYgdGhlIEdVRSBpcyBkZXZvdGVkIHRvIGhlbHANCj4gPiBzYXZlIHRoZSBV RFAgcG9ydCBudW1iZXIgcmVzb3VyY2UgZm9yIHRoZSBJRVRGIGNvbW11bml0eTopKQ0KPiANCj4g WHV4aWFvaHUsDQo+IA0KPiBXZSBoYXZlIGFscmVhZHkgaW1wbGVtZW50ZWQgdGhlIGZhY2lsaXR5 IHRvIGRpcmVjdGx5IGVuY2Fwc3VsYXRlIGFuIElQIHByb3RvY29sDQo+IGRpcmVjdGx5IGluIFVE UC4gVGhpcyBpcyBGT1Utb3Zlci1VRFAgKEZPVSkgYW5kIGluIGZhY3QgR1JFLWluLVVEUCBpcyBq dXN0IG9uZQ0KPiBzdWIgY2FzZSBvZiB0aGUgaW1wbGVtZW50YXRpb24uIEkga25vdyBwZW9wbGUg YXJlIHVzaW5nIEZPVSBmb3IgdmFyaW91cw0KPiBwcm90b2NvbHMgaW4gdGhlaXIgbmV0d29ya3Ms IGhvd2V2ZXIgSSBkb3VidCB3ZSBnZXQgdmVyeSBmYXIgaWYgd2UgcmVxdWVzdGVkDQo+IDI1NiBw b3J0cyB0byBkaXJlY3RseSBlbmNhcHN1bGF0ZSBlYWNoIElQIHByb3RvY29sISBJdCBtaWdodCBt YWtlIHNlbnNlIHRvDQo+IGRvY3VtZW50IEZPVSBhcyBpbmZvcm1hdGlvbmFsLg0KDQpUaGVyZSBo YWQgYmVlbiBhIEZvby1vdmVyLVVEUCBkcmFmdCAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC15b25nLXRzdndnLXVkcC1lbmNhcC00LWlwLXR1bm5lbGluZy0wMSkuIEhvd2V2 ZXIsIHRoZSByZWFsaXR5IGlzIHRoYXQgZGlmZmVyZW50IEZvbydzIGFyZSBzcGVjaWZpZWQgaW4g ZGVkaWNhdGVkIGRyYWZ0cyBzaW5jZSBtYW55IGZvby1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucyBu ZWVkIHRvIGJlIHNwZWNpZmllZC4NCg0KPiA+DQo+ID4gQlRXLCB3aGF0IGhhcHBlbnMgaWYgYW55 IG90aGVyIEdVRSBwYXlsb2FkIGhhcyB0aGUgc2FtZSBkZXNpcmUgb2Ygc2F2aW5nDQo+IHRoZSA0 IGJ5dGUgR1VFIGhlYWRlciBvdmVyaGVhZD8NCj4gDQo+IFRoZSBvbmx5IG90aGVyIGNhbmRpZGF0 ZSBiZXlvbmQgSVB2NCBhbmQgSVB2NiB0aGF0IGhhcyBiZWVuIHN1Z2dlc3RlZCBpcw0KPiBFdGhl cm5ldCB3aGljaCB3b3VsZCBiZSBFdGhlcklQLiBUaGF0IGlzIHByZXR0eSBmZWFzaWJsZSB0byBz dXBwb3J0IGlmIHRoZXJlIGlzDQo+IGVub3VnaCBkZXNpcmUuDQoNCkNvdWxkIHlvdSBleHBsYWlu IGhvdyB0byBzdXBwb3J0IHRoZSBlbmNhcHN1bGF0aW9uIG9mIEV0aGVybmV0IHdpdGhvdXQgdGhl IDQtb2N0ZWN0IG92ZXJoZWFkPyBCeSB0aGUgd2F5LCB3aHkgRXRoZXJuZXQgaXMgdGhlIG9ubHkg b3RoZXIgY2FuZGlkYXRlIHNpbmNlIEdVRSBpcyBjbGFpbWVkIHRvIGJlIGdlbmVyaWM/DQoNCj4g Pg0KPiA+PiA+IEhvd2V2ZXIsIHRoZSBwcmVtaXNlIGlzIHRoYXQgaXQncyBtZWFuaW5nZnVsIGZv ciB0aGUgSUVURiB0bw0KPiA+PiA+IGRldmVsb3Agc3VjaCBhIEdFTkVSSUMgYW5kIENPVkVSQUxM IGVuY2Fwc3VsYXRpb24gbWV0aG9kIHdoaWNoIGlzDQo+ID4+ID4gc3RpbGwgbG9va2luZyBmb3Ig bmFpbHM6KQ0KPiA+Pg0KPiA+PiBUaGUgcHJvdG9jb2wgaXMgY2FsbGVkICpHZW5lcmljKiBVRFAg RW5jYXBzdWxhdGlvbiBmb3IgcmVhc29uLg0KPiA+DQo+ID4gSSBrbm93IHRoYXQgeW91IGFyZSB0 cnlpbmcgdG8gc3BlY2lmeSBhIGdlbmVyaWMgVURQIGVuY2Fwc3VsYXRpb24uIEhvd2V2ZXIsDQo+ IHRoZXJlIGhhcyBiZWVuIGEgZ2VuZXJpYyBVRFAgZW5jYXBzdWxhdGlvbiBzY2hlbWUgdGhhdCBp cyBHUkUtaW4tVURQDQo+IFtSRkM4MDg2XS4gRnVydGhlcm1vcmUsIHRoZXJlIGlzIGFub3RoZXIg Z2VuZXJpYyBVRFAgZW5jYXBzdWxhdGlvbiBzY2hlbWUNCj4gY2FsbGVkIEdFTkVWRSB0aGF0IHRo ZSBOVk8zIGdyb3VwIGlzIHdvcmtpbmcgb24uIEl0J3MgYmV0dGVyIGZvciB0aGUgSUVURg0KPiBj b21tdW5pdHkgdG8gYXZvaWQgc3BlY2lmeWluZyBtdWx0aXBsZSBzaW1pbGFyIGVuY2Fwc3VsYXRp b24gc2NoZW1lcyBhbmQNCj4gdGhlcmVmb3JlIHRoZSBOVm8zIFdHIGNvLWNoYWlycyBhbmQgdGhl IGNvcnJlc3BvbmRpbmcgQUQgdHJ5IHRoZWlyIGJlc3QgdG8NCj4gcmVhY2ggYSBjb25zZW5zdXMg b2Ygd29ya2luZyB0b2dldGhlciBvbiBhIHNpbmdsZSBlbmNhcHN1bGF0aW9uIG9uIHRoZSBiYXNp cyBvZg0KPiBHRU5FVkUgYW1vbmcgdGhlIFdHIG1lbWJlcnMuIERvIHlvdSBzdGlsbCBiZWxpZXZl IGl0J3MgaGVscGZ1bCBmb3IgdGhlDQo+IGluZHVzdHJ5IHRvIHNwZWNpZnkgb25lIGFkZGl0aW9u YWwgZ2VuZXJpYyBlbmNhcHN1bGF0aW9uIHNjaGVtZSBpbiBhbm90aGVyIElFVEYNCj4gV0c/DQo+ ID4NCj4gWWVzLiBUaGUgcmVhc29uIHdlIG5lZWRlZCB0byBkZWZpbmUgR1VFIGlzIHRoYXQgbm8g b3RoZXIgZW5jYXBzdWxhdGlvbg0KPiBwcm90b2NvbCBzYXRpc2ZpZXMgdGhlIHJlcXVpcmVtZW50 cy4gR1JFIGNvbWVzIGNsb3NlLCBhbmQgaW4gZmFjdCBHVUUgaXMgYmFzZWQNCj4gb24gR1JFLiBX ZSBsb3ZlIEdSRSBmb3IgdGhlIGRhdGFjZW50ZXIuIEl0J3MgZ2VuZXJpYywgZXh0ZW5zaWJsZSwg c2ltcGxlLA0KPiBmbGFnLWZpZWxkcyBhcmUgc3VwZXIgZWZmaWNpZW50LCBhbmQgYWxsIGhhcmR3 YXJlIHdlIHRlc3RlZCB3b3JrcyB3ZWxsIHdpdGggaXQuIFRoZQ0KPiBkb3duc2lkZSBvZiBHUkUg aXMgdGhhdCBpdCdzIGV4dGVuc2liaWxpdHkgaXMgcXVpdGUgbGltaXRlZDsgd2UgY2FuIG9ubHkg Z2V0IDEyDQo+IGJ5dGVzIGZvciBmaWVsZHMuDQo+IFRoYXQncyBqdXN0IG5vdCBlbm91Z2guIFRo ZSBwYXJ0aWN1bGFyIG5lZWQgd2UgaGFkIHdhcyB0byBhZGQgc2VjdXJpdHkgdG8NCj4gYXV0aGVu dGljYXRlIHRoZSBoZWFkZXIuIFdlIGFjdHVhbGx5IHdlJ3JlIGFibGUgdG8gImZpbmQiIDY0IGJp dHMgb2YgaW4gdGhlIGZpZWxkcw0KPiBieSBvdmVybG9hZGluZyBjaGVja3N1bSBhbmQgc2VxdWVu Y2UgbnVtYmVyLCBidXQgdGhhdCBpcyByZWFsbHkgbm90IGVub3VnaA0KPiBmb3Igc2VjdXJpdHku IEJlc2lkZXMgdGhhdCwgdGhlcmUgYXJlIG90aGVyIG5lZWRzIGZvciBleHRlbnNpYmlsaXR5IGxp a2UNCj4gZnJhZ21lbnRhdGlvbiwgY2hlY2tzdW0sIHBheWxvYWQgdHJhbnNmb3JtLg0KPiBXZSds bCBvbmx5IGV2ZXIgbmVlZCBhIGhhbmRmdWwgb2Ygc3VjaCBleHRlbnNpb25zLCBidXQgaXQncyBt b3JlIHRoYW4gY2FuIGJlIGZpdA0KPiBpbnRvIEdSRS4gU28gR1VFIGlzIGFuIGFuc3dlci4gSXQg aGFzIHRoZSBzYW1lIGVmZmljaWVuY3kgb2YgR1JFIGJ1dCBpcyBtb3JlDQo+IGV4dGVuc2libGUu IFNpbmNlIGl0IGlzIGEgbmV3IHByb3RvY29sIHdlIGFyZSBhYmxlIHRvIGFkZCBhIGZldyBvdGhl ciBuaWNlIHRvIGhhdmUNCj4gZmVhdHVyZXMgbGlrZSBoZWFkZXIgbGVuZ3RoLCBlbmNhcCBieSBJ UCBwcm90b2NvbCwgYW5kIHByaXZhdGUgZGF0YSBibG9jay4gU2VjdGlvbg0KPiA2IGluIHRoZSBk cmFmdCBnaXZlcyBhIG1vdGl2YXRpb24gZm9yIEdVRS4NCg0KSWYgR1JFLWluLVVEUCBpcyBub3Qg ZW5vdWdoLCB3aGF0IGFib3V0IEdFTkVWRT8gKGNjZWQgdG8gTlZPMykNCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gVG9tDQo= From nobody Tue May 23 09:17:23 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A79129BAD for ; Tue, 23 May 2017 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 A91IKcKqngkc for ; Tue, 23 May 2017 09:17:21 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 2C080126BF0 for ; Tue, 23 May 2017 09:17:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NGHJw5026718; Tue, 23 May 2017 09:17:19 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NGH8Pw026086 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 09:17:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 09:17:07 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 09:17:07 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" , Joe Touch Thread-Topic: IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuA== Date: Tue, 23 May 2017 16:17:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 16:17:23 -0000 Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation ha= s problems because of the 16-bit ID field. So, why not insert an IPv6 Fragmen= t Header between the IPv4 header and the upper layer protocol data, then use IPv6-style fragmentation instead of IPv4 fragmentation? So, the IPv4 Protocol field would be set to '44', the IPv4 header would be followed by an IPv6 Fragment Header, and the "Next Header" field in the IPv6 Fragment Header would be set to the Protocol Number for the upper layer protocol. Then, upon fragmentation, each fragment would have an IPv4 header followed by an IPv6 Fragment Header. This format is shown in Figure 6 in Appendix A of the AERO draft: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Does this look like something that should be broken out and put into a little standalone document? Thanks - Fred From nobody Tue May 23 10:38:17 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67426129C46 for ; Tue, 23 May 2017 10:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 kHiwY0ONy4C9 for ; Tue, 23 May 2017 10:38:13 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BB32B129C43 for ; Tue, 23 May 2017 10:38:13 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id a72so135881124qkj.2 for ; Tue, 23 May 2017 10:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NM1OrlLfejBoQR6CP+rV6ljLnnNbUZ9ASk9aYmhMxdo=; b=xHKlOSZqqLqiBFRDpDBmkbrKHqVANS8qxFqMjzmfiltCDd3DgT+idhpzHDUYYqGbw0 fYJB2vn687J/R2xSEmCxdc/B+OiwrKF6eh0zbVueh4kaILCfzIt8B9xzvRfMq2z1fRjI 0rS/aNJUDGuCFns+9Hso81S4M39VLj6XyC01wyG9DLlSkaRDn9BTeZChuOvrk71fUeap Glw0buHEPDx6S5luiBkwWLWUg6adxB6TYg8PLfeiswI5f+59QxwMhgprBRjRcZWUYC3m m8rJymWBvH/6Y1PspKwwGfQnZzj5SEu6YvMbP+W/Cv5dGBxt+i8V6YGXSZqRiu3zpcIP wzXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NM1OrlLfejBoQR6CP+rV6ljLnnNbUZ9ASk9aYmhMxdo=; b=Rzwk8iqOVJXQsjoCKm82degqsMqbjOXN8Wf/4a5qTZZrWdMBK936QOl+vRU/fiVoYm Kk0w92LwIwNgMtp9xbnQd6yJBusSJBkO0VZVeRvVO6YWXIHjqjAEz+aBGPERTJ5CHRkt lZt2QO6ZOg/V8kvuIcpnhgg9Bpmt0RfaMN9LJaOAWYePU1cQxggkfg3jGM/xgAIg7rKl r+7frbX0ieP7nNj3M7Ct5Ppeb5xMrrXVotDi8cLNbK7ee1PeoHwxxfkY6jPLywd5Ch9b Wanh9BZ5FAyxgVpDC81TA9yNjsp9r4ZMWhuxHOm5qz55LXjv/BKVwRE16HW4+BNixJad ntYA== X-Gm-Message-State: AODbwcBxRr3hJOPCgK6qa/T8dGy26DhJNzXgtQbLx8864VMDbKwoQHPU sHVP/W4JzlywbC8xBjiZIXdYi3FaPayu X-Received: by 10.55.169.193 with SMTP id s184mr26152068qke.118.1495561092752; Tue, 23 May 2017 10:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 23 May 2017 10:38:12 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Tue, 23 May 2017 10:38:12 -0700 Message-ID: To: "Templin, Fred L" Cc: "int-area@ietf.org" , Joe Touch Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 17:38:15 -0000 On Tue, May 23, 2017 at 9:17 AM, Templin, Fred L wrote: > Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has > problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment > Header between the IPv4 header and the upper layer protocol data, then > use IPv6-style fragmentation instead of IPv4 fragmentation? > Hi Fred, What is the use case for this? Unlike IPv6, IPv4 fragmentation can be done a routers so this technique wouldn't work in that case. If the fragmentation is occurring at tunnel ingress its probably just as easy to fragment as part of the encapsulation like we do in GUE. Tom > So, the IPv4 Protocol field would be set to '44', the IPv4 header would be > followed by an IPv6 Fragment Header, and the "Next Header" field in the > IPv6 Fragment Header would be set to the Protocol Number for the upper > layer protocol. Then, upon fragmentation, each fragment would have an > IPv4 header followed by an IPv6 Fragment Header. > > This format is shown in Figure 6 in Appendix A of the AERO draft: > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > Does this look like something that should be broken out and put into a > little standalone document? > > Thanks - Fred > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue May 23 10:44:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96910129C4E for ; Tue, 23 May 2017 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 czuJVlTnuHKx for ; Tue, 23 May 2017 10:44:15 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 27CB2127137 for ; Tue, 23 May 2017 10:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NHiDHY047151; Tue, 23 May 2017 10:44:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NHi5W9046699 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 10:44:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 10:44:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 10:44:04 -0700 From: "Templin, Fred L" To: Tom Herbert CC: "int-area@ietf.org" , Joe Touch Thread-Topic: [Int-area] IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAASKCMAAA6V56A= Date: Tue, 23 May 2017 17:44:04 +0000 Message-ID: <7d5f1e8643c84cd9813342fa31fd8c70@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 17:44:17 -0000 SGkgVG9tLA0KDQpJIGFtIHRoaW5raW5nIGFib3V0IHNvdXJjZS1mcmFnbWVudGF0aW9uIG9ubHks IHRoZW4gc2VuZCBhbGwgZnJhZ21lbnRzIHdpdGgNCkRGPTEgc28gdGhleSB3b24ndCBiZSBmdXJ0 aGVyIGZyYWdtZW50ZWQgaW4gdGhlIG5ldHdvcmsuDQoNCk9uZSB1c2UgY2FzZSB3b3VsZCBiZSBm b3IgSVAtaW4tSVB2NCB0dW5uZWxpbmcgd2hlbiB0aGVyZSBpcyBubyBHVUUgaGVhZGVyLg0KSSBo YXZlbid0IHRob3VnaHQgbXVjaCBhYm91dCBvdGhlciB1c2UgY2FzZXMsIGJ1dCBpdCBzaG91bGQg YXBwbHkgdG8gYW55IElQL1gNCmVuY2Fwc3VsYXRpb25zIChYIGNvdWxkIGJlIFRDUCwgZm9yIGV4 YW1wbGUpLg0KDQpUaGFua3MgLSBGcmVkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBNYXkgMjMsIDIwMTcgMTA6MzggQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IGludC1hcmVhQGlldGYub3JnOyBKb2Ug VG91Y2ggPHRvdWNoQGlzaS5lZHU+DQo+IFN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIElQdjYgZnJh Z21lbnRhdGlvbiBmb3IgSVB2NA0KPiANCj4gT24gVHVlLCBNYXkgMjMsIDIwMTcgYXQgOToxNyBB TSwgVGVtcGxpbiwgRnJlZCBMDQo+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToN Cj4gPiBKb2UsIEkgd2FudGVkIHRvIHJ1biBhbiBpZGVhIGJ5IHlvdS4gV2UgYWxsIGtub3cgdGhh dCBJUHY0IGZyYWdtZW50YXRpb24gaGFzDQo+ID4gcHJvYmxlbXMgYmVjYXVzZSBvZiB0aGUgMTYt Yml0IElEIGZpZWxkLiBTbywgd2h5IG5vdCBpbnNlcnQgYW4gSVB2NiBGcmFnbWVudA0KPiA+IEhl YWRlciBiZXR3ZWVuIHRoZSBJUHY0IGhlYWRlciBhbmQgdGhlIHVwcGVyIGxheWVyIHByb3RvY29s IGRhdGEsIHRoZW4NCj4gPiB1c2UgSVB2Ni1zdHlsZSBmcmFnbWVudGF0aW9uIGluc3RlYWQgb2Yg SVB2NCBmcmFnbWVudGF0aW9uPw0KPiA+DQo+IEhpIEZyZWQsDQo+IA0KPiBXaGF0IGlzIHRoZSB1 c2UgY2FzZSBmb3IgdGhpcz8gVW5saWtlIElQdjYsIElQdjQgZnJhZ21lbnRhdGlvbiBjYW4gYmUN Cj4gZG9uZSBhIHJvdXRlcnMgc28gdGhpcyB0ZWNobmlxdWUgd291bGRuJ3Qgd29yayBpbiB0aGF0 IGNhc2UuIElmIHRoZQ0KPiBmcmFnbWVudGF0aW9uIGlzIG9jY3VycmluZyBhdCB0dW5uZWwgaW5n cmVzcyBpdHMgcHJvYmFibHkganVzdCBhcyBlYXN5DQo+IHRvIGZyYWdtZW50IGFzIHBhcnQgb2Yg dGhlIGVuY2Fwc3VsYXRpb24gbGlrZSB3ZSBkbyBpbiBHVUUuDQo+IA0KPiBUb20NCj4gDQo+ID4g U28sIHRoZSBJUHY0IFByb3RvY29sIGZpZWxkIHdvdWxkIGJlIHNldCB0byAnNDQnLCB0aGUgSVB2 NCBoZWFkZXIgd291bGQgYmUNCj4gPiBmb2xsb3dlZCBieSBhbiBJUHY2IEZyYWdtZW50IEhlYWRl ciwgYW5kIHRoZSAiTmV4dCBIZWFkZXIiIGZpZWxkIGluIHRoZQ0KPiA+IElQdjYgRnJhZ21lbnQg SGVhZGVyIHdvdWxkIGJlIHNldCB0byB0aGUgUHJvdG9jb2wgTnVtYmVyIGZvciB0aGUgdXBwZXIN Cj4gPiBsYXllciBwcm90b2NvbC4gVGhlbiwgdXBvbiBmcmFnbWVudGF0aW9uLCBlYWNoIGZyYWdt ZW50IHdvdWxkIGhhdmUgYW4NCj4gPiBJUHY0IGhlYWRlciBmb2xsb3dlZCBieSBhbiBJUHY2IEZy YWdtZW50IEhlYWRlci4NCj4gPg0KPiA+IFRoaXMgZm9ybWF0IGlzIHNob3duIGluIEZpZ3VyZSA2 IGluIEFwcGVuZGl4IEEgb2YgdGhlIEFFUk8gZHJhZnQ6DQo+ID4NCj4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9saW5rLw0KPiA+DQo+ID4gRG9l cyB0aGlzIGxvb2sgbGlrZSBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgYnJva2VuIG91dCBhbmQg cHV0IGludG8gYQ0KPiA+IGxpdHRsZSBzdGFuZGFsb25lIGRvY3VtZW50Pw0KPiA+DQo+ID4gVGhh bmtzIC0gRnJlZA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCj4gPiBJbnQtYXJlYUBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWEN Cg0K From nobody Tue May 23 10:59:12 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8951126C23 for ; Tue, 23 May 2017 10:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 o-7XGYLRhKp0 for ; Tue, 23 May 2017 10:59:08 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 3896B126BF7 for ; Tue, 23 May 2017 10:59:08 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a72so136335024qkj.2 for ; Tue, 23 May 2017 10:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FulkhKTZvMTIl612PQupelRlezl4hcBM19JWYiEC23Y=; b=VNoSQpRWnGHwcto/LqNx1flHJ7s3Qf104dVyGSmS3VP8tR5m8PO7uJEiOyafVP1bcy 9Z9MQGYD32rDDCBOMyo3A94VKPnn6w5TbOtTfR08y4O3pjoRj8sqCBlXAgbSASr00U+k db7Ky/FoGdxe/ZD7O48YqzEtJNHx9u0twh32ECiq+mTN5xkX9fU7IPVTQimyX0C3tCYe K+zyz77XUbu1tyw1/jKY+IVPOvQpWc/kndWPfE8zPdtOdy22nMgMtJVrUVgpGKxzvz3k Ua/6GnFFREyh1Wv/93F+LB5VRvoZsI9s4lSShLXfSLaKHYzwgNEecBjsSagqXwMVMMq/ K38w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FulkhKTZvMTIl612PQupelRlezl4hcBM19JWYiEC23Y=; b=E+GacTfgFOz2zOTqkc2+DN05D2ewoV5ylKm4o5A9PDBlM9xB77mzZ4sXhPv0aZQ6YJ 1EKAZtCafVvTfUgz7zeIKthsU+Mx1m53q8hpGrMwDE9J1qnmkxIIDEolYQzlivjSyXsg 2mjVTcFRO7JuqwUjlVLteQqybtD5S3sMQAXBUuzR+NivFsyXWBieeEaSyXCSCpE3f8Ie pySfpEN5L5fAU4upmjy9Mbn99SLAu6Z6VtaVcH/QLooUV6Lg0tDwXOgon8jtpZFLippI nErzE1r3sKxoLfWM8+nxdF+jo4jsIWJ/vGQJlBZZlQOKjg51J0NFxPKlb7ldbHktxlBK tSxg== X-Gm-Message-State: AODbwcDdf0a6dGZKVESHiiLBwx/QmVvIT/VBbpToxO5aNgN/+F4uHWh5 ET14dvzcwj9jCwaPhe3frI+iEkFd2Jhq X-Received: by 10.55.195.220 with SMTP id r89mr26075373qkl.115.1495562347260; Tue, 23 May 2017 10:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 23 May 2017 10:59:06 -0700 (PDT) In-Reply-To: <7d5f1e8643c84cd9813342fa31fd8c70@XCH15-06-08.nw.nos.boeing.com> References: <7d5f1e8643c84cd9813342fa31fd8c70@XCH15-06-08.nw.nos.boeing.com> From: Tom Herbert Date: Tue, 23 May 2017 10:59:06 -0700 Message-ID: To: "Templin, Fred L" Cc: "int-area@ietf.org" , Joe Touch Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 17:59:10 -0000 On Tue, May 23, 2017 at 10:44 AM, Templin, Fred L wrote: > Hi Tom, > > I am thinking about source-fragmentation only, then send all fragments with > DF=1 so they won't be further fragmented in the network. > > One use case would be for IP-in-IPv4 tunneling when there is no GUE header. > I haven't thought much about other use cases, but it should apply to any IP/X > encapsulations (X could be TCP, for example). > Introducing extension headers in IPv4 might be opening a can of worms. Could this be done in a new IPv4 option? Tom > Thanks - Fred > >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Tuesday, May 23, 2017 10:38 AM >> To: Templin, Fred L >> Cc: int-area@ietf.org; Joe Touch >> Subject: Re: [Int-area] IPv6 fragmentation for IPv4 >> >> On Tue, May 23, 2017 at 9:17 AM, Templin, Fred L >> wrote: >> > Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has >> > problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment >> > Header between the IPv4 header and the upper layer protocol data, then >> > use IPv6-style fragmentation instead of IPv4 fragmentation? >> > >> Hi Fred, >> >> What is the use case for this? Unlike IPv6, IPv4 fragmentation can be >> done a routers so this technique wouldn't work in that case. If the >> fragmentation is occurring at tunnel ingress its probably just as easy >> to fragment as part of the encapsulation like we do in GUE. >> >> Tom >> >> > So, the IPv4 Protocol field would be set to '44', the IPv4 header would be >> > followed by an IPv6 Fragment Header, and the "Next Header" field in the >> > IPv6 Fragment Header would be set to the Protocol Number for the upper >> > layer protocol. Then, upon fragmentation, each fragment would have an >> > IPv4 header followed by an IPv6 Fragment Header. >> > >> > This format is shown in Figure 6 in Appendix A of the AERO draft: >> > >> > https://datatracker.ietf.org/doc/draft-templin-aerolink/ >> > >> > Does this look like something that should be broken out and put into a >> > little standalone document? >> > >> > Thanks - Fred >> > >> > _______________________________________________ >> > Int-area mailing list >> > Int-area@ietf.org >> > https://www.ietf.org/mailman/listinfo/int-area > From nobody Tue May 23 11:01:28 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC28129C4A for ; Tue, 23 May 2017 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 uQR9-6WnLp9t for ; Tue, 23 May 2017 11:01:26 -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 83DE4126BF7 for ; Tue, 23 May 2017 11:01:26 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NI0exs011895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 11:00:50 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: From: Joe Touch Message-ID: Date: Tue, 23 May 2017 11:00:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 18:01:27 -0000 Hi, Fred (et al.), On 5/23/2017 9:17 AM, Templin, Fred L wrote: > Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has > problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment > Header between the IPv4 header and the upper layer protocol data, then > use IPv6-style fragmentation instead of IPv4 fragmentation? IPv4 fragmentation has several impediments: - small ID field - lack of a reassembly checksum - lack of a fixed-location flow ID Using IPv6-Frag as the next header solves only the first of these. The last is significant - putting a new header would defeat IPv4 flow ECMP even for the first fragment. IPv6 includes a flow field that serves this purpose. Joe From nobody Tue May 23 11:03:26 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB73C129C3F for ; Tue, 23 May 2017 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 kzru5EIXGR_N for ; Tue, 23 May 2017 11:03:23 -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 D9C571250B8 for ; Tue, 23 May 2017 11:03:23 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NI2pIE014326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 11:03:01 -0700 (PDT) To: Tom Herbert , "Templin, Fred L" Cc: "int-area@ietf.org" References: <7d5f1e8643c84cd9813342fa31fd8c70@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <7669102f-0b34-9abb-0ce7-f47486e77518@isi.edu> Date: Tue, 23 May 2017 11:02:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 18:03:25 -0000 On 5/23/2017 10:59 AM, Tom Herbert wrote: > Introducing extension headers in IPv4 might be opening a can of worms. > Could this be done in a new IPv4 option? Only if you want it dropped by routers. IPv4 doesn't define a flag that says "ignore this option if it isn't supported". Joe From nobody Tue May 23 11:49:43 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AFD12E058 for ; Tue, 23 May 2017 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 jSYgZ05yqtgj for ; Tue, 23 May 2017 11:49:41 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 2EE13127136 for ; Tue, 23 May 2017 11:49:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NIndgb052151; Tue, 23 May 2017 11:49:39 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NInTJw051947 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 11:49:29 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 11:49:28 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 11:49:28 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAAS8QEAAA0n34A= Date: Tue, 23 May 2017 18:49:28 +0000 Message-ID: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 18:49:42 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMywgMjAxNyAx MTowMSBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t PjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IElQdjYgZnJhZ21lbnRhdGlvbiBm b3IgSVB2NA0KPiANCj4gSGksIEZyZWQgKGV0IGFsLiksDQo+IA0KPiBPbiA1LzIzLzIwMTcgOTox NyBBTSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IEpvZSwgSSB3YW50ZWQgdG8gcnVuIGFu IGlkZWEgYnkgeW91LiBXZSBhbGwga25vdyB0aGF0IElQdjQgZnJhZ21lbnRhdGlvbiBoYXMNCj4g PiBwcm9ibGVtcyBiZWNhdXNlIG9mIHRoZSAxNi1iaXQgSUQgZmllbGQuIFNvLCB3aHkgbm90IGlu c2VydCBhbiBJUHY2IEZyYWdtZW50DQo+ID4gSGVhZGVyIGJldHdlZW4gdGhlIElQdjQgaGVhZGVy IGFuZCB0aGUgdXBwZXIgbGF5ZXIgcHJvdG9jb2wgZGF0YSwgdGhlbg0KPiA+IHVzZSBJUHY2LXN0 eWxlIGZyYWdtZW50YXRpb24gaW5zdGVhZCBvZiBJUHY0IGZyYWdtZW50YXRpb24/DQo+IA0KPiBJ UHY0IGZyYWdtZW50YXRpb24gaGFzIHNldmVyYWwgaW1wZWRpbWVudHM6DQo+ICAgICAtIHNtYWxs IElEIGZpZWxkDQo+ICAgICAtIGxhY2sgb2YgYSByZWFzc2VtYmx5IGNoZWNrc3VtDQo+ICAgICAt IGxhY2sgb2YgYSBmaXhlZC1sb2NhdGlvbiBmbG93IElEDQo+IA0KPiBVc2luZyBJUHY2LUZyYWcg YXMgdGhlIG5leHQgaGVhZGVyIHNvbHZlcyBvbmx5IHRoZSBmaXJzdCBvZiB0aGVzZS4gVGhlDQo+ IGxhc3QgaXMgc2lnbmlmaWNhbnQgLSBwdXR0aW5nIGEgbmV3IGhlYWRlciB3b3VsZCBkZWZlYXQg SVB2NCBmbG93IEVDTVANCj4gZXZlbiBmb3IgdGhlIGZpcnN0IGZyYWdtZW50Lg0KDQpFQ01QIGdh dGV3YXlzIGNvdWxkIGJlIHVwZGF0ZWQgdG8gbG9vayBhdCB0aGUgVUxQIGhlYWRlcnMNCmZvbGxv d2luZyB0aGUgSVB2NiBGcmFnIGhlYWRlciBpbiB0aGUgZmlyc3QgZnJhZ21lbnQuDQoNCj4gSVB2 NiBpbmNsdWRlcyBhIGZsb3cgZmllbGQgdGhhdCBzZXJ2ZXMgdGhpcw0KPiBwdXJwb3NlLg0KDQpI b3cgZG9lcyBpdCB3b3JrIGZvciBwbGFpbi1vbGQgSVB2NCBmcmFnbWVudGF0aW9uPyBJIHdvdWxk IHRoaW5rDQp0aGF0IEVDTVAgZ2F0ZXdheXMgd291bGQgbG9vayBhdCB0aGUgSVAgSUQgYW5kIHRy eSB0byBhc3NvY2lhdGUNCnRoZSBmcmFnbWVudHMgc28gdGhleSBhbGwgZ2V0IGVxdWFsIEVDTVAg dHJlYXRtZW50LCBpLmUuLCB0aGUNCnNhbWUgYXMgZm9yIHZhbmlsbGEgSVB2NC4NCg0KVGhhbmtz IC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IEpvZQ0KDQo= From nobody Tue May 23 13:13:35 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF40912943F for ; Tue, 23 May 2017 13:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 PIQIwKmHh2_M for ; Tue, 23 May 2017 13:13:30 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 2079012EB0E for ; Tue, 23 May 2017 13:13:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NKDFR1063100; Tue, 23 May 2017 13:13:15 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NKDESE063092 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 13:13:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 13:13:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 13:13:13 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAAS8QEAAA0n34AAF4ZcAA== Date: Tue, 23 May 2017 20:13:13 +0000 Message-ID: <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:13:34 -0000 Joe, > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, F= red L > Sent: Tuesday, May 23, 2017 11:49 AM > To: Joe Touch ; int-area@ietf.org > Subject: Re: [Int-area] IPv6 fragmentation for IPv4 >=20 > Hi Joe, >=20 > > -----Original Message----- > > From: Joe Touch [mailto:touch@isi.edu] > > Sent: Tuesday, May 23, 2017 11:01 AM > > To: Templin, Fred L ; int-area@ietf.org > > Subject: Re: IPv6 fragmentation for IPv4 > > > > Hi, Fred (et al.), > > > > On 5/23/2017 9:17 AM, Templin, Fred L wrote: > > > Joe, I wanted to run an idea by you. We all know that IPv4 fragmentat= ion has > > > problems because of the 16-bit ID field. So, why not insert an IPv6 F= ragment > > > Header between the IPv4 header and the upper layer protocol data, the= n > > > use IPv6-style fragmentation instead of IPv4 fragmentation? > > > > IPv4 fragmentation has several impediments: > > - small ID field > > - lack of a reassembly checksum > > - lack of a fixed-location flow ID > > > > Using IPv6-Frag as the next header solves only the first of these. The > > last is significant - putting a new header would defeat IPv4 flow ECMP > > even for the first fragment. >=20 > ECMP gateways could be updated to look at the ULP headers > following the IPv6 Frag header in the first fragment. >=20 > > IPv6 includes a flow field that serves this > > purpose. >=20 > How does it work for plain-old IPv4 fragmentation? I would think > that ECMP gateways would look at the IP ID and try to associate > the fragments so they all get equal ECMP treatment, i.e., the > same as for vanilla IPv4. Here's another think - since the IPv6 Frag Header already has a 32-bit IP ID that we are using for fragmentation, and since we are asking the IPv4 header to set DF=3D1, the 16-bit IP ID field in the IPv4 header is available for use as a flow field - right? Thanks - Fred > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Joe >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue May 23 13:21:59 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B3E12EB0E for ; Tue, 23 May 2017 13:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 QEYZm5TATV2E for ; Tue, 23 May 2017 13:21: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 6A8D6126C0F for ; Tue, 23 May 2017 13:21:56 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NKHLma006801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 13:17:31 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: Date: Tue, 23 May 2017 13:17:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:21:57 -0000 On 5/23/2017 11:49 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 23, 2017 11:01 AM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: IPv6 fragmentation for IPv4 >> >> Hi, Fred (et al.), >> >> On 5/23/2017 9:17 AM, Templin, Fred L wrote: >>> Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has >>> problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment >>> Header between the IPv4 header and the upper layer protocol data, then >>> use IPv6-style fragmentation instead of IPv4 fragmentation? >> IPv4 fragmentation has several impediments: >> - small ID field >> - lack of a reassembly checksum >> - lack of a fixed-location flow ID >> >> Using IPv6-Frag as the next header solves only the first of these. The >> last is significant - putting a new header would defeat IPv4 flow ECMP >> even for the first fragment. > ECMP gateways could be updated to look at the ULP headers > following the IPv6 Frag header in the first fragment. They could, but... >> IPv6 includes a flow field that serves this >> purpose. > How does it work for plain-old IPv4 fragmentation? It doesn't. That's part of the problem. > I would think > that ECMP gateways would look at the IP ID and try to associate > the fragments so they all get equal ECMP treatment, i.e., the > same as for vanilla IPv4. AFAICT, they largely either drop fragments or send them based on the base IPv4 header. I wonder whether NATs deal with this issue correctly. I doubt either one keeps per-ID state. (FWIW, IMO, anything that needs to look past the IP header really ought to reassemble - if you think that's not something an IP router should do, neither do I - but then I don't think routers should be looking past the IP header either). Joe From nobody Tue May 23 13:23:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B112EB02 for ; Tue, 23 May 2017 13:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 v-O2zTm9o_as for ; Tue, 23 May 2017 13:23:16 -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 AD95C1287A7 for ; Tue, 23 May 2017 13:23:16 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NKLhaI007933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 13:21:58 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu> Date: Tue, 23 May 2017 13:21:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:23:18 -0000 On 5/23/2017 1:13 PM, Templin, Fred L wrote: > Here's another think - since the IPv6 Frag Header already has a > 32-bit IP ID that we are using for fragmentation, and since we > are asking the IPv4 header to set DF=1, the 16-bit IP ID field in > the IPv4 header is available for use as a flow field - right? Except for all those devices that look only at the IPv4 header. In that case, redefining the IPv4 header this way could interfere with mechanisms to manage NAT traversal based based on ID context. Finally, how do you know when you can even use this? Legacy devices could choke on such packets - whether routers or endpoints. Joe From nobody Tue May 23 13:23:29 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5961287A7 for ; Tue, 23 May 2017 13:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 iZJnVl6DRj0t for ; Tue, 23 May 2017 13:23:17 -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 A286B12943F for ; Tue, 23 May 2017 13:23:17 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NKLjTS007949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 13:22:00 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> From: Joe Touch Message-ID: <2c19348a-497f-0482-dd74-7313893207d7@isi.edu> Date: Tue, 23 May 2017 13:21:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:23:19 -0000 On 5/23/2017 11:49 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 23, 2017 11:01 AM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: IPv6 fragmentation for IPv4 >> >> Hi, Fred (et al.), >> >> On 5/23/2017 9:17 AM, Templin, Fred L wrote: >>> Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has >>> problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment >>> Header between the IPv4 header and the upper layer protocol data, then >>> use IPv6-style fragmentation instead of IPv4 fragmentation? >> IPv4 fragmentation has several impediments: >> - small ID field >> - lack of a reassembly checksum >> - lack of a fixed-location flow ID >> >> Using IPv6-Frag as the next header solves only the first of these. The >> last is significant - putting a new header would defeat IPv4 flow ECMP >> even for the first fragment. > ECMP gateways could be updated to look at the ULP headers > following the IPv6 Frag header in the first fragment. They could, but... >> IPv6 includes a flow field that serves this >> purpose. > How does it work for plain-old IPv4 fragmentation? It doesn't. That's part of the problem. > I would think > that ECMP gateways would look at the IP ID and try to associate > the fragments so they all get equal ECMP treatment, i.e., the > same as for vanilla IPv4. AFAICT, they largely either drop fragments or send them based on the base IPv4 header. I wonder whether NATs deal with this issue correctly. I doubt either one keeps per-ID state. (FWIW, IMO, anything that needs to look past the IP header really ought to reassemble - if you think that's not something an IP router should do, neither do I - but then I don't think routers should be looking past the IP header either). Joe From nobody Tue May 23 13:25:04 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AC312EB13 for ; Tue, 23 May 2017 13:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 2NYyd-nZCzID for ; Tue, 23 May 2017 13:25:01 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 84AB112EB15 for ; Tue, 23 May 2017 13:25:00 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id t26so138709934qtg.0 for ; Tue, 23 May 2017 13:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vxeMpx1fp2OHZOzytE25vC1ummrvHI8bKGva4TsUFo4=; b=JJlQ4yJnNPG/SZ6ZnwUOLVYzZevo3Fmeht485ctsv0a0cjaX5m9Vtqiroi+uq2hb7T Hi+x52Odo+9n3tdhEorBosV/YvQexl6/tyPb3VkzOMxPeVPch2Ft/9ZkLXocMj/zb9wx 86ilO1jmhDNdYfRkqlCOUPQliIs2zVvKuZ8+FYsq6GvaYonlCx/dF63QOifj72N89rij 3MwWKLRkjE05R8lXc5DvlaGryQ97SWsx0d17EQOSmnKU+XaBpWneRteRpoa7QQrPIXMo 8cz1LI5NB4nb9t2FW0A/0mTppT0DGO5XFl4vBNNmYNuSpLPOTKhxuNTfkNVJwqa/LF79 mHRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vxeMpx1fp2OHZOzytE25vC1ummrvHI8bKGva4TsUFo4=; b=BVhlF2JQty63mt1wGMXwsktdpq9TZcR8lQ9L8lYyIU/Ymfzh6vLJ3g87LozbKAXJyq YD+5oEu4pH8AdEHidRyzJDF6PnYWkaZ/MKae1oOyrStJ0ad8SmIXvVEdlsX7rQdXL/5a +4rRrYknQPJ7BouSFf1P+AmTD8Qc5GGKGuBNk6cfH7FLodPHknlFX21SYPJny4Xs4E74 K2n/hNvu69DOrVfakdTpHaYp6kfAfndafdIGCsngJbXPT2ZWrzajqgIuqdqHhso+xgOD tDk3yAg3OdLQaVQN2aEsHO+9EJUukDGfKtFpym9i/1fPgQ6b8mmdQUnzY+b0Urw7vfgm 1DxA== X-Gm-Message-State: AODbwcDj6KlOgACw+qS8RmMWpJ/8goeZKc8eb1XU+UVwxnDzr99JiCNL ufpjVO/RApUnZQPmEMdUPRYUKaOvWRnP X-Received: by 10.200.57.73 with SMTP id t9mr33390306qtb.16.1495571099701; Tue, 23 May 2017 13:24:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 23 May 2017 13:24:59 -0700 (PDT) In-Reply-To: <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> From: Tom Herbert Date: Tue, 23 May 2017 13:24:59 -0700 Message-ID: To: "Templin, Fred L" Cc: Joe Touch , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:25:03 -0000 On Tue, May 23, 2017 at 1:13 PM, Templin, Fred L wrote: > Joe, > >> -----Original Message----- >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fred L >> Sent: Tuesday, May 23, 2017 11:49 AM >> To: Joe Touch ; int-area@ietf.org >> Subject: Re: [Int-area] IPv6 fragmentation for IPv4 >> >> Hi Joe, >> >> > -----Original Message----- >> > From: Joe Touch [mailto:touch@isi.edu] >> > Sent: Tuesday, May 23, 2017 11:01 AM >> > To: Templin, Fred L ; int-area@ietf.org >> > Subject: Re: IPv6 fragmentation for IPv4 >> > >> > Hi, Fred (et al.), >> > >> > On 5/23/2017 9:17 AM, Templin, Fred L wrote: >> > > Joe, I wanted to run an idea by you. We all know that IPv4 fragmentation has >> > > problems because of the 16-bit ID field. So, why not insert an IPv6 Fragment >> > > Header between the IPv4 header and the upper layer protocol data, then >> > > use IPv6-style fragmentation instead of IPv4 fragmentation? >> > >> > IPv4 fragmentation has several impediments: >> > - small ID field >> > - lack of a reassembly checksum >> > - lack of a fixed-location flow ID >> > >> > Using IPv6-Frag as the next header solves only the first of these. The >> > last is significant - putting a new header would defeat IPv4 flow ECMP >> > even for the first fragment. >> >> ECMP gateways could be updated to look at the ULP headers >> following the IPv6 Frag header in the first fragment. >> >> > IPv6 includes a flow field that serves this >> > purpose. >> >> How does it work for plain-old IPv4 fragmentation? I would think >> that ECMP gateways would look at the IP ID and try to associate >> the fragments so they all get equal ECMP treatment, i.e., the >> same as for vanilla IPv4. > > Here's another think - since the IPv6 Frag Header already has a > 32-bit IP ID that we are using for fragmentation, and since we > are asking the IPv4 header to set DF=1, the 16-bit IP ID field in > the IPv4 header is available for use as a flow field - right? > Fred, I think this would over kill. Assuming fragmentation remains the rare case, getting the ECMP hash over the addresses should be sufficient. ECMP is a performance optimization, once you're fragmenting that's already giving up a lot. Tom > Thanks - Fred > >> Thanks - Fred >> fred.l.templin@boeing.com >> >> > Joe >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue May 23 13:41:10 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09FC12EAA4 for ; Tue, 23 May 2017 13:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 5gY-EQ0eS-3l for ; Tue, 23 May 2017 13:41:06 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 4A78D12EA8C for ; Tue, 23 May 2017 13:41:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NKf5mM015882; Tue, 23 May 2017 13:41:05 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NKf4i1015867 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 13:41:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 13:41:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 13:41:03 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAAS8QEAAA0n34D//7zxgIAAcBUQ Date: Tue, 23 May 2017 20:41:03 +0000 Message-ID: References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:41:08 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMywgMjAxNyAx OjE3IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ OyBpbnQtYXJlYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogSVB2NiBmcmFnbWVudGF0aW9uIGZv ciBJUHY0DQo+IA0KPiANCj4gDQo+IE9uIDUvMjMvMjAxNyAxMTo0OSBBTSwgVGVtcGxpbiwgRnJl ZCBMIHdyb3RlOg0KPiA+IEhpIEpvZSwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiA+PiBT ZW50OiBUdWVzZGF5LCBNYXkgMjMsIDIwMTcgMTE6MDEgQU0NCj4gPj4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IGludC1hcmVhQGlldGYub3JnDQo+ID4+ IFN1YmplY3Q6IFJlOiBJUHY2IGZyYWdtZW50YXRpb24gZm9yIElQdjQNCj4gPj4NCj4gPj4gSGks IEZyZWQgKGV0IGFsLiksDQo+ID4+DQo+ID4+IE9uIDUvMjMvMjAxNyA5OjE3IEFNLCBUZW1wbGlu LCBGcmVkIEwgd3JvdGU6DQo+ID4+PiBKb2UsIEkgd2FudGVkIHRvIHJ1biBhbiBpZGVhIGJ5IHlv dS4gV2UgYWxsIGtub3cgdGhhdCBJUHY0IGZyYWdtZW50YXRpb24gaGFzDQo+ID4+PiBwcm9ibGVt cyBiZWNhdXNlIG9mIHRoZSAxNi1iaXQgSUQgZmllbGQuIFNvLCB3aHkgbm90IGluc2VydCBhbiBJ UHY2IEZyYWdtZW50DQo+ID4+PiBIZWFkZXIgYmV0d2VlbiB0aGUgSVB2NCBoZWFkZXIgYW5kIHRo ZSB1cHBlciBsYXllciBwcm90b2NvbCBkYXRhLCB0aGVuDQo+ID4+PiB1c2UgSVB2Ni1zdHlsZSBm cmFnbWVudGF0aW9uIGluc3RlYWQgb2YgSVB2NCBmcmFnbWVudGF0aW9uPw0KPiA+PiBJUHY0IGZy YWdtZW50YXRpb24gaGFzIHNldmVyYWwgaW1wZWRpbWVudHM6DQo+ID4+ICAgICAtIHNtYWxsIElE IGZpZWxkDQo+ID4+ICAgICAtIGxhY2sgb2YgYSByZWFzc2VtYmx5IGNoZWNrc3VtDQo+ID4+ICAg ICAtIGxhY2sgb2YgYSBmaXhlZC1sb2NhdGlvbiBmbG93IElEDQo+ID4+DQo+ID4+IFVzaW5nIElQ djYtRnJhZyBhcyB0aGUgbmV4dCBoZWFkZXIgc29sdmVzIG9ubHkgdGhlIGZpcnN0IG9mIHRoZXNl LiBUaGUNCj4gPj4gbGFzdCBpcyBzaWduaWZpY2FudCAtIHB1dHRpbmcgYSBuZXcgaGVhZGVyIHdv dWxkIGRlZmVhdCBJUHY0IGZsb3cgRUNNUA0KPiA+PiBldmVuIGZvciB0aGUgZmlyc3QgZnJhZ21l bnQuDQo+ID4gRUNNUCBnYXRld2F5cyBjb3VsZCBiZSB1cGRhdGVkIHRvIGxvb2sgYXQgdGhlIFVM UCBoZWFkZXJzDQo+ID4gZm9sbG93aW5nIHRoZSBJUHY2IEZyYWcgaGVhZGVyIGluIHRoZSBmaXJz dCBmcmFnbWVudC4NCj4gVGhleSBjb3VsZCwgYnV0Li4uDQo+IA0KPiA+PiBJUHY2IGluY2x1ZGVz IGEgZmxvdyBmaWVsZCB0aGF0IHNlcnZlcyB0aGlzDQo+ID4+IHB1cnBvc2UuDQo+ID4gSG93IGRv ZXMgaXQgd29yayBmb3IgcGxhaW4tb2xkIElQdjQgZnJhZ21lbnRhdGlvbj8NCj4gSXQgZG9lc24n dC4gVGhhdCdzIHBhcnQgb2YgdGhlIHByb2JsZW0uDQo+IA0KPiA+IEkgd291bGQgdGhpbmsNCj4g PiB0aGF0IEVDTVAgZ2F0ZXdheXMgd291bGQgbG9vayBhdCB0aGUgSVAgSUQgYW5kIHRyeSB0byBh c3NvY2lhdGUNCj4gPiB0aGUgZnJhZ21lbnRzIHNvIHRoZXkgYWxsIGdldCBlcXVhbCBFQ01QIHRy ZWF0bWVudCwgaS5lLiwgdGhlDQo+ID4gc2FtZSBhcyBmb3IgdmFuaWxsYSBJUHY0Lg0KPiBBRkFJ Q1QsIHRoZXkgbGFyZ2VseSBlaXRoZXIgZHJvcCBmcmFnbWVudHMgb3Igc2VuZCB0aGVtIGJhc2Vk IG9uIHRoZQ0KPiBiYXNlIElQdjQgaGVhZGVyLg0KDQpJIHRoaW5rIHRoZW4gaXQgd291bGQgYmUg dGhlIHNhbWUgZm9yIGJvdGggdmFuaWxsYSBJUHY0IGZyYWdtZW50YXRpb24NCmFuZCB0aGlzIGh5 YnJpZCBJUHY0LzYgZnJhZ21lbnRhdGlvbi4NCg0KPiBJIHdvbmRlciB3aGV0aGVyIE5BVHMgZGVh bCB3aXRoIHRoaXMgaXNzdWUgY29ycmVjdGx5LiBJIGRvdWJ0IGVpdGhlciBvbmUNCj4ga2VlcHMg cGVyLUlEIHN0YXRlLg0KDQpJIGhlYXJkIG9uY2UgbG9uZyBhZ28gYWJvdXQgVmlydHVhbCBGcmFn bWVudCBSZWFzc2VtYmx5IHdoZXJlIHRoZQ0KbWlkZGxlYm94IGNvbGxlY3RzIHVwIGZyYWdtZW50 cyB1bnRpbCBpdCBoYXMgYWxsIG9mIHRoZW0sIGJ1dCB0aGVuDQppbnN0ZWFkIG9mIGFjdHVhbGx5 IHJlYXNzZW1ibGluZyBpdCByZWxlYXNlcyB0aGUgZnJhZ21lbnRzIHNvIHRoYXQNCnRoZSBmaW5h bCBkZXN0aW5hdGlvbiBoYXMgdG8gcmVhc3NlbWJsZS4gSSB0aGluayBpdCBpcyBhIGNpc2NvIHRo aW5nLg0KRG9lcyBhbnlvbmUga25vdyBpZiBpdCBpcyB3aWRlbHkgZGVwbG95ZWQ/DQoNCj4gKEZX SVcsIElNTywgYW55dGhpbmcgdGhhdCBuZWVkcyB0byBsb29rIHBhc3QgdGhlIElQIGhlYWRlciBy ZWFsbHkgb3VnaHQNCj4gdG8gcmVhc3NlbWJsZSAtIGlmIHlvdSB0aGluayB0aGF0J3Mgbm90IHNv bWV0aGluZyBhbiBJUCByb3V0ZXIgc2hvdWxkDQo+IGRvLCBuZWl0aGVyIGRvIEkgLSBidXQgdGhl biBJIGRvbid0IHRoaW5rIHJvdXRlcnMgc2hvdWxkIGJlIGxvb2tpbmcgcGFzdA0KPiB0aGUgSVAg aGVhZGVyIGVpdGhlcikuDQoNCkluZGVlZC4gDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBKb2UNCj4g DQo+IA0KDQo= From nobody Tue May 23 13:45:53 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95F312EB22 for ; Tue, 23 May 2017 13:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 eJ9NS0lT5gXL for ; Tue, 23 May 2017 13:45:51 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 817FF12EB21 for ; Tue, 23 May 2017 13:45:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NKjpCv023315; Tue, 23 May 2017 13:45:51 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NKjgEd023277 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 13:45:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 13:45:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 13:45:41 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAAS8QEAAA0n34AAF4ZcAP//AfaAgABvzFA= Date: Tue, 23 May 2017 20:45:41 +0000 Message-ID: References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu> In-Reply-To: <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:45:53 -0000 SGkgSm9lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMywgMjAxNyAx OjIyIFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ OyBpbnQtYXJlYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogSVB2NiBmcmFnbWVudGF0aW9uIGZv ciBJUHY0DQo+IA0KPiANCj4gDQo+IE9uIDUvMjMvMjAxNyAxOjEzIFBNLCBUZW1wbGluLCBGcmVk IEwgd3JvdGU6DQo+ID4gSGVyZSdzIGFub3RoZXIgdGhpbmsgLSBzaW5jZSB0aGUgSVB2NiBGcmFn IEhlYWRlciBhbHJlYWR5IGhhcyBhDQo+ID4gMzItYml0IElQIElEIHRoYXQgd2UgYXJlIHVzaW5n IGZvciBmcmFnbWVudGF0aW9uLCBhbmQgc2luY2Ugd2UNCj4gPiBhcmUgYXNraW5nIHRoZSBJUHY0 IGhlYWRlciB0byBzZXQgREY9MSwgdGhlIDE2LWJpdCBJUCBJRCBmaWVsZCBpbg0KPiA+IHRoZSBJ UHY0IGhlYWRlciBpcyBhdmFpbGFibGUgZm9yIHVzZSBhcyBhIGZsb3cgZmllbGQgLSByaWdodD8N Cj4gRXhjZXB0IGZvciBhbGwgdGhvc2UgZGV2aWNlcyB0aGF0IGxvb2sgb25seSBhdCB0aGUgSVB2 NCBoZWFkZXIuIEluIHRoYXQNCj4gY2FzZSwgcmVkZWZpbmluZyB0aGUgSVB2NCBoZWFkZXIgdGhp cyB3YXkgY291bGQgaW50ZXJmZXJlIHdpdGgNCj4gbWVjaGFuaXNtcyB0byBtYW5hZ2UgTkFUIHRy YXZlcnNhbCBiYXNlZCBiYXNlZCBvbiBJRCBjb250ZXh0Lg0KDQpXaGF0IHdhcyBpdCB0aGF0IHlv dXIgZG9jdW1lbnQgc2FpZCBhYm91dCB0aGUgc2V0dGluZyBvZiBJUCBJRCB3aGVuDQpERj0xPyBT aG91bGRuJ3QgaXQgYmUgT0sgdG8gc2V0IHRoZSBJRCB0byBzb21lIHZhbHVlIG9mIG91ciBvd24N CmNob29zaW5nLCBlLmcuLCBhIGhhc2ggb2YgdGhlIDUtdHVwbGUgb2YgdGhlIG9yaWdpbmFsIHBh Y2tldD8NCg0KPiBGaW5hbGx5LCBob3cgZG8geW91IGtub3cgd2hlbiB5b3UgY2FuIGV2ZW4gdXNl IHRoaXM/IExlZ2FjeSBkZXZpY2VzDQo+IGNvdWxkIGNob2tlIG9uIHN1Y2ggcGFja2V0cyAtIHdo ZXRoZXIgcm91dGVycyBvciBlbmRwb2ludHMuDQoNClRoYXQgaXMgYSByZWFsIGNvbmNlcm4sIHll cy4gRm9yIHRoZSBzYW1lIHJlYXNvbiB0aGF0IG5ldyB0cmFuc3BvcnRzDQpsaWtlIFNDVFAgYW5k IERDQ1AgaGF2ZSBiZWVuIHByb3ZlbiBkaWZmaWN1bHQgdG8gZGVwbG95LiBXaXRoIHRoaXMNCnBy b3Bvc2FsLCBpcC1wcm90by00NCB3b3VsZCBiZSBqdXN0IGFub3RoZXIgcHJvdG9jb2wgdGhhdCBt aWRkbGVib3hlcw0KYmxvY2suIEJ1dCwgbWF5YmUgaXQgd291bGQgd29yayBpbiBwcml2YXRlIGlu dGVybmV0d29ya3Mgc3VjaCBhcw0KYW4gZW50ZXJwcmlzZSBuZXR3b3JrLg0KDQpUaGFua3MgLSBG cmVkDQoNCj4gSm9lDQoNCg== From nobody Tue May 23 13:47:17 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FB612EB28 for ; Tue, 23 May 2017 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 rd9je1tB4pJF for ; Tue, 23 May 2017 13:47:14 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 DA04B12EB21 for ; Tue, 23 May 2017 13:47:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4NKlEor025565; Tue, 23 May 2017 13:47:14 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4NKl9sq025505 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 May 2017 13:47:09 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 13:47:09 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 23 May 2017 13:47:08 -0700 From: "Templin, Fred L" To: Tom Herbert CC: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] IPv6 fragmentation for IPv4 Thread-Index: AdLT3WVYMdiisvTeTLyu7THIVnRQuAAS8QEAAA0n34AAF4ZcAP//AuCAgABveKA= Date: Tue, 23 May 2017 20:47:08 +0000 Message-ID: <63388d4b7e894e518cfb7427b7256d1c@XCH15-06-08.nw.nos.boeing.com> References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:47:16 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogVHVlc2RheSwgTWF5IDIz LCAyMDE3IDE6MjUgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCj4gQ2M6IEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdT47IGludC1hcmVhQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIElQdjYgZnJhZ21lbnRhdGlvbiBmb3IgSVB2 NA0KPiANCj4gT24gVHVlLCBNYXkgMjMsIDIwMTcgYXQgMToxMyBQTSwgVGVtcGxpbiwgRnJlZCBM DQo+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPiBKb2UsDQo+ID4NCj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSW50LWFyZWEgW21haWx0 bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiwgRnJlZCBM DQo+ID4+IFNlbnQ6IFR1ZXNkYXksIE1heSAyMywgMjAxNyAxMTo0OSBBTQ0KPiA+PiBUbzogSm9l IFRvdWNoIDx0b3VjaEBpc2kuZWR1PjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDog UmU6IFtJbnQtYXJlYV0gSVB2NiBmcmFnbWVudGF0aW9uIGZvciBJUHY0DQo+ID4+DQo+ID4+IEhp IEpvZSwNCj4gPj4NCj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+IEZy b206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+ID4gU2VudDogVHVlc2Rh eSwgTWF5IDIzLCAyMDE3IDExOjAxIEFNDQo+ID4+ID4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IGludC1hcmVhQGlldGYub3JnDQo+ID4+ID4gU3ViamVj dDogUmU6IElQdjYgZnJhZ21lbnRhdGlvbiBmb3IgSVB2NA0KPiA+PiA+DQo+ID4+ID4gSGksIEZy ZWQgKGV0IGFsLiksDQo+ID4+ID4NCj4gPj4gPiBPbiA1LzIzLzIwMTcgOToxNyBBTSwgVGVtcGxp biwgRnJlZCBMIHdyb3RlOg0KPiA+PiA+ID4gSm9lLCBJIHdhbnRlZCB0byBydW4gYW4gaWRlYSBi eSB5b3UuIFdlIGFsbCBrbm93IHRoYXQgSVB2NCBmcmFnbWVudGF0aW9uIGhhcw0KPiA+PiA+ID4g cHJvYmxlbXMgYmVjYXVzZSBvZiB0aGUgMTYtYml0IElEIGZpZWxkLiBTbywgd2h5IG5vdCBpbnNl cnQgYW4gSVB2NiBGcmFnbWVudA0KPiA+PiA+ID4gSGVhZGVyIGJldHdlZW4gdGhlIElQdjQgaGVh ZGVyIGFuZCB0aGUgdXBwZXIgbGF5ZXIgcHJvdG9jb2wgZGF0YSwgdGhlbg0KPiA+PiA+ID4gdXNl IElQdjYtc3R5bGUgZnJhZ21lbnRhdGlvbiBpbnN0ZWFkIG9mIElQdjQgZnJhZ21lbnRhdGlvbj8N Cj4gPj4gPg0KPiA+PiA+IElQdjQgZnJhZ21lbnRhdGlvbiBoYXMgc2V2ZXJhbCBpbXBlZGltZW50 czoNCj4gPj4gPiAgICAgLSBzbWFsbCBJRCBmaWVsZA0KPiA+PiA+ICAgICAtIGxhY2sgb2YgYSBy ZWFzc2VtYmx5IGNoZWNrc3VtDQo+ID4+ID4gICAgIC0gbGFjayBvZiBhIGZpeGVkLWxvY2F0aW9u IGZsb3cgSUQNCj4gPj4gPg0KPiA+PiA+IFVzaW5nIElQdjYtRnJhZyBhcyB0aGUgbmV4dCBoZWFk ZXIgc29sdmVzIG9ubHkgdGhlIGZpcnN0IG9mIHRoZXNlLiBUaGUNCj4gPj4gPiBsYXN0IGlzIHNp Z25pZmljYW50IC0gcHV0dGluZyBhIG5ldyBoZWFkZXIgd291bGQgZGVmZWF0IElQdjQgZmxvdyBF Q01QDQo+ID4+ID4gZXZlbiBmb3IgdGhlIGZpcnN0IGZyYWdtZW50Lg0KPiA+Pg0KPiA+PiBFQ01Q IGdhdGV3YXlzIGNvdWxkIGJlIHVwZGF0ZWQgdG8gbG9vayBhdCB0aGUgVUxQIGhlYWRlcnMNCj4g Pj4gZm9sbG93aW5nIHRoZSBJUHY2IEZyYWcgaGVhZGVyIGluIHRoZSBmaXJzdCBmcmFnbWVudC4N Cj4gPj4NCj4gPj4gPiBJUHY2IGluY2x1ZGVzIGEgZmxvdyBmaWVsZCB0aGF0IHNlcnZlcyB0aGlz DQo+ID4+ID4gcHVycG9zZS4NCj4gPj4NCj4gPj4gSG93IGRvZXMgaXQgd29yayBmb3IgcGxhaW4t b2xkIElQdjQgZnJhZ21lbnRhdGlvbj8gSSB3b3VsZCB0aGluaw0KPiA+PiB0aGF0IEVDTVAgZ2F0 ZXdheXMgd291bGQgbG9vayBhdCB0aGUgSVAgSUQgYW5kIHRyeSB0byBhc3NvY2lhdGUNCj4gPj4g dGhlIGZyYWdtZW50cyBzbyB0aGV5IGFsbCBnZXQgZXF1YWwgRUNNUCB0cmVhdG1lbnQsIGkuZS4s IHRoZQ0KPiA+PiBzYW1lIGFzIGZvciB2YW5pbGxhIElQdjQuDQo+ID4NCj4gPiBIZXJlJ3MgYW5v dGhlciB0aGluayAtIHNpbmNlIHRoZSBJUHY2IEZyYWcgSGVhZGVyIGFscmVhZHkgaGFzIGENCj4g PiAzMi1iaXQgSVAgSUQgdGhhdCB3ZSBhcmUgdXNpbmcgZm9yIGZyYWdtZW50YXRpb24sIGFuZCBz aW5jZSB3ZQ0KPiA+IGFyZSBhc2tpbmcgdGhlIElQdjQgaGVhZGVyIHRvIHNldCBERj0xLCB0aGUg MTYtYml0IElQIElEIGZpZWxkIGluDQo+ID4gdGhlIElQdjQgaGVhZGVyIGlzIGF2YWlsYWJsZSBm b3IgdXNlIGFzIGEgZmxvdyBmaWVsZCAtIHJpZ2h0Pw0KPiA+DQo+IEZyZWQsDQo+IA0KPiBJIHRo aW5rIHRoaXMgd291bGQgb3ZlciBraWxsLiBBc3N1bWluZyBmcmFnbWVudGF0aW9uIHJlbWFpbnMg dGhlIHJhcmUNCj4gY2FzZSwgZ2V0dGluZyB0aGUgRUNNUCBoYXNoIG92ZXIgdGhlIGFkZHJlc3Nl cyBzaG91bGQgYmUgc3VmZmljaWVudC4NCj4gRUNNUCBpcyBhIHBlcmZvcm1hbmNlIG9wdGltaXph dGlvbiwgb25jZSB5b3UncmUgZnJhZ21lbnRpbmcgdGhhdCdzDQo+IGFscmVhZHkgZ2l2aW5nIHVw IGEgbG90Lg0KDQpZZXMsIEkgZG9uJ3QgZGlzYWdyZWUuIEJ1dCB3cml0aW5nIGEgaGFzaCBvZiB0 aGUgNS10dXBsZSBpbiB0aGUgSVB2NA0KSUQgZmllbGQgb2YgZWFjaCBmcmFnbWVudCAoYW5kIHNl dHRpbmcgREY9MSkgc2hvdWxkbid0IGJlIHNvIGhhcmQuDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBU b20NCj4gDQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+DQo+ID4+IFRoYW5rcyAtIEZyZWQNCj4gPj4g ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+Pg0KPiA+PiA+IEpvZQ0KPiA+Pg0KPiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBJbnQt YXJlYSBtYWlsaW5nIGxpc3QNCj4gPj4gSW50LWFyZWFAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0KPiA+DQo+ID4NCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEludC1hcmVh IG1haWxpbmcgbGlzdA0KPiA+IEludC1hcmVhQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0KDQo= From nobody Tue May 23 14:20:04 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DE12EB32 for ; Tue, 23 May 2017 14:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 xJ3IhHYfbJCF for ; Tue, 23 May 2017 14:20:00 -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 C80BD1287A7 for ; Tue, 23 May 2017 14:20:00 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4NLJBf9014405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 May 2017 14:19:26 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu> From: Joe Touch Message-ID: Date: Tue, 23 May 2017 14:19:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 21:20:03 -0000 On 5/23/2017 1:45 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, May 23, 2017 1:22 PM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: IPv6 fragmentation for IPv4 >> >> >> >> On 5/23/2017 1:13 PM, Templin, Fred L wrote: >>> Here's another think - since the IPv6 Frag Header already has a >>> 32-bit IP ID that we are using for fragmentation, and since we >>> are asking the IPv4 header to set DF=1, the 16-bit IP ID field in >>> the IPv4 header is available for use as a flow field - right? >> Except for all those devices that look only at the IPv4 header. In that >> case, redefining the IPv4 header this way could interfere with >> mechanisms to manage NAT traversal based based on ID context. > What was it that your document said about the setting of IP ID when > DF=1? Shouldn't it be OK to set the ID to some value of our own > choosing, e.g., a hash of the 5-tuple of the original packet? If DF=1, then the ID should be ignored everywhere. That's also consistent with the uses that were reported about some systems just setting DF=1 and using a single ID. It can't indicate a flow unless you know the next proto=44. But then why not make next proto=(new number) and just put a proper flow ID (and reassembly) there? > >> Finally, how do you know when you can even use this? Legacy devices >> could choke on such packets - whether routers or endpoints. > That is a real concern, yes. For the same reason that new transports > like SCTP and DCCP have been proven difficult to deploy. With this > proposal, ip-proto-44 would be just another protocol that middleboxes > block. But, maybe it would work in private internetworks such as > an enterprise network. IMO, if you've gotten to the point of upgrading a system to speak a new variant of IPv4, it ought to be IPv6. :-) Joe From nobody Tue May 23 15:45:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775DA1273B1 for ; Tue, 23 May 2017 15:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JXeT9c4OfIev for ; Tue, 23 May 2017 15:45:16 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 D5E5B12704B for ; Tue, 23 May 2017 15:45:15 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id t26so141337999qtg.0 for ; Tue, 23 May 2017 15:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tnINa0TDt9zm4Ac/AM5cfC0M/T4wNOSzMW3/CbQmTSE=; b=tr0GvQKfqnvujYaCjxWZ21BU3FgAeYzRXCh8losB8GHwBB2K6v/1RkOlGIOFc8Z88U j0UVxQbZykI+PT3Fbm91i3g2b+dXK6mU2NtIbj6jChLmyEbiY7bFL36jw7nmHXtj37Bv i8gGNsa/z1H6VSKpMRnsFnshRuXMVg53qBJiqiwbVRnRRLCpasajibusFNFCnExk9K/0 fZ3ge7Q+Lc2d3ATLOh0PnDZblovQtH5fKgf1+5QPvuWrRE6WIwX2VaVyGiY0z5jfl/6O x6KcepX0dhlCd8KbtDNv4l2Pdb+26I+H4f4/p4BXhs5yatsSAeOoVfYBjGmrAm172wjV cIjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tnINa0TDt9zm4Ac/AM5cfC0M/T4wNOSzMW3/CbQmTSE=; b=lXrjBI+MZK8ANTypbhzV77WvXZpO5jGar29kijiWNVIxpd8gW3oxGn0un5Fn7jGtmn wqsyNY1oSzW+gzRm70dx0ahWADzv8ttJA19DH+gzKL9JkbURqKKXXPw5hzgPODtIjvn4 2+yHXJRMAB01aU79HwuYBKDxD4MpiUkyRo8521HbxEq8qc/z8k5qZvpfd5IFGyXYmQ/M haYyX1JmLxeoQUeFHG9h70oUM3G2hSp8gNyp4PzinA6hyUYToqFMdq+SMK2NPLiZP4N8 nE8oNrrdIvFC7ywbqE2lMYTES+Hr9TEdexhfUCLLd9IwcTCPBWhZPfJ76cugEs6KYVL6 XfwA== X-Gm-Message-State: AODbwcBZLmFUu0E9++pwaVrk3oKHd5p2aYCSreCmGX+DnEx7suSY9vgP 9jaA+JG7SvQLwg== X-Received: by 10.200.54.199 with SMTP id b7mr32148520qtc.145.1495579515089; Tue, 23 May 2017 15:45:15 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id o13sm1424348qke.30.2017.05.23.15.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 15:45:14 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AC4E9A2C-36D3-44C3-9177-4CDC4823BA2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 23 May 2017 15:45:10 -0700 In-Reply-To: Cc: Bob Hinden , "int-area@ietf.org" To: Joe Touch , "Templin, Fred L" References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 22:45:17 -0000 --Apple-Mail=_AC4E9A2C-36D3-44C3-9177-4CDC4823BA2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >>=20 >>> Finally, how do you know when you can even use this? Legacy devices >>> could choke on such packets - whether routers or endpoints. >> That is a real concern, yes. For the same reason that new transports >> like SCTP and DCCP have been proven difficult to deploy. With this >> proposal, ip-proto-44 would be just another protocol that middleboxes >> block. But, maybe it would work in private internetworks such as >> an enterprise network. Upgrading enterprise networks isn=E2=80=99t so easy these days. They = have many different kinds of devices (some owned by the enterprise, some = BYOD) each with different software. It=E2=80=99s one thing to push out = an application, changing the IP stack is difficult. > IMO, if you've gotten to the point of upgrading a system to speak a = new > variant of IPv4, it ought to be IPv6. +1 Especially, since most devices have IPv6 already. Bob --Apple-Mail=_AC4E9A2C-36D3-44C3-9177-4CDC4823BA2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZJLt3AAoJEK7rdBF357uoKMkH/1qZp5rl2bUaxyEMTYvyDGGY 6XVcFCsc9DU8c07p+lIUVzwwUW/mmSjGOt0q8KQPfBElPKYyC2tr9KU4TPi5RFbl jUFvgDYZ6Vkr7uxlL96F4laAum5KKIc7Y3TSvcwKAsEyW9FtUtr4lggTCqBKfHKR 5kHr8w5q1nb5nHRXpGf06dUab4RSZYFgrKBTwV3HKWJZ82nhMKrYKFHmZ2QbreiS RrO1DJnI2Gj23HzaOc4hBOryDnaOQMvP/CS1BuQd8FuuIbUI3Eh6waR92+gqcDgh pNQ+Y3GQnr1E7+ItoTNSFsv8HRI1cGmlcEU/tFc+JrHolvqQAm1AFBFUR+VtE8g= =8ERG -----END PGP SIGNATURE----- --Apple-Mail=_AC4E9A2C-36D3-44C3-9177-4CDC4823BA2C-- From nobody Tue May 23 19:38:24 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387481286AB for ; Tue, 23 May 2017 19:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 GCo6b1tdqLoo for ; Tue, 23 May 2017 19:38:20 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 706D2126CC4 for ; Tue, 23 May 2017 19:38:20 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id u75so144274992qka.3 for ; Tue, 23 May 2017 19:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yL9f/4wyNy1QqCbw0L9/fgV+GZ3/cPc745NH91eyo7U=; b=KzkUvW7cXcc5TcHJtNHDn6Qg+a2DEe9SkYPUlukrrpAA9fduJ2YGugeeJ7GDFZZNGj 4xwbe3BSkBbYHc97Rcwo6rr8qNzcF2uATNHpGip+k7dJ2SOATcWQV75mhcVJAX70991G EwXjknlDcyxuVNgNZOhNPxiypGjZDDo0esJhSOV1BFCX4s94MrHJ9G3+BxAeRIsKVmh5 MLUFv9s+gz/QFMbE7m6YkGjR9NtIDxKnCheowhUD3oHoQuyc0jQChopDAhft3vmjf7yo lhj+PFfbLtEYeWMRqBXj9U0m6VOXTESJzAWFdFLzmXP0lopr2Z75nHV7pj+KFqFzcEzP 2V0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yL9f/4wyNy1QqCbw0L9/fgV+GZ3/cPc745NH91eyo7U=; b=JffZ/eWnYjluWehEpyjAjPFZXKM0r9q3l8xa1QoNnvebW5I54W2k9O//pM11IkyegK ixT71TwgCQAZHtySSvn0alzdnXPbrHqFqJseiboiMRhEJZlQj0n/6FP56PTKx8U3M6qf VSYRK19HOVGCwUsCsBd5jsnb5bCTvp22sbpn3WW/FJFiQbogRX65b18TAgbrLembDbvI DN2yCvWjBnel8hUnmMsZXhKsAHJqy4XGEJEfnVJZezf2DXnWUxxzVCX+yjwRJTgxV0Dr DcbOoUsvd9B7x69QEtv4VuRVUw57Ib8ClbuBLerZiksxjCXXrF/nbgFJpXhg/Mu+ZZwJ LGOQ== X-Gm-Message-State: AODbwcCVPdfx0/GY6hHBlb2atVF6N9keCxbjTDvdbFeKSOxkFVyikj+R u86E9nf7K1kFx+6sw4tEJ06DGwgsXhEi X-Received: by 10.55.195.220 with SMTP id r89mr27897382qkl.115.1495593499639; Tue, 23 May 2017 19:38:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 23 May 2017 19:38:19 -0700 (PDT) In-Reply-To: References: <82ea9cb1ddec4c159fd4b4bdea90be41@XCH15-06-08.nw.nos.boeing.com> <1e04c4fdef5249ec816638aaf0584422@XCH15-06-08.nw.nos.boeing.com> <7b58e6e2-8f58-0f80-494c-11053257759c@isi.edu> From: Tom Herbert Date: Tue, 23 May 2017 19:38:19 -0700 Message-ID: To: Joe Touch Cc: "Templin, Fred L" , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] IPv6 fragmentation for IPv4 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 02:38:23 -0000 On Tue, May 23, 2017 at 2:19 PM, Joe Touch wrote: > > > On 5/23/2017 1:45 PM, Templin, Fred L wrote: >> Hi Joe, >> >>> -----Original Message----- >>> From: Joe Touch [mailto:touch@isi.edu] >>> Sent: Tuesday, May 23, 2017 1:22 PM >>> To: Templin, Fred L ; int-area@ietf.org >>> Subject: Re: IPv6 fragmentation for IPv4 >>> >>> >>> >>> On 5/23/2017 1:13 PM, Templin, Fred L wrote: >>>> Here's another think - since the IPv6 Frag Header already has a >>>> 32-bit IP ID that we are using for fragmentation, and since we >>>> are asking the IPv4 header to set DF=1, the 16-bit IP ID field in >>>> the IPv4 header is available for use as a flow field - right? >>> Except for all those devices that look only at the IPv4 header. In that >>> case, redefining the IPv4 header this way could interfere with >>> mechanisms to manage NAT traversal based based on ID context. >> What was it that your document said about the setting of IP ID when >> DF=1? Shouldn't it be OK to set the ID to some value of our own >> choosing, e.g., a hash of the 5-tuple of the original packet? > If DF=1, then the ID should be ignored everywhere. > > That's also consistent with the uses that were reported about some > systems just setting DF=1 and using a single ID. > > It can't indicate a flow unless you know the next proto=44. But then why > not make next proto=(new number) and just put a proper flow ID (and > reassembly) there? Alternatively, you could encapsulate in GUE with fragmentation option. Then the packet is UDP/IP which makes intermediate devices happy and ECMP is taken care of. The receiver needs to be running GUE, but that is a much easier task than deploying a protocol. >> >>> Finally, how do you know when you can even use this? Legacy devices >>> could choke on such packets - whether routers or endpoints. >> That is a real concern, yes. For the same reason that new transports >> like SCTP and DCCP have been proven difficult to deploy. With this >> proposal, ip-proto-44 would be just another protocol that middleboxes >> block. But, maybe it would work in private internetworks such as >> an enterprise network. > IMO, if you've gotten to the point of upgrading a system to speak a new > variant of IPv4, it ought to be IPv6. > +1 Tom > :-) > > Joe > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu May 25 09:00:27 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5E5129B2E for ; Thu, 25 May 2017 09:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 hpgbBX1_Wpoj for ; Thu, 25 May 2017 09:00:23 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 9DBB0129B25 for ; Thu, 25 May 2017 09:00:20 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id b84so98057171wmh.0 for ; Thu, 25 May 2017 09:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t+fgrja2tIc1qJyKmlwDrOaJstu3JRf36EkOVx9ZniY=; b=GUDPCCV62FHmHS/CVpblprXi1tvijDV36wO/Ohq8l22CoiDug1GvIj4Y/JOdQ/Oyk3 u4SiIqQ9QVdaQ69Np1+piEDGCYccSf5nUdeFq4giJTAIFzngCJTVVWgy06dnDfOJKURw TyHFfKGzg/Z7iiulUC/1kO9IUcoGMRvhOmWuOGDXtFG9sfkLxm1jU4yJgvP6ZkQf0NRp 4UkK7BFjeHF3xa1ylpDKlGyRSSFfhOGdRvvmCL0F7++cLu+GCaVA4UjHzI/x58OPAd6G Gevo/B0yz+RF7Ij4U25dIeQqVbcGfmxb2A4L4LaCszn/287/xLEAsn0ti7/zaA11pFbN d/jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t+fgrja2tIc1qJyKmlwDrOaJstu3JRf36EkOVx9ZniY=; b=S/y+NRH3M4ABlGXbshRXo5IlQdJhSaohct4lpIEx2LC0ahmm+PP6qB6/m6tG0tyUtX jgrBOuFZmnL+BiDjwMDrkKvirSjGrTK+qdPMS+ANGr38m//q352JfPkWanb79x3qFUCg k3NHeIYDXimkBL9vjO1Yk5pLUiw5lH7xa07VCrfR5Siq3IV5xRGapYLgP6vIbuF8eVCY gGXm/c+OnYQrSVgkTNYmFAOiLamPJB0Fia5Dha8qcEzUjnfmVk6tlMelq47deFSEsXcO dzg4JljGBWq/ZgRwq8z0q29Y4miL44BjUcTR2kZNxUHLdZYPAf9ADU6d11WhHIdRF708 nOOg== X-Gm-Message-State: AODbwcDiE5qPJ9ddpF+BWnl+R2bKER7BdS8ZJ2Kc4QaBcbmlzkcT4hG0 X6LdQpjxaGhnVs5QLp3CM9ZLVHwB7usd X-Received: by 10.223.183.31 with SMTP id l31mr509460wre.115.1495728018233; Thu, 25 May 2017 09:00:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 09:00:17 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> From: Tom Herbert Date: Thu, 25 May 2017 09:00:17 -0700 Message-ID: To: Xuxiaohu Cc: Joe Touch , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 16:00:26 -0000 On Mon, May 22, 2017 at 7:49 PM, Xuxiaohu wrote: > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Tom Herbert [mailto:tom@herbertland.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8821=E6=97=A5= 0:01 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> =E6=8A=84=E9=80=81: Joe Touch; int-area@ietf.org >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: [Int-are= a] =E7=AD=94=E5=A4=8D: Is the UDP destination port number >> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> On Fri, May 19, 2017 at 11:09 PM, Xuxiaohu wrote: >> > >> > >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:touch@isi.edu] >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8820=E6=97= =A5 12:15 >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Tom Herbert >> >> =E6=8A=84=E9=80=81: int-area@ietf.org >> >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [Int-area] =E7=AD=94=E5= =A4=8D: Is the UDP destination port number >> >> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> >> >> >> >> >> On 5/19/2017 8:57 PM, Xuxiaohu wrote: >> >> > Hi Joe, >> >> > >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:touch@isi.edu] >> >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8820=E6= =97=A5 11:41 >> >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Tom Herbert >> >> >> =E6=8A=84=E9=80=81: int-area@ietf.org >> >> >> =E4=B8=BB=E9=A2=98: Re: [Int-area] =E7=AD=94=E5=A4=8D: Is the UDP = destination port number resource >> >> >> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> >> >> >> >> >> >> >> >> >> On 5/19/2017 6:39 PM, Xuxiaohu wrote: >> >> >>> If the saving is beneficial, it'd better to assign a dedicated >> >> >>> port number for each UDP payload type( e.g., IP packet), rather >> >> >>> than combining the UDP port number dedicated for GUE and the >> >> >>> version field within the GUE header together to indicate whether >> >> >>> the UDP payload is GUE or IP (or even other payload type if the >> >> >>> GUE is devoted to help save the UDP port number resource for the >> >> >>> IETF >> >> >>> community:)) >> >> >> FWIW, IANA strives to assign one port for a service. >> >> > Great. Hence IPvx should be taken as a service rather than taking >> >> > IPvx and >> >> GUE as a service, IMO. >> >> GUE is supposed to be both signalling and content (data), where the >> >> data are IP packets. >> > >> > Since IANA strives to assign one port for a service, IP packet within = the UDP >> tunnel should be assigned a dedicated port. In other words, GUE and IP-i= n-UDP >> are distinguished by the different port numbers. >> > >> >> Take away the IP part and GUE isn't an E anymore. >> >> >> Services are expected to have version fields and subtype >> >> >> demultiplexing indicators, to so that all message variants of >> >> >> current and future versions can use a single port number. >> >> > Sure, the version field within the IPvx packet could be used for >> >> > demultiplexing >> >> purpose. >> >> >> >> That demultiplexes within IPvx. There still needs to be a way to >> >> demultiplex non-IPvx packets (control) from IPvx. >> > >> > Since GUE and IP-in-UDP have different UDP port numbers, I don't know = why >> there is still a need to demultiplex GUE and IP-in-UDP. >> > >> It's header compression. Consider a scenario that GUE is tunneling >> IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel ingre= ss. >> So some packets will have a fragmentation option and some won't. For >> unfragmented packets with no GUE options, they can be sent in direct >> encapsulation of IP. This could be done as version 1 of GUE or in IP-in-= UDP as >> you're suggesting. The problem with the latter is that it doubles the nu= mber of >> flows in the network. So instead of punching one hole for a tunnel in a = firewall >> we need two (the fragment tunnel and non-fragment UDP ports). Packets in >> individual flows now can take different paths depending on whether they'= re >> fragmented so this introduces OOO. > > Since GUE is intended to be a generic UDP encapsulation, now let's assume= GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once th= ose encapsulations have the same requirement of saving the 4-byte GUE base = header overhead as the encapsulation of IP in UDP. > Xiaohu, GUE encapsulates by IP protocol, I don't believe there is a protocol number for NSH or BIER so they should not be encapsulated in version 1. There is a protocol number for MPLS-IP, however there is no fixed field in the MPLS header (like the IP version) so the overlay technique can't work. Furthermore, these three protocols are already encapsulations, the optimization makes the most sense for simple network protocols that are not encapsulations. IPv4 and IPv6 can be directly encapsulated since they have a protocol number (can be encapsulated by version 0). As I mentioned previously, Ethernet could be directly encapsulated via EtherIP that has a 4 bit version number at the beginning of its header. The way this would work is to set a version 1 pattern to indicate EtherIP. For example, we could specify that 0101 would be EtherIP. When GUE receives such a packet it will notice it's version one and then see that it is EtherIP (differentiated from IPv4 0100 and IPv6 0110 values). The first four bits are then overwritten by 0011 to make it a valid EtherIP header and then the packet is resubmitted to the stack as EtherIP. Transport protocols (TCP, UDP, SCTP) might also be nice to support with direct encapsulation in version 1, but unfortunately since they start with a variable port number there's no way to do that. Tom > Best regards, > Xiaohu > >> Tom >> >> > Xiaohu >> > >> >> Joe From nobody Thu May 25 10:44:51 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB22129B84 for ; Thu, 25 May 2017 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] 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 7kCu9e5-aYgr for ; Thu, 25 May 2017 10:44:48 -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 1C543127011 for ; Thu, 25 May 2017 10:44:48 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v4PHiS8j018101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 10:44:29 -0700 (PDT) To: Tom Herbert , Xuxiaohu Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> From: Joe Touch Message-ID: Date: Thu, 25 May 2017 10:44:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-MailScanner-ID: v4PHiS8j018101 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 17:44:49 -0000 Hi, Tom, On 5/25/2017 9:00 AM, Tom Herbert wrote: > IPv4 and IPv6 can be directly encapsulated since they have a protocol > number (can be encapsulated by version 0). > > As I mentioned previously, Ethernet could be directly encapsulated via > EtherIP that has a 4 bit version number at the beginning of its > header. The way this would work is to set a version 1 pattern to > indicate EtherIP. For example, we could specify that 0101 would be > EtherIP. When GUE receives such a packet it will notice it's version > one and then see that it is EtherIP (differentiated from IPv4 0100 and > IPv6 0110 values). The first four bits are then overwritten by 0011 to > make it a valid EtherIP header and then the packet is resubmitted to > the stack as EtherIP. If you use the first 4 bits as the type identifier (which I think you should, as noted below), then you could easily support a bunch of encapsulations without needing the 4-byte overhead. E.g.: 0000 = GUE control (your "Version 0") 0100 = IPv4 0101 = IPv6 That leaves 13 other codes you can use for other protocols (including MPLS, Ethernet, etc.), as long as you burn at least those 4 bits. EtherIP effectively burns 2 bytes rather than 4 bits, but has the same net effect. > Transport protocols (TCP, UDP, SCTP) might also be nice to support > with direct encapsulation in version 1, but unfortunately since they > start with a variable port number there's no way to do that. That works the same way as EtherIP - burn at least 4 bits indicating the transport. Joe ------ >From my previous post: When we look at the first 2 bits of a GUE packet, we see: 00 = GUE version 0 01 = IPv4 or IPv6 10 = undefined 11 = undefined That's nearly the same as looking at the first 4 bits as simply the IP version number, and defining some of the unused IP versions as control: 0000 (IPv0) = GUE control 0001 (IPv1) = GUE control 0010 (IPv2) = GUE encapsulation using the GUE header 0011 (IPv3) = GUE encapsulation using the GUE header 0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE header 0101 (IPv5) = direct encapsulation of IPv5 (ST), with no intervening GUE header 0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE header 0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no intervening GUE header 1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no intervening GUE header 1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no intervening GUE header 1010 (IPv10) = direct encapsulation of IPv10, when assigned 1010 (IPv11) = direct encapsulation of IPv11, when assigned 1010 (IPv12) = direct encapsulation of IPv12, when assigned 1010 (IPv13) = direct encapsulation of IPv13, when assigned 1010 (IPv14) = direct encapsulation of IPv14, when assigned 1010 (IPv15) = direct encapsulation of IPv15, when assigned I.e., all you're basically doing is defining the first four version numbers of IP as your control plane. Unless we come back and assign them in the future, any mechanism that encapsulates IP packets (which should, IMO, be able to handle ALL IP versions, by definition) should be able to include GUE-style signaling. IMO, it's simpler to explain this all using this fixed-field demultiplexer - in which case, you could even use just the IPv0 pattern for control and the IPv1 pattern for encapsulation using the GUE header, leaving the IPv2 and IPv3 equivalent patterns for future expansion. Joe From nobody Thu May 25 11:27:07 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC47C124D85 for ; Thu, 25 May 2017 11:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 S8k4W19Vdgwe for ; Thu, 25 May 2017 11:27:04 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 EAFEF126C3D for ; Thu, 25 May 2017 11:27:03 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id d127so108433481wmf.0 for ; Thu, 25 May 2017 11:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M1jTFDVAwxqQlU7A0KUDdAznnJqM4O9ieYebwXjnwl4=; b=M98xGzTib6YQE2B4SzpAyuPCCjSCSmjy6KzJ4x+8q9HWBal3fV5VkDct1kjt5N5QVx 9D7SRP0OLnjuXS/KtXAz/9l5ML4/J6P0qo5ywbDEKKCNyswttQ5BZ4gPUSsyBQ4UFx4S px9pj2JllWiNqm+fX1e7mRO86q6FCrbJzcdJPWIWbvI383MlUlMRdMP5HDiDqbPrMYbb Tk0HIDjKw0E/zGxW5cGeniT6bidKG44NBS43QG8iKQlySUDI4woZlL0p1dycLNUmieJv bzkd8M5ILGBgQ7e9T8CdSC/4GvBaszjN6uKo/0V3IqvGKJTQ/hJDbc9dgxTqTg1vBbff urRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M1jTFDVAwxqQlU7A0KUDdAznnJqM4O9ieYebwXjnwl4=; b=UAmKWfdDM69+ULjgkBnsf89g44N9rxt1nTXj51cTFAX0MSTKZRkPpGESwOXl/6H/up xghyi0XRpNVJUZixbs1JXxGYi8ihaj+cRHLSVWH6M6AYLrKzsb/IG6KoGtuk+u4orgct KbHQgjLPItnJGerYiKcfWH4SsVU9tjhkTifaaoMvID+SG6PMeZdEPdP6haJrJwYpvfDz LKkivpAAmErX6gevtrYU0K/DIYcTk2alm0lAqU6P3pJb7pq4syMsByztF4HK02tNE/PU Cyo1Utp+bR8ovASxY6sGhdsdw4nlTIRh3zPLVDwtSpPmHQPpfj5HSUJPAOjLJa/pFbhJ 78Ug== X-Gm-Message-State: AODbwcAv+dsJMF6XAHcnJfcARyBoBiEkPs12McHddzcm1ZBi4Zmjbwtj CJjVFoumjJEuI/0UCCjATSciMVPbfJIQ X-Received: by 10.28.56.198 with SMTP id f189mr10101139wma.111.1495736822325; Thu, 25 May 2017 11:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 11:27:01 -0700 (PDT) In-Reply-To: References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> From: Tom Herbert Date: Thu, 25 May 2017 11:27:01 -0700 Message-ID: To: Joe Touch Cc: Xuxiaohu , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:27:06 -0000 On Thu, May 25, 2017 at 10:44 AM, Joe Touch wrote: > Hi, Tom, > > On 5/25/2017 9:00 AM, Tom Herbert wrote: >> IPv4 and IPv6 can be directly encapsulated since they have a protocol >> number (can be encapsulated by version 0). >> >> As I mentioned previously, Ethernet could be directly encapsulated via >> EtherIP that has a 4 bit version number at the beginning of its >> header. The way this would work is to set a version 1 pattern to >> indicate EtherIP. For example, we could specify that 0101 would be >> EtherIP. When GUE receives such a packet it will notice it's version >> one and then see that it is EtherIP (differentiated from IPv4 0100 and >> IPv6 0110 values). The first four bits are then overwritten by 0011 to >> make it a valid EtherIP header and then the packet is resubmitted to >> the stack as EtherIP. > If you use the first 4 bits as the type identifier (which I think you > should, as noted below), then you could easily support a bunch of > encapsulations without needing the 4-byte overhead. > > E.g.: > 0000 = GUE control (your "Version 0") > 0100 = IPv4 > 0101 = IPv6 > > That leaves 13 other codes you can use for other protocols (including > MPLS, Ethernet, etc.), as long as you burn at least those 4 bits. > Right, although even with 00 for version zero there's still enough for ten other codes which is a lot. > EtherIP effectively burns 2 bytes rather than 4 bits, but has the same > net effect. > >> Transport protocols (TCP, UDP, SCTP) might also be nice to support >> with direct encapsulation in version 1, but unfortunately since they >> start with a variable port number there's no way to do that. > That works the same way as EtherIP - burn at least 4 bits indicating the > transport. EtherIP begins with a fixed version number, for the transport protocols we would be overwriting the source port with no way to recover the bits. > > Joe > > ------ > From my previous post: > > When we look at the first 2 bits of a GUE packet, we see: > 00 = GUE version 0 > 01 = IPv4 or IPv6 > 10 = undefined > 11 = undefined > > That's nearly the same as looking at the first 4 bits as simply the IP > version number, and defining some of the unused IP versions as control: > 0000 (IPv0) = GUE control > 0001 (IPv1) = GUE control > 0010 (IPv2) = GUE encapsulation using the GUE header > 0011 (IPv3) = GUE encapsulation using the GUE header > 0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE > header > 0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni > GUE header > 0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE > header > 0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no > intervening GUE header > 1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no > intervening GUE header > 1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no > intervening GUE header > 1010 (IPv10) = direct encapsulation of IPv10, when assigned > 1010 (IPv11) = direct encapsulation of IPv11, when assigned > 1010 (IPv12) = direct encapsulation of IPv12, when assigned > 1010 (IPv13) = direct encapsulation of IPv13, when assigned > 1010 (IPv14) = direct encapsulation of IPv14, when assigned > 1010 (IPv15) = direct encapsulation of IPv15, when assigned > > I.e., all you're basically doing is defining the first four version > numbers of IP as your control plane. Unless we come back and assign them > in the future, any mechanism that encapsulates IP packets (which should, > IMO, be able to handle ALL IP versions, by definition) should be able to > include GUE-style signaling. > Right, this scheme could work to generally encapsulate different IP versions. There is a caveat though: AFAIK there is no IP protocol number to encapsulate any IP protocols other then IPv4 (IPIP 94) and IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means they need a protocol number. Version 1 is header compression for version 0 so the there must be a way to encapsulate the protocol using version 0. What would resolve that is a new IP protocol number for encapsulating a packet of any IP version and use the IP version itself to differentiate. Tom > IMO, it's simpler to explain this all using this fixed-field > demultiplexer - in which case, you could even use just the IPv0 pattern > for control and the IPv1 pattern for encapsulation using the GUE header, > leaving the IPv2 and IPv3 equivalent patterns for future expansion. > > Joe > > From nobody Thu May 25 11:34:56 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6C127B73 for ; Thu, 25 May 2017 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 5QKenrDJir2s for ; Thu, 25 May 2017 11:34:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 AB297126BFD for ; Thu, 25 May 2017 11:34:52 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PIXndE006223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 11:33:50 -0700 (PDT) To: Tom Herbert Cc: Xuxiaohu , "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> From: Joe Touch Message-ID: <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> Date: Thu, 25 May 2017 11:33:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:34:54 -0000 On 5/25/2017 11:27 AM, Tom Herbert wrote: > On Thu, May 25, 2017 at 10:44 AM, Joe Touch wrote: >> Hi, Tom, >> >> On 5/25/2017 9:00 AM, Tom Herbert wrote: >>> IPv4 and IPv6 can be directly encapsulated since they have a protocol >>> number (can be encapsulated by version 0). >>> >>> As I mentioned previously, Ethernet could be directly encapsulated via >>> EtherIP that has a 4 bit version number at the beginning of its >>> header. The way this would work is to set a version 1 pattern to >>> indicate EtherIP. For example, we could specify that 0101 would be >>> EtherIP. When GUE receives such a packet it will notice it's version >>> one and then see that it is EtherIP (differentiated from IPv4 0100 and >>> IPv6 0110 values). The first four bits are then overwritten by 0011 to >>> make it a valid EtherIP header and then the packet is resubmitted to >>> the stack as EtherIP. >> If you use the first 4 bits as the type identifier (which I think you >> should, as noted below), then you could easily support a bunch of >> encapsulations without needing the 4-byte overhead. >> >> E.g.: >> 0000 = GUE control (your "Version 0") >> 0100 = IPv4 >> 0101 = IPv6 >> >> That leaves 13 other codes you can use for other protocols (including >> MPLS, Ethernet, etc.), as long as you burn at least those 4 bits. >> > Right, although even with 00 for version zero there's still enough for > ten other codes which is a lot. Yes, but there's very little benefit in looking at 2 bits vs 4. That would matter only for serial processing and saves far too little to be worthwhile IMO. It also complicates the way the protocol is described (I personally find it confusing; it's a lot more obvious to just say that you use IPv0 for control, IPv1 for encapsulation, and other IP versions are included without overriding headers). > >> EtherIP effectively burns 2 bytes rather than 4 bits, but has the same >> net effect. >> >>> Transport protocols (TCP, UDP, SCTP) might also be nice to support >>> with direct encapsulation in version 1, but unfortunately since they >>> start with a variable port number there's no way to do that. >> That works the same way as EtherIP - burn at least 4 bits indicating the >> transport. > EtherIP begins with a fixed version number, for the transport > protocols we would be overwriting the source port with no way to > recover the bits. You can't put bare Ethernet inside GUE. You need to use EtherIP - exactly because it has a 16-bit field, of which only the first 4 bits are (already) defined. My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 bits allow it to be mapped to one of the IP versions (you picked IPv5). The same trick works for UDP and TCP - just pick a different 16 bit pattern for each one. The catch is that EtherIP and these corresponding tricks for UDP and TCP end up burning 16 bits more than the bare packet would, but that's still less than the GUE encapsulation header burns. Joe > >> Joe >> >> ------ >> From my previous post: >> >> When we look at the first 2 bits of a GUE packet, we see: >> 00 = GUE version 0 >> 01 = IPv4 or IPv6 >> 10 = undefined >> 11 = undefined >> >> That's nearly the same as looking at the first 4 bits as simply the IP >> version number, and defining some of the unused IP versions as control: >> 0000 (IPv0) = GUE control >> 0001 (IPv1) = GUE control >> 0010 (IPv2) = GUE encapsulation using the GUE header >> 0011 (IPv3) = GUE encapsulation using the GUE header >> 0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE >> header >> 0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni >> GUE header >> 0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE >> header >> 0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no >> intervening GUE header >> 1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no >> intervening GUE header >> 1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no >> intervening GUE header >> 1010 (IPv10) = direct encapsulation of IPv10, when assigned >> 1010 (IPv11) = direct encapsulation of IPv11, when assigned >> 1010 (IPv12) = direct encapsulation of IPv12, when assigned >> 1010 (IPv13) = direct encapsulation of IPv13, when assigned >> 1010 (IPv14) = direct encapsulation of IPv14, when assigned >> 1010 (IPv15) = direct encapsulation of IPv15, when assigned >> >> I.e., all you're basically doing is defining the first four version >> numbers of IP as your control plane. Unless we come back and assign them >> in the future, any mechanism that encapsulates IP packets (which should, >> IMO, be able to handle ALL IP versions, by definition) should be able to >> include GUE-style signaling. >> > Right, this scheme could work to generally encapsulate different IP > versions. There is a caveat though: AFAIK there is no IP protocol > number to encapsulate any IP protocols other then IPv4 (IPIP 94) and > IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means > they need a protocol number. Version 1 is header compression for > version 0 so the there must be a way to encapsulate the protocol using > version 0. What would resolve that is a new IP protocol number for > encapsulating a packet of any IP version and use the IP version itself > to differentiate. > > Tom > >> IMO, it's simpler to explain this all using this fixed-field >> demultiplexer - in which case, you could even use just the IPv0 pattern >> for control and the IPv1 pattern for encapsulation using the GUE header, >> leaving the IPv2 and IPv3 equivalent patterns for future expansion. >> >> Joe >> >> From nobody Thu May 25 11:48:00 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50312AF84 for ; Thu, 25 May 2017 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 wayaFmg-RxVL for ; Thu, 25 May 2017 11:47:56 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 6F3F112AF6E for ; Thu, 25 May 2017 11:47:56 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id d127so109102608wmf.0 for ; Thu, 25 May 2017 11:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e3n1No5zDeUlbGdIs1guDf1Yu3P3mVl15qjdTukgl5w=; b=nBNXIG8vYM7kx4wY5ssCKiIBf5DPRF/W3k84G/vda8bCPYI0069C2I0LJ+E3z/GD79 bPSAB+sSmbpE7Wpcg4nsXfEu2vE0I+Ub9JU29oqLKcvPuryvXaBLf37t9LvvZ5TzWqOu 3V2eV7Zibf17DMz9BGPnQQEnoCAb9Q5OWX7K6oPMWFhcfXejKTSLnQWnjaeKcBbBg+By moarMK+XdAOObNvhzE6z0sqV2Rp6IRJ7hn13h2smgxVK3teH2KvKgMVeipMjZDWuK47w oLRqfRwpIGItFt6AfmOAgKQYvt3h3Nb7TDHWktHoWEvNrJ/A4wXfl5C+37RP9AVCjtGr 7qEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e3n1No5zDeUlbGdIs1guDf1Yu3P3mVl15qjdTukgl5w=; b=jChIYN/ku6bxc3VSLaZSHz7SUsjlj+fmicHnCedyj0bPSrjpy3P4oTykwNQ6Br1u5r 8cN4kAlkjQgTNqi6e5RyVe1WQFL4hVa4nuczh0dlgc92nRwq9+CPAfd3nGkUs2l6TwVG M7h57H49SjsVnC+1i0fDS1sE7rZFs1L4Vh3x4lPpZ4hmL9aWtheL3jEVzQaLybWDVWxF j/xjYYsb5hT7E2x/S77NQQO54ueWjjzdzEaJeuF8sQaw/9Sts2CaiAI5i4VwyL98f/63 Nt0M/Q5A/m3dJnm2wGIevPu9y6UDSSxTxtPkIqN0beVlkorS24O+HQ8iUc54p4LOG5D2 2LSw== X-Gm-Message-State: AODbwcAWk0BUfS3CU8uhjzc25xJAb6zF41qFryjvMeoM4M5qGCyfyC+o DDM85ZGaTjbhA0bOxwpA0rie+yFDeuSl X-Received: by 10.223.160.68 with SMTP id l4mr22733342wrl.52.1495738074765; Thu, 25 May 2017 11:47:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 11:47:54 -0700 (PDT) In-Reply-To: <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> From: Tom Herbert Date: Thu, 25 May 2017 11:47:54 -0700 Message-ID: To: Joe Touch Cc: Xuxiaohu , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:47:59 -0000 On Thu, May 25, 2017 at 11:33 AM, Joe Touch wrote: > > > On 5/25/2017 11:27 AM, Tom Herbert wrote: >> On Thu, May 25, 2017 at 10:44 AM, Joe Touch wrote: >>> Hi, Tom, >>> >>> On 5/25/2017 9:00 AM, Tom Herbert wrote: >>>> IPv4 and IPv6 can be directly encapsulated since they have a protocol >>>> number (can be encapsulated by version 0). >>>> >>>> As I mentioned previously, Ethernet could be directly encapsulated via >>>> EtherIP that has a 4 bit version number at the beginning of its >>>> header. The way this would work is to set a version 1 pattern to >>>> indicate EtherIP. For example, we could specify that 0101 would be >>>> EtherIP. When GUE receives such a packet it will notice it's version >>>> one and then see that it is EtherIP (differentiated from IPv4 0100 and >>>> IPv6 0110 values). The first four bits are then overwritten by 0011 to >>>> make it a valid EtherIP header and then the packet is resubmitted to >>>> the stack as EtherIP. >>> If you use the first 4 bits as the type identifier (which I think you >>> should, as noted below), then you could easily support a bunch of >>> encapsulations without needing the 4-byte overhead. >>> >>> E.g.: >>> 0000 = GUE control (your "Version 0") >>> 0100 = IPv4 >>> 0101 = IPv6 >>> >>> That leaves 13 other codes you can use for other protocols (including >>> MPLS, Ethernet, etc.), as long as you burn at least those 4 bits. >>> >> Right, although even with 00 for version zero there's still enough for >> ten other codes which is a lot. > > Yes, but there's very little benefit in looking at 2 bits vs 4. That > would matter only for serial processing and saves far too little to be > worthwhile IMO. It also complicates the way the protocol is described (I > personally find it confusing; it's a lot more obvious to just say that > you use IPv0 for control, IPv1 for encapsulation, and other IP versions > are included without overriding headers). > >> >>> EtherIP effectively burns 2 bytes rather than 4 bits, but has the same >>> net effect. >>> >>>> Transport protocols (TCP, UDP, SCTP) might also be nice to support >>>> with direct encapsulation in version 1, but unfortunately since they >>>> start with a variable port number there's no way to do that. >>> That works the same way as EtherIP - burn at least 4 bits indicating the >>> transport. >> EtherIP begins with a fixed version number, for the transport >> protocols we would be overwriting the source port with no way to >> recover the bits. > You can't put bare Ethernet inside GUE. You need to use EtherIP - > exactly because it has a 16-bit field, of which only the first 4 bits > are (already) defined. > > My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 > bits allow it to be mapped to one of the IP versions (you picked IPv5). > The same trick works for UDP and TCP - just pick a different 16 bit > pattern for each one. > Inserting two bytes before the TCP header breaks four byte alignment of the header which is a bigger hit than the benefit of saving two bytes. A nice side effect of the two byte header in EtherIP is that it aligns the Ethernet payload (e.g. an IP header) to four bytes. Maintaining this four byte alignment is still important to some CPU architectures most notably Sparc, but can even be problematic to x86 under certain circumstances. Tom > The catch is that EtherIP and these corresponding tricks for UDP and TCP > end up burning 16 bits more than the bare packet would, but that's still > less than the GUE encapsulation header burns. > > Joe >> >>> Joe >>> >>> ------ >>> From my previous post: >>> >>> When we look at the first 2 bits of a GUE packet, we see: >>> 00 = GUE version 0 >>> 01 = IPv4 or IPv6 >>> 10 = undefined >>> 11 = undefined >>> >>> That's nearly the same as looking at the first 4 bits as simply the IP >>> version number, and defining some of the unused IP versions as control: >>> 0000 (IPv0) = GUE control >>> 0001 (IPv1) = GUE control >>> 0010 (IPv2) = GUE encapsulation using the GUE header >>> 0011 (IPv3) = GUE encapsulation using the GUE header >>> 0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE >>> header >>> 0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni >>> GUE header >>> 0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE >>> header >>> 0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no >>> intervening GUE header >>> 1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no >>> intervening GUE header >>> 1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no >>> intervening GUE header >>> 1010 (IPv10) = direct encapsulation of IPv10, when assigned >>> 1010 (IPv11) = direct encapsulation of IPv11, when assigned >>> 1010 (IPv12) = direct encapsulation of IPv12, when assigned >>> 1010 (IPv13) = direct encapsulation of IPv13, when assigned >>> 1010 (IPv14) = direct encapsulation of IPv14, when assigned >>> 1010 (IPv15) = direct encapsulation of IPv15, when assigned >>> >>> I.e., all you're basically doing is defining the first four version >>> numbers of IP as your control plane. Unless we come back and assign them >>> in the future, any mechanism that encapsulates IP packets (which should, >>> IMO, be able to handle ALL IP versions, by definition) should be able to >>> include GUE-style signaling. >>> >> Right, this scheme could work to generally encapsulate different IP >> versions. There is a caveat though: AFAIK there is no IP protocol >> number to encapsulate any IP protocols other then IPv4 (IPIP 94) and >> IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means >> they need a protocol number. Version 1 is header compression for >> version 0 so the there must be a way to encapsulate the protocol using >> version 0. What would resolve that is a new IP protocol number for >> encapsulating a packet of any IP version and use the IP version itself >> to differentiate. >> >> Tom >> >>> IMO, it's simpler to explain this all using this fixed-field >>> demultiplexer - in which case, you could even use just the IPv0 pattern >>> for control and the IPv1 pattern for encapsulation using the GUE header, >>> leaving the IPv2 and IPv3 equivalent patterns for future expansion. >>> >>> Joe >>> >>> > From nobody Thu May 25 12:08:38 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09CC12940D for ; Thu, 25 May 2017 12:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 axDjvppKTRA6 for ; Thu, 25 May 2017 12:08:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 8BC411200CF for ; Thu, 25 May 2017 12:08:35 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PJ7hD6010680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 12:07:45 -0700 (PDT) To: Tom Herbert Cc: Xuxiaohu , "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> From: Joe Touch Message-ID: <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> Date: Thu, 25 May 2017 12:07:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------542EF687F133E5FF0556E82D" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:08:37 -0000 This is a multi-part message in MIME format. --------------542EF687F133E5FF0556E82D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/25/2017 11:47 AM, Tom Herbert wrote: >> You can't put bare Ethernet inside GUE. You need to use EtherIP - >> exactly because it has a 16-bit field, of which only the first 4 bits >> are (already) defined. >> >> My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 >> bits allow it to be mapped to one of the IP versions (you picked IPv5). >> The same trick works for UDP and TCP - just pick a different 16 bit >> pattern for each one. >> > Inserting two bytes before the TCP header breaks four byte alignment > of the header which is a bigger hit than the benefit of saving two > bytes. A nice side effect of the two byte header in EtherIP is that it > aligns the Ethernet payload (e.g. an IP header) to four bytes. > Maintaining this four byte alignment is still important to some CPU > architectures most notably Sparc, but can even be problematic to x86 > under certain circumstances. > > Tom Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any case, frankly -- even for IP. Joe --------------542EF687F133E5FF0556E82D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 5/25/2017 11:47 AM, Tom Herbert wrote:
You can't put bare Ethernet inside GUE. You need to use EtherIP -
exactly because it has a 16-bit field, of which only the first 4 bits
are (already) defined.

My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16
bits allow it to be mapped to one of the IP versions (you picked IPv5).
The same trick works for UDP and TCP - just pick a different 16 bit
pattern for each one.


Inserting two bytes before the TCP header breaks four byte alignment
of the header which is a bigger hit than the benefit of saving two
bytes. A nice side effect of the two byte header in EtherIP is that it
aligns the Ethernet payload (e.g. an IP header) to four bytes.
Maintaining this four byte alignment is still important to some CPU
architectures most notably Sparc, but can even be problematic to x86
under certain circumstances.

Tom
Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any case, frankly -- even for IP.

Joe
--------------542EF687F133E5FF0556E82D-- From nobody Thu May 25 12:14:44 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D304112945A for ; Thu, 25 May 2017 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 0avmyoft4chU for ; Thu, 25 May 2017 12:14:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 924F5129449 for ; Thu, 25 May 2017 12:14:41 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PJDs2p011406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 12:13:55 -0700 (PDT) From: Joe Touch To: Tom Herbert Cc: Xuxiaohu , "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> Message-ID: <29a541ec-7457-933c-56fd-8a699634385e@isi.edu> Date: Thu, 25 May 2017 12:13:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> Content-Type: multipart/alternative; boundary="------------054E09929C64B83823FE993F" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:14:43 -0000 This is a multi-part message in MIME format. --------------054E09929C64B83823FE993F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FWIW, my general concern with this service is that lacks a version identifier, and cannot be extended to support such an identifier for bare IP packets as payloads, as encouraged by RFC7605 Section 7.5 At a minimum, one of the first fields after the "Version 0" format identifier (a name which is confusing, for this reason) needs to be a version field, so that future variants of this service will not need a new port assignment. Joe On 5/25/2017 12:07 PM, Joe Touch wrote: > > > > On 5/25/2017 11:47 AM, Tom Herbert wrote: >>> You can't put bare Ethernet inside GUE. You need to use EtherIP - >>> exactly because it has a 16-bit field, of which only the first 4 bits >>> are (already) defined. >>> >>> My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 >>> bits allow it to be mapped to one of the IP versions (you picked IPv5). >>> The same trick works for UDP and TCP - just pick a different 16 bit >>> pattern for each one. >>> >> Inserting two bytes before the TCP header breaks four byte alignment >> of the header which is a bigger hit than the benefit of saving two >> bytes. A nice side effect of the two byte header in EtherIP is that it >> aligns the Ethernet payload (e.g. an IP header) to four bytes. >> Maintaining this four byte alignment is still important to some CPU >> architectures most notably Sparc, but can even be problematic to x86 >> under certain circumstances. >> >> Tom > Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly > any case, frankly -- even for IP. > > Joe --------------054E09929C64B83823FE993F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

FWIW, my general concern with this service is that lacks a version identifier, and cannot be extended to support such an identifier for bare IP packets as payloads, as encouraged by RFC7605 Section 7.5

At a minimum, one of the first fields after the "Version 0" format identifier (a name which is confusing, for this reason) needs to be a version field, so that future variants of this service will not need a new port assignment.

Joe


On 5/25/2017 12:07 PM, Joe Touch wrote:



On 5/25/2017 11:47 AM, Tom Herbert wrote:
You can't put bare Ethernet inside GUE. You need to use EtherIP -
exactly because it has a 16-bit field, of which only the first 4 bits
are (already) defined.

My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16
bits allow it to be mapped to one of the IP versions (you picked IPv5).
The same trick works for UDP and TCP - just pick a different 16 bit
pattern for each one.


Inserting two bytes before the TCP header breaks four byte alignment
of the header which is a bigger hit than the benefit of saving two
bytes. A nice side effect of the two byte header in EtherIP is that it
aligns the Ethernet payload (e.g. an IP header) to four bytes.
Maintaining this four byte alignment is still important to some CPU
architectures most notably Sparc, but can even be problematic to x86
under certain circumstances.

Tom
Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any case, frankly -- even for IP.

Joe

--------------054E09929C64B83823FE993F-- From nobody Thu May 25 12:44:26 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA432127ABE for ; Thu, 25 May 2017 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7me_2F3zyTKj for ; Thu, 25 May 2017 12:44:22 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 B83BE12700F for ; Thu, 25 May 2017 12:44:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4PJiLVu021473; Thu, 25 May 2017 12:44:22 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4PJiIVJ021425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 25 May 2017 12:44:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 25 May 2017 12:44:17 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 25 May 2017 12:44:17 -0700 From: "Templin, Fred L" To: Joe Touch , Tom Herbert CC: "int-area@ietf.org" Thread-Topic: =?utf-8?B?W0ludC1hcmVhXSDnrZTlpI06IOetlOWkjTog562U5aSNOiAg562U5aSNOiBJ?= =?utf-8?B?cyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1?= =?utf-8?B?bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFy?= =?utf-8?Q?ea-gue-04.txt?= Thread-Index: AQHS1YpZcMPCykwF7kes5feA57QyOqIFcv6w Date: Thu, 25 May 2017 19:44:17 +0000 Message-ID: References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> In-Reply-To: <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b1d251aff62c45d392c2ee8c1b3828b2XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:44:25 -0000 --_000_b1d251aff62c45d392c2ee8c1b3828b2XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IGFyZSB0YWxraW5nIGFib3V0IHRoZSBHVUUgZGlyZWN0IGVuY2Fwc3VsYXRpb24gb2Yg SVB2NCBhbmQgSVB2NiwgSSBhZ3JlZQ0Kd2l0aCB0aGUgY3VycmVudCBzcGVjIGFuZCB0aGF0IGRp cmVjdCBlbmNhcHN1bGF0aW9uIChpLmUuLCB3aXRoIG5vIGFkZGl0aW9uYWwNCmVuY2Fwc3VsYXRp b25zIGJldHdlZW4gdGhlIElQL1VEUCBhbmQgaW5uZXIgSVAgaGVhZGVycykgaXMgZGVzaXJhYmxl IGFuZA0Kc2hvdWxkIHJlbWFpbiBhcyBwYXJ0IG9mIHRoZSBzcGVjLiBJIHRoaW5rIHdlIG1heSBi ZSBvdmVyLXRoaW5raW5nIHRoaXMuDQoNCkZyZWQNCg0KRnJvbTogSW50LWFyZWEgW21haWx0bzpp bnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lIFRvdWNoDQpTZW50OiBU aHVyc2RheSwgTWF5IDI1LCAyMDE3IDEyOjA4IFBNDQpUbzogVG9tIEhlcmJlcnQgPHRvbUBoZXJi ZXJ0bGFuZC5jb20+DQpDYzogaW50LWFyZWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW50LWFy ZWFdIOetlOWkjTog562U5aSNOiDnrZTlpI06IOetlOWkjTogSXMgdGhlIFVEUCBkZXN0aW5hdGlv biBwb3J0IG51bWJlciByZXNvdXJjZSBydW5uaW5nIG91dD8vLyByZTogSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1pbnRhcmVhLWd1ZS0wNC50eHQNCg0KDQoNCg0KT24gNS8yNS8yMDE3IDExOjQ3IEFN LCBUb20gSGVyYmVydCB3cm90ZToNCg0KWW91IGNhbid0IHB1dCBiYXJlIEV0aGVybmV0IGluc2lk ZSBHVUUuIFlvdSBuZWVkIHRvIHVzZSBFdGhlcklQIC0NCg0KZXhhY3RseSBiZWNhdXNlIGl0IGhh cyBhIDE2LWJpdCBmaWVsZCwgb2Ygd2hpY2ggb25seSB0aGUgZmlyc3QgNCBiaXRzDQoNCmFyZSAo YWxyZWFkeSkgZGVmaW5lZC4NCg0KDQoNCk15IHBvaW50IGlzIHRoYXQgRXRoZXJJUCBidXJucyAx NiBiaXRzIHZzIGJhcmUgRXRoZXJuZXQsIGJ1dCB0aG9zZSAxNg0KDQpiaXRzIGFsbG93IGl0IHRv IGJlIG1hcHBlZCB0byBvbmUgb2YgdGhlIElQIHZlcnNpb25zICh5b3UgcGlja2VkIElQdjUpLg0K DQpUaGUgc2FtZSB0cmljayB3b3JrcyBmb3IgVURQIGFuZCBUQ1AgLSBqdXN0IHBpY2sgYSBkaWZm ZXJlbnQgMTYgYml0DQoNCnBhdHRlcm4gZm9yIGVhY2ggb25lLg0KDQoNCg0KSW5zZXJ0aW5nIHR3 byBieXRlcyBiZWZvcmUgdGhlIFRDUCBoZWFkZXIgYnJlYWtzIGZvdXIgYnl0ZSBhbGlnbm1lbnQN Cg0Kb2YgdGhlIGhlYWRlciB3aGljaCBpcyBhIGJpZ2dlciBoaXQgdGhhbiB0aGUgYmVuZWZpdCBv ZiBzYXZpbmcgdHdvDQoNCmJ5dGVzLiBBIG5pY2Ugc2lkZSBlZmZlY3Qgb2YgdGhlIHR3byBieXRl IGhlYWRlciBpbiBFdGhlcklQIGlzIHRoYXQgaXQNCg0KYWxpZ25zIHRoZSBFdGhlcm5ldCBwYXls b2FkIChlLmcuIGFuIElQIGhlYWRlcikgdG8gZm91ciBieXRlcy4NCg0KTWFpbnRhaW5pbmcgdGhp cyBmb3VyIGJ5dGUgYWxpZ25tZW50IGlzIHN0aWxsIGltcG9ydGFudCB0byBzb21lIENQVQ0KDQph cmNoaXRlY3R1cmVzIG1vc3Qgbm90YWJseSBTcGFyYywgYnV0IGNhbiBldmVuIGJlIHByb2JsZW1h dGljIHRvIHg4Ng0KDQp1bmRlciBjZXJ0YWluIGNpcmN1bXN0YW5jZXMuDQoNCg0KDQpUb20NClN1 cmUgLSBJJ20gbm90IHN1cmUgdGhlIDQtYnl0ZSBwZW5hbHR5IGlzIHdvcnRoIGF2b2lkaW5nIGFu eSBuZWFybHkgYW55IGNhc2UsIGZyYW5rbHkgLS0gZXZlbiBmb3IgSVAuDQoNCkpvZQ0K --_000_b1d251aff62c45d392c2ee8c1b3828b2XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9y OmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhl IEdVRSBkaXJlY3QgZW5jYXBzdWxhdGlvbiBvZiBJUHY0IGFuZCBJUHY2LCBJIGFncmVlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPndpdGggdGhlIGN1cnJlbnQgc3BlYyBhbmQgdGhhdCBkaXJlY3QgZW5jYXBz dWxhdGlvbiAoaS5lLiwgd2l0aCBubyBhZGRpdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmVuY2Fw c3VsYXRpb25zIGJldHdlZW4gdGhlIElQL1VEUCBhbmQgaW5uZXIgSVAgaGVhZGVycykgaXMgZGVz aXJhYmxlIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zaG91bGQgcmVtYWluIGFzIHBhcnQgb2YgdGhl IHNwZWMuIEkgdGhpbmsgd2UgbWF5IGJlIG92ZXItdGhpbmtpbmcgdGhpcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gSW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2UgVG91Y2g8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE1heSAyNSwgMjAxNyAxMjowOCBQTTxicj4NCjxiPlRvOjwvYj4gVG9tIEhl cmJlcnQgJmx0O3RvbUBoZXJiZXJ0bGFuZC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpbnQtYXJl YUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0ludC1hcmVhXSA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7nrZTlpI08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjoNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij46DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPuetlOWkjTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+OiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBv cnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWludGFyZWEtZ3VlLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNS8yNS8yMDE3IDExOjQ3IEFNLCBU b20gSGVyYmVydCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+WW91IGNh bid0IHB1dCBiYXJlIEV0aGVybmV0IGluc2lkZSBHVUUuIFlvdSBuZWVkIHRvIHVzZSBFdGhlcklQ IC08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5leGFjdGx5IGJlY2F1c2UgaXQgaGFzIGEgMTYtYml0 IGZpZWxkLCBvZiB3aGljaCBvbmx5IHRoZSBmaXJzdCA0IGJpdHM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5hcmUgKGFscmVhZHkpIGRlZmluZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+TXkgcG9pbnQgaXMgdGhhdCBFdGhlcklQIGJ1cm5zIDE2 IGJpdHMgdnMgYmFyZSBFdGhlcm5ldCwgYnV0IHRob3NlIDE2PG86cD48L286cD48L3ByZT4NCjxw cmU+Yml0cyBhbGxvdyBpdCB0byBiZSBtYXBwZWQgdG8gb25lIG9mIHRoZSBJUCB2ZXJzaW9ucyAo eW91IHBpY2tlZCBJUHY1KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgc2FtZSB0cmljayB3 b3JrcyBmb3IgVURQIGFuZCBUQ1AgLSBqdXN0IHBpY2sgYSBkaWZmZXJlbnQgMTYgYml0PG86cD48 L286cD48L3ByZT4NCjxwcmU+cGF0dGVybiBmb3IgZWFjaCBvbmUuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SW5zZXJ0 aW5nIHR3byBieXRlcyBiZWZvcmUgdGhlIFRDUCBoZWFkZXIgYnJlYWtzIGZvdXIgYnl0ZSBhbGln bm1lbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vZiB0aGUgaGVhZGVyIHdoaWNoIGlzIGEgYmln Z2VyIGhpdCB0aGFuIHRoZSBiZW5lZml0IG9mIHNhdmluZyB0d288bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5ieXRlcy4gQSBuaWNlIHNpZGUgZWZmZWN0IG9mIHRoZSB0d28gYnl0ZSBoZWFkZXIgaW4g RXRoZXJJUCBpcyB0aGF0IGl0PG86cD48L286cD48L3ByZT4NCjxwcmU+YWxpZ25zIHRoZSBFdGhl cm5ldCBwYXlsb2FkIChlLmcuIGFuIElQIGhlYWRlcikgdG8gZm91ciBieXRlcy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5NYWludGFpbmluZyB0aGlzIGZvdXIgYnl0ZSBhbGlnbm1lbnQgaXMgc3Rp bGwgaW1wb3J0YW50IHRvIHNvbWUgQ1BVPG86cD48L286cD48L3ByZT4NCjxwcmU+YXJjaGl0ZWN0 dXJlcyBtb3N0IG5vdGFibHkgU3BhcmMsIGJ1dCBjYW4gZXZlbiBiZSBwcm9ibGVtYXRpYyB0byB4 ODY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51bmRlciBjZXJ0YWluIGNpcmN1bXN0YW5jZXMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VG9tPG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUg LSBJJ20gbm90IHN1cmUgdGhlIDQtYnl0ZSBwZW5hbHR5IGlzIHdvcnRoIGF2b2lkaW5nIGFueSBu ZWFybHkgYW55IGNhc2UsIGZyYW5rbHkgLS0gZXZlbiBmb3IgSVAuPGJyPg0KPGJyPg0KSm9lPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b1d251aff62c45d392c2ee8c1b3828b2XCH150608nwnosboeingcom_-- From nobody Thu May 25 13:40:33 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B39127871 for ; Thu, 25 May 2017 13:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 On6qtp7YAsrl for ; Thu, 25 May 2017 13:40:30 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 7580F126C23 for ; Thu, 25 May 2017 13:40:30 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 7so105629880wmo.1 for ; Thu, 25 May 2017 13:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oWFvxu4ltNfehFRPlYD+dHytH2sv0bzrJ7ARzp3LuqQ=; b=KOVpKtuAtdM3z3451EQRd8XW/2viXF1NXVITDy2U2G8Kb1vw4G2DaBHjfAq+opQ89U LPDNt0yHez/dL+/odx+R8eNu4LTdPoGlz8xshqz0ONr2SNegjRah9pOb/m+C/TE+TQe7 eotdK3cBA8vrW/qJTv2zR79yVvOSQ5lBT6FVRWPbzsADoG/dWrfZtHK6MP3gBV9b6srW JhP1k/1FnF2vs7qV2L2MuV13s65RMM7I+Is5POilXWF1V9AlnfJoesyKUvKiOOHiJh4s 5fLyffyxjaWUvFOSvlnuiVaKqZ0kIKKAxMywBnAgZXFCvUxVWJaCXZWR7PpnrCP2ub5M LyBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oWFvxu4ltNfehFRPlYD+dHytH2sv0bzrJ7ARzp3LuqQ=; b=dOQFEUZg4B0IbUWd8fZMklAuuk5Vrbory1GuTO1WhKp+x0dIhnQd40I7V4KEluztA2 QPQ9duMCaSZddvOWyvsTJpZKibCYcM/eWVL3vz3rxpCDnubD6djCHZ02P+4N1Nq0YCgu WsyWrRXWXtRt7iQIdKU8hVp8RzQdom1yGmnhlOPMdZ6US9DJJ41FEfDxKwNMiWj/NTmQ +FASI7sfZMGU0R8sSAMm98Vd52VH75YB80bAVKq7Cmun2ve+Dr4rZf/1zZNoqYfhzg60 M7S4wWdYhsIuSdbMTm0TE5xgsey6TS1CdPgyR23DuJezofssWziQVuew6r6M2/4EYwpB 8otA== X-Gm-Message-State: AODbwcB56XPkEZ+Ww83VzrMmUlG3kd7hFvXeb5aoIVkwHeSAKrjv6iyG kVNT74Bfus45wo8BBuZTFwf28ARY+lTO X-Received: by 10.223.183.31 with SMTP id l31mr1224376wre.115.1495744828936; Thu, 25 May 2017 13:40:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 13:40:28 -0700 (PDT) In-Reply-To: References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> From: Tom Herbert Date: Thu, 25 May 2017 13:40:28 -0700 Message-ID: To: "Templin, Fred L" Cc: Joe Touch , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A_Is_the_UDP_destination_port_number_resource_running_out=3F/?= =?utf-8?q?/_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:40:32 -0000 On Thu, May 25, 2017 at 12:44 PM, Templin, Fred L wrote: > If you are talking about the GUE direct encapsulation of IPv4 and IPv6, I > agree > > with the current spec and that direct encapsulation (i.e., with no > additional > > encapsulations between the IP/UDP and inner IP headers) is desirable and > > should remain as part of the spec. I think we may be over-thinking this. > +1. I think a little too much has been inferred beyond the what is actually in draft. Versions are straightforward: - There is a two bit version number field that begins GUE header. The format of the rest of the header depends on the version. - Version 0 defines an encapsulation header that encapsulates by IP protocol number. - Version 1 defined a means for direct encapsulation of select protocols as an optimization. Formats for IPv4 and IPv6 are defined. - Version 2 and 3 are reserved Rather Version 1 constitutes a new version or a different format seems to be a matter of terminology, however semantically and implementation wise the intent is clear. If it's necessary the field could be renamed "version/format" Tom > > > Fred > > > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, May 25, 2017 12:08 PM > To: Tom Herbert > Cc: int-area@ietf.org > Subject: Re: [Int-area] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: =E7=AD=94= =E5=A4=8D: =E7=AD=94=E5=A4=8D: Is the UDP destination port number > resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt > > > > > > > > On 5/25/2017 11:47 AM, Tom Herbert wrote: > > You can't put bare Ethernet inside GUE. You need to use EtherIP - > > exactly because it has a 16-bit field, of which only the first 4 bits > > are (already) defined. > > > > My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16 > > bits allow it to be mapped to one of the IP versions (you picked IPv5). > > The same trick works for UDP and TCP - just pick a different 16 bit > > pattern for each one. > > > > Inserting two bytes before the TCP header breaks four byte alignment > > of the header which is a bigger hit than the benefit of saving two > > bytes. A nice side effect of the two byte header in EtherIP is that it > > aligns the Ethernet payload (e.g. an IP header) to four bytes. > > Maintaining this four byte alignment is still important to some CPU > > architectures most notably Sparc, but can even be problematic to x86 > > under certain circumstances. > > > > Tom > > Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any > case, frankly -- even for IP. > > Joe From nobody Thu May 25 15:14:47 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CC1129AF1 for ; Thu, 25 May 2017 15:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 Z2ifZ80hYuYb for ; Thu, 25 May 2017 15:14:45 -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 D233C127B5A for ; Thu, 25 May 2017 15:14:45 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4PMEPVR014753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 15:14:36 -0700 (PDT) To: Tom Herbert , "Templin, Fred L" Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> From: Joe Touch Message-ID: <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu> Date: Thu, 25 May 2017 15:14:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A_Is_the_UDP_destination_port_number_resource_running_out=3F/?= =?utf-8?q?/_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 22:14:47 -0000 On 5/25/2017 1:40 PM, Tom Herbert wrote: > On Thu, May 25, 2017 at 12:44 PM, Templin, Fred L > wrote: >> If you are talking about the GUE direct encapsulation of IPv4 and IPv6, I >> agree >> >> with the current spec and that direct encapsulation (i.e., with no >> additional >> >> encapsulations between the IP/UDP and inner IP headers) is desirable and >> >> should remain as part of the spec. I think we may be over-thinking this. >> > +1. I think a little too much has been inferred beyond the what is > actually in draft. Versions are straightforward: > > - There is a two bit version number field that begins GUE header. The > format of the rest of the header depends on the version. > - Version 0 defines an encapsulation header that encapsulates by IP > protocol number. > - Version 1 defined a means for direct encapsulation of select > protocols as an optimization. Formats for IPv4 and IPv6 are defined. > - Version 2 and 3 are reserved I continue to be confused as to why it is more useful to try to make decisions based on the first two bits rather than the first four. There's near zero benefit, and the harm is that you end up with only two reserved versions. > > Rather Version 1 constitutes a new version or a different format seems > to be a matter of terminology, however semantically and implementation > wise the intent is clear. If it's necessary the field could be renamed > "version/format" It is not a version; I think that's at least part of the problem. It's a type or kind, but version implies that V0 is superceded by V1, which may or may not be backward compatible with V0. Joe From nobody Thu May 25 15:21:59 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25F3129B21 for ; Thu, 25 May 2017 15:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 PakD4l9J7Mkh for ; Thu, 25 May 2017 15:21:56 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.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 BD0FA127B52 for ; Thu, 25 May 2017 15:21:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4PMLtL6028666; Thu, 25 May 2017 15:21:55 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4PMLni5028518 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 25 May 2017 15:21:49 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 25 May 2017 15:21:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 25 May 2017 15:21:48 -0700 From: "Templin, Fred L" To: Joe Touch , Tom Herbert CC: "int-area@ietf.org" Thread-Topic: =?utf-8?B?W0ludC1hcmVhXSDnrZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06IElz?= =?utf-8?B?IHRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1iZXIgcmVzb3VyY2UgcnVu?= =?utf-8?B?bmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJl?= =?utf-8?Q?a-gue-04.txt?= Thread-Index: AQHS1aVMgScevXYRJ06CTPxLhS8/mQ== Date: Thu, 25 May 2017 22:21:48 +0000 Message-ID: References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu> In-Reply-To: <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A_Is_the_UDP_destination_port_number_resource_running_out=3F/?= =?utf-8?q?/_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 22:21:59 -0000 Sm9lLA0KDQpJIGFtIGZvciB3aGF0ZXZlciBhbGxvd3MgdXMgdG8gZG8gZGlyZWN0IGVuY2Fwc3Vs YXRpb24gKGkuZS4sIElQL1VEUC9JUCB3aXRoIE5VTEwgR1VFIGhlYWRlcikNCmluIHRoZSBzaW1w bGVzdCB3YXkgcG9zc2libGUuIEknbSBub3QgdG9vIGNvbmNlcm5lZCB3aXRoIGZ1dHVyZS1wcm9v ZmluZyBpdDsgaXMgdGhhdCB3aGF0IHlvdQ0KYXJlIHdvcnJpZWQgYWJvdXQ/DQoNClRoYW5rcyAt IEZyZWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2UgVG91Y2gg W21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDI1LCAyMDE3IDM6 MTQgUE0NCj4gVG86IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPjsgVGVtcGxpbiwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiBDYzogaW50LWFyZWFAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0g562U5aSNOiDnrZTlpI06IOetlOWkjTog562U 5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcg b3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLQ0KPiBpbnRhcmVhLWd1ZS0wNC50eHQN Cj4gDQo+IA0KPiANCj4gT24gNS8yNS8yMDE3IDE6NDAgUE0sIFRvbSBIZXJiZXJ0IHdyb3RlOg0K PiA+IE9uIFRodSwgTWF5IDI1LCAyMDE3IGF0IDEyOjQ0IFBNLCBUZW1wbGluLCBGcmVkIEwNCj4g PiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4+IElmIHlvdSBhcmUgdGFs a2luZyBhYm91dCB0aGUgR1VFIGRpcmVjdCBlbmNhcHN1bGF0aW9uIG9mIElQdjQgYW5kIElQdjYs IEkNCj4gPj4gYWdyZWUNCj4gPj4NCj4gPj4gd2l0aCB0aGUgY3VycmVudCBzcGVjIGFuZCB0aGF0 IGRpcmVjdCBlbmNhcHN1bGF0aW9uIChpLmUuLCB3aXRoIG5vDQo+ID4+IGFkZGl0aW9uYWwNCj4g Pj4NCj4gPj4gZW5jYXBzdWxhdGlvbnMgYmV0d2VlbiB0aGUgSVAvVURQIGFuZCBpbm5lciBJUCBo ZWFkZXJzKSBpcyBkZXNpcmFibGUgYW5kDQo+ID4+DQo+ID4+IHNob3VsZCByZW1haW4gYXMgcGFy dCBvZiB0aGUgc3BlYy4gSSB0aGluayB3ZSBtYXkgYmUgb3Zlci10aGlua2luZyB0aGlzLg0KPiA+ Pg0KPiA+ICsxLiBJIHRoaW5rIGEgbGl0dGxlIHRvbyBtdWNoIGhhcyBiZWVuIGluZmVycmVkIGJl eW9uZCB0aGUgd2hhdCBpcw0KPiA+IGFjdHVhbGx5IGluIGRyYWZ0LiBWZXJzaW9ucyBhcmUgc3Ry YWlnaHRmb3J3YXJkOg0KPiA+DQo+ID4gLSBUaGVyZSBpcyBhIHR3byBiaXQgdmVyc2lvbiBudW1i ZXIgZmllbGQgdGhhdCBiZWdpbnMgR1VFIGhlYWRlci4gVGhlDQo+ID4gZm9ybWF0IG9mIHRoZSBy ZXN0IG9mIHRoZSBoZWFkZXIgZGVwZW5kcyBvbiB0aGUgdmVyc2lvbi4NCj4gPiAtIFZlcnNpb24g MCBkZWZpbmVzIGFuIGVuY2Fwc3VsYXRpb24gaGVhZGVyIHRoYXQgZW5jYXBzdWxhdGVzIGJ5IElQ DQo+ID4gcHJvdG9jb2wgbnVtYmVyLg0KPiA+IC0gVmVyc2lvbiAxIGRlZmluZWQgYSBtZWFucyBm b3IgZGlyZWN0IGVuY2Fwc3VsYXRpb24gb2Ygc2VsZWN0DQo+ID4gcHJvdG9jb2xzIGFzIGFuIG9w dGltaXphdGlvbi4gRm9ybWF0cyBmb3IgSVB2NCBhbmQgSVB2NiBhcmUgZGVmaW5lZC4NCj4gPiAt IFZlcnNpb24gMiBhbmQgMyBhcmUgcmVzZXJ2ZWQNCj4gSSBjb250aW51ZSB0byBiZSBjb25mdXNl ZCBhcyB0byB3aHkgaXQgaXMgbW9yZSB1c2VmdWwgdG8gdHJ5IHRvIG1ha2UNCj4gZGVjaXNpb25z IGJhc2VkIG9uIHRoZSBmaXJzdCB0d28gYml0cyByYXRoZXIgdGhhbiB0aGUgZmlyc3QgZm91ci4N Cj4gVGhlcmUncyBuZWFyIHplcm8gYmVuZWZpdCwgYW5kIHRoZSBoYXJtIGlzIHRoYXQgeW91IGVu ZCB1cCB3aXRoIG9ubHkgdHdvDQo+IHJlc2VydmVkIHZlcnNpb25zLg0KPiANCj4gPg0KPiA+IFJh dGhlciBWZXJzaW9uIDEgY29uc3RpdHV0ZXMgYSBuZXcgdmVyc2lvbiBvciBhIGRpZmZlcmVudCBm b3JtYXQgc2VlbXMNCj4gPiB0byBiZSBhIG1hdHRlciBvZiB0ZXJtaW5vbG9neSwgaG93ZXZlciBz ZW1hbnRpY2FsbHkgYW5kIGltcGxlbWVudGF0aW9uDQo+ID4gd2lzZSB0aGUgaW50ZW50IGlzIGNs ZWFyLiBJZiBpdCdzIG5lY2Vzc2FyeSB0aGUgZmllbGQgY291bGQgYmUgcmVuYW1lZA0KPiA+ICJ2 ZXJzaW9uL2Zvcm1hdCINCj4gSXQgaXMgbm90IGEgdmVyc2lvbjsgSSB0aGluayB0aGF0J3MgYXQg bGVhc3QgcGFydCBvZiB0aGUgcHJvYmxlbS4gSXQncyBhDQo+IHR5cGUgb3Iga2luZCwgYnV0IHZl cnNpb24gaW1wbGllcyB0aGF0IFYwIGlzIHN1cGVyY2VkZWQgYnkgVjEsIHdoaWNoIG1heQ0KPiBv ciBtYXkgbm90IGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBWMC4NCj4gDQo+IEpvZQ0KPiAN Cj4gDQoNCg== From nobody Thu May 25 18:36:46 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC01129BDD for ; Thu, 25 May 2017 18:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Cy3fUvhf9nBG for ; Thu, 25 May 2017 18:36:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B86129B41 for ; Thu, 25 May 2017 18:36:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHI00940; Fri, 26 May 2017 01:36:39 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 26 May 2017 02:36:38 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 26 May 2017 09:36:34 +0800 From: Xuxiaohu To: Tom Herbert CC: Joe Touch , "int-area@ietf.org" Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogW0ludC1hcmVhXSDnrZTlpI06IElz?= =?utf-8?B?IHRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1iZXIgcmVzb3VyY2UgcnVu?= =?utf-8?B?bmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJl?= =?utf-8?Q?a-gue-04.txt?= Thread-Index: AQHS0RsMnyvO0qVuZEOz5xejzfeIJKH8l23w//9/jYCAAKQ8oIAAIOaAgARdqYCAA33pgIABITGQ Date: Fri, 26 May 2017 01:36:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAB24C@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.592786A7.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 16e7f54091501823f02e5f41a77eb5a0 Archived-At: Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiAg?= =?utf-8?q?=E7=AD=94=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resour?= =?utf-8?q?ce_running_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-?= =?utf-8?q?04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 01:36:44 -0000 VG9tLA0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBUb20gSGVyYmVy dCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDXm nIgyNuaXpSAwOjAwDQo+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4g5oqE6YCBOiBKb2UgVG91Y2g7 IGludC1hcmVhQGlldGYub3JnDQo+IOS4u+mimDogUmU6IOetlOWkjTog562U5aSNOiDnrZTlpI06 IFtJbnQtYXJlYV0g562U5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQNCj4gbnVtYmVy IHJlc291cmNlIHJ1bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFy ZWEtZ3VlLTA0LnR4dA0KPiANCj4gT24gTW9uLCBNYXkgMjIsIDIwMTcgYXQgNzo0OSBQTSwgWHV4 aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS3p gq7ku7bljp/ku7YtLS0tLQ0KPiA+PiDlj5Hku7bkuro6IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9t QGhlcmJlcnRsYW5kLmNvbV0NCj4gPj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0NeaciDIx5pelIDA6 MDENCj4gPj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiA+PiDmioTpgIE6IEpvZSBUb3VjaDsgaW50 LWFyZWFAaWV0Zi5vcmcNCj4gPj4g5Li76aKYOiBSZTog562U5aSNOiDnrZTlpI06IFtJbnQtYXJl YV0g562U5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyDQo+ID4+IHJlc291 cmNlIHJ1bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3Vl LTA0LnR4dA0KPiA+Pg0KPiA+PiBPbiBGcmksIE1heSAxOSwgMjAxNyBhdCAxMTowOSBQTSwgWHV4 aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4NCj4g Pj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+PiA+PiDlj5Hku7bkuro6IEpvZSBUb3Vj aCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+ID4+IOWPkemAgeaXtumXtDogMjAxN+W5tDXm nIgyMOaXpSAxMjoxNQ0KPiA+PiA+PiDmlLbku7bkuro6IFh1eGlhb2h1OyBUb20gSGVyYmVydA0K PiA+PiA+PiDmioTpgIE6IGludC1hcmVhQGlldGYub3JnDQo+ID4+ID4+IOS4u+mimDogUmU6IOet lOWkjTogW0ludC1hcmVhXSDnrZTlpI06IElzIHRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1i ZXINCj4gPj4gPj4gcmVzb3VyY2UgcnVubmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rpb246DQo+ID4+ ID4+IGRyYWZ0LWlldGYtaW50YXJlYS1ndWUtMDQudHh0DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ ID4+DQo+ID4+ID4+IE9uIDUvMTkvMjAxNyA4OjU3IFBNLCBYdXhpYW9odSB3cm90ZToNCj4gPj4g Pj4gPiBIaSBKb2UsDQo+ID4+ID4+ID4NCj4gPj4gPj4gPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0t LQ0KPiA+PiA+PiA+PiDlj5Hku7bkuro6IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVd DQo+ID4+ID4+ID4+IOWPkemAgeaXtumXtDogMjAxN+W5tDXmnIgyMOaXpSAxMTo0MQ0KPiA+PiA+ PiA+PiDmlLbku7bkuro6IFh1eGlhb2h1OyBUb20gSGVyYmVydA0KPiA+PiA+PiA+PiDmioTpgIE6 IGludC1hcmVhQGlldGYub3JnDQo+ID4+ID4+ID4+IOS4u+mimDogUmU6IFtJbnQtYXJlYV0g562U 5aSNOiBJcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyDQo+ID4+ID4+ID4+IHJlc291 cmNlIHJ1bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOg0KPiA+PiA+PiA+PiBkcmFmdC1pZXRm LWludGFyZWEtZ3VlLTA0LnR4dA0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pg0K PiA+PiA+PiA+PiBPbiA1LzE5LzIwMTcgNjozOSBQTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4+ID4+ ID4+PiBJZiB0aGUgc2F2aW5nIGlzIGJlbmVmaWNpYWwsIGl0J2QgYmV0dGVyIHRvIGFzc2lnbiBh IGRlZGljYXRlZA0KPiA+PiA+PiA+Pj4gcG9ydCBudW1iZXIgZm9yIGVhY2ggVURQIHBheWxvYWQg dHlwZSggZS5nLiwgSVAgcGFja2V0KSwNCj4gPj4gPj4gPj4+IHJhdGhlciB0aGFuIGNvbWJpbmlu ZyB0aGUgVURQIHBvcnQgbnVtYmVyIGRlZGljYXRlZCBmb3IgR1VFDQo+ID4+ID4+ID4+PiBhbmQg dGhlIHZlcnNpb24gZmllbGQgd2l0aGluIHRoZSBHVUUgaGVhZGVyIHRvZ2V0aGVyIHRvDQo+ID4+ ID4+ID4+PiBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBVRFAgcGF5bG9hZCBpcyBHVUUgb3IgSVAgKG9y IGV2ZW4gb3RoZXINCj4gPj4gPj4gPj4+IHBheWxvYWQgdHlwZSBpZiB0aGUgR1VFIGlzIGRldm90 ZWQgdG8gaGVscCBzYXZlIHRoZSBVRFAgcG9ydA0KPiA+PiA+PiA+Pj4gbnVtYmVyIHJlc291cmNl IGZvciB0aGUgSUVURg0KPiA+PiA+PiA+Pj4gY29tbXVuaXR5OikpDQo+ID4+ID4+ID4+IEZXSVcs IElBTkEgc3RyaXZlcyB0byBhc3NpZ24gb25lIHBvcnQgZm9yIGEgc2VydmljZS4NCj4gPj4gPj4g PiBHcmVhdC4gSGVuY2UgSVB2eCBzaG91bGQgYmUgdGFrZW4gYXMgYSBzZXJ2aWNlIHJhdGhlciB0 aGFuDQo+ID4+ID4+ID4gdGFraW5nIElQdnggYW5kDQo+ID4+ID4+IEdVRSBhcyBhIHNlcnZpY2Us IElNTy4NCj4gPj4gPj4gR1VFIGlzIHN1cHBvc2VkIHRvIGJlIGJvdGggc2lnbmFsbGluZyBhbmQg Y29udGVudCAoZGF0YSksIHdoZXJlDQo+ID4+ID4+IHRoZSBkYXRhIGFyZSBJUCBwYWNrZXRzLg0K PiA+PiA+DQo+ID4+ID4gU2luY2UgSUFOQSBzdHJpdmVzIHRvIGFzc2lnbiBvbmUgcG9ydCBmb3Ig YSBzZXJ2aWNlLCBJUCBwYWNrZXQNCj4gPj4gPiB3aXRoaW4gdGhlIFVEUA0KPiA+PiB0dW5uZWwg c2hvdWxkIGJlIGFzc2lnbmVkIGEgZGVkaWNhdGVkIHBvcnQuIEluIG90aGVyIHdvcmRzLCBHVUUg YW5kDQo+ID4+IElQLWluLVVEUCBhcmUgZGlzdGluZ3Vpc2hlZCBieSB0aGUgZGlmZmVyZW50IHBv cnQgbnVtYmVycy4NCj4gPj4gPg0KPiA+PiA+PiBUYWtlIGF3YXkgdGhlIElQIHBhcnQgYW5kIEdV RSBpc24ndCBhbiBFIGFueW1vcmUuDQo+ID4+ID4+ID4+IFNlcnZpY2VzIGFyZSBleHBlY3RlZCB0 byBoYXZlIHZlcnNpb24gZmllbGRzIGFuZCBzdWJ0eXBlDQo+ID4+ID4+ID4+IGRlbXVsdGlwbGV4 aW5nIGluZGljYXRvcnMsIHRvIHNvIHRoYXQgYWxsIG1lc3NhZ2UgdmFyaWFudHMgb2YNCj4gPj4g Pj4gPj4gY3VycmVudCBhbmQgZnV0dXJlIHZlcnNpb25zIGNhbiB1c2UgYSBzaW5nbGUgcG9ydCBu dW1iZXIuDQo+ID4+ID4+ID4gU3VyZSwgdGhlIHZlcnNpb24gZmllbGQgd2l0aGluIHRoZSBJUHZ4 IHBhY2tldCBjb3VsZCBiZSB1c2VkIGZvcg0KPiA+PiA+PiA+IGRlbXVsdGlwbGV4aW5nDQo+ID4+ ID4+IHB1cnBvc2UuDQo+ID4+ID4+DQo+ID4+ID4+IFRoYXQgZGVtdWx0aXBsZXhlcyB3aXRoaW4g SVB2eC4gVGhlcmUgc3RpbGwgbmVlZHMgdG8gYmUgYSB3YXkgdG8NCj4gPj4gPj4gZGVtdWx0aXBs ZXggbm9uLUlQdnggcGFja2V0cyAoY29udHJvbCkgZnJvbSBJUHZ4Lg0KPiA+PiA+DQo+ID4+ID4g U2luY2UgR1VFIGFuZCBJUC1pbi1VRFAgaGF2ZSBkaWZmZXJlbnQgVURQIHBvcnQgbnVtYmVycywg SSBkb24ndA0KPiA+PiA+IGtub3cgd2h5DQo+ID4+IHRoZXJlIGlzIHN0aWxsIGEgbmVlZCB0byBk ZW11bHRpcGxleCBHVUUgYW5kIElQLWluLVVEUC4NCj4gPj4gPg0KPiA+PiBJdCdzIGhlYWRlciBj b21wcmVzc2lvbi4gQ29uc2lkZXIgYSBzY2VuYXJpbyB0aGF0IEdVRSBpcyB0dW5uZWxpbmcNCj4g Pj4gSVB2NiBhbmQgSVB2NCBhbmQgd2lsbCBkbyBHVUUgZnJhZ21lbnRhdGlvbiBpZiBuZWNlc3Nh cnkgb24gdHVubmVsIGluZ3Jlc3MuDQo+ID4+IFNvIHNvbWUgcGFja2V0cyB3aWxsIGhhdmUgYSBm cmFnbWVudGF0aW9uIG9wdGlvbiBhbmQgc29tZSB3b24ndC4gRm9yDQo+ID4+IHVuZnJhZ21lbnRl ZCBwYWNrZXRzIHdpdGggbm8gR1VFIG9wdGlvbnMsIHRoZXkgY2FuIGJlIHNlbnQgaW4gZGlyZWN0 DQo+ID4+IGVuY2Fwc3VsYXRpb24gb2YgSVAuIFRoaXMgY291bGQgYmUgZG9uZSBhcyB2ZXJzaW9u IDEgb2YgR1VFIG9yIGluDQo+ID4+IElQLWluLVVEUCBhcyB5b3UncmUgc3VnZ2VzdGluZy4gVGhl IHByb2JsZW0gd2l0aCB0aGUgbGF0dGVyIGlzIHRoYXQNCj4gPj4gaXQgZG91YmxlcyB0aGUgbnVt YmVyIG9mIGZsb3dzIGluIHRoZSBuZXR3b3JrLiBTbyBpbnN0ZWFkIG9mIHB1bmNoaW5nDQo+ID4+ IG9uZSBob2xlIGZvciBhIHR1bm5lbCBpbiBhIGZpcmV3YWxsIHdlIG5lZWQgdHdvICh0aGUgZnJh Z21lbnQgdHVubmVsDQo+ID4+IGFuZCBub24tZnJhZ21lbnQgVURQIHBvcnRzKS4gUGFja2V0cyBp biBpbmRpdmlkdWFsIGZsb3dzIG5vdyBjYW4gdGFrZQ0KPiA+PiBkaWZmZXJlbnQgcGF0aHMgZGVw ZW5kaW5nIG9uIHdoZXRoZXIgdGhleSdyZSBmcmFnbWVudGVkIHNvIHRoaXMgaW50cm9kdWNlcw0K PiBPT08uDQo+ID4NCj4gPiBTaW5jZSBHVUUgaXMgaW50ZW5kZWQgdG8gYmUgYSBnZW5lcmljIFVE UCBlbmNhcHN1bGF0aW9uLCBub3cgbGV0J3MgYXNzdW1lDQo+IEdVRSBpcyB0dW5uZWxpbmcgTVBM UywgTlNIIG9yIEJJRVIuIFBsZWFzZSBjb250aW51ZSB5b3VyIHJhdGlvbmFsZSBvbmNlIHRob3Nl DQo+IGVuY2Fwc3VsYXRpb25zIGhhdmUgdGhlIHNhbWUgcmVxdWlyZW1lbnQgb2Ygc2F2aW5nIHRo ZSA0LWJ5dGUgR1VFIGJhc2UNCj4gaGVhZGVyIG92ZXJoZWFkIGFzIHRoZSBlbmNhcHN1bGF0aW9u IG9mIElQIGluIFVEUC4NCj4gPg0KPiBYaWFvaHUsDQo+IA0KPiBHVUUgZW5jYXBzdWxhdGVzIGJ5 IElQIHByb3RvY29sLCBJIGRvbid0IGJlbGlldmUgdGhlcmUgaXMgYSBwcm90b2NvbCBudW1iZXIg Zm9yDQo+IE5TSCBvciBCSUVSIHNvIHRoZXkgc2hvdWxkIG5vdCBiZSBlbmNhcHN1bGF0ZWQgaW4g dmVyc2lvbiAxLiBUaGVyZSBpcyBhIHByb3RvY29sDQo+IG51bWJlciBmb3IgTVBMUy1JUCwgaG93 ZXZlciB0aGVyZSBpcyBubyBmaXhlZCBmaWVsZCBpbiB0aGUgTVBMUyBoZWFkZXIgKGxpa2UgdGhl DQo+IElQIHZlcnNpb24pIHNvIHRoZSBvdmVybGF5IHRlY2huaXF1ZSBjYW4ndCB3b3JrLiBGdXJ0 aGVybW9yZSwgdGhlc2UgdGhyZWUNCj4gcHJvdG9jb2xzIGFyZSBhbHJlYWR5IGVuY2Fwc3VsYXRp b25zLCB0aGUgb3B0aW1pemF0aW9uIG1ha2VzIHRoZSBtb3N0IHNlbnNlIGZvcg0KPiBzaW1wbGUg bmV0d29yayBwcm90b2NvbHMgdGhhdCBhcmUgbm90IGVuY2Fwc3VsYXRpb25zLg0KDQpJZiBzbywg aXQgc2VlbXMgYSBsaXR0bGUgYml0IGNvbmZ1c2VkIHRvIGNsYWltIGl0IGFzIGEgZ2VuZXJpYyB1 ZHAgZW5jYXBzdWxhdGlvbi4NCg0KPiBJUHY0IGFuZCBJUHY2IGNhbiBiZSBkaXJlY3RseSBlbmNh cHN1bGF0ZWQgc2luY2UgdGhleSBoYXZlIGEgcHJvdG9jb2wgbnVtYmVyDQo+IChjYW4gYmUgZW5j YXBzdWxhdGVkIGJ5IHZlcnNpb24gMCkuDQoNCklmIHRoZSBwb3NzaWJsZSBwYXlsb2FkIHR5cGVz IG9mIEdVRSBhcmUgbGltaXRlZCB0byBJUHY0LCBJUHY2IGFuZCBNUExTLCBhbmQgdGhlc2UgcGF5 bG9hZHMgbmVlZCB0byBiZSBkaXJlY3RseSB0cmFuc3BvcnRlZCBvdmVyIFVEUCwgdGhlIG1vc3Qg c2ltcGxlIHdheSBpcyB0byBhbGxvY2F0ZSBhIGRlZGljYXRlZCBwb3J0IG51bWJlciBmb3IgSVAg c2luY2UgTVBMUyBoYXMgYWxyZWFkeSBiZSBhc3NpZ25lZCBvbmUgKFJGQzc1MTApLCBJTUhPLg0K DQo+IEFzIEkgbWVudGlvbmVkIHByZXZpb3VzbHksIEV0aGVybmV0IGNvdWxkIGJlIGRpcmVjdGx5 IGVuY2Fwc3VsYXRlZCB2aWEgRXRoZXJJUA0KPiB0aGF0IGhhcyBhIDQgYml0IHZlcnNpb24gbnVt YmVyIGF0IHRoZSBiZWdpbm5pbmcgb2YgaXRzIGhlYWRlci4gVGhlIHdheSB0aGlzDQo+IHdvdWxk IHdvcmsgaXMgdG8gc2V0IGEgdmVyc2lvbiAxIHBhdHRlcm4gdG8gaW5kaWNhdGUgRXRoZXJJUC4g Rm9yIGV4YW1wbGUsIHdlDQo+IGNvdWxkIHNwZWNpZnkgdGhhdCAwMTAxICB3b3VsZCBiZSBFdGhl cklQLiBXaGVuIEdVRSByZWNlaXZlcyBzdWNoIGEgcGFja2V0IGl0DQo+IHdpbGwgbm90aWNlIGl0 J3MgdmVyc2lvbiBvbmUgYW5kIHRoZW4gc2VlIHRoYXQgaXQgaXMgRXRoZXJJUCAoZGlmZmVyZW50 aWF0ZWQgZnJvbQ0KPiBJUHY0IDAxMDAgYW5kDQo+IElQdjYgMDExMCB2YWx1ZXMpLiBUaGUgZmly c3QgZm91ciBiaXRzIGFyZSB0aGVuIG92ZXJ3cml0dGVuIGJ5IDAwMTEgdG8gbWFrZSBpdCBhDQo+ IHZhbGlkIEV0aGVySVAgaGVhZGVyIGFuZCB0aGVuIHRoZSBwYWNrZXQgaXMgcmVzdWJtaXR0ZWQg dG8gdGhlIHN0YWNrIGFzIEV0aGVySVAuDQoNClRvIHNhdmUgdGhlIDQtYnl0ZSBHVUUgYmFzZSBo ZWFkZXIgb3ZlcmhlYWQgd2hlbiBlbmNhcHN1bGF0aW5nIEV0aGVybmV0IG92ZXIgVURQLCB5b3Ug cHJvcG9zZSB0byBpbnNlcnQgdGhlIGFkZGl0aW9uYWwgMTYtYml0IEV0aGVySVAgaGVhZGVyIGJl dHdlZW4gdGhlIFVEUCBoZWFkZXIgYW5kIE1BQyBmcmFtZT8NCg0KWGlhb2h1DQoNCj4gVHJhbnNw b3J0IHByb3RvY29scyAoVENQLCBVRFAsIFNDVFApIG1pZ2h0IGFsc28gYmUgbmljZSB0byBzdXBw b3J0IHdpdGggZGlyZWN0DQo+IGVuY2Fwc3VsYXRpb24gaW4gdmVyc2lvbiAxLCBidXQgdW5mb3J0 dW5hdGVseSBzaW5jZSB0aGV5IHN0YXJ0IHdpdGggYSB2YXJpYWJsZQ0KPiBwb3J0IG51bWJlciB0 aGVyZSdzIG5vIHdheSB0byBkbyB0aGF0Lg0KPiANCj4gVG9tDQo+IA0KPiA+IEJlc3QgcmVnYXJk cywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBUb20NCj4gPj4NCj4gPj4gPiBYaWFvaHUNCj4gPj4g Pg0KPiA+PiA+PiBKb2UNCg== From nobody Thu May 25 18:50:06 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4458D12EB0A for ; Thu, 25 May 2017 18:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 jyj6i765zzJC for ; Thu, 25 May 2017 18:50:01 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 9F7B812EB08 for ; Thu, 25 May 2017 18:50:00 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id b84so112638842wmh.0 for ; Thu, 25 May 2017 18:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NADYtpOvc2zMzeDSOPuHjh4GbmtOPNoeweBlDgrR8k4=; b=J9nY5Dw3HL9Vuo/uqsv6HMHMHygJonpd9GcLZhfEmZqQ6k2LIiBwqVSSdjV0D+hxki 3rHW8DKNHm2kwzveeLvkAqnC6su9lHAhrgzgxHrLQkDI+J/E2Ttk05zaPHMUiybiAwLI 1KfEiqjA4STBLCCKJyAU0nleQDqax+od9+XBkX4tZNZ4Gfuf9fLeTa7Lx/77WAVDbhK9 //ehyKmuk8GS80lUdLhsVmoj26raFxsUt4Y9Q8r35yDZgXzh6ZLTMRul55TovJuWO6VA XDRRnZC9n48ufAg3U2qsZQnYk58zh1wohN6gNZY9zMHv9mG38EdXy49i0edU17p7GxJz B6kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NADYtpOvc2zMzeDSOPuHjh4GbmtOPNoeweBlDgrR8k4=; b=ZZX5vzJfgP/ntaY3Q8iAjh1wu1V/Fvo8a33RtvC2NmBl3PZRpE0CFMQbuIDDktvqrZ yvdZgyV8KaMvWpleBTYZDXmzg8ypD0innp049Jyjbxwv7cVrrULCfOlbsUD/5nw/nx9m KsftaXCbwQ2o/HhIewq1T2kVLNmCSgTTrh3n/IS+uD0CwMPK+Fa5EsSaH0yyYCmjCouR AjwySqY+iaETZ0VxLyk+isibOSBe38DwTRp0EN30WlXlQOdgLRjG/wc1RYLYO90ArvxC w84M+8WRKLtveyMynjcTgDhf+68eAWBXkhoRs9zG5XZ2ZlQz4BmuYoBgBvHJF/LgFa8t 0Ldw== X-Gm-Message-State: AODbwcCrGlyHZldDCZyMF/AwD44sHO6Xqt5yFl1efSaXFHoOEdRkeAAF hAKd4mYtks++aNDOOzZIQ4jvR9bDcPAM X-Received: by 10.28.87.72 with SMTP id l69mr10751035wmb.111.1495763399158; Thu, 25 May 2017 18:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 18:49:58 -0700 (PDT) In-Reply-To: <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu> From: Tom Herbert Date: Thu, 25 May 2017 18:49:58 -0700 Message-ID: To: Joe Touch Cc: "Templin, Fred L" , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A_Is_the_UDP_destination_port_number_resource_running_out=3F/?= =?utf-8?q?/_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 01:50:02 -0000 On Thu, May 25, 2017 at 3:14 PM, Joe Touch wrote: > > > On 5/25/2017 1:40 PM, Tom Herbert wrote: >> On Thu, May 25, 2017 at 12:44 PM, Templin, Fred L >> wrote: >>> If you are talking about the GUE direct encapsulation of IPv4 and IPv6, I >>> agree >>> >>> with the current spec and that direct encapsulation (i.e., with no >>> additional >>> >>> encapsulations between the IP/UDP and inner IP headers) is desirable and >>> >>> should remain as part of the spec. I think we may be over-thinking this. >>> >> +1. I think a little too much has been inferred beyond the what is >> actually in draft. Versions are straightforward: >> >> - There is a two bit version number field that begins GUE header. The >> format of the rest of the header depends on the version. >> - Version 0 defines an encapsulation header that encapsulates by IP >> protocol number. >> - Version 1 defined a means for direct encapsulation of select >> protocols as an optimization. Formats for IPv4 and IPv6 are defined. >> - Version 2 and 3 are reserved > I continue to be confused as to why it is more useful to try to make > decisions based on the first two bits rather than the first four. > There's near zero benefit, and the harm is that you end up with only two > reserved versions. > If necessary, new version could be defined to be fours bits versions like version 1 so that gives thirteen possible versions (00 01xx 10xx 11xx) of which three have been defined. v0 is already quite extensible and generic so I don't see it will be obsoleted any time in the foreseeable future. Personally, I don't think rearranging the GUE header is needed at this point. Tom From nobody Thu May 25 18:52:31 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3612EB05 for ; Thu, 25 May 2017 18:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 O5t85WW3GUlP for ; Thu, 25 May 2017 18:52:26 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 2E5B112EB04 for ; Thu, 25 May 2017 18:52:26 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id 7so111687936wmo.1 for ; Thu, 25 May 2017 18:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HDAbjTY3m+8YX1otPeF89SDJUOZWFLmS46m4b4D3IR8=; b=oTJ+YxC29rjF7545fnzCyobPwQXLePbhrVVtbkr3gkhsrTRV1h43xaY/YFcezIo5Sl PuQt3nuBdog85lBFhmVoCwXtVjNhm9lDPQPFCFzBar2RFwqFSgUOvNnBAf/wfo3FVggu CyxVZZ+jAmXQLUw9wWtDsMLETT8J5MNCu33/gvZNhpFcXnTPMUZzzRXQIZURE514SXQE yBpivHwnWcO7LnjEhzNMRaos1lSCsnTj+oylOugdpkPYU6rOPQSiaOKZPmXFAJtskiTR dzvThdfFVVke0yqE8bzm4Y9wcGWIGqO+JJQ2kfwQ1EvH2+E++aDjf4JtG3ZbK0bSfVXS lYrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HDAbjTY3m+8YX1otPeF89SDJUOZWFLmS46m4b4D3IR8=; b=ABnf7fkAXmcZzjJd7TSnCbwOUEiqzZeaX4Z/LRdc25qgrWnnpA5/OzKxyD4rmjvVIF JsO1IcuGJa6vIV9oFRmYYXCxV17IZzDywtN2/OhwyRSRsS5chUYl3f4jhX56BL9KyAqw eNK65cI8LWOYgQqe+VNEiM78BHBu0eTdlsP+muP9YYVBLcHIFXWxHC3abP02VQGAIu15 33tjnuo519iy9QT/MSI+ZZvqBPyU0b9HOx2VBo84Rl2VOVcynnUY+zsXKYXwCHd1e85l 0ssaJly4O//AvI3WChuUIR04M0uh6WzYnwIwNebx6dPdc5t9zYykcVQrvtV7gAoBoqfg llsw== X-Gm-Message-State: AODbwcD1ATW/c3ZRzXKAWJmThzuYWRhl+uBOBInDWMhScPX+uCHz0epr fNgz7Odi0bUKi06eRn+lNO6nHj0Ig4aV X-Received: by 10.28.139.69 with SMTP id n66mr265292wmd.60.1495763544625; Thu, 25 May 2017 18:52:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 18:52:23 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAB24C@NKGEML515-MBX.china.huawei.com> References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAB24C@NKGEML515-MBX.china.huawei.com> From: Tom Herbert Date: Thu, 25 May 2017 18:52:23 -0700 Message-ID: To: Xuxiaohu Cc: Joe Touch , "int-area@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A__=E7=AD=94=E5=A4=8D=3A_Is_the_UDP_destination_port_number_r?= =?utf-8?q?esource_running_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea?= =?utf-8?q?-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 01:52:28 -0000 On Thu, May 25, 2017 at 6:36 PM, Xuxiaohu wrote: > Tom, > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Tom Herbert [mailto:tom@herbertland.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8826=E6=97=A5= 0:00 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> =E6=8A=84=E9=80=81: Joe Touch; int-area@ietf.org >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: =E7=AD= =94=E5=A4=8D: [Int-area] =E7=AD=94=E5=A4=8D: Is the UDP destination port >> number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04= .txt >> >> On Mon, May 22, 2017 at 7:49 PM, Xuxiaohu wrote: >> > >> > >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Tom Herbert [mailto:tom@herbertland.com] >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8821=E6=97= =A5 0:01 >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> >> =E6=8A=84=E9=80=81: Joe Touch; int-area@ietf.org >> >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: [Int-= area] =E7=AD=94=E5=A4=8D: Is the UDP destination port number >> >> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt >> >> >> >> On Fri, May 19, 2017 at 11:09 PM, Xuxiaohu >> wrote: >> >> > >> >> > >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:touch@isi.edu] >> >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8820=E6= =97=A5 12:15 >> >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Tom Herbert >> >> >> =E6=8A=84=E9=80=81: int-area@ietf.org >> >> >> =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [Int-area] =E7=AD=94= =E5=A4=8D: Is the UDP destination port number >> >> >> resource running out?// re: I-D Action: >> >> >> draft-ietf-intarea-gue-04.txt >> >> >> >> >> >> >> >> >> >> >> >> On 5/19/2017 8:57 PM, Xuxiaohu wrote: >> >> >> > Hi Joe, >> >> >> > >> >> >> >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> >> >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:touch@isi.edu] >> >> >> >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B45=E6=9C=8820= =E6=97=A5 11:41 >> >> >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Tom Herbert >> >> >> >> =E6=8A=84=E9=80=81: int-area@ietf.org >> >> >> >> =E4=B8=BB=E9=A2=98: Re: [Int-area] =E7=AD=94=E5=A4=8D: Is the U= DP destination port number >> >> >> >> resource running out?// re: I-D Action: >> >> >> >> draft-ietf-intarea-gue-04.txt >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 5/19/2017 6:39 PM, Xuxiaohu wrote: >> >> >> >>> If the saving is beneficial, it'd better to assign a dedicated >> >> >> >>> port number for each UDP payload type( e.g., IP packet), >> >> >> >>> rather than combining the UDP port number dedicated for GUE >> >> >> >>> and the version field within the GUE header together to >> >> >> >>> indicate whether the UDP payload is GUE or IP (or even other >> >> >> >>> payload type if the GUE is devoted to help save the UDP port >> >> >> >>> number resource for the IETF >> >> >> >>> community:)) >> >> >> >> FWIW, IANA strives to assign one port for a service. >> >> >> > Great. Hence IPvx should be taken as a service rather than >> >> >> > taking IPvx and >> >> >> GUE as a service, IMO. >> >> >> GUE is supposed to be both signalling and content (data), where >> >> >> the data are IP packets. >> >> > >> >> > Since IANA strives to assign one port for a service, IP packet >> >> > within the UDP >> >> tunnel should be assigned a dedicated port. In other words, GUE and >> >> IP-in-UDP are distinguished by the different port numbers. >> >> > >> >> >> Take away the IP part and GUE isn't an E anymore. >> >> >> >> Services are expected to have version fields and subtype >> >> >> >> demultiplexing indicators, to so that all message variants of >> >> >> >> current and future versions can use a single port number. >> >> >> > Sure, the version field within the IPvx packet could be used for >> >> >> > demultiplexing >> >> >> purpose. >> >> >> >> >> >> That demultiplexes within IPvx. There still needs to be a way to >> >> >> demultiplex non-IPvx packets (control) from IPvx. >> >> > >> >> > Since GUE and IP-in-UDP have different UDP port numbers, I don't >> >> > know why >> >> there is still a need to demultiplex GUE and IP-in-UDP. >> >> > >> >> It's header compression. Consider a scenario that GUE is tunneling >> >> IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel in= gress. >> >> So some packets will have a fragmentation option and some won't. For >> >> unfragmented packets with no GUE options, they can be sent in direct >> >> encapsulation of IP. This could be done as version 1 of GUE or in >> >> IP-in-UDP as you're suggesting. The problem with the latter is that >> >> it doubles the number of flows in the network. So instead of punching >> >> one hole for a tunnel in a firewall we need two (the fragment tunnel >> >> and non-fragment UDP ports). Packets in individual flows now can take >> >> different paths depending on whether they're fragmented so this intro= duces >> OOO. >> > >> > Since GUE is intended to be a generic UDP encapsulation, now let's ass= ume >> GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once = those >> encapsulations have the same requirement of saving the 4-byte GUE base >> header overhead as the encapsulation of IP in UDP. >> > >> Xiaohu, >> >> GUE encapsulates by IP protocol, I don't believe there is a protocol num= ber for >> NSH or BIER so they should not be encapsulated in version 1. There is a = protocol >> number for MPLS-IP, however there is no fixed field in the MPLS header (= like the >> IP version) so the overlay technique can't work. Furthermore, these thre= e >> protocols are already encapsulations, the optimization makes the most se= nse for >> simple network protocols that are not encapsulations. > > If so, it seems a little bit confused to claim it as a generic udp encaps= ulation. > >> IPv4 and IPv6 can be directly encapsulated since they have a protocol nu= mber >> (can be encapsulated by version 0). > > If the possible payload types of GUE are limited to IPv4, IPv6 and MPLS, = and these payloads need to be directly transported over UDP, the most simpl= e way is to allocate a dedicated port number for IP since MPLS has already = be assigned one (RFC7510), IMHO. > >> As I mentioned previously, Ethernet could be directly encapsulated via E= therIP >> that has a 4 bit version number at the beginning of its header. The way = this >> would work is to set a version 1 pattern to indicate EtherIP. For exampl= e, we >> could specify that 0101 would be EtherIP. When GUE receives such a pack= et it >> will notice it's version one and then see that it is EtherIP (differenti= ated from >> IPv4 0100 and >> IPv6 0110 values). The first four bits are then overwritten by 0011 to m= ake it a >> valid EtherIP header and then the packet is resubmitted to the stack as = EtherIP. > > To save the 4-byte GUE base header overhead when encapsulating Ethernet o= ver UDP, you propose to insert the additional 16-bit EtherIP header between= the UDP header and MAC frame? > That is already part of EtherIP (RFC3378). Tom > Xiaohu > >> Transport protocols (TCP, UDP, SCTP) might also be nice to support with = direct >> encapsulation in version 1, but unfortunately since they start with a va= riable >> port number there's no way to do that. >> >> Tom >> >> > Best regards, >> > Xiaohu >> > >> >> Tom >> >> >> >> > Xiaohu >> >> > >> >> >> Joe From nobody Fri May 26 07:58:51 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF802129ABE for ; Fri, 26 May 2017 07:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 WJPruDiNrjoz for ; Fri, 26 May 2017 07:58:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 5475812E057 for ; Fri, 26 May 2017 07:58:42 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4QEvwln025998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 May 2017 07:58:00 -0700 (PDT) To: "Templin, Fred L" , Tom Herbert Cc: "int-area@ietf.org" References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu> From: Joe Touch Message-ID: <772455f4-4f37-4ead-18ff-a695209f9695@isi.edu> Date: Fri, 26 May 2017 07:57:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A_Is_the_UDP_destination_port_number_resource_running_out=3F/?= =?utf-8?q?/_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?= X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 14:58:50 -0000 On 5/25/2017 3:21 PM, Templin, Fred L wrote: > Joe, > > I am for whatever allows us to do direct encapsulation (i.e., IP/UDP/IP with NULL GUE header) > in the simplest way possible. I'm not too concerned with future-proofing it; is that what you > are worried about? Yes, but I've made my position clear. If this is believed by others to be sufficiently addressed, that's fine. Joe From nobody Mon May 29 00:30:47 2017 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F6126DED; Mon, 29 May 2017 00:30:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: int-area@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149604303879.3966.14334001000021071156@ietfa.amsl.com> Date: Mon, 29 May 2017 00:30:38 -0700 Archived-At: Subject: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 07:30:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Privacy considerations for IP broadcast and multicast protocol designers Authors : Rolf Winter Michael Faath Fabian Weisshaar Filename : draft-ietf-intarea-broadcast-consider-03.txt Pages : 13 Date : 2017-05-29 Abstract: A number of application-layer protocols make use of IP broadcasts or multicast messages for functions like local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcasts or multicast messages, a passive observer in the same broadcast/ multicast domain can trivially record these messages and analyze their content. Therefore, broadcast/multicast protocol designers need to take special care when designing their protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-03 https://datatracker.ietf.org/doc/html/draft-ietf-intarea-broadcast-consider-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 00:39:10 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364931293F2 for ; Mon, 29 May 2017 00:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 lMVHJxj67wdC for ; Mon, 29 May 2017 00:39:07 -0700 (PDT) Received: from fly.RZ.HS-Augsburg.DE (fly.RZ.HS-Augsburg.DE [141.82.217.48]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277EC1293DF for ; Mon, 29 May 2017 00:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fly.RZ.HS-Augsburg.DE (Postfix) with ESMTP id 0E7841D6379 for ; Mon, 29 May 2017 09:38:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de Received: from fly.RZ.HS-Augsburg.DE ([127.0.0.1]) by localhost (fly.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4kNEANZS3CwH for ; Mon, 29 May 2017 09:37:58 +0200 (CEST) Received: from [192.168.1.148] (nightswatch.informatik.hs-augsburg.de [141.82.79.79]) by fly.RZ.HS-Augsburg.DE (Postfix) with ESMTPSA id 230B21D6374 for ; Mon, 29 May 2017 09:37:57 +0200 (CEST) To: int-area@ietf.org References: <149604303879.3966.14334001000021071156@ietfa.amsl.com> From: Rolf Winter Organization: Conntac Message-ID: <8868c8ac-0bfa-8c98-69ca-0a932a986d4b@hs-augsburg.de> Date: Mon, 29 May 2017 09:39:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149604303879.3966.14334001000021071156@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 07:39:09 -0000 Hi, we updated the draft trying to address comments made by Joe and Tom. In particular we added a section on types and use of broadcast and multicast. This is not an all encompassing summary of it, but highlights the types most important for the scope of the document. We did not include LANE as suggested, because we felt that this is side-tracking the discussion a little. Also, we left out relays for certain protocols, as the focus is on the standard broadcast and multicast capabilities of the network which proprietary protocols will need to use, as by design, there are no relays for these types of protocols. Joe, could you check, whether the new text properly addresses your comments or not? Thanks, Rolf Am 29.05.17 um 09:30 schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : Privacy considerations for IP broadcast and multicast protocol designers > Authors : Rolf Winter > Michael Faath > Fabian Weisshaar > Filename : draft-ietf-intarea-broadcast-consider-03.txt > Pages : 13 > Date : 2017-05-29 > > Abstract: > A number of application-layer protocols make use of IP broadcasts or > multicast messages for functions like local service discovery or name > resolution. Some of these functions can only be implemented > efficiently using such mechanisms. When using broadcasts or > multicast messages, a passive observer in the same broadcast/ > multicast domain can trivially record these messages and analyze > their content. Therefore, broadcast/multicast protocol designers > need to take special care when designing their protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-03 > https://datatracker.ietf.org/doc/html/draft-ietf-intarea-broadcast-consider-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Tue May 30 16:08:19 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDD4129490; Tue, 30 May 2017 16:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 8vi0YmVAQB-Q; Tue, 30 May 2017 16:08:16 -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 6CBA1124281; Tue, 30 May 2017 16:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:From:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HeXbdWiJiqYBfI5Q2NOxuZzQOzJfrBHivF4DVS3mHkM=; b=R7Pdxu6ZZAeoF2gWC9iZqrD1On fdWolo7RSOALqGCM3VBxqdUGuQmPXnUHok0akjsxqY5qKIJ8V1027JgmCW8G9IUG85U812DssAxoM /RkARnUOvfQ8vcxrHeufhoBVMrOrwbXtSHuindQQpvhm6ENwVSGamTxNaQJBaLWSwXq5+c03kXWOo gglZ6rVYTMTn9uZFuP5UwyzGM8K6uIGuljpEArye+yxX1YTKiKXAXGdyD2A3RYYyCCBP4vd5V1Rbf j2kgmxx9Y0hi6G8jShhee7U1YAhXBlqdNqgvlepbxAMrCHi+NIPhIfUaO6WBPs+Pq5XAzYKISckT5 lDyvBM2A==; Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:58396 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dFqFJ-0004OK-Ro; Wed, 31 May 2017 00:08:14 +0100 From: Bob Briscoe To: intarea IETF list References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> Cc: "Black, David" , tsvwg IETF list Message-ID: <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net> Date: Wed, 31 May 2017 00:08:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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: Subject: [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:08:17 -0000 Intarea list, I presented this short draft just under a year ago in intarea. Since then it has been adopted as a tsvwg work item. I have just added specific text to update those tunnel specs that are under IETF change control (L2TP and GRE), as well as addressing non-IETF specs too (VXLAN, GTP, NVGRE etc). I would appreciate review from someone in intarea who knows these specs better than I do. If you know L2TP well, pls check the l2tpext list, where I have just posted three L2TP-specific question. Cheers Bob On 30/05/17 22:49, Bob Briscoe wrote: > David (as doc shepherd) and the tsvwg list, > > As requested, I have added specific text that updates the other > relevant RFCs under IETF change control (GRE and L2TP). I have also > explained the position in each case for specs not under IETF change > control. > > I will now go to the relevant WGs (intarea and lt2pext) and ask them > to improve my first attempt. > > I'll cc you and this list as appropriate. > > Cheers > > > > Bob > > PS. I have also said > > the rules in [RFC6040] for > propagating the ECN field MUST be applied > > whereas before it said "SHOULD". And added an explanation for why > "MUST" is appropriate: > > The above is written as a 'MUST' because RFC 6040 allows > a compatibility mode for the encapsulator in cases where the > decapsulator does not (or cannot) support ECN propagation. > > > > > > > On 30/05/17 22:36, internet-drafts@ietf.org wrote: >> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt >> has been successfully submitted by Bob Briscoe and posted to the >> IETF repository. >> >> Name: draft-ietf-tsvwg-rfc6040update-shim >> Revision: 01 >> Title: Propagating Explicit Congestion Notification Across IP >> Tunnel Headers Separated by a Shim >> Document date: 2017-05-30 >> Group: tsvwg >> Pages: 10 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01 >> >> Abstract: >> RFC 6040 on "Tunnelling of Explicit Congestion Notification" made >> the >> rules for propagation of ECN consistent for all forms of IP in IP >> tunnel. This specification extends the scope of RFC 6040 to include >> tunnels where two IP headers are separated by at least one shim >> header that is not sufficient on its own for packet forwarding. >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue May 30 16:51:33 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3819129AA0 for ; Tue, 30 May 2017 16:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 Sxas9vS1pF6U for ; Tue, 30 May 2017 16:51:30 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 0B2D3129A90 for ; Tue, 30 May 2017 16:51:30 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id v104so130138wrb.0 for ; Tue, 30 May 2017 16:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cAF7GlAMc9sK/0xG2yzawn+5ZylQjPVMz3CmG8ZriA4=; b=tcTTU5BS6PV1hjUTHwuPbIrnoKQguS6srU1I5jxiFotSLXce0+JoGVnnPNSGDBlgof SVc6o0aBUMQJLb66IlQSoX+72mSvIMrD2dDl2heuN396lVCQA4BQIdvYUZfzJriWxRW2 90m+RszQsAnXdmrbJv91AraZ83PPMIXQpsdgyBsVd2rYvpIw5Dp5I6LjDrlA4rFSrNoh DH0bCjubkk/TpaGy6s9z8vbQws96vKFWv2bWR9+/oQVUWq0l5R3/iE38g7wH8z8budB3 hQrTNF/tIFsvJ579RxhY3BQEIqgfR+BLCoJw8K/GZY3KHJwEVuC+OOIS2hJcR28k1wOR Qgow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cAF7GlAMc9sK/0xG2yzawn+5ZylQjPVMz3CmG8ZriA4=; b=fNmz6pNW08mvqSznjyQn72wruKeqrEkGY/ByKMKnC77RB3j8T2Tg4WW/nXxvfFQ0Fe h9mRpYoAQyodtPdcvrcNyBYxLbOy1PYIUI1Vx13Edq/WsakeIaO/VpaATIGguKJcjye1 WtOk1bfgZhaeMK6fpDwRJbYc/84N4WKfYTzVn6ta9MbaZ/MBFc3/w8Rx++kteZ6FWMG9 NK7JB6SKfuSHT5veNm1GQpEsOcyis8P6i39SsL6pqXnY2kougsHFLW9z2aR+vpWjRwFY rpoB1q8lehA750bhoul9koXfAB247QbeDqdtcaDkwSj1P2UaJ4I0ojIkSsMgNJzIy3Le NSag== X-Gm-Message-State: AODbwcALuBL4oiwIKBfLLpI+/AlEtZRVaPlbCP3C9vU1ZfsoY3g3Jxm+ dMg9H5TFd2RmNxvVMhW883565Qge1SdB X-Received: by 10.223.128.80 with SMTP id 74mr19448668wrk.30.1496188288527; Tue, 30 May 2017 16:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.132.195 with HTTP; Tue, 30 May 2017 16:51:28 -0700 (PDT) In-Reply-To: <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net> References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net> From: Tom Herbert Date: Tue, 30 May 2017 16:51:28 -0700 Message-ID: To: Bob Briscoe Cc: intarea IETF list , "Black, David" , tsvwg IETF list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:51:33 -0000 On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe wrote: > Intarea list, > > I presented this short draft just under a year ago in intarea. Since then it > has been adopted as a tsvwg work item. > > I have just added specific text to update those tunnel specs that are under > IETF change control (L2TP and GRE), as well as addressing non-IETF specs too > (VXLAN, GTP, NVGRE etc). > Hi Bob, On comment. GRE allows encapsulation of layer 2 (e.g. Ethernet, MPLS, etc.) and VXLAN only does encapsulation of Ethernet. I don't think these layer 2 headers could be considered shim headers per the draft, they are not removed in with the encapsulation headers and are routable in the layer 2 network. However, the layer 2 packet may contain an IP packet and in at least once case (VXLAN) there is a recommendation to apply RFC6040 to an inner IP header. Maybe the requirements for this scenario should be clarified? I think it's probably reasonable to say that ECN SHOULD be propagated in this case. Tom > I would appreciate review from someone in intarea who knows these specs > better than I do. > > If you know L2TP well, pls check the l2tpext list, where I have just posted > three L2TP-specific question. > > > Cheers > > > Bob > > > On 30/05/17 22:49, Bob Briscoe wrote: >> >> David (as doc shepherd) and the tsvwg list, >> >> As requested, I have added specific text that updates the other relevant >> RFCs under IETF change control (GRE and L2TP). I have also explained the >> position in each case for specs not under IETF change control. >> >> I will now go to the relevant WGs (intarea and lt2pext) and ask them to >> improve my first attempt. >> >> I'll cc you and this list as appropriate. >> >> Cheers >> >> >> >> Bob >> >> PS. I have also said >> >> the rules in [RFC6040] for >> propagating the ECN field MUST be applied >> >> whereas before it said "SHOULD". And added an explanation for why "MUST" >> is appropriate: >> >> The above is written as a 'MUST' because RFC 6040 allows >> a compatibility mode for the encapsulator in cases where the >> decapsulator does not (or cannot) support ECN propagation. >> >> >> >> >> >> >> On 30/05/17 22:36, internet-drafts@ietf.org wrote: >>> >>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt >>> has been successfully submitted by Bob Briscoe and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-tsvwg-rfc6040update-shim >>> Revision: 01 >>> Title: Propagating Explicit Congestion Notification Across IP >>> Tunnel Headers Separated by a Shim >>> Document date: 2017-05-30 >>> Group: tsvwg >>> Pages: 10 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01 >>> >>> Abstract: >>> RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the >>> rules for propagation of ECN consistent for all forms of IP in IP >>> tunnel. This specification extends the scope of RFC 6040 to include >>> tunnels where two IP headers are separated by at least one shim >>> header that is not sufficient on its own for packet forwarding. >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Tue May 30 18:45:48 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF9C126C2F; Tue, 30 May 2017 18:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 G9voNmnD1nOW; Tue, 30 May 2017 18:45:37 -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 4C112129B36; Tue, 30 May 2017 18:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qIIOoEmEcLNHd6ZavkOg/XRHMnX7ByJAiRS2Zzwf/c0=; b=Ot8BBm3cBQofziM+EtPmRMRLtc /D+YVvT7C1x9PtfV5pXRc7gQReZk9bTvEtznV/XBhcMoEUFKLsS2DVaCAlmdOLx5+atczRWeYRgVY sCkS+0eCkd2Yi2mCMSEHIFWLE0fd2IRPxS8wn1J7IJQD+ZxXwxnPL32L/voga8uAm7gbXuFltSVjl 1iSuDtQLNy766vXL0FzDTpebtWGrZUGLTWl+chgefa43VDIfHgLU1Rmllgz9rnBLETRya9Bq1FO+y WnsQlnN+qDj89Onl1TWbnG5MgK+zSvf8KluwiBtRfDIkeSZnC7urHQg0WRV5ULLklNkLoMnW+FNbH wtXXPWlg==; Received: from [31.185.135.175] (port=59888 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dFshb-0005r7-DV; Wed, 31 May 2017 02:45:35 +0100 To: Tom Herbert Cc: intarea IETF list , "Black, David" , tsvwg IETF list References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Wed, 31 May 2017 02:45:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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: Subject: Re: [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 01:45:41 -0000 Tom, On 31/05/17 00:51, Tom Herbert wrote: > On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe wrote: >> Intarea list, >> >> I presented this short draft just under a year ago in intarea. Since then it >> has been adopted as a tsvwg work item. >> >> I have just added specific text to update those tunnel specs that are under >> IETF change control (L2TP and GRE), as well as addressing non-IETF specs too >> (VXLAN, GTP, NVGRE etc). >> > Hi Bob, > > On comment. GRE allows encapsulation of layer 2 (e.g. Ethernet, MPLS, > etc.) and VXLAN only does encapsulation of Ethernet. I don't think > these layer 2 headers could be considered shim headers per the draft, > they are not removed in with the encapsulation headers and are > routable in the layer 2 network. However, the layer 2 packet may > contain an IP packet You're right in all cases. After posting the draft, I also realized that is usually the case with L2TP as well. One way to include all these cases in the scope of the draft is to say the tunnel endpoint SHOULD check the L2 payload for an IP header, even when the L2 header is not being added / removed. But that is rather an onerous requirement, don't you think? Especially given this would be asking the implementer to violate layering, we can only ask that it is done when feasible; it cannot be a hard requirement (e.g. L2 payload could be encrypted). > and in at least once case (VXLAN) there is a > recommendation to apply RFC6040 to an inner IP header. What do you mean by "there is a recommendation"? I don't see it in RFC7348? I am aware that the Linux code for VXLAN does ECN propagation per RFC6040. Perhaps that is what you're thinking of? > > Maybe the requirements for this scenario should be clarified? I think > it's probably reasonable to say that ECN SHOULD be propagated in this > case. Yes, overnight I shall mull on how best to rephrase the scope of this, without too much mission creep. Cheers Bob > > Tom > >> I would appreciate review from someone in intarea who knows these specs >> better than I do. >> >> If you know L2TP well, pls check the l2tpext list, where I have just posted >> three L2TP-specific question. >> >> >> Cheers >> >> >> Bob >> >> >> On 30/05/17 22:49, Bob Briscoe wrote: >>> David (as doc shepherd) and the tsvwg list, >>> >>> As requested, I have added specific text that updates the other relevant >>> RFCs under IETF change control (GRE and L2TP). I have also explained the >>> position in each case for specs not under IETF change control. >>> >>> I will now go to the relevant WGs (intarea and lt2pext) and ask them to >>> improve my first attempt. >>> >>> I'll cc you and this list as appropriate. >>> >>> Cheers >>> >>> >>> >>> Bob >>> >>> PS. I have also said >>> >>> the rules in [RFC6040] for >>> propagating the ECN field MUST be applied >>> >>> whereas before it said "SHOULD". And added an explanation for why "MUST" >>> is appropriate: >>> >>> The above is written as a 'MUST' because RFC 6040 allows >>> a compatibility mode for the encapsulator in cases where the >>> decapsulator does not (or cannot) support ECN propagation. >>> >>> >>> >>> >>> >>> >>> On 30/05/17 22:36, internet-drafts@ietf.org wrote: >>>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt >>>> has been successfully submitted by Bob Briscoe and posted to the >>>> IETF repository. >>>> >>>> Name: draft-ietf-tsvwg-rfc6040update-shim >>>> Revision: 01 >>>> Title: Propagating Explicit Congestion Notification Across IP >>>> Tunnel Headers Separated by a Shim >>>> Document date: 2017-05-30 >>>> Group: tsvwg >>>> Pages: 10 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01 >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01 >>>> Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01 >>>> >>>> Abstract: >>>> RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the >>>> rules for propagation of ECN consistent for all forms of IP in IP >>>> tunnel. This specification extends the scope of RFC 6040 to include >>>> tunnels where two IP headers are separated by at least one shim >>>> header that is not sufficient on its own for packet forwarding. >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed May 31 10:12:43 2017 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827DA129BB2 for ; Wed, 31 May 2017 10:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 0pHX_2n49jek for ; Wed, 31 May 2017 10:12:17 -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 31B44129B9A for ; Wed, 31 May 2017 10:12:10 -0700 (PDT) Received: from [128.9.184.76] ([128.9.184.76]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4VH992a014628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 31 May 2017 10:09:10 -0700 (PDT) To: Rolf Winter , int-area@ietf.org References: <149604303879.3966.14334001000021071156@ietfa.amsl.com> <8868c8ac-0bfa-8c98-69ca-0a932a986d4b@hs-augsburg.de> From: Joe Touch Message-ID: <0abe6f0f-9379-7de1-15ae-f40598f5365f@isi.edu> Date: Wed, 31 May 2017 10:09:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <8868c8ac-0bfa-8c98-69ca-0a932a986d4b@hs-augsburg.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 17:12:27 -0000 Hi, Rolf, Thanks - yes, this addresses my concerns. Joe On 5/29/2017 12:39 AM, Rolf Winter wrote: > Hi, > > we updated the draft trying to address comments made by Joe and Tom. > > In particular we added a section on types and use of broadcast and > multicast. This is not an all encompassing summary of it, but > highlights the types most important for the scope of the document. We > did not include LANE as suggested, because we felt that this is > side-tracking the discussion a little. Also, we left out relays for > certain protocols, as the focus is on the standard broadcast and > multicast capabilities of the network which proprietary protocols will > need to use, as by design, there are no relays for these types of > protocols. > > Joe, could you check, whether the new text properly addresses your > comments or not? > > Thanks, > > Rolf > > Am 29.05.17 um 09:30 schrieb internet-drafts@ietf.org: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Internet Area Working Group of the >> IETF. >> >> Title : Privacy considerations for IP broadcast >> and multicast protocol designers >> Authors : Rolf Winter >> Michael Faath >> Fabian Weisshaar >> Filename : draft-ietf-intarea-broadcast-consider-03.txt >> Pages : 13 >> Date : 2017-05-29 >> >> Abstract: >> A number of application-layer protocols make use of IP broadcasts or >> multicast messages for functions like local service discovery or >> name >> resolution. Some of these functions can only be implemented >> efficiently using such mechanisms. When using broadcasts or >> multicast messages, a passive observer in the same broadcast/ >> multicast domain can trivially record these messages and analyze >> their content. Therefore, broadcast/multicast protocol designers >> need to take special care when designing their protocols. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-broadcast-consider-03 >> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-03 >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area