Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Tony Przygienda <tonysietf@gmail.com> Sat, 17 February 2018 02:30 UTC

Return-Path: <tonysietf@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 251F5129516; Fri, 16 Feb 2018 18:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level:
X-Spam-Status: No, score=-0.699 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_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 a-4bvGWuV_C6; Fri, 16 Feb 2018 18:30:14 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 BFE70126CD8; Fri, 16 Feb 2018 18:30:13 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id f3so6119647wmc.1; Fri, 16 Feb 2018 18:30:13 -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=4FcxKdU1dPoMPvX15g/zQ1nVH1R6pFr5UAdI5FC8KUg=; b=CWZMsqCqa24odpJPxWbMX8NhVWhOdwnkt22UsFxuovQkrbwtjJl2kyUI+9vG+k2RJg 0Tj04RbB+Luajwv1MlE2kXZwYRbHNWCriWJadHz5W2vMpt4bPcyFKmsYZ9YXyYf50TYJ ogHkV+LD4yVRBKr1WbXYO9z+agZmzwaZhmkCcq+zqptInlS5yXxWElOqOFWU+jpZeyKt 1fSeZk2EgAoU5Ao+RBkJ+GeJPYpC9HUVt6kpTt5aAbvWFlAagzIetL9riY290ZHt5ZN2 ifhNDFbGZOhydpE+G5uhbiHHys9I6euX3IEqRFZupQNxe03vZbvrGOw7BOVvT3qxps24 jNNw==
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=4FcxKdU1dPoMPvX15g/zQ1nVH1R6pFr5UAdI5FC8KUg=; b=drnQaCzpFfV+teestlPwpydrbEtthmVetVzPNpzPsA4nHeBnxpBngf88cgYuVioPM1 O1EE12EAFa2USrOKQ3CdkzUs0YL7W1AkTiVLL/vefjTth7quGJdId7uiX8066qGiFT8B vbIFQPxXej5ab9hY6JCtwkyAZ9eOkWTr2HWJdlSzTS/4LXrlFcPloBec3oto/u6+aNKy x0xgSvqQM8hwWSjd6pzgM9ylzIGJK0Jf9AAVnIwK+9Y9b4hRta6slXuj/ym7SN8df12g I5ukq0NzRXvMNyepkTSmoiM83DRe7f3hllnHBl4yZqJN8QtqYrGgqE3Ckt29MCGzfoa3 gOLg==
X-Gm-Message-State: APf1xPAyatJvoXej7eqSmm6cB9pOAwA2uA0SU5r51C6CDrfgrsdsECyY V9KwjmZ3Ph0P7j4x3ILXEhifSbAXUNrYKEHFupE=
X-Google-Smtp-Source: AH8x2245N7l95FAoqhbfQ5I9uPZHv+eZX3AuT9JIovD3Nkftqz+HCSMEKk+wNeEkOpFu46dJed9ZEh9b11DWrUN5OE4=
X-Received: by 10.80.180.173 with SMTP id w42mr10432534edd.41.1518834612276; Fri, 16 Feb 2018 18:30:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.231.7 with HTTP; Fri, 16 Feb 2018 18:29:31 -0800 (PST)
In-Reply-To: <CD571E7C-3832-4EA6-A8AA-151B44DE6762@nokia.com>
References: <4A496052E7B7E84A9324854763C616FA377499CF@C111NTDEMBX52.ERF.thomson.com> <16253F7987E4F346823E305D08F9115A99A17846@nkgeml514-mbx.china.huawei.com> <D5A8BFBD-BDFA-40BA-9EB9-F4BF98AF12CA@nokia.com> <70842FFE-F12E-485D-A069-42977A8C0F7D@cisco.com> <F1CE0B21-32B5-43A2-81E6-258D9D9E1105@gmail.com> <63676097-F901-4B5F-9ED2-AB65ACE825A3@cisco.com> <3e06417f-f5af-6e95-2424-7e79b98153a8@juniper.net> <CA+wi2hN8KNSyCcspk6h5frSu8jrvqMPM8W3GOO1+HDfP4yM87g@mail.gmail.com> <CABFReBop9CtLexmzjNByad4PBj2r6XhiuUw+Nvto9xg8575xaA@mail.gmail.com> <CA+wi2hOw5oO8hgAUa=xu5m707i9=GHgNQ5hTF70iH=2OPdQg3w@mail.gmail.com> <CABFReBot3=NBuf=cfa3VhUd0X0VtEX-O5VbQgadNuvzXMkPCPg@mail.gmail.com> <CA+wi2hO2fzTRt7k9xDFiBhpw5wUo2N5WOUUGS0HeECf9Gh96pQ@mail.gmail.com> <F3CCFA49-DD0F-45D6-9BA0-FFC7751425B2@cisco.com> <3E720AD3-00FF-4E7F-83F9-6151F8480DA9@nokia.com> <d354d279d31749beab5ad736e81bb444@XCH-ALN-001.cisco.com> <dd6bd5e4-1b62-8134-56ca-497cbbc059b5@juniper.net> <8d2293ed9c88471fba61eee1856e2d90@XCH-ALN-001.cisco.com> <CD571E7C-3832-4EA6-A8AA-151B44DE6762@nokia.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Fri, 16 Feb 2018 18:29:31 -0800
Message-ID: <CA+wi2hPeRgqS2C+y_wy3=7po5M9rocr3E+sjOPMqiaAraBTWZw@mail.gmail.com>
To: "Dolganow, Andrew (Nokia - SG/Singapore)" <andrew.dolganow@nokia.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Eric C Rosen <erosen@juniper.net>, IJsbrand Wijnands <ice@cisco.com>, Greg Shepherd <gjshep@gmail.com>, Xiejingrong <xiejingrong@huawei.com>, "arkadiy.gulko@thomsonreuters.com" <arkadiy.gulko@thomsonreuters.com>, "bier@ietf.org" <bier@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0a54ce8994e405655f3d0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/ksjdOtK5WC9U5yHoic-HtdEt4wk>
Subject: Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
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: Sat, 17 Feb 2018 02:30:18 -0000

I'm working on a strawman of what I understood we seem to agree on for
further comments in detail, ETA tommorow ...

On Fri, Feb 16, 2018 at 6:18 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
andrew.dolganow@nokia.com> wrote:

> Agree, what Eric has is starting to look like a compromise. Let’s get the
> final text (wip) on the list asap.
>
>
>
> Andrew
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
> *Date: *Friday, February 16, 2018 at 11:08 PM
> *To: *Eric Rosen <erosen@juniper.net>et>, Andrew Dolganow <
> andrew.dolganow@nokia.com>gt;, "(Ice) IJsbrand Wijnands" <ice@cisco.com>
> *Cc: *Greg Shepherd <gjshep@gmail.com>om>, "bier@ietf.org" <bier@ietf.org>rg>, "
> isis-wg@ietf.org" <isis-wg@ietf.org>rg>, Xiejingrong <xiejingrong@huawei.com>om>,
> Arkadiy Gulko <arkadiy.gulko@thomsonreuters.com>
> *Subject: *RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Eric -
>
>
>
> *From:* Eric C Rosen [mailto:erosen@juniper.net]
> *Sent:* Friday, February 16, 2018 6:45 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; Dolganow, Andrew
> (Nokia - SG/Singapore) <andrew.dolganow@nokia.com>om>; IJsbrand Wijnands <
> ice@cisco.com>
> *Cc:* Greg Shepherd <gjshep@gmail.com>om>; bier@ietf.org; isis-wg@ietf.org;
> Xiejingrong <xiejingrong@huawei.com>om>; arkadiy.gulko@thomsonreuters.com
> *Subject:* Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Perhaps the following would be a good compromise (or perhaps not).
>
> Have an eight-bit field whose values are taken from the "IGP Algorithms"
> Registry.
>
> Have another eight-bit field whose values are taken from a new
> BIER-specific registry.  I don't know, maybe call it the "BIER Underlay
> Algorithm Modifier" registry.  The way the underlay paths are computed for
> a given BIER sub-domain is determined by the pair of codepoints: <IGP
> Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.
>
>
> *[Les:] Makes sense – except I would think only when the BUAM == 0 do the
> values come from IGP registry. Other values for BUAM would require a
> different set of definitions for the algorithm value.*
>
> *   Les*
>
>
> The default value for the "BIER Underlay Algorithm Modifier" field would
> be zero.   The value zero in this field would mean "just use the IGP
> Algorithms field to figure out how the underlay paths are computed."
> Non-zero values could be used to add additional nuance.  Existing drafts
> can say "the use of non-zero values in this field is outside the scope of
> this document".
>
> The registration policy for the new registry could save about  half the
> values for "standards action", and about half for FCFS.  And a few for
> Experimental.  (This would be a good policy for the IGP Algorithms registry
> as well, imho.)
>
> This seems to have minimal impact on existing implementations, and leaves
> room for further development of BIER while avoiding entanglements (or
> peceived entanglements) with other technologies that might be considered
> controversial.
>
> Now perhaps the WG can proceed to the really important issues, such as how
> to best design the T-shirts.  (Though frankly I'd rather get a few more
> home-brewed beers than a T-shirt.)
>
>
>
> On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) wrote:
>
> Andrew –
>
>
>
> There is no change being considered to the size of the algorithm field for
> Segment Routing.  That is 8 bits – there are mature SR documents and
> multiple implementations that use that encoding. There is also the IGP
> registry defined in an SR document (though not necessarily exclusively for
> SR use) which defines 8 bit values.
>
>
>
> The only thing which is being discussed here is whether BIER should use an
> 8 bit or 16 bit algorithm field. Also, even if it is decided BIER should
> use a 16 bit algorithm, it is conceivable that the values defined in the
> IGP algorithm registry may still be of use to BIER.
>
>
>
>    Les
>
>
>
> *From:* BIER [mailto:bier-bounces@ietf.org <bier-bounces@ietf.org>] *On
> Behalf Of *Dolganow, Andrew (Nokia - SG/Singapore)
> *Sent:* Thursday, February 15, 2018 7:39 PM
> *To:* IJsbrand Wijnands <ice@cisco.com> <ice@cisco.com>
> *Cc:* Greg Shepherd <gjshep@gmail.com> <gjshep@gmail.com>om>; bier@ietf.org;
> isis-wg@ietf.org; Xiejingrong <xiejingrong@huawei.com>
> <xiejingrong@huawei.com>om>; arkadiy.gulko@thomsonreuters.com; Eric C Rosen
> <erosen@juniper.net> <erosen@juniper.net>
> *Subject:* Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Well,
>
>
>
> Now, there are multiple treads being discussed here under one topic:
>
>
>
> - how big should the the field be?
>
> - should there be common registry for all technologies?
>
> - where should it be defined and which WG should standardize it?
>
>
>
> To me the first question is totally dependent on the answer to the last
> two, since the use case pointed out suggests a common registry.
>
>
>
> Now there may be different opinions (I believe there are from this
> exchange) whether we should or should not have a common registry, how
> complicated would it be and whether it would tax all groups trying to use
> that. But even before we go there, the basic question has to be answered:
>
> - which WG would own that registry. It is not in a charter of BIER to own
> it nor it is in a charter of SR nor it is in a charter of ISIS. Do none of
> them should own and mandate use. We are chartering LSR now - should we add
> registry for all IGP algorithms, we have routing WG, others?  Would like to
> hear AD’s opinion. Note that although LSR appears obvious, the algorithms
> to compute BIER may be controller-based that do bot require LSR (same
> applies to SR).
>
>
>
> - if we do agree to have a common registry, I would assume we all then tax
> everyone to signal that the same way. That would mean changes to SR and
> changes to BIER.
>
>
>
> This seems a lot. We have implementations of both technologies, so are
> changes to those warranted or is it too late and we should pursue
> independent  alg definition and registry as it has been set-up in the
> existing drafts. And we are talking only of those two but more WG will come
> and want to define things for them as well.
>
>
>
> Andrew
>
>
>
> Sent from my iPhone
>
>
> On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <ice@cisco.com> wrote:
>
> I think its clear from the discussion there are different opinions on the
> matter on how to make BIER use the BAR field. The reason for me to support
> 16 bits is that everybody seemed ok go move forward with an 8bits BAR
> without a registry, a 16bits BAR does not change anything, its just a
> bigger field. But at least with 16bits, we can split in Type, Value, and
> support different use-cases. IMO, pointing to whatever the Unicast underlay
> is providing is the main use-case, but it allows other ways to do things.
>
>
>
> One thing is clear, with just 8bits, it will be very hard to reach an
> agreement what the registry would look like. If we make it 16bits, we know
> we can solve multiple use-cases. The main question (I think) is whether we
> document how a 16bit BAR is carved up now, or we defer that to later. And
> as I said, since everybody seemed ok with 8bit BAR without a registry, I
> don’t see why its now different for 16bits. It gives us time to workout
> exactly how to use it and get input from the WGs.
>
>
>
> And, of course, the goal is to create a registry for the 16 bits through a
> new draft!
>
>
>
> Thx,
>
>
>
> Ice.
>
>
>
>
>
>
>
> On 15 Feb 2018, at 18:28, Tony Przygienda <tonysietf@gmail.com> wrote:
>
>
>
> On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <gjshep@gmail.com> wrote:
> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <tonysietf@gmail.com
> > wrote:
>
>
> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <gjshep@gmail.com> wrote:
> For the record, there is no SR Registry. There is only an IGP Algo Type
> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
> section 8.5
>
> So is that a good idea, having multiple drafts in flight with fields
> expecting to have magic couplings to each other while leaving e'thing
> "unspecified" to "publish RFCs" while we "decide things later"?
>
> That was a pivot, but still; there is no reference, there is no coupling.
>
> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around
> for a while, and the IGP Algo registry will be tied to this draft and it's
> fate. If anyone is expecting to use this registry outside of the scope of
> this draft, it would be in their best interest to pull the registry
> description out into a separate draft.
>
>
> OK, and I agree that if such a registry is pulled and under a clear
> charter of mandating multiple technologies within an independent body then
> a discussion starts to make sense and what the size of that should be given
> that mandates algorithms over multiple technologies (SR, unicast, mcast,
> whatever) and implies a "God's eye view" of all the elements of all
> the technologies (and if a computation touches elements from two
> technologies they become [optionally] coupled).  We are not talking IGP
> registry or multicast computation registry or SR registry then but a "wider
> scope registry". Yes, that is an intriguing thought with its own validity
> but outside the scope of charter we're under as BIER.  Personally, I
> consider multiple, if needed loosely coupled registries for each technology
> a less centralized and hence "more Internet like" solution but I see how
> opinions on such a thing can diverge ...
>
> thanks
>
> --- tony
>
>
>
> _______________________________________________
> 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=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=vxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=>
>
>
>
> <PastedGraphic-6.png>
>
>
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_isis-2Dwg&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=gRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=>
>
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>