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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Tue, 20 February 2018 02:37 UTC

Return-Path: <zzhang@juniper.net>
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 00F23126D73; Mon, 19 Feb 2018 18:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
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 QjM9zHA2Md0a; Mon, 19 Feb 2018 18:37:15 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1AC124234; Mon, 19 Feb 2018 18:37:15 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1K2aZ7R018377; Mon, 19 Feb 2018 18:37:13 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=gsUtPnImHMIONFXwwGeLxga1Lhe+Zb6sAHPe74AmzSY=; b=CXtXr/QRwBwonQ2ELw8GbJdKYrolBc/K7GqZpihEVCfBIl0Xe2QaFJYaXPNWjgGtFKhe 5FqL9NIOksfkpoyIvCsv0t1ZjXpd7qSFFbA6DtYRHmhRB3Nko4mjPure/P+QDEGE3uKi A8qxG3a2K0BsKUrQu5oCI5TpkwZj3YlZ5ZfPNAX9e9u3apPB034NB5LR0BzQJz+so0TN sj7S0C6+ZQukaXEcV+nbtdzsGQPgmzGIpLsa+Svv7FmIayMXT/UAyM68Wynv3lWyoWyD s19EZn0XZhfYSxTeEDWWd4l2YC6FSePj3Jt4CcmteHEh+1i739R23IZZ5NmL26pBh4lm kA==
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0118.outbound.protection.outlook.com [207.46.163.118]) by mx0a-00273201.pphosted.com with ESMTP id 2g8b1q800u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 18:37:12 -0800
Received: from CY1PR0501MB1340.namprd05.prod.outlook.com (10.160.226.145) by CY1PR0501MB1705.namprd05.prod.outlook.com (10.163.140.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Tue, 20 Feb 2018 02:37:08 +0000
Received: from CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) by CY1PR0501MB1340.namprd05.prod.outlook.com ([10.160.226.145]) with mapi id 15.20.0527.012; Tue, 20 Feb 2018 02:37:08 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Alia Atlas <akatlas@gmail.com>, BIER WG <bier@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Thread-Index: AQHTqcvDpgRf7bSxH0OHscLI1QV+WqOskPRA
Date: Tue, 20 Feb 2018 02:37:08 +0000
Message-ID: <CY1PR0501MB1340EEBA74D7421A0227B3A3D4CF0@CY1PR0501MB1340.namprd05.prod.outlook.com>
References: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com>
In-Reply-To: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1705; 7:VvQGZ0m+ZQBWXmGHuBuyxJL9blqFFQqdua2F5nxABXzlTZurV/xT0S5aHof2xEpaHKdBwLLFRarJ253CmEa16ysIEFf4vEyg4431pfhKNNZJHAJa1in29h03IAoV2wvZMmTuMijqITLAUcZFkn4/mVxoYwif6gRSX+/dO2YIpmW7oDYzqR5+b6nZBMykj/LVU2NbcKe4QIi+Fr0wyHSu+r0imC5AK+tV49B7bXn/RtccqI/kOvnAWjRPx6n4u1fE
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cb89e2d6-81b1-43d2-a1ea-08d5780ad684
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY1PR0501MB1705;
x-ms-traffictypediagnostic: CY1PR0501MB1705:
x-microsoft-antispam-prvs: <CY1PR0501MB170595070EB088C16C618804D4CF0@CY1PR0501MB1705.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY1PR0501MB1705; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1705;
x-forefront-prvs: 05891FB07F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(376002)(39380400002)(39860400002)(189003)(199004)(45074003)(2906002)(3280700002)(478600001)(66066001)(229853002)(110136005)(59450400001)(39060400002)(316002)(53936002)(2950100002)(97736004)(33656002)(2900100001)(53946003)(68736007)(5660300001)(6246003)(53546011)(6506007)(8936002)(26005)(102836004)(86362001)(77096007)(3660700001)(74316002)(81156014)(81166006)(105586002)(186003)(106356001)(8676002)(99286004)(14454004)(76176011)(7696005)(3846002)(6116002)(790700001)(54896002)(6436002)(7736002)(6306002)(9686003)(55016002)(25786009)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1705; H:CY1PR0501MB1340.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: y2JIgtruNSveA/o+IrmDy0Ccsepf0lbbZJTHBXE4Cr82RcTqf8RJurXcN8RBDYOg68oq8++mASq7IgvrKdZB7zzzcxOi9K/ZrRIVuqvtgXlOHLUDXcOOfN/7zITlWhh5YQEulLbO/oFfI+qluZcLbh6OXTMVbojN0Flkg8MQDM8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1340EEBA74D7421A0227B3A3D4CF0CY1PR0501MB1340_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: cb89e2d6-81b1-43d2-a1ea-08d5780ad684
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 02:37:08.6346 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1705
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-20_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802200031
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/cepTi49NXB3FB1i_KiwMtkaN7Ww>
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 02:37:18 -0000

I would go with Option B:

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.

This gives best architecture cleanness/flexibility:


-          BIER-specific algorithms that are not tied to anything else, via the BAR value.

-          Anything that is not tied to BIER, via the sub-type. For example, if Flexible Algorithm is needed, the FA number could be specified in the sub-type.

I can provide the text for this option if we end up with going with this option.

Jeffrey

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Monday, February 19, 2018 4:51 PM
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