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

Adrian Farrel <> Thu, 26 November 2020 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98CF63A108B for <>; Thu, 26 Nov 2020 05:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dl0RQNQLRK3x for <>; Thu, 26 Nov 2020 05:11:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D5793A1084 for <>; Thu, 26 Nov 2020 05:11:36 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 0AQDBXf9021047; Thu, 26 Nov 2020 13:11:33 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 819B52203B; Thu, 26 Nov 2020 13:11:33 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 6BF032203A; Thu, 26 Nov 2020 13:11:33 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 0AQDBV7j012994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Nov 2020 13:11:32 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Tony Przygienda'" <>, "'Greg Shepherd'" <>
Cc: "'BIER WG'" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Date: Thu, 26 Nov 2020 13:11:30 -0000
Organization: Old Dog Consulting
Message-ID: <02fd01d6c3f5$a8f23de0$fad6b9a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FE_01D6C3F5.A8F2DA20"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJW4ZgcgJn9V6dtIlaK/47czvNh1wE/cTJnAeqNA30DXQLSuwINZ543AaWk7vGoiD4kEA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--5.667-10.0-31-10
X-imss-scan-details: No--5.667-10.0-31-10
X-TMASE-Result: 10--5.666900-10.000000
X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbMGNvKPnBgOaf6iC0fNopZm5K2LUGgeo9hPG mi1N02rqxbFLHHeGK6WAdHUuvxzmfO4nE9/5On7kbeVjUPAuRsapB34ezti/uxdxU211U8eCu4k FqJqYgtHNtpuh0JTLmAtiP/IxAbjtquGM4v2rVfuprpImTnz4ti/6pa9YxNkxeWrZ5uNwmk13ul 3YOZKsr3yf6L4FCq4XGyW5eflM9Zh2DOBFJe2MXyxaglEO8YXMguwtqyXlE6EruUVdHizCWec9u TWZVtE9IH+lJfHXW0wJNx5HSxkhEO5AunY+eGod40jcxy3aXNo1X1Ls767cphW+93iqRvX7BjXK Pl04Nk9Z7knSEOJ+7zH7wXD2VTL7aBevM/eurMfG693ff8j9ZLhmEEF0z0FZe7ijHq7g9obUjgj /Y0GZgtUvIWq5IE4nDd/boLgdYLAL6WqH6WmX3i/MuWzsdN8ZxlTeSbP0L8e77ExFvcxKE9RLWU k/X2OZIkMfm3ZD3muFTbmaXoQVLSRAKGLOqnEcWTGejGdB9VIbQ57RP6lOUSvFSzw3D/Z+JeLxn uELHSi4sCBjXtjOxDjg8ByNel7pi1Wy9iZD/yhYcYljwpu4xAZyESFXAljfBCzD0Dc8iUt0CWYL 2/UpqyLl1QRjV0UczKtqhcfnlJSUwv7broiTGuVSr005h5SpB7lMZ4YsZk+1eX0jEQ9c6th0G2S RzYOc5D2tKiyNJ30Rkfeo8/5evkQ3QFLy6/3RvTbC9sRJi8tjOK+x61Ttn0Yza41dGqxSa7zSl1 9MxFeAqaPWZq/mIC//e9EoAQLFx+58WEjyi9+eAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKgwoKUf6Cqk/5uG8PNrB8kGM2rXyXqBgwWEw3Pn2QC8d1MlI2fGejH5rySI1iO8aAPU5Sb9VB 9Xo8BrHj7MhLpMHf80AIkImkw0JFKZrtaVBHftwZ3X11IV0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Nov 2020 13:11:41 -0000

I’ve been reading up on this thread and the three related drafts.


I don’t dip into BIER often (I’m not a multicast person, and I have a life), but this seemed to be a fairly weighty topic which has been bubbling away for a while, and the volume of the discussion suggested that this is a really important question (it sounded like a life and death decision judging by some of the emails!).


I think Tony captured some really key points in his email below. I particularly like his observation that BIER is working at the neck of the hourglass: that demands caution and good judgement; it also requires everyone to step back and do the right thing regardless of their investment (emotional or financial) in their preferred solution.


It seems to me (again, from the outside, and apologies if this is re-opening age-old discussions) that most of this is just protocol engineering. We have long experience at making any protocol do anything we want. If a particular solution lacks some capability, it can always be added with an extra TLV. That makes comparisons of solutions (also known as beauty contests) somewhat pointless: if you judge A better than B because B lacks some feature, then we just add the feature to B, and the cycle starts again.


That means that, while the requirements work is highly valuable for working out what the solution should deliver, it is not so helpful in determining which solution the WG should pursue. We are left, IMHO, with some of the edge requirements about transiting non-BIER nodes. These are nodes that can happily process “normal” IPv6 packets, but don’t know what to do with a BIER encapsulation. That looks like Section 3.1.3 of the requirements draft.


Embedded in that requirement is discussion of what an IPv6 router that is a transit might do with a packet. On the whole, routers just route on the fields in the v6 header itself, but they may look deeper in order to perform ECMP functions etc. For example, they may look for the transport payload to hash on ports etc. To achieve this, a router must be able to step over any additional headers (RH, DOH, etc.) to find the payload or must know not to even try. In general, a router that doesn’t understand a header will step over it if it can, but will probably give up the hunt for hashable fields. 


At this point I ran aground ☹ 8926 doesn’t have anything to say about ECMP in a BIER network (with or without BIER-capable routers). But 8279 has a nice fat section on ECMP, but this seems to describe how ECMP works when processing the BIER encapsulation for equal cost paths between BIER routers, not for how the “underlay” (the IPv6 network in this case) might handle equal cost paths in its own routing.


Any clues as to how ECMP is expected to work in the context of the v6 requirements? Anything that should be added to 3.1.3 or a new section?






From: BIER <> On Behalf Of Tony Przygienda
Sent: 20 November 2020 05:36
To: Greg Shepherd <>
Cc: BIER WG <>rg>; Gyan Mishra <>om>; draft-ietf-bier-ipv6-requirements <>rg>; <>cn>; Alvaro Retana <>om>; Jeffrey (Zhaohui) Zhang <>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09


Well, I’m glad that the work on requirements draft, albeit as product found wanting in AD’s assessment, has led to clarification of the crucial questions that e'one seems to agree need to be asked. 

It surprised me then mildly that my co-chair had to explicitly lay out the semantics of what was a clear direction spelled out during the meeting but that’s all well to get e’one better in sync I guess. Needless to say I am sharing his assessment and questions put to the room entirely. 

Some things that I think need explicit spelling out IMO after the last few meetings (since I’m not sure e’one in the process internalized that) is that WG is not here to tell people they cannot work on something whatever the perception seems to be, IETF doesn’t work that way. People go sideways and build stuff based on what we publish/develop in open source and for their customers in all kind of ways which may be neither fitting into an architecture, consensus or interest of a WG all the time. And that’s wonderful and more power to them, RFCs are free to download and they are just RFCs, they are not stone tablets brought from the mountain. However, and that's a big however, _if_ a work is looking for WG adoption and ultimately RFC status, the IETF process kicks in and the process has been here and well debugged over 30 years and that’s why Internet was built IME. The process is unusual in the way that it resists pretty well pressure based on non-technical claims, exceedingly poor architectural choices, chair shopping, padding of communication channels with “I participated only once to send a +1 to a list”, ad-hominem attacks and similar shenanigans that have been all tried over and over again. In the same vein the process tends to weigh based on reputation of “who said what in which context”'; such reputation being built on community service and sound work over many years. And sometimes hard calls are made based on rough consensus called by people that are here to steer stuff and nudge it along the way. Sure, it’s easy to standardize and build “something”, it’s very hard to keep it going operationally @ Internet scale for 20 years and lots of those lessons are unfortunately scar tissue not easily transferred except at level of RFC1925. Last point to emphasize is that BIER is not the average set of RFCs, we have been handed the permission to go into the hourglass of the Internet, something that happens every 15 years or so. The stuff we deliver is as fundamental as MPLS or IP forwarding plane and as PS has to meet toughest architectural standards to prevent a melt-down of non-orthogonal, under’spec’ed solutions leading to poor operational properties @ scale and non-interoperable solutions which long-term serves no'one well that relies on IP technology to support high quality infrastructure @ scale.