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

Alia Atlas <akatlas@gmail.com> Tue, 20 February 2018 05:15 UTC

Return-Path: <akatlas@gmail.com>
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 14BA8124235; Mon, 19 Feb 2018 21:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dEJ2oaoFKLga; Mon, 19 Feb 2018 21:15:22 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 878C11200C1; Mon, 19 Feb 2018 21:15:22 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id 79so10405630oth.11; Mon, 19 Feb 2018 21:15:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lPX//bVQcMRNgPxUE6uyd3HgPgVRZTJRGU3lJFcTLQA=; b=gqFXSveRFMIECKW7pKG6l3JLPopylVeAtBiPkSCBkcrOTf5Cdiy8ov5eQ1kfdOhSZq XfGmcl9Iwy1EQrRYsUFSaO5C6A4bb4sJiaQYzp6Gn4N3etaSHun6RPXL+qejHnPOjyxv 3I4b5LQU6BCsRnKtZ6UUxewqDXXjA7smciOn6nm4LrndIf3B7D5Q9rBzpbcPmk3ivd65 ovh9LqnD0pSpcxnJvCp/WxPX9G05ov/anSWuwoNsakWYVtbylmLMDknFAohm8dJBvWdB ly4MdjuPmS9QZ4qYJP4wYymyOzH+uf1Ls94uXh6g7cXwuX3ZVs0CKR5mXMCLuycKoGDI DrkA==
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=lPX//bVQcMRNgPxUE6uyd3HgPgVRZTJRGU3lJFcTLQA=; b=MPxKZJobRzt2042srHbO/Xv4C97S8TkKuOa3qXNVtPcXwGNuP9DaE+O5irCXwk0Nyh aJjTL6sxj/U186SFd7m/7flnrcuWIWOJJv9/F6336pUsUot5EJEX/XzcE45SVBrTWK1C A7IAZiyztsBylThNcqhlWWA37G6wqprbqWgLZstLYkxPqmdEDn3RIHNJqvoKfvU3T3VC vkBbMU8eQPqJ9dFcpJImUbbOlA7/pRuriJO4P05y+y/JFyC30p5ktNXM9fcaKHqKbfpZ SdS32gj32HdGDAqmrfFYIE++4DUDSO4SkbdAhsjaPwlp/qawWQMCobac+5LIOxQKoQ8a RcPA==
X-Gm-Message-State: APf1xPCUJlv1k+9uY+aDEBVkJ5tVO9x2R9R69meQbBcq8UkQQmYVBH5P jGsYgUYoe2YeKL8dGjEnhBvbFn+m+Kbwp+Nl7xE=
X-Google-Smtp-Source: AH8x2269m3X1LLkUnrjVfOFgJYCB2jXNm35AKmyqRXSwZxn+U6U4xmpATJ9ZMJYMCqhW1crJM5Xi7wDhPeTvRyyEjcw=
X-Received: by 10.157.3.196 with SMTP id f62mr1906404otf.360.1519103721541; Mon, 19 Feb 2018 21:15:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.68.57 with HTTP; Mon, 19 Feb 2018 21:15:20 -0800 (PST)
Received: by 10.157.68.57 with HTTP; Mon, 19 Feb 2018 21:15:20 -0800 (PST)
In-Reply-To: <9778B23E32FB2745BEA3BE037F185DC4A5BA61A3@BLREML503-MBX.china.huawei.com>
References: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com> <9778B23E32FB2745BEA3BE037F185DC4A5BA61A3@BLREML503-MBX.china.huawei.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 20 Feb 2018 00:15:20 -0500
Message-ID: <CAG4d1rc8=2gnEj4vTjjAja5SPfezBT+hBKRg219uLgndvA78Kg@mail.gmail.com>
To: Senthil Dhanaraj <senthil.dhanaraj@huawei.com>
Cc: BIER WG <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c03c326b3165905659de503"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/lLRiNFgu1jzsJOlWF74ZDyeZ9fs>
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: Tue, 20 Feb 2018 05:15:25 -0000

I have one additional question for those with implementations or testing
them.

What is the impact of going with your preferred option in terms of
interoperability?  It may be early enough that changes can happen, but more
feedback is needed.

For those favoring Option B, could you send email to the list providing
exact text so we have the details?

For those favoring the current status without an IANA registry, are you
able to handle one being imposed during IESG Review?  It is an obvious
concern to raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka



On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <senthil.dhanaraj@huawei.com>;
wrote:

> +1 to Option-B
>
> Seems future proof to me.
>
>
>
> Thanks,
>
> Senthil
>
>
>
>
>
>
>
> *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Alia Atlas
> *Sent:* 20 February 2018 03:21
> *To:* BIER WG <bier@ietf.org>;; isis-wg@ietf.org list <isis-wg@ietf.org>;
> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions and
> draft-ietf-bier-ospf-extensions
>
>
>
> 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
>
>
>