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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 29 March 2017 21:18 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 44C471295EB for <int-area@ietfa.amsl.com>; Wed, 29 Mar 2017 14:18:43 -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 nW2VcjiNrDI7 for <int-area@ietfa.amsl.com>; Wed, 29 Mar 2017 14:18: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 45F0112945D for <int-area@ietf.org>; Wed, 29 Mar 2017 14:18: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 v2TLIelx026997; Wed, 29 Mar 2017 14:18:40 -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 v2TLIbAh026954 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 29 Mar 2017 14:18:37 -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, 29 Mar 2017 14:18:36 -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, 29 Mar 2017 14:18:36 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>
CC: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
Thread-Index: AQHSpxB0dZTEVAB270esoqM4xp8NZaGqcslggACqEoCAASy6sA==
Date: Wed, 29 Mar 2017 21:18:36 +0000
Message-ID: <6ede932f07ca4b8ebd17f82e17eb4cf4@XCH15-06-08.nw.nos.boeing.com>
References: <149062888196.30638.8369941985115982808@ietfa.amsl.com> <f5ab0422-fd49-9082-147b-8312e974de7e@isi.edu> <4d2a86f4948c4dc49ab3b0729743d028@XCH15-06-08.nw.nos.boeing.com> <583e59d2-f846-6cd6-8e15-f3a0888889ac@isi.edu>
In-Reply-To: <583e59d2-f846-6cd6-8e15-f3a0888889ac@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: <https://mailarchive.ietf.org/arch/msg/int-area/hiaWaLOv-6F1QwOfxUt1GlmIUaM>
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 <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 21:18:43 -0000

Hi Joe,

See below:

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tuesday, March 28, 2017 12:38 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
> 
> Hi, Fred,
> 
> Thanks for the feedback. Let's assume I incorporate the nits/bugs and I
> address any clarifications when I get to them in detail, so I'll jump
> only to the deeper issues below...
> 
> Joe
> 
> 
> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
> > Here are my comments for this draft. Mostly editorial, but some substantial.
> > I also noticed several indications that further work was needed in some
> > sections. Will those sections be worked before publication?
> As per Mark's presentation, it depends on whether this doc stays
> informational (as was adopted) or becomes BCP (as we think it probably
> should).
> 
> If informational, much of Section 5 will be removed. If not, then that
> will be fleshed out.
> 
> > 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". Calling it
an "atom" would be introducing a new term here, and we could
argue whether the term would have more or less baggage than
the term "cell".

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

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

> The current doc does need a scrub to make this point clearly and
> consistently.

It doesn't work, regardless of the amount of scrubbing.

> > 14) Section 4.2.2, should include discussion of how common tunnel
> >     specs regard EMTU_R and the tunnel atom (cell) size. Namely,
> >     many common specs assume larger EMTU_R and tunnel cell sizes
> >     than are guaranteed by RFC1122 and RFC2460. That means that
> >     these tunnel specs are relying on operational assurances of
> >     larger values than the IPv4 and IPv6 minimums. Since they are
> >     already published as standards, this document needs to explain
> >     how they are able to operate without fragmentation.
> I'll see what I can do to add that point; I'm hoping to not need to cite
> dozens of examples, though.

OK, and I agree that you shouldn't need to cite the multitude of
standards that do this.

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

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

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. 

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

Thanks - Fred
fred.l.templin@boeing.com
 
> -----