Re: [Bier] Warren Kumari's No Objection on draft-ietf-bier-architecture-07: (with COMMENT)

Warren Kumari <warren@kumari.net> Wed, 05 July 2017 20:49 UTC

Return-Path: <warren@kumari.net>
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 64C3E131DDF for <bier@ietfa.amsl.com>; Wed, 5 Jul 2017 13:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 Xqio5CBH9Z93 for <bier@ietfa.amsl.com>; Wed, 5 Jul 2017 13:49:24 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 17359131DDA for <bier@ietf.org>; Wed, 5 Jul 2017 13:49:21 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id g40so385769uaa.3 for <bier@ietf.org>; Wed, 05 Jul 2017 13:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oQ8lBvo36EuwAt/wWZnYPdOovwnaoAP4t2tcSNEHR5k=; b=wEndIurSPXbZIesTdKsSDwrLFCJX2b0cCsFqOOwIzws77S2ClR+fwLhsI1WkmNJc+Y I/8sRzxNxXp2bLVdOcQWE4P9gyuS00BPzbiIer2iFthgMAHTO5oLOcOr4EZeB1Lua4Zb cmUlpUi1DyroJs790nNjZ2kRPz51oPyX6Mwh17/m1U650hLw1fPRkqBYKUhLVBBV5j0l 2a4eYoRHCwC3HUy8VwoXC/IFg38wzW5FfoDmHu0vssJPJJ23KJB3Ss0coFxM0liFc8zL OfSLDdRhYno2KmxzXUkZ/QpOsYMr/HROpc14PJ4idgSnVvfWuidpgoxQsV2LfmLUcCVM QRbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oQ8lBvo36EuwAt/wWZnYPdOovwnaoAP4t2tcSNEHR5k=; b=eUfgm6fdx1lx6kkKUJesK2TNWiIlEEqKZBj4X6Zj0HB/5KatoTE5r+NEWTZlioMw8l F1Rq/RQuNn7oYWdNivrow9Sj0e+tO5mLGUs6puNqiySRptVx7falLnu9farLMkUdXhHS Qg0QiRP56UbmtkKH/SV0yBDhF6Z1gwNCSGCwlOm8//kiRMwSji2/A9KthHD2fNDuE/PP 1EGkfwv8Qia1hqoR5YycyK5z3Xfwzvqum1G16eyTgJOTS9Nzue0QxvQ8mTeatBos/taB SOuZAdaO3WPeyKKX+45PxDqEMF3iOrGzU6+0YwWWhO4HsyfP/kJtT14i4qjpfTHVkZ+L ysWA==
X-Gm-Message-State: AKS2vOxfoyEZNFSHhQXfhVudf/+ZaKKQxbA5Pqv/r6/02pk4kHwa0JI/ BXPzmnzFZoFmgmGUIog+sjPmAlO9PHwd
X-Received: by 10.159.59.93 with SMTP id j29mr24595454uah.155.1499287759909; Wed, 05 Jul 2017 13:49:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.39.165 with HTTP; Wed, 5 Jul 2017 13:48:39 -0700 (PDT)
In-Reply-To: <46b9c2e5-f4dc-7fbd-7b6b-72de693af9ae@juniper.net>
References: <149928257588.22631.11073122843340523128.idtracker@ietfa.amsl.com> <46b9c2e5-f4dc-7fbd-7b6b-72de693af9ae@juniper.net>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 05 Jul 2017 16:48:39 -0400
Message-ID: <CAHw9_iLzRVy+AVMJKbvVr7UXGMzit0ttXZ5mgzHzRb86anZtjw@mail.gmail.com>
To: Eric C Rosen <erosen@juniper.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bier-architecture@ietf.org, Greg Shepherd <gjshep@gmail.com>, bier-chairs@ietf.org, bier@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Tl3doTbVBMsTjWwPjyTg7Red7ho>
Subject: Re: [Bier] Warren Kumari's No Objection on draft-ietf-bier-architecture-07: (with COMMENT)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 05 Jul 2017 20:49:25 -0000

On Wed, Jul 5, 2017 at 4:08 PM, Eric C Rosen <erosen@juniper.net> wrote:
> On 7/5/2017 3:22 PM, Warren Kumari wrote:
>>
>> Notes:
>> Section 1:
>> "If the packet also needs to be sent to a BFER whose BFR-id is 257, the
>> BFIR
>> would have to create a second copy of the packet, and the BIER
>> encapsulation
>> would specify an SI of 1, and a BitString with bit 1 set and all the other
>> bits
>> clear." - while reading this it seemed to me that it would be much simpler
>> to
>> do away with the SI completely and just make the BitString N bits longer
>
>
> The size of the BitString is really determined by the capabilities of the
> forwarding hardware.

Oh. Yeah, that is obvious (now :-)).

>  And the encapsulations (at least, those specified in
> draft-ietf-bier-mpls-encapsulation) support only certain sizes.  If your
> hardware supports only a BitStringLength of 256, and you have 257 BFERs, you
> can't just say, "hey let's use a longer BitString".  Even if your hardware
> supports the next larger BitStringLength, 512, you might not want to use a
> BitStringLength of 512 when you only have 257 BFERs.
>
>> (instead of having e.g a one octet SI and 2 octet BitString, concatenate
>> this
>> and have a 3 octet BitString).
>
>
> A 3-octet BitString would allow you to identify 24 BFERs (3*8), whereas a
> 1-octet SI and a 2-octet BitString allow you to identify 4096 BFERs
> (256*16).  BTW, the BitStringLengths that are envisioned are all larger than
> two octets.  I wouldn't expect to see less than 64 bits, and 256 is more
> likely.
>
>> It was only when I got down to Section 3 that I
>> discovered that this is (kinda) discussed, and that each SI can have a
>> different BitString length.
>
>
> Sub-domains can have different BitStringLengths, the SI is relative to a
> single sub-domain.  The fact that sub-domains can have different
> BitStringLengths may be useful if you have hardware that supports multiple
> BitStringLengths, but that's really orthogonal to whether the SI is needed.
>
>> "Alternatively, one could deploy a routing underlay that creates a
>> multicast-specific tree of some sort, perhaps a Steiner tree." A reference
>> for
>> Steiner trees would be nice -- best I could find was probably the WA page
>> at:
>> Weisstein, Eric W. "Steiner Tree." From MathWorld--A Wolfram Web Resource.
>> http://mathworld.wolfram.com/SteinerTree.html
>
>
> I think it is probably best to remove the mention of Steiner trees and
> instead just say that the routing underlay could be some sort of multicast
> tree.

Awww. I really wanted a router with a big bucket of water and some
soap, but your solutiuon works too.

Thanks,
W



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf