Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

joel jaeggli <joelja@bogus.com> Wed, 22 April 2015 06:34 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 A51841B31A1 for <v6ops@ietfa.amsl.com>; Tue, 21 Apr 2015 23:34:22 -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 no1lZSrmQ7et for <v6ops@ietfa.amsl.com>; Tue, 21 Apr 2015 23:34:21 -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 D91FD1B2D92 for <v6ops@ietf.org>; Tue, 21 Apr 2015 23:33:02 -0700 (PDT)
Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:6127:947a:22bf:5c78]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3M6Wq0c041964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2015 06:32:52 GMT (envelope-from joelja@bogus.com)
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>, Nick Hilliard <nick@foobar.org>, "v6ops@ietf.org" <v6ops@ietf.org>
references: <5536814D.7030708@foobar.org> <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
From: joel jaeggli <joelja@bogus.com>
x-enigmail-draft-status: N1110
message-id: <55374092.9000406@bogus.com>
Date: Tue, 21 Apr 2015 23:32:50 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: <1347296409.2158102.1429683600983.JavaMail.yahoo@mail.yahoo.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="rQqIIsgoBXuuU4I2m2pgxcHXve4vu2AJD"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/z-NcMHHlnauHNiIvR2aXaKtIs9Y>
Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
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: <http://www.ietf.org/mail-archive/web/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: Wed, 22 Apr 2015 06:34:22 -0000

On 4/21/15 11:20 PM, Mark ZZZ Smith wrote:
> So I'm going to call the emperor naked.

not a transit provider so I'm sitting in the edge that said I have some
exposure to this problem space.

hence

https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

> What I think you and Gert actually want is for EHs to be completely
> deprecated, so that the TCP and UDP headers are always in the same place
> in the packet, so that hardware can look at them for the purposes of
> dropping them in hardware or as inputs into LB. Is that the case?
> 
> What I'm curious about then is how do you handle DDoSes that are using
> IP fragments, where there are no TCP or UDP headers ports to look at?

https://datatracker.ietf.org/doc/draft-taylor-v6ops-fragdrop/

> I'm also curious about how you LB packets (either at layer 2 or layer 3)
> that don't have TCP or UDP headers, or aren't IP. I've seen LB become
> completely ineffective at layer 2 because a customer was using MPLS
> between two routers, so no MAC address variation, and no IP addresses
> and no TCP or UDP ports to look at.

as someone who does stateless l3+l4 loadbalancing to servers, if I can't
find the l4 header in an asic based forwarding engine even if a server
can I have problem.

> In fact, given the trouble LAG has caused me in the past 2 years (LAG
> member links that are not current members are supposed to be considered
> by the bridge as normal bridge ports, so if you want to avoid loops
> across the links that are candidate members of the LAG, the IEEE expect
> you to be running STP of some form across them...), I'm a big fan of the
> quote on the last slide of this presentation:
> 
> "IEEE 802.3ad Link Aggregation (LAG) what it is, and what it is not"
> http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf
> 
> 
> "LAG is good, but it’s not as good as a fatter pipe."
> 
> 
> ------------------------------------------------------------------------
> *From:* Nick Hilliard <nick@foobar.org>
> *To:* v6ops@ietf.org
> *Sent:* Wednesday, 22 April 2015, 2:56
> *Subject:* Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world:
> clarification text
> 
> On 21/04/2015 16:51, Gert Doering wrote:
>> I'm fully at a loss to express my amazement in polite words, so I'm just
>> *out* of this discussion now.
> 
> Fully agreed on this + that this thread needs to end.  The lack of
> operational reality being displayed is pretty severe.
> 
> Nick
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>