Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review

joel jaeggli <joelja@bogus.com> Thu, 06 August 2015 15:53 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4781B2E0E; Thu, 6 Aug 2015 08:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ysdS9SDtHcys; Thu, 6 Aug 2015 08:53:15 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 A89751B2CF6; Thu, 6 Aug 2015 08:53:15 -0700 (PDT)
Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t76FrCYV087262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Aug 2015 15:53:12 GMT (envelope-from joelja@bogus.com)
To: Benoit Claise <bclaise@cisco.com>, draft-ietf-v6ops-pmtud-ecmp-problem@ietf.org
References: <55C20D5A.6070409@cisco.com> <55C2A2B7.3050304@cisco.com>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55C382E1.8070406@bogus.com>
Date: Thu, 06 Aug 2015 08:53:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0
MIME-Version: 1.0
In-Reply-To: <55C2A2B7.3050304@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Rxg0KjxnueOkx7mDXu9vMRhJVA6VERIxn"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ZVGUypk26WLu9eut5og88iw0vdo>
Cc: "<v6ops@ietf.org>" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 15:53:17 -0000

On 8/5/15 4:56 PM, Benoit Claise wrote:
> Dear all,
> 
> Joel, being a document author, asked me to look into this draft
> Here is my feedback. I don't have any background on this draft. So a
> fresh pair of eyes.
> 
> 1. It took me a little bit of time to grasp the problem behind this draft.
> From the abstract, I(wrongly) assumed a PTB packet sent from the server
> back to the source.

yup it's the one from the client. let me see if we can tweak this slightly.

> It's only in section 2 that I found my answer (well, the second time I
> read it)
> 
>   An ICMPv6 type 2 PTB message generated
>    on an intermediate device _for a packet sent from a server_
> 
> And the figure 1 was not too helpful, as, obviously I was wondering
> about the ptb direction...

figure 1 contains

  ptb -> router ecmp -> nexthop L4/L7 load balancer -> destination

the limitations of ascii art may be a limitation here, but it's not
really a state flow since it could be emitted by any device in the path.
at any time. but I think if we address item 1 the problem of
directionality is no doubt clear.

> What would have made it crystal-clear is a figure 1 such as:
> 
>    Topology
> 
>    client -...-- router -- load balancer 1 --- server 1
>                       \\-- load balancer 2 --- server 2
>                        \-- load balancer N --- server N
> 
> 
>     Sequence 1: packet from source to server
>         client -> ... -> router ecmp -> nexthop L4/L7 load balancer  ->
> server (*)
>    
>     Sequence 2: reply from server to source
>                      .... <- router ecmp <- nexthop L4/L7 load balancer 
> <- server (*)
> 
>     Sequence 3: ptb sent back to the server
>                     ptb -> router ecmp -> nexthop L4/L7 load balancer ->
> server (**)
> 
>     Note: As (*) and (**) are unlikely the same instance, so the ptb
> could be mis-delivered
> 
> 
> 2.
> Confused about the order
> 
>  3
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3>.  Mitigation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-4>
>      3.1
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3.1>.  Alternatives  . . . . . . . . . . . . . . . . . . . . . .   5
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-5>

3.1 can be changed to Alternative mitigations

it's important that clamping the mss doesn't get lost in all if this
because both the ietf considers that minimum best effort (everything has
to carry 1280 right) and because people do it.

>      3.2
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3.2>.  Implementation  . . . . . . . . . . . . . . . . . . . . .   5
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-5>
>        3.2.1
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#section-3.2.1>.  Alternatives  . . . . . . . . . . . . . . . . . . . .   6
> <https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-03#page-6>
> 
>  3.2 is the implementation of what? The intro in section 3?

3.2 yes is an example mitigiation based  on 3 paragraph 2

> So why do you insert alternatives 3.1 (which you don't recommend) in
> between?
> And 3.2.1 is the alternative to what? the implementation in section 3.2

3.2.1 yes. the point being there's more than one way to solve the
problem. operationally one approach may be more desirable the the other,
in point of fact when I asked the cloudflare guys came up with their's
so I added it.


>
> 3.
> 
>     1. Filter-based-forwarding matches next-header ICMPv6 type-2 and
>        matches a next-hop on a particular subnet directly attached to
>        both border routers.  The filter is policed to reasonable limits
>        (we chose 1000pps, more conservative rates might be required in
>        other implementations).
> 
> border router? make it consistent with the terminology in figure 1

ok routers

>    2.  Filter is applied on input side of all external interfaces
> 
> Make it clear that you speak about router in figure 1

external routers

>    4.  Anycast servers receive the PTB error and process packet as
>        needed.
> 
> "anycast server" make it consistent with the terminology is figure 1

figure 1 is bounded by width limitations for ascii art otherwise the
label would be longer, the fact that it is naycast is brought up in
section 2. we can probably arrange to us server more freely in the text
prior to this.

> 
> 4.
> Section 3.2.1 
> "ECMP hop could distribute the proxy onto the end systems"

   Alternatively, network designs in which a common layer 2 network
   exists on the ECMP hop could distribute the proxy onto the end
   systems, eliminating the need for policy routing.

Proxy in this case refers to the mitigiation proposed in section 3
paragraph 2 of which this is a sub section.

The excerpt is missing a preposition ( exists on the ECMP hop)  and I
agree it's hard to parse without that.

> Not sure what it means.
> 
>  5.
> section 4. Improvements to what? The implementation or the potential specification.

These are improvements on the mitigation. they are not specification
changes rfc 4821 already exists it's just not widely (at all afaik) used.

> I guess the "specification", but then, how is this different that the mitigation section?
> Your improvement point 1 is the same as the "mitigation" section paragraph 1

Right but no asic or at least microcode exists today can actually do that.

> Your improvement point 2 is the same as the "mitigation" section paragraph 2

no it isn't. in the mitigitation it was necessary to build a proxy to
flood them by  rewritting the L2 nexthop.  that's rather different than
getting router to forward a unicast packet to say 16 destinations if
somebody gives me a knob for the latter then all this proxy junk is done.

> 
> nits: 
> implmentation -> implementation 
> 
> Regards, Benoit
> 
> 
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>