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

"IJsbrand Wijnands (iwijnand)" <iwijnand@cisco.com> Wed, 21 February 2018 14:32 UTC

Return-Path: <iwijnand@cisco.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 290FD12D7F2; Wed, 21 Feb 2018 06:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 rAtdYCDy0hJq; Wed, 21 Feb 2018 06:32:48 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C3112E03E; Wed, 21 Feb 2018 06:32:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77311; q=dns/txt; s=iport; t=1519223562; x=1520433162; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nkpCAHehB/GmHmZQtQF99F2TbnhsgtJ7tKyqZ8pg1H4=; b=FuuC4aecKDCgig8RWmw6sB60Sh420N9p+j2+3Rq+0IJgZ9j7tPyxaqEM BSuyRFx2Z0UreAjg8OwK4GCeQ8jigrx1PANTz90jTUHB7vCQKlwPA8V/3 suEpxoH6ffchC6vcck7qQ2kpyfDjcdyGtUhcDpe+j6FB3v+Kqh7mNTA5e Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DEAwB3go1a/4oNJK1UCRkBAQEBAQEBAQEBAQEHAQEBAQGCWkQxZnAog2iYHIFbJ4EXlkqCFgqFNAIaglxVFwECAQEBAQEBAmsohSMBAQEEIwpMEAIBCBEBAwEBIQEGAwICAiQMFAMGCAIEDgQBG4kkZKoggieIeYITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYUOgieBV4FnKQyCeYR5OCiCYTGCNAWLe4Zbh1mKDAkCjC2JXg6UN5d5AhEZAYE7ASABN4FRcBU6KgGCGAmDAIFteI0IAQEB
X-IronPort-AV: E=Sophos; i="5.46,543,1511827200"; d="scan'208,217"; a="73318556"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 14:32:41 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1LEWfml025947 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2018 14:32:41 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Feb 2018 08:32:41 -0600
Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1320.000; Wed, 21 Feb 2018 08:32:41 -0600
From: "IJsbrand Wijnands (iwijnand)" <iwijnand@cisco.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
CC: "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, IJsbrand Wijnands <ice@cisco.com>, "EXT-arkadiy.gulko@thomsonreuters.com" <arkadiy.gulko@thomsonreuters.com>, Eric Rosen <erosen@juniper.net>
Thread-Topic: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
Thread-Index: AQHTqcvCbrFVxgn6skOKRTRs+8ZF+KOtHo8AgAAGCQCAAK3OAIAAF8qAgAAPAgCAAB3TgIAAOHGAgAAlj4D///TYgIAAbrDqgABl5gD//525RoAAAxbCgABvOoD//5+UQw==
Date: Wed, 21 Feb 2018 14:32:40 +0000
Message-ID: <E39CE548-8FA4-4134-B56B-60811E5A3101@cisco.com>
References: <CAG4d1remdUKutEdc2DU6Gaan3z63CAZVo1D-L0GXg_=eHJxffw@mail.gmail.com> <9778B23E32FB2745BEA3BE037F185DC4A5BA61A3@BLREML503-MBX.china.huawei.com> <CAG4d1rc8=2gnEj4vTjjAja5SPfezBT+hBKRg219uLgndvA78Kg@mail.gmail.com> <CA+wi2hPoTA0u2rx0f5eoBsoOAH+m1uN0ggr=P7sSYFcX=1qQxw@mail.gmail.com> <CAG4d1rf_mphexVqMv20HQbd=px5koH5c_+VW_5TTfgjWq4EtSA@mail.gmail.com> <B94D11DC-F46A-4F8C-873F-6F4A21BC4071@thomsonreuters.com> <14dca8e9-9afd-b5ff-c753-3554b911d753@juniper.net> <CY1PR0501MB1340543164C052E207A44D9DD4CF0@CY1PR0501MB1340.namprd05.prod.outlook.com> <DD0F774D-E132-488E-B75A-A8FFA3B771F6@cisco.com>, <CA+wi2hPgGGAmon=4HYofOGA899eb-eZyQ5F1hV1Rf-S6q5rdhQ@mail.gmail.com> <3D8AD227-D32A-4534-83B8-73D1C06FD635@cisco.com>, <BN3PR0501MB13319C71FEDC239B98A7AF5BD4CE0@BN3PR0501MB1331.namprd05.prod.outlook.com>, <68283F1C-3D3D-4467-9570-331BFF94A6DA@cisco.com> <DC905E5C-2C34-4E7E-A1B3-7991CE582F93@cisco.com>, <BN3PR0501MB13310564C6CC0A939F4EE0C6D4CE0@BN3PR0501MB1331.namprd05.prod.outlook.com>
In-Reply-To: <BN3PR0501MB13310564C6CC0A939F4EE0C6D4CE0@BN3PR0501MB1331.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_E39CE5488FA44134B56B60811E5A3101ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/fLtnf3wbTM-mPq1SoK6VdsLZbQA>
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: Wed, 21 Feb 2018 14:32:50 -0000

Jeffrey,

To make it absolutely clear using an example: even with <BART 1, BARM 200> it is still that the two fields are independent of each other.
This particular combination means “apply BART 1” to “Flexible-Algo 200”, where “Flexible-Algo 200” could be “exclude red links”, while “BART 1” could be “skip BIER incapable routers”.

This is a very practical and concrete example showing the advantage of having two separate fields. Other ways could be used to achieve the same result, but they’re more cumbersome.

I agree.

But, which combinations are supported must be documented in an IETF draft. We don't assume any combinations to just work without being specified.

Thx,

Ice.


Jeffrey

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Wednesday, February 21, 2018 8:40 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: bier@ietf.org<mailto:bier@ietf.org>; isis-wg@ietf.org<mailto:isis-wg@ietf.org>; IJsbrand Wijnands <ice@cisco.com<mailto:ice@cisco.com>>; EXT-arkadiy.gulko@thomsonreuters.com<mailto:EXT-arkadiy.gulko@thomsonreuters.com> <arkadiy.gulko@thomsonreuters.com<mailto:arkadiy.gulko@thomsonreuters.com>>; Eric Rosen <erosen@juniper.net<mailto:erosen@juniper.net>>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions



Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.

Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.

Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and v.s., if BART is used, BARM will just be 0.

Thx,

Ice.



THx,

Ice.



Jeffrey


Registry Algorithm a.k.a as BARM then ... Without this section we would be mandating that BARM is always an IGP algorithm or FA so basically it would mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on the list who are of the opinion that aligning with IGP is important.


Algorithm registry as the only option to perform a calculation making BART possibly pretty much useless ... Having a registry being mapped 1:1 into  another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all yours. Its unfortunate that a large part of the discussion is dominated by perceived functionality in the form of BIER Algorithm, while there is no architecture draft that describes how it should work and no discussion has happen in any IETF meeting, which leaves us all guessing. I think Alia asked a very good question on the list regarding "constraints". It is not at all clear if BART is a Algorithm or a Constraint. I think from your response you're saying its both, which seems wrong IMO.. To me Alia's question is still open, but that that may be because I could not decipher the rest of your response.


as identity makes them both them the same thing by another name.
So, to get anywhere close to consensus let's get bit less creative maybe and stick to the four letters of the alphabet that the AD extended as a wide playing field and the WG seems to converge around ... Or otherwise stick to option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what we are doing, and that is how you can converge on a solution and reach consensus. That is better compared to a vote on an option and everybody walks away with a different interpretation of it.

Thx,

Ice.