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

Toerless Eckert <tte@cs.fau.de> Mon, 19 February 2018 23:00 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406B1126BFD; Mon, 19 Feb 2018 15:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.96
X-Spam-Level:
X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Dxz4t31MkZY9; Mon, 19 Feb 2018 15:00:46 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40371241FC; Mon, 19 Feb 2018 15:00:45 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5952358C595; Tue, 20 Feb 2018 00:00:41 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 37870B0DAE3; Tue, 20 Feb 2018 00:00:41 +0100 (CET)
Date: Tue, 20 Feb 2018 00:00:41 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Alia Atlas <akatlas@gmail.com>
Cc: BIER WG <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Message-ID: <20180219230040.GC17205@faui40p.informatik.uni-erlangen.de>
References: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/qbPeZcXnrgGasQ8rO-H_osYr8UI>
Subject: Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 23:00:48 -0000

"current status". 

Maybe folks should ask themselves: 
Whats the worst case that could happen when we stick to "current status" ?

IMHO, we can do whatever we want with future work in a backward compatible
fashion and would at most have wasted 7 bits of BAR field. Thats not bad
enough to delay these 2.5++ year old drafts any further IMHO.  Best case, we
will have more efficient encoding for future work than future/additional {sub-}sub-TLVs
if we'd shrunk/cut the field now. 

Cheers
   Toerless


On Mon, Feb 19, 2018 at 04:51:01PM -0500, Alia Atlas wrote:
> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
> draft-ietf-bier-ospf-extensions-12, I have been following the discussion on
> the mailing list with interest.
> 
> I have not seen clear consensus for any change.
> 
> Let me be clear on what I see the options are from the discussion.  Then
> I'll elaborate
> a bit on how you can express your perspective most usefully.
> 
> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only
> value 0 is specified.  The drafts do not have an IANA registry - with the
> expectation that one will be created when the first additional use is
> clear.  It is possible that there will be objections from the IESG to
> progressing without an IANA registry.  Given the lack of clarity for future
> use-cases and after discussion, I decided not to force one after my AD
> review - but I will not push back against having a BIER IANA registry if
> raised by others.
> 
> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current
> TLVs.
>    Define an IANA registry for the BAR type.  The meaning of the BAR
> sub-type derives
>    from the BAR type.   We can debate over the registration policy for the
> BAR type.
> 
> 3) Option C: Change the BAR field to be 16 bits and define an IANA
> registry.  Part of the range can be FCFS with Expert Review, part can be
> Specification Required, and part can be IETF Consensus.
> 
> 4) Option D: At some point in the future, if there is an actual understood
> and documented need, a BAR sub-type could be added a sub-TLV.  The length
> of the BAR sub-type could be determined when the sub-TLV is defined.
> 
> Given
> 
>   a) option D exists
>   b) there is currently only one defined value for BAR
>   c) I do not see strong consensus for change to one particular other option
> 
> I see no current reason for a change and I certainly see absolutely no
> reason for
> a delay in progressing the documents.
> 
> I do want to be clear about what the WG wants to do on this issue.
> Therefore, here is
> my following request.
> 
> Please send your feedback to the mailing list as follows:
> 
> IF you prefer or can accept the current status, please say so.  No more
> justification
> or reasoning is required. I just don't want the bulk of folks who are
> content to be
> overlooked by those suggesting change.
> 
> IF you prefer or can accept the current status, but think there should be
> an IANA registry
> as is usual for managing code-points, please say so.  No more justification
> is needed.
> 
> IF you prefer Option B, C, and/or D, please say so with your explanation.
> More technical depth than "'we might need it" would be helpful; the
> availability of sub-TLVs already
> provides future proofing.
> 
> IF you have a clear technical objection to why the Current Status is not
> acceptable,
> please express that - with clear details.
> 
> IF you feel that additional code-points should be allocated in a BAR IANA
> Registry or
> have thoughts on the appropriate policy, please say so with your
> explanation for what
> those should be.
> 
> Unless I see clear and strong consensus for something other than the
> Current Status,
> that will remain.
> 
> IF there is clear and strong consensus for Option B, C, or D, or adding an
> IANA registry with particular values, then it will be possible to have a
> change up through this Weds night - with a 1 week WGLC on that particular
> technical change.
> 
> My priority is to have the base BIER specifications published as Proposed
> Standards so that more BIER implementations and deployment can be done.  I
> would like the WG to wrap up the core work (as expressed in the proposed
> recharter) so that you all can look
> at how to use it.
> 
> Given this topic was raised last Weds and given that there are no technical
> objections raised to the documents as are, there isn't much time - so
> please just respond to this email ASAP.  My deadline for a decision is 6pm
> EST on Weds.
> 
> Regards,
> Alia

> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
tte@cs.fau.de