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> Wed, 21 February 2018 16:38 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 CBBD212D87C; Wed, 21 Feb 2018 08:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 o9MAeyWrs2iE; Wed, 21 Feb 2018 08:38:01 -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 0552F12D7F8; Wed, 21 Feb 2018 08:38:01 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1LF4LSQ004504; Wed, 21 Feb 2018 07:05:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=T0VfPQuDV4ShLOSnK/0wZjdTeGzRjbSHaMbBgANdwtY=; b=NBvaE7H2cMlwtVHr8Mg4JZyq6e2Sm4uG8XDVlepYAUwE0TKIcFrl+PYKN1/7uXmsPO02 Y+fGjw05yFfoHQ+v9xoks4IqufaQvMfTvSukzUaUO34bcKwUu7SCkyBDjKNo4MM+JoTW SSpDFWKH09mqrnGSvmzOi24uQWBCT65pQQVDoXCB0O1yEqO7owjCzFv1sfdEtHsN3v0y a8b9L/XfXY1MNbVNXuiQ5BlbdvDb0RLYwxPJ9ho0lq3iD35Lp+LBsCHku335L5WsfW5e KyFWw/RYdmBQvkr1OBZHdkyxqaqrPCe/lpXvZEoIdP9RJxiDKBmpX+JWuCn8IYG+TrOW iQ==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0080.outbound.protection.outlook.com [207.46.163.80]) by mx0a-00273201.pphosted.com with ESMTP id 2g9ahf82kf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Feb 2018 07:05:08 -0800
Received: from BN3PR0501MB1331.namprd05.prod.outlook.com (10.160.183.20) by BN3PR0501MB1268.namprd05.prod.outlook.com (10.160.183.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Wed, 21 Feb 2018 15:05:05 +0000
Received: from BN3PR0501MB1331.namprd05.prod.outlook.com ([fe80::7509:f083:9ff5:c01c]) by BN3PR0501MB1331.namprd05.prod.outlook.com ([fe80::7509:f083:9ff5:c01c%9]) with mapi id 15.20.0548.005; Wed, 21 Feb 2018 15:05:05 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Alia Atlas <akatlas@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "IJsbrand Wijnands (iwijnand)" <iwijnand@cisco.com>, "EXT-arkadiy.gulko@thomsonreuters.com" <arkadiy.gulko@thomsonreuters.com>, "bier@ietf.org" <bier@ietf.org>, IJsbrand Wijnands <ice@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, 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: AQHTqcvDpgRf7bSxH0OHscLI1QV+WqOsufoAgAAGCQCAAK3NAIAAF8uAgAAPAgCAAB3TgIAANeXwgAAXV4CAAAWbgIAA00UAgAAA2/CAAALEAIAAAxaAgAAHlWCAAAqLgIAAA6lg
Date: Wed, 21 Feb 2018 15:05:05 +0000
Message-ID: <BN3PR0501MB133182EC7AF3AFD189B007F3D4CE0@BN3PR0501MB1331.namprd05.prod.outlook.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> <CAG4d1rfKdKuifUewJZp3TBk3s0BAM9mcsn3AJV1rysmyGGAxEA@mail.gmail.com>
In-Reply-To: <CAG4d1rfKdKuifUewJZp3TBk3s0BAM9mcsn3AJV1rysmyGGAxEA@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; BN3PR0501MB1268; 7:HqsF8sMC8n3Sdx0YeKat85E976n6NBX8/sWJVp8rCE5p5BYucQSjG8QUVssoHd2H+8RX40gj12hcgA5sKkLXARRk39xXhzWbJ7AMHaq3G6gNW/XNlcFrlatRa9Dg8BLZ3C7TTc1saJTkDSLt7uOXbLDCrSvmse5k5Vob4AJSz4h4xCnpvJtchE4++ypg+pQq3+ZXKa6H1cXvclbNs4V65/Yto2opzeh/lJ4qeTSPjn2Zxob7gZgV/zm13NqqTPmB
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: cef11189-0ec6-4e3b-55ed-08d5793c7dda
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BN3PR0501MB1268;
x-ms-traffictypediagnostic: BN3PR0501MB1268:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <BN3PR0501MB1268C0F5856F3647BA3B16BAD4CE0@BN3PR0501MB1268.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(138986009662008)(85827821059158)(100405760836317)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001068)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231158)(944501161)(52105067)(10201501046)(6055026)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN3PR0501MB1268; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1268;
x-forefront-prvs: 0590BBCCBC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(376002)(39860400002)(39380400002)(37854004)(51444003)(199004)(189003)(53946003)(7736002)(107886003)(53936002)(790700001)(6116002)(3846002)(236005)(6306002)(316002)(16200700003)(54896002)(105586002)(110136005)(6346003)(68736007)(26005)(5250100002)(9686003)(2900100001)(74316002)(39060400002)(6436002)(186003)(4326008)(229853002)(2906002)(106356001)(25786009)(3660700001)(55016002)(54906003)(6246003)(2950100002)(606006)(86362001)(76176011)(3280700002)(33656002)(8936002)(8656006)(102836004)(8676002)(93886005)(478600001)(99286004)(7696005)(966005)(5660300001)(97736004)(9326002)(14454004)(53546011)(66066001)(81166006)(59450400001)(6506007)(81156014)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1268; H:BN3PR0501MB1331.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: fRW1WrpKfvPrztzcUoKQtoorf7s+Fxk5tCH5fON+x61SO4N1B6bovzoZI8p0g9aWcMbDg2yhyXmERNvWwXptwSMRqGgWJiKjwP3lRZCOBFKYkjGPye0qV0HxRLq3syXJFrXPgmSdjWa9Pvc8XBwsLSlVLzSu2D6WV0/goeVCAcM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB133182EC7AF3AFD189B007F3D4CE0BN3PR0501MB1331_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: cef11189-0ec6-4e3b-55ed-08d5793c7dda
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 15:05:05.8141 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1268
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-21_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802210183
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/RKYMuoYjb9ny3vbLKOFjoxcbNwY>
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 16:38:05 -0000

Hi Alia,

Thanks for articulating it very clearly, and bring out the issue of having a clear specification on the interaction.

I need one clarification from you though – is it possible that the you actually meant BART when you said BARM, and vice versa, in the following?

------------------
With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the constraints are empty.

For the BARM, all the necessary constraints can be applied first.

To define a code-point for BARM, the following information is necessary:
   i) Constraints
   ii) Can constraints be additive  (default yes unless specified otherwise)
   iii) What is the algorithm - or is it "empty"
-------------

I’ll try to work with Les on the text to specify the interaction.

Jeffrey

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

First, I greatly appreciate the rapid education I have gotten on why the different aspects of this are important.

Let us explore some details on the plan for an 8-bit BART and an 8-bit BARM that are independent.  Jeffrey,
I really appreciate your bringing this option to the list.  It simplifies the option B idea of subtypes away and there
seems to be a good amount of interest in it.

My concern is that we specify adequately how the codepoints in BART and BARM interact.

One of the challenges with doing so has been, IMHO, a bit of terminology where we are describing these as
algorithms but in fact these are tuples consisting of a set of constraints and a base algorithm.

BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us describe this as BART =  (BC, BA).

BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us describe this as BARM = (RC, RA).

Let me give some concrete examples.

Consider a case of BART=4 which is known to mean (prune non-BIER routers, use SPF).
BARM = 200, which is known to mean (prune links with BW <10G, use SPF)

It is desirable to have an outcome that is (prune non-BIER routers and links with BW < 10G, use SPF).

This can work algorithmically because the constraints are the types that we've seen before for RSVP-TE.

What I think we need to make the independent 8-bit BART plus 8-bit BARM work is a clear specification
of the interaction. I think that is:

Start with the topology Topology.
1) Apply the constraints represented by the BART  BC(Topology)
2) Apply the constraints represented by the BARM  RC(BC(Topology))
3) Select the algorithm A as follows:  use BA or if BA is "empty", use RA.
    Run A on RC(BC(Topology)) to get the next-hops and information for the BIFT.

Key points on the algorithm aspect are:
a) BIER is the higher layer, so it is assumed to know better which algorithm should be used.
b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so that the algorithm
    falls through to whatever is RA.

With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the constraints are empty.

For the BARM, all the necessary constraints can be applied first.

To define a code-point for BARM, the following information is necessary:
   i) Constraints
   ii) Can constraints be additive  (default yes unless specified otherwise)
   iii) What is the algorithm - or is it "empty"

I am bringing forth this description now because I am concerned that the interaction between
BARM and BART is not adequately defined to be published - but I see the strong interest in
this as the solution and, from my understanding of the problem, agree.

Please comment ASAP.

Jeffrey & Les, is this something that you can turn into clear text for the drafts?

Regards,
Alia




On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
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.

Jeffrey

From: BIER [mailto:bier-bounces@ietf.org<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.

_______________________________________________
BIER mailing list
BIER@ietf.org<mailto:BIER@ietf.org>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=-s4yYMmN1jlRwgyk02_2IFamu-k7K7di1WiwKt-AoeE&s=pJHykwbjl-mkz5oRRkXE6hjOs0tsiC1ucjQtr6-F-4k&e=>