[Pals] Fwd: MPLS transit heuristics

Stewart Bryant <stewart.bryant@gmail.com> Wed, 25 October 2017 15:55 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F21813DC3B for <pals@ietfa.amsl.com>; Wed, 25 Oct 2017 08:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 IGTIFy1EMfTM for <pals@ietfa.amsl.com>; Wed, 25 Oct 2017 08:55:52 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 0304B13DA67 for <pals@ietf.org>; Wed, 25 Oct 2017 08:55:52 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id o44so458206wrf.11 for <pals@ietf.org>; Wed, 25 Oct 2017 08:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7V39ueLTACocN0V6AuBENQ4RWepO/jYHZp7wj5sm2Tg=; b=SI6FLJfyUw9uNN+BFNGx49YOU1Dvd+pDDH1xTmsQrmihuJu3a5L8RitrdKG7qO4Vw3 LB1xDkrt/jvfawhV+Ak2Bdjj+Qu5xd0pPyZ2upTF5R4SUIIBzYD09AzjFelZ1+uKxppI Ad9loJx7vZ0hvr24B3STLDclxXcdeeJUXZGDbA+lXb4uIeiykG0vcZXrGu41XEP12S3I +rXKBmkw36YPH1xJOQ4Lomsi8T1QMmMVqtv4Wsh8KyO5ho2CoJkfXadtp60GjM/qjVdj r3sbF+kNlTtfgt82DQvqgQRaFQ6BfbYiS1k2C+7qKOb/V4zBbZv453n1TY9GgBTTF7x5 VAPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7V39ueLTACocN0V6AuBENQ4RWepO/jYHZp7wj5sm2Tg=; b=FTm/EdEZoio4XyImFYZGTr338nJ0/3aT97+9UsKeSnITiTaPa0aoknLO9gLoRRCUhm UYyEUlLV0MUdZz0HszfoWGXkWhBCQJ1/dz9dB6n3Eu0sBV5CrmEtds4NPpHGW6XfeYE0 GFOCPsKcEtGjO6g5mV17nHj7yLx3HagvWajb+p9CHo07vqszqBQGUTy9Oz5b5inpISHD eIvstuon83cJt3cJnJuSBNq31BcMVTntBXGLkst9tZHL0feStEGLiSWkakd5EznN7Bo4 ihdJwA3bSxDuznu2o/R8U0gczFeiPvUtNsJzMl4sV07vTrM0IvUtHQjECJzKeQhw54/W 8lrA==
X-Gm-Message-State: AMCzsaWKkG4JWWft84fgsURe7qmntaVEsLrq4qig0yLFUi8/7KdfneNS LjhOA2k7n9iymIaAStjQk7b+nvxy
X-Google-Smtp-Source: ABhQp+Q+nLJRqFgfeOLOEOLByvAzowK7aEJmdwEcRp+LVb8wLcKe8gC2v9yxOZz/vioPMOVGH9/FDA==
X-Received: by 10.223.166.146 with SMTP id t18mr2852897wrc.64.1508946950468; Wed, 25 Oct 2017 08:55:50 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id u18sm3798489wrg.94.2017.10.25.08.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Oct 2017 08:55:49 -0700 (PDT)
References: <CAAeewD-o2HergukOn5K39s-TyHhzxRuRX0=jN8jc-Yz_5oP0pg@mail.gmail.com>
To: "pals@ietf.org" <pals@ietf.org>
Cc: Saku Ytti <saku@ytti.fi>, Job Snijders <job@instituut.net>
From: Stewart Bryant <stewart.bryant@gmail.com>
X-Forwarded-Message-Id: <CAAeewD-o2HergukOn5K39s-TyHhzxRuRX0=jN8jc-Yz_5oP0pg@mail.gmail.com>
Message-ID: <3d3a966d-c2d0-6e35-880c-a1932fa18979@gmail.com>
Date: Wed, 25 Oct 2017 16:55:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAAeewD-o2HergukOn5K39s-TyHhzxRuRX0=jN8jc-Yz_5oP0pg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------962B3C65A034F88BC661BBCC"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/u7_LXi_75IxSgtiZAVKS4HIziwg>
Subject: [Pals] Fwd: MPLS transit heuristics
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 15:55:54 -0000

Thanks to Ytti for pointing this out.

It seems that there are other implementations that also do deep heuristics.

- Stewart



-------- Forwarded Message --------
Subject: 	MPLS transit heuristics
Resent-Date: 	Wed, 25 Oct 2017 02:22:33 -0700 (PDT)
Resent-From: 	alias-bounces@ietf.org
Resent-To: 	stewart.bryant@gmail.com, agmalis@gmail.com, 
ibagdona.ietf@gmail.com
Date: 	Wed, 25 Oct 2017 12:22:25 +0300
From: 	Saku Ytti <saku@ytti.fi>;
To: 	draft-ietf-pals-ethernet-cw@ietf.org
CC: 	Job Snijders <job@instituut.net>;



Hey,

Just enabling CW does not stop transit from mis-guessing payload.
Complete solution requires


a) Enable CW
b) Disable payload heuristics in transit (only rely on labels)
c) Enable Entropy or FAT (ECMP/LAG is essentially non-optional today).


Why enabling just CW won't help, is that some platforms, like JunOS
will by default try to detect presence of CW and proceed with
heuristics with different offset if or not CW was detected.

This creates several problem, first if you have CW and non-CW traffic,
then non-CW traffic with XEROX DMAC will cause wrong offset for
heuristics, allowing transit to misidentify.

JunOS isn't just checking for first nibble, it'll need etherType,
ipVer and and ipLen to match. But as detecting CW doesn't actually
change the heuristics, just offset. There is 0 guarantee that we are
actually seeing IP packet when we think we are. It is highly probable
we guess right, but really convenient packet, and we will misidentify.
Because it'll need extremely convenient frame, it will happen very
very rarely, but when it does, no one will be able to troubleshoot it.
How can you attribute problem like this to core 'everything works
perfectly on every station before we added GRE tunnels to our
stations, but after we added GRE tunnels to our station, _one_ station
experiences packet loss', this is possible outcome in JunOS
implementation with or without CW, unless heuristics is also disabled.

ytti@r24.labxtx01.us.bb-re1# set forwarding-options enhanced-hash-key
family mpls ?
   no-ether-pseudowire  Omit IP payload over ethernet PW from the hash-key
   no-payload           Omit MPLS payload data from the hash key
https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html


http://ytti.fi/pseudohell.png

-- 
   ++ytti