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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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) <[email protected]> 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)" <[email protected] on behalf of >> [email protected]> 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 <[email protected]> on behalf of Xiejingrong < >> [email protected]> >> >> Date: Wednesday, February 14, 2018 at 5:06 PM >> >> To: Arkadiy Gulko <[email protected]>, "[email protected]" < >> [email protected]>, "[email protected]" <[email protected]> >> >> 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:[email protected] <[email protected]>] >> On Behalf Of [email protected] >> >> Sent: Wednesday, February 14, 2018 8:42 AM >> >> To: [email protected]; [email protected] >> >> 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:[email protected] <[email protected]>] >> On Behalf Of [email protected] >> >> Sent: Friday, February 09, 2018 5:11 PM >> >> To: [email protected] >> >> Cc: [email protected] >> >> 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 >> >> [email protected] >> >> 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 >> >> [email protected] >> >> 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 >> >> [email protected] >> >> 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 >> >> [email protected] >> >> 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 >> >> [email protected] >> >> 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 >> [email protected] >> 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 [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/isis-wg >> >> > > _______________________________________________ > BIER mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bier > >
_______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
