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

Alia Atlas <akatlas@gmail.com> Wed, 21 February 2018 15:09 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 A6924127010; Wed, 21 Feb 2018 07:09:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 u_vLkDvuXuG2; Wed, 21 Feb 2018 07:09:08 -0800 (PST)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 F1AB1126DFB; Wed, 21 Feb 2018 07:09:07 -0800 (PST)
Received: by mail-ot0-x231.google.com with SMTP id 79so1661955oth.11; Wed, 21 Feb 2018 07:09:07 -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=AxtAj+AgYHG47A/d6scEmS2wrRtqKqZisReBExX9nMg=; b=Af5+jCx+c61MBkVTPtB2FHwZVueiSkJjWKf5GXz9+HzEdOYe5C3ZavGYWd1Y6fyO31 nyhNrNc9rvB8vDAdLjr8xA4JIw2ZIGMDZoLNjV1+xP19t7iM4OAWEp7M7OKOfp9oVgcZ x6uOvpA/KISbWkt3tP+FU7N3dWoFG87L559EVJAkfKidgpbfEOAbulmcTkyVrxC0stcL k4cLeqpy096WtpEjuxBvT96UxwqoMJxQ7wZicQJmqGP3joOVAA06Q7EC+xqsS5gm4NYp IJSaIigphmcoIojp+NSOf+dKWV2AuzMC0XGnfCsYtyeIRJBLhaTKe+bisy+sXb7Kxqzm 4wEA==
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=AxtAj+AgYHG47A/d6scEmS2wrRtqKqZisReBExX9nMg=; b=OGVMCLLZ8+CVuQKIBKN08sb5YtrH1QTJrs4JtBJj2fm3vbFgqV9E+XGIGaJmg3WAZQ a8LYkYu0WkcP2HAiT6cVHqlZpNwA6iMZwgn2jorv9i7b16JGmwNJqEiOVxNO4MUngtFz 99M8SdfC6/tclvQfIa9F+NqAngvvLGGyEgoXbBfUsB0iE+kJqzHCzGqjjAR2gj61eoZt XvqVb9PtQS3ZprIgUa6iSHZBbA5/oNwjCwcw3RCR2Tjpgzlb45bCWzTtdG0WA4IdscL9 bm4h3zIq6BPYc0IBf2bubz0PWI/PVxC/FOI0X7NtEBuvA5nDkmYEcARD6TDRz21Vmmdr Hqqw==
X-Gm-Message-State: APf1xPAfkwG9nADpmIDk77eWYPpok5t1u/ikubSc0gWdtQqzOzEZ1R77 vVQ1g6hHdzqMqHQOkKaO9oydiilyP13MFDDIBtE=
X-Google-Smtp-Source: AG47ELsli+9AsNGKDhbn8v+zpZetIdtcAcAcKfXLLiC0u68jAX7avqWwjGywYN3reM7veh05ToKHDM6v7kUmHmGYAsQ=
X-Received: by 10.157.41.2 with SMTP id d2mr2539158otb.219.1519225746885; Wed, 21 Feb 2018 07:09:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.68.57 with HTTP; Wed, 21 Feb 2018 07:09:05 -0800 (PST)
Received: by 10.157.68.57 with HTTP; Wed, 21 Feb 2018 07:09:05 -0800 (PST)
In-Reply-To: <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> <BN3PR0501MB133182EC7AF3AFD189B007F3D4CE0@BN3PR0501MB1331.namprd05.prod.outlook.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 21 Feb 2018 10:09:05 -0500
Message-ID: <CAG4d1rfNRgpFhqj=qwA6r6-JRdEvEVL1w83q9SGNckjP4Xms7w@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "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>
Content-Type: multipart/alternative; boundary="94eb2c04f602fa32f70565ba4ef4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/MxL1j42sgM063aLqp-jigRAJrlU>
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 15:09:11 -0000

Hi Jeffrey,

Yes, I was rushing & may have mangled the terminology in the final bit.

The routing layer 8-bit field can be from the IGP Algorithm registry.

Thanks for catching it & for your willingness to write this up more clearly!

Regards,
Aka

On Feb 21, 2018 10:05 AM, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>;
wrote:

> 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>; 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] *On Behalf Of *IJsbrand
> Wijnands (iwijnand)
> *Sent:* Wednesday, February 21, 2018 8:40 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>;
> *Cc:* bier@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>;
> *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
> 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=>
>
>
>