Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Adrian Farrel <adrian@olddog.co.uk> Fri, 27 November 2020 14:13 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7B3A0BDE for <bier@ietfa.amsl.com>; Fri, 27 Nov 2020 06:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 0Qj00gGj7rBO for <bier@ietfa.amsl.com>; Fri, 27 Nov 2020 06:13:37 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 C16683A0D09 for <bier@ietf.org>; Fri, 27 Nov 2020 06:13:36 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AREDXIN024312; Fri, 27 Nov 2020 14:13:33 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 698F92203B; Fri, 27 Nov 2020 14:13:33 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 539882203A; Fri, 27 Nov 2020 14:13:33 +0000 (GMT)
Received: from LAPTOPK7AS653V ([195.166.134.111]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0AREDVg3012226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Nov 2020 14:13:32 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Tony Przygienda'" <tonysietf@gmail.com>
Cc: "'Jeffrey \(Zhaohui\) Zhang'" <zzhang@juniper.net>, "'Greg Shepherd'" <gjshep@gmail.com>, "'BIER WG'" <bier@ietf.org>
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <MN2PR05MB5981CEBAA6AB7329350293EED4E10@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV26CqDs8vwT=mcPQMVGVTFLVEOgVYtaYZyuyNiBFMYGcw@mail.gmail.com> <MN2PR05MB5981CB5AB50C0641A54DDCDAD4E00@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBqJ5HVUBzbNv-LjYsCqjdvtNvXtdOjCscGftkBrVtbEmA@mail.gmail.com> <CA+wi2hMTxELaf6MQv2ocdp7nxeOusW_dv6hUZ6O2uRZa=ob6Qg@mail.gmail.com> <02fd01d6c3f5$a8f23de0$fad6b9a0$@olddog.co.uk> <MN2PR05MB59815B822B853C19A60251DED4F90@MN2PR05MB5981.namprd05.prod.outlook.com> <033a01d6c410$92e413f0$b8ac3bd0$@olddog.co.uk> <MN2PR05MB5981468EC6B680A0671EA982D4F90@MN2PR05MB5981.namprd05.prod.outlook.com> <03c201d6c44f$478cd240$d6a676c0$@olddog.co.uk> <CA+wi2hP2ozNVSEWaTtXiJZEYmKd37VYLhxiSASRS64UKKYaE3A@mail.gmail.com>
In-Reply-To: <CA+wi2hP2ozNVSEWaTtXiJZEYmKd37VYLhxiSASRS64UKKYaE3A@mail.gmail.com>
Date: Fri, 27 Nov 2020 14:13:30 -0000
Organization: Old Dog Consulting
Message-ID: <049001d6c4c7$7c713be0$7553b3a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0491_01D6C4C7.7C72C280"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJW4ZgcgJn9V6dtIlaK/47czvNh1wE/cTJnAeqNA30DXQLSuwINZ543AaWk7vEBlsWxfwEyp29BAipMmkYBDXPuWgIxZfPEAc3KlMSoOfEF8A==
Content-Language: en-gb
X-Originating-IP: 195.166.134.111
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25816.000
X-TM-AS-Result: No--6.538-10.0-31-10
X-imss-scan-details: No--6.538-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25816.000
X-TMASE-Result: 10--6.538100-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbC/MZ1E/PtpxIiTd2l7lf6FOEILBOBemL2pm mKqvAIv7u7MLnfc0u3tQb2f8BNpv7LZuUe/HYL6qlTsGW3DmpUvP60q/FX5hsFcVXC6W/BMtZvo +mFW19mAiijEjtm5Ilv7K1AtfLy0afWGbSoc9kUbwqDryy7bDIS0rLNhFaIy7sp5O052MzLqby9 F6QvnXNqomeYPpRypQv1EnDvFdNJLKu8V2LYtvQZVRzPxemJL0pQH4ogtVQP1cpms3pMhT0QANW vJGjEIOZS3q7ULrhWoApVEyoAvqeBr6xpiiqQrsRFakFvQb7akbubJAjG7gv1c/Cedjlcvkl1c2 KaizWDT33Cn3R5G3IWJcmrvWNMBPPYlJFtcr6tH4AIbmhYnu0qt8JTb7GATYkLgFDSBkHMfV9x7 gL2l/Mla3sBCro+3p7bGd/pRQtMB4pkAgPeEdVoFQ6r3ltRpKwrtnG5u0wfCeI1jwWXaeIxzNua fMOUOd8zkrxz1SKuHl+dPvOwcMWonq5Bh0G7/+bMGKOuLn5FV+JGMYYph/2/PXnE+NdHS+9Spi2 XpXgKRGRpMTw05NY3d5M5tyqJS/5Wlph4hc0awtMfCdg6KRDTzLhqT0KeNijiLABC6i+1j0ixuM ZzTrwaokJCK+1+u4GZATdUS3TNagTtrJZysAVDIHIyLCTr7eNroBpCbt+GYzkEBwRJneSu//vbM LiEkVS23jFwoI7b1+1uW3cIJ1vBWVVkGuW6Jr3zSg/bkXzGlxDjcOu4ElXEp12IXZajx52TaXuL ehzjNHDd+lAeDDe5frKASrZ1St3/EFjqNmqdmeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLr8uVzX avvg1KMqIeOstif8TGYzM98Nm+qmOtm7JtwdnCidvpIyx3dvCkgVYai7Rtf4wrEX1p8/fBnxuCo 1cBGJuBtibJe4Ot3RzN7cvifBwjbQMqi02QQpvvawtFsFOOeqD9WtJkSIw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/JiEsZ_VOPiUJ7sQr204JhssknLM>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Nov 2020 14:13:39 -0000

Summarising…

1.	You wish we didn’t have to support tunneling over multiple IPv6 hops, but you think it’s going to happen so be better factor it.
We should capture that explicitly in the requirements doc.
2.	Given 1, we have no control over what happens in the IPv6 network. We should probably try not to do anything that encumbers “normal” IPv6 operation. That includes ECMP (but probably other things).

 

I’m *really* trying to stay away from discussing the solutions and the consequences. But..  :-Z

We can take two approaches to ECMP…

a.	Flow label and other primary fields are enough. Any attempt to look deeper into the packet is not necessary and if the router doesn’t understand the next header type it doesn’t matter.
b.	Where the payload is IP, Ethernet, or an IETF transport protocol, the router should be able to access it to improve the ECMP hashing.

 

Now, that leads me to a solution-oriented conclusion, but I’m not going to voice it. Let’s stick to the requirements.

 

Cheers,

Adrian

 

From: Tony Przygienda <tonysietf@gmail.com> 
Sent: 27 November 2020 01:11
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; Greg Shepherd <gjshep@gmail.com>om>; BIER WG <bier@ietf.org>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

 

<as individual> 

 

On Thu, Nov 26, 2020 at 3:53 PM Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > wrote:

Thanks Jeffery,

 

I think our discussion forks.

In one direction Tony says (possibly) don’t worry about legacy transit routers because we shouldn’t be tunneling through them anyway.

In the other direction we worry about legacy routers, and here you are suggesting we should hope that they are legacy-but-modern 😉 That doesn’t seem to work out for us because *if* we need to tunnel through non-BIER routers we should probably assume that they might be old enough to not be considered modern.

 

I do like your answer that if the BIER header is encountered as payload it will not be hashed because of the first nibble. I’d missed that and it handles the case of native encapsulation.

 

But I think that even legacy IPv6 routers that do ECMP are capable of walking the extension headers until they find a header that is a known protocol or until they find one they can’t parse. (But I may be wrong here.)

 

Now, we have got diverted (again) into discussions of what we can and can’t do with different solutions. We need to come back to the requirement:

 

Do we need to be able to tunnel through legacy routers? I am sure I hear Tony saying “no, that is explicitly excluded”.

 

I wish we couldn't but reality will be, people will throw tunnels multiple hops (and architecture allows that to deal with non-BIER HW inbetween)

 

If the answer is “no”, let’s capture that in the requirements doc.

If the answer is “yes” then we have a second question…

Do we need to provide ECMP in that tunnel?

 

well, it's IPv6 ECMP so who are we to argue how they do it. We should od the best we can to support v6 ECMP AFAIS but we don't have in BIER anything predictable but entropy field. 

 

If the answer to that is “no”, we’re done.

But if the answer here is “yes”, we have to ask…

Is it enough to rely on the flow label (and src/dst), or do other fields need to be available.

 

right, so what's your take here? BIER doesn't offer anything except an entropy field and that's what we can provide. encaps'ing it in UDP just oget 5 tuple sounds desperate and pretty dirty (think vxlan) and what happens if we carry native ETHER or MPLS inside, parsing into the BIER paylod to figure out WHAT protocol is carried (v4, mpls or so) and then into that is possible but sounds like a really, really, really deep silicon lookup 

 

what you're aiming at, Adrian?

 

-=-- tony