Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Tony Przygienda <> Tue, 20 February 2018 04:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F822126CB6; Mon, 19 Feb 2018 20:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 16B9XI1jyuPC; Mon, 19 Feb 2018 20:51:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0F1D124D37; Mon, 19 Feb 2018 20:51:08 -0800 (PST)
Received: by with SMTP id q83so9496239wme.5; Mon, 19 Feb 2018 20:51:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u4Ew7NRzmIfP7cTKL7zwzJRCcqMtvgkBF/x9q8DarzY=; b=YKP0ad9rfejkXlLX81NQAxRwADY0yTzfhZdw5EwISvOBmt+f1hSNtDv/p2snEQLdgI +dJ/X/torNH1QruusP4A0Bn+CB6uTkoVTd431O5KY3rkktqQk55qbrKUb0BzQGzZ2cwp rKv/HVlRcec8bwK308OrwXcErcjaxX4y92HFocP7EiVV+VQYvfnYjvBGG7jw1ezgdVuu eHHk5zXaB/1mNvD3ygq8PFkaFCVuWAEOs4Xe00PYhdOsjKjMWOP5H/pR+KL3bmt2IN2d LIQzwvc9cDR8pJIhEqiPW9YWK8eqS0PuvUIDdVJ22upsilI7JWiZjB5119nrQ624Z6Mg DJnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u4Ew7NRzmIfP7cTKL7zwzJRCcqMtvgkBF/x9q8DarzY=; b=nXeeYu7THwwvoRSQIik0IZ9vtJLlNIpAf2ZhVRreOGu58DTbV1nTJDuQ5xTS0FE+nr 4dcxcUBbvdyTNHM1jt0b5v4RTXQ6PjKr6k9RW1XhOPjOqtjBcJaZCJU0ZLfGbNUn0mOO 2tNnTwOvdhExr39eMONQfDiRjp6AQlojClNXnC47aiK4jPwCxQd8IZg6h5yn76dOmT8l vdid3G/kVPmsnFYohCcd7bSp3I9AfXR9rsGPpQ7Be+W28o2LbTpIbUpWr6bBGGx9httj ZEDtqntus/7FvK6vLOi8+BGsjnAMq5k51iBCU2IwrBH/XYEXIRM4Lp9b1fp7ZX0tIuXh DIxg==
X-Gm-Message-State: APf1xPCTdgIIlZUKjwzA6o0dVpa89zvU2ew8jDkmeXadzimh4XOGYgJ3 jtz78l0hY6dC7Nel3S0/MPPQwx4uY8DlpXPL1Ss=
X-Google-Smtp-Source: AH8x2246W8vEd7GmakW7yuh7VvLM7sgc3VHsgJsNbpGeed7I6PuaDmojNUHXjrPTKTmnKB7Vz+wq5b1fJc1NBaqcqJ4=
X-Received: by with SMTP id 61mr22203483edh.16.1519102267333; Mon, 19 Feb 2018 20:51:07 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Feb 2018 20:50:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tony Przygienda <>
Date: Mon, 19 Feb 2018 20:50:27 -0800
Message-ID: <>
To: IJsbrand Wijnands <>
Cc: Alia Atlas <>, "Les Ginsberg (ginsberg)" <>, "Dolganow, Andrew (Nokia - SG/Singapore)" <>, BIER WG <>, " list" <>
Content-Type: multipart/alternative; boundary="94eb2c0da41205a25a05659d8f01"
Archived-At: <>
Subject: Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Feb 2018 04:51:11 -0000

> Les’s response to Andrew’s comments are spot on. Over the weekend we tried
> to converge over a 16 bit BAR, and how it would look like. We where not
> able to converge on the semantics, especially related to option B and
> the “BAR sub-type”. Its opening an other can of worms and will cause new
> discussion over the BIER architecture in the future. I know, not your
> problem.
And would you care to explain in plain technical terms HOW the option B)
will cause problems specifically?  Allocating a BAR type will put the
sub-type (or whatever we call it) under full disposition of the allocator
of the value who can use it as it fits the problem they are out to solve.
You need under your BAR value an IGP registry, go ahead, you want some
flex-algo, feel free, you need some indication of e.g. hash value to
tie-break multiple possible computations, works for you ...  Same can be
achieved with sub-TLVs but as I explained in less backwards compatible
fashion. IETF must have been doing something very wrong in the last 20
years to have registries in place so resolving this mysterious unseen
problems could benefit us all ...

It seems to me like putting BIER BAR type under a clear, well managed
registry is actually the way to close this most interesting 6 months where
no'one had a particular idea where things were supposed to be steered until
things came to head and we finally talk openly about the probably
well-meant intentions (while still being very thin on truly technical
arguments of those intentions I observe) ...