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

Greg Shepherd <gjshep@gmail.com> Thu, 15 February 2018 16:38 UTC

Return-Path: <gjshep@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 53C6A12D949; Thu, 15 Feb 2018 08:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 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, HTML_OBFUSCATE_05_10=0.26, 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=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 Q483wZHbg5tt; Thu, 15 Feb 2018 08:38:54 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 15ABB12DB6D; Thu, 15 Feb 2018 08:38:54 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id 140so1286905iti.0; Thu, 15 Feb 2018 08:38:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7YubnWwbbYBcq7+WanjK2PZTmxd0qw+MPFdUGLEJXm8=; b=r97ht7ZN5DC1CAydbOoO1dp8TdH28bT3dY50pqAHLviXc67SxQCVhd1ZuETPpuGua8 juaHK3YZrRFQu8TD/XxO1pmrUYX+mZzRFA2qyH/lC91vDDMtadV68T5crzxHN7zgyGoV mz4vINTM6xK4mrDkp45lJFtNrfDjZxCG/NqAwAB3GOjaoJNZH1bTjpQECqt1JRrJ0Lnf aPZIVu0l6NWOaWzIrQIMMb6WQ105grBQAong5x+zsuGIWOQQYtMQ1s5MHLDH/hpUuAWh m/XW62ZRQsaJzZVXceM60nKuoXJ/Wu2bg0wX/53+ZrsYLhRhFNq1g97YFVK97fk1hXe8 Zprw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=7YubnWwbbYBcq7+WanjK2PZTmxd0qw+MPFdUGLEJXm8=; b=bTk0ZVLwN9KlgbzEhsQ+0X1eF3jkAkK4lm7wT84OAjkc2IOIX/Krf3E9dimrIMEte4 dr/UFDTvtJqjLU85dKdtfjNoJUN9w0ujSY10dSyDBzZLvsdXonJTJHD0xoZZsqywqvMc ZfXNcnU/gV1wmlZB2SZXDoNozOPZMkwekQCHrZfVBpsMAzQogO2WIFr41mZaBmxT+ZxZ YIA4xQzTYgEVYx3qU3kYepBLTSkSsvFmeT1JL8g46iEt0goNJDnBi3eHNWqql2i+Nu/G qK3Jhq5PH/rsD61lrlzQqMm8h/3HWa2gjvqrx3D783Cbac0ayuCLeYlssGwDrR87Wqw0 YSBw==
X-Gm-Message-State: APf1xPDFcloVWMNcqgMjm5sq9tEHaSeUPBSc5ZCtBYD8P4ClBu+bzEN+ SjJfSHmH57+4LekrhfLquBHSEZNHFOHAMhZlKKA=
X-Google-Smtp-Source: AH8x2262BcfFZ14lPaJh41jFwXe5Ej4+oj61/8Ynj9DvMgxE1qgKEfaS4D54hD0e0qr3lpSVET70/Xb6qAoRtaX8jEM=
X-Received: by 10.36.21.131 with SMTP id 125mr4117344itq.71.1518712733131; Thu, 15 Feb 2018 08:38:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.159.9 with HTTP; Thu, 15 Feb 2018 08:38:52 -0800 (PST)
Reply-To: gjshep@gmail.com
In-Reply-To: <CA+wi2hN8KNSyCcspk6h5frSu8jrvqMPM8W3GOO1+HDfP4yM87g@mail.gmail.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>
From: Greg Shepherd <gjshep@gmail.com>
Date: Thu, 15 Feb 2018 08:38:52 -0800
Message-ID: <CABFReBop9CtLexmzjNByad4PBj2r6XhiuUw+Nvto9xg8575xaA@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Eric C Rosen <erosen@juniper.net>, Xiejingrong <xiejingrong@huawei.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, "bier@ietf.org" <bier@ietf.org>, "arkadiy.gulko@thomsonreuters.com" <arkadiy.gulko@thomsonreuters.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Content-Type: multipart/alternative; boundary="001a11449e22f96d7d056542dce8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/p9RwpeiG7f7wzwnAMF7OhjSlJ3U>
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: Thu, 15 Feb 2018 16:38:59 -0000

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

More inline:

On Thu, Feb 15, 2018 at 8:25 AM, Tony Przygienda <tonysietf@gmail.com>
wrote:

> Under 8-bit artistic license granted by Acee herewith ;-)
>
> First, I want to emphasize that this is IETF LC (called by Greg as
> shepherding WG chair) which means chairs have no further function so we all
> can only speak as individuals only .
>
> 2nd, I oppose any suggestion to align any kind of SR registry with BAR
> registry using 8 bits on couple of very simple grounds that my
> co-participants may have missed
>
> a)       No IGP or SR working group has any charter to mandate any of the
> BIER technology so as well-meant the suggestion seems to be, it has no
> standing in IETF working procedures as far as I can see unless according
> charters are extended by ADs. Unless I'm missing something here.
>

If a WG points to a registry of any kind, a draft is all that is needed to
justify an new entry in the registry.


> b)       More as a question: Can we even publish an RFC now (experimental)
> pointing to an SR draft as normative? And if, how do we move it to intended
> standards track unless SR draft is a standards RFC?
>

Nobody is asking to reference it now. The current issue on the table to to
leave it undefined with only default value, so let's stick with the current
issue.


> c)       Probably most importantly, technically, In case any of the SR
> computations starts to rely on elements advertised in SR to perform the
> computations, deployment of BIER will precondition deployment of SR in the
> network. Worse, if we need computation that needs BIER specific elements in
> its course, that would mean we have SR becoming aware of a multicast
> technology underneath. Unicast computations are simply not multicast
> computations longer-term  (and I had discussions about couple such cases
> already). Having multicast specific elements being considered in unicast
> computations and multicast computations being "standardized" in unicast
> computations couples everything with everything again known as the
> big-ball-of-yarn (unless THAT is the intention). In long experience things
> like this are simply a very bad architecture (TM ;-).
>

Again, it's an IGP Algo registry. It's documentation. There are no
dependencies other than our references, which right now we don't have any.


> 3rd, I thought about the issues involved in BAR probably longer than
> anyone on the list here (remember Tree ID ;-) and I have a meta issue to
> make and then a finer one
>
> a)      Independent of whether we end up with 8 or 16 bits I think we need
> a firm BIER BAR registry in place here (expert review?) and some document
> to gather the BAR ideas. Sooner the better. Ideas as in this thread are
> coming in it would be good to channelize them to prevent codepoint
> squatting or replicated effort. In fact we have a draft we circulated and
> we decided to push out today to give a strawman framework to the discussed
> use-cases. Granted, only the new charter (if given to us) would allow this
> work to be adopted but it’s good to have a vessel to contain the ideas
> already IMO. So check the new-publication queue ;-)
>


>
> b)      Then, if we consider BAR as purely “special BIER nexthop
> computation” 8 bits sounds plenty but never underestimate new technology to
> stretch artistic boundaries and ideas you see here ;-) So if we think e.g.
> about things like the above mentioned draft-ietf-isis-segment-routing-extensions-15
> proposal playing a role one could imagine that the “SR algorithm registry”
> specifies an algorithm that BAR registry likes to use as well 1:1. Simple,
> we just allocate a BIER BAR codepoint that is mapped (or even same) to the
> SR UCAST codepoint in this case (well, let discussion whether we would have
> the charter to do that or go ask for permission in SPRING outstanding for
> now). And that could be done of course via a TLV as well by using a single
> “BAR # meaning it’s an SR algorithm” and then a BIER sub-tlv saying which
> one of those. But things get finer. Let’s say we use a BAR=1 as BIER
> computation saying “avoid all non-BIER routers”. Now, that’s cool but maybe
> SR defined an algorithm we want to use on top as in “compute SPF with
> enough bandwidth”. For that could have a funky TLV saying “any BAR
> computation should stack this SR computation on top” but it would be then
> way more elegant to have a 16 bit with 8bit BAR from registry and then 8
> bits of some context (in this example SR computation# to be stacked on top
> of the necessary BAR computation). Yes, that would precondition in such
> case simultaneous BIER and SR deployment but since then no technology
> forces mandatory use of another it’s flexible, open and nicely smelling. I
> hope at least some people could follow that and old IGP hands will see that
> this is actually as efficient in terms of actual implementation as a single
> set of constraints despite seeming complex.
>
> I won’t stretch my artistic license further than 16 bits albeit there are
> even more interesting ideas I saw that would blow through this ;-) I
> probably owe Acee a beer in London already as it is.
>
> So, in shorter form for the non-IGP cracks, I think 8 bits looks good but
> I see how 16 could have an elegance to channelize some of the suggestions
> (and get a "goldilocks solution"), if we e.g. decide to “stack algorithmic
> constraints from multiple technologies optionally on top of each other,
> each with its own registry that can refer to another”. This would
> accommodate also the proposal extended by Ice in a simple, clean, loosely
> coupled way by having 16 bits, *first 8 bits as BIER type being a BIER
> BAR registry and 8 bits after that being “open” so e.g. being SR unicast
> registry number*.
>
> I do also think that if we get to such a consensus, adding text
> introducing test adding a BAR type/BAR subtype 16-bits field with a BAR
> type BIER registry into the documents is just a bit of text ...
>
> As  I said, our draft will follow later today since some co-authors are in
> funky timezones ;-) …
>

thanks,
Greg


> --- tony
>
> On Thu, Feb 15, 2018 at 6:46 AM, Eric C Rosen <erosen@juniper.net> wrote:
>
>> Ice's reasoning makes sense to me.
>>
>>
>> On 2/15/2018 3:11 AM, IJsbrand Wijnands (iwijnand) wrote:
>>
>> Hi Folks,
>>
>> I support 16 bits because of the following reasons.
>>
>> For me it would make sense to align the Algorithm value to the "IGP
>> Algorithm" registry. This registry is defined in:
>> https://tools.ietf.org/html/draft-ietf-ospf-segment-rout
>> ing-extensions-24#section-8.5
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dospf-2Dsegment-2Drouting-2Dextensions-2D24-23section-2D8.5&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=wFHQGdbIofGfam7tl7rnRjckYdcPp1WR-BqnaNE1mV8&e=>
>>
>>
>> In my opinion, this is going to cover 90% of the use-cases because BIER
>> is defined to run over a unicast underlay, so what ever is done for
>> Unicast, it will work for BIER automatically (like Flex Algo), and avoids
>> to duplicate registries. However, this registry is also 8 bits. That means
>> there is no room for anything else and I already know there are different
>> options about this.
>>
>> To avoid an other long debate/fight over these 8 bits, lets get more bits
>> now so we don't corner our selfs. Its a minor change to the draft.
>>
>> Lets not start a debate now on how BAR is used, as I'm sure we will not
>> reach agreement  in time and we're gonna delay the IGP drafts. We can start
>> a discussion after the IGP draft are through and what all the use-cases are
>> we need to cover. I already look forward to those discussions :-)
>>
>> Thx,
>>
>> Ice.
>>
>> Sent from my iPad
>>
>> On 15 Feb 2018, at 07:24, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
>>
>> +1
>>
>> I’d really like to see justification for anything larger than 8 bits.
>>
>> Regards,
>> Jeff
>>
>> On Feb 14, 2018, at 18:30, Acee Lindem (acee) <acee@cisco.com> wrote:
>>
>>
>> I agree. As a point of reference, we've only have defined two IGP
>> algorithms so far and the segment routing draft dates back about 4 years.
>>
>>
>> https://www.iana.org/assignments/igp-parameters/igp-
>> parameters.xhtml#igp-algorithm-types
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_igp-2Dparameters_igp-2Dparameters.xhtml-23igp-2Dalgorithm-2Dtypes&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=5yaJPFqWpr5V5oBQ4O7o779WCOla79NlPw5FEfmRAUY&e=>
>>
>>
>> Even with more artistic freedom afforded to multicast,  I still believe
>> 256 standard algorithms are enough.
>>
>>
>> Thanks,
>>
>> Acee
>>
>>
>> On 2/14/18, 9:15 PM, "BIER on behalf of Dolganow, Andrew (Nokia -
>> SG/Singapore)" <bier-bounces@ietf.org on behalf of
>> andrew.dolganow@nokia.com> wrote:
>>
>>
>>   Guys,
>>
>>
>>   I would think 8 bits are sufficient. Others (like SegRtg mentioned
>> below also use 8). 8 bits gives us tons of room to grow - especially since
>> we have only a single value defined currently (SFP 0). If we have clear use
>> cases that show us running out of 8 bits or getting close to that we
>> can/should discuss and evaluate extensions in light of that but increasing
>> the space "just in case" is not a prudent way to go.
>>
>>
>>   Andrew
>>
>>
>>   -----Original Message-----
>>
>>   From: BIER <bier-bounces@ietf.org> on behalf of Xiejingrong <
>> xiejingrong@huawei.com>
>>
>>   Date: Wednesday, February 14, 2018 at 5:06 PM
>>
>>   To: Arkadiy Gulko <arkadiy.gulko@thomsonreuters.com>om>, "bier@ietf.org" <
>> bier@ietf.org>gt;, "isis-wg@ietf.org" <isis-wg@ietf.org>
>>
>>   Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
>>
>>
>>       Hi Arkadiy,
>>
>>
>>       I checked the latest <draft-ietf-ospf-segment-routing-extensions-24>
>> and <draft-ietf-isis-segment-routing-extensions-15> for reference and
>> comparing, and they both use a 8 bits Algorithm.
>>
>>       One of the description: "Algorithm: Single octet identifying the
>> algorithm."
>>
>>
>>       Interesting to use more than 8 bits for BIER's future flexibility
>> :-)
>>
>>
>>       Regards,
>>
>>       XieJingrong
>>
>>
>>
>>       -----Original Message-----
>>
>>       From: BIER [mailto:bier-bounces@ietf.org <bier-bounces@ietf.org>]
>> On Behalf Of arkadiy.gulko@thomsonreuters.com
>>
>>       Sent: Wednesday, February 14, 2018 8:42 AM
>>
>>       To: bier@ietf.org; isis-wg@ietf.org
>>
>>       Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
>>
>>
>>       Hello Working Group,
>>
>>       After initial discussions between multiple participants of the
>> working group, we consolidated that BIER's future flexibility would be well
>> served if we extend the IGP signaling BAR field to 16 bits. We are
>> currently reviewing various use-cases that can greatly benefit from this
>> enhancement.
>>
>>       I would appreciate if the proposed change could be considered as
>> part of IETF Last Call review.
>>
>>       Thanks,
>>
>>       Arkadiy
>>
>>
>>
>>       -----Original Message-----
>>
>>       From: BIER [mailto:bier-bounces@ietf.org <bier-bounces@ietf.org>]
>> On Behalf Of internet-drafts@ietf.org
>>
>>       Sent: Friday, February 09, 2018 5:11 PM
>>
>>       To: i-d-announce@ietf.org
>>
>>       Cc: bier@ietf.org
>>
>>       Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt
>>
>>
>>
>>       A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>       This draft is a work item of the Bit Indexed Explicit Replication
>> WG of the IETF.
>>
>>
>>               Title           : BIER support via ISIS
>>
>>               Authors         : Les Ginsberg
>>
>>                                 Tony Przygienda
>>
>>                                 Sam Aldrin
>>
>>                                 Jeffrey (Zhaohui) Zhang
>>
>>           Filename        : draft-ietf-bier-isis-extensions-07.txt
>>
>>           Pages           : 10
>>
>>           Date            : 2018-02-09
>>
>>
>>       Abstract:
>>
>>          Specification of an ISIS extension to support BIER domains and
>> sub-
>>
>>          domains.
>>
>>
>>
>>
>>       The IETF datatracker status page for this draft is:
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Disis-2Dextens
>> ions_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY
>> &r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8R
>> eKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=3qPmQav_QUBjHi7KygPVk9bIh
>> VZ7TL2Z3xfHOo_Cjwc&e=
>>
>>
>>       There are also htmlized versions available at:
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> tools.ietf.org_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-
>> 2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&
>> r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8Re
>> KzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=_nTFvlAW24snrkMm3aQ2uWLFsL
>> CajYeW4HO3DdEiwvs&e=
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-2Disis-
>> 2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-
>> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4
>> cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&
>> s=zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4&e=
>>
>>
>>       A diff from the previous version is available at:
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbier-2Disis-
>> 2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-
>> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4
>> cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&
>> s=pDVWzZrYzGia4WKiA_cSF0P5isUmMeojSvHJIGgdOTk&e=
>>
>>
>>
>>       Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=qZ3p2sAIpzRPXfiRBbzrB1rPAkaJXEKiz43EmIKO03Y&e=>
>> .
>>
>>
>>       Internet-Drafts are also available by anonymous FTP at:
>>
>>       https://urldefense.proofpoint.com/v2/url?u=ftp-3A__
>> ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=4ZIZThykDLcoWk-
>> GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcx
>> u4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvY
>> s&s=wqMqmybm38ZiX4CuzJaNJPMea1Mf-pSgD-vdgAHk850&e=
>>
>>
>>       _______________________________________________
>>
>>       BIER mailing list
>>
>>       BIER@ietf.org
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=4ZIZThykDLcoWk
>> -GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcx
>> u4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvY
>> s&s=kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU&e=
>>
>>
>>       _______________________________________________
>>
>>       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=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>
>>
>>       _______________________________________________
>>
>>       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=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>
>>
>>
>>   _______________________________________________
>>
>>   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=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>
>>
>>
>> _______________________________________________
>>
>> 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=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>
>>
>> _______________________________________________
>> 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=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>
>>
>>
>> _______________________________________________
>> BIER mailing listBIER@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=
>>
>>
>>
>> _______________________________________________
>> Isis-wg mailing list
>> Isis-wg@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
>>
>>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>