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 17:36 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 507FF120454; Tue, 20 Feb 2018 09:36:00 -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 woI3LPqoDCPI; Tue, 20 Feb 2018 09:35:58 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 DD6131201F8; Tue, 20 Feb 2018 09:35:57 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id b15so6177284otf.3; Tue, 20 Feb 2018 09:35:57 -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=AybZaCnsnTqnooOhxusMG+ShunAznUg267k0RqZxkp0=; b=OsNVoQBcQ1paC89lWsuaAo4yQvYi8NE42pbbFIfbrjHht6eTXvRJf4/x499TjCGIVx s8t8J510JB9dDchnFEzpsWCuBuKJZILOh4kUxJPpr8VZvU7hkwta+bbb87cLNHI4EMnL 8Sgan/fO6swxNqIt/va/yee6BAI488s0z0JQXEJL43OaVfxfLlRZHyrJLEzHeUQ4iN5x RfY7mlOcJhiOOrRLisLaw6xA2eGUUPrhE41w98P5X2D1w5pTjEo8Hb+ALgUTJ5p54QvF NLGXYy6tU6SVb6Vo5dBdoSRoJ5MfAcD9qM+ChAkygcrFLMsItKpx7gN5ixTQKCbvgb9D LVpQ==
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=AybZaCnsnTqnooOhxusMG+ShunAznUg267k0RqZxkp0=; b=kmdfV7FsZbw2iRonRpcxjoyQori6vtxb5oUGZYNHXkQoKyY2P1UAj5Sr9XgzBnxynG 0yUy2OqdP+NOiVnSqPQBMFc3zT9b+0+w77lA+oPwg6YHm9X+8LTy42nKw2GUuAIIOQSZ n/C9R3B9gt6y4lZA6UzuG6OJu47e1FT5Qut8YMIRhxkL3U8cwCtV5hvYB+HovSfrVg6z F5sNso41TQxxhzL8dpuLDA6gLLnQ4eQ1izZMfQVpTqcadomhqo6GD6fUDSMqgColg78q 1ESl74ohymJreDhJ5xf+NK7pFeZki+MuZshO4zNrm2N7HBOFQFNrGX5VAoyf3kmX/8ES yzkQ==
X-Gm-Message-State: APf1xPAzfW4bNOuwqEnRkNJTZZ7GJRXDZQ1IuNYawA3HnsrqPXB2D3Eo HJM4FcArp+g6SETOQyozxF1vjrb28qBulnGywGQ=
X-Google-Smtp-Source: AG47ELvC9WzCQ5pztzidvy/aZ2gdLsMvy+m2CjFOPQktweWRqh0kFBZ8IzuA1KAPYvWNkD0E3Y0RRYf8fZ60qjUPSvI=
X-Received: by 10.157.13.75 with SMTP id 69mr321773oti.258.1519148156827; Tue, 20 Feb 2018 09:35:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.68.57 with HTTP; Tue, 20 Feb 2018 09:35:56 -0800 (PST)
In-Reply-To: <5A8C5A99.8090201@cisco.com>
References: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com> <5A8C5A99.8090201@cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 20 Feb 2018 12:35:56 -0500
Message-ID: <CAG4d1rcVnmjisMxX0tJRrhQnWc_ZsGn0c4mXPFygo7RSRqtM2g@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: BIER WG <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e37c43fbfd80565a83e7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/PK-dH9BVt0dczXfGANKq623grUk>
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 17:36:00 -0000

Hi Peter,

Thanks very much for the feedback.

On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <ppsenak@cisco.com>; wrote:

> Hi Alia,
>
> 1. I see a benefit in having the BIER a way to map to any of the IGP
> algorithms. Simply because IGPs already provide paths to all nodes in the
> domain and BIER can simply use these paths instead of computing its own.
>

Makes sense.


> 2. Not sure if people plan to deploy the BIER in a model where it does its
> own topology related computations, independent of IGPs. If they do, I'm not
> objecting that.
>

That is what I'm hearing as a requirement.

The encoding of the BAR though must be done in a way that it easily
> supports both (1) and (2).
>

There's the rub :-)  The challenge seems to be when there are BIER-specific
constraints and also other more generic constraints.

Regards,
Alia

my 2c,
> Peter
>
>
>
>
> On 19/02/18 22:51 , 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
>>
>>
>