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

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>, "bier@ietf.org" <
>> bier@ietf.org>, "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
>
>