And the registry has already been created: https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
Les From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Greg Shepherd Sent: Thursday, February 15, 2018 8:39 AM To: Tony Przygienda <tonysi...@gmail.com> Cc: b...@ietf.org; isis-wg@ietf.org; Xiejingrong <xiejingr...@huawei.com>; Jeff Tantsura <jefftant.i...@gmail.com>; arkadiy.gu...@thomsonreuters.com; Eric C Rosen <ero...@juniper.net> Subject: Re: [Bier] [Isis-wg] 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 <tonysi...@gmail.com<mailto:tonysi...@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 <ero...@juniper.net<mailto:ero...@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-routing-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.i...@gmail.com<mailto:jefftant.i...@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) <a...@cisco.com<mailto:a...@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-boun...@ietf.org<mailto:bier-boun...@ietf.org> on behalf of andrew.dolga...@nokia.com<mailto:andrew.dolga...@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-boun...@ietf.org<mailto:bier-boun...@ietf.org>> on behalf of Xiejingrong <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>> Date: Wednesday, February 14, 2018 at 5:06 PM To: Arkadiy Gulko <arkadiy.gu...@thomsonreuters.com<mailto:arkadiy.gu...@thomsonreuters.com>>, "b...@ietf.org<mailto:b...@ietf.org>" <b...@ietf.org<mailto:b...@ietf.org>>, "isis-wg@ietf.org<mailto:isis-wg@ietf.org>" <isis-wg@ietf.org<mailto: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-boun...@ietf.org] On Behalf Of arkadiy.gu...@thomsonreuters.com<mailto:arkadiy.gu...@thomsonreuters.com> Sent: Wednesday, February 14, 2018 8:42 AM To: b...@ietf.org<mailto:b...@ietf.org>; isis-wg@ietf.org<mailto: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-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Sent: Friday, February 09, 2018 5:11 PM To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> Cc: b...@ietf.org<mailto:b...@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-2Dextensions_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=3qPmQav_QUBjHi7KygPVk9bIhVZ7TL2Z3xfHOo_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=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=_nTFvlAW24snrkMm3aQ2uWLFsLCajYeW4HO3DdEiwvs&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-jvOcxu4cQskARppQFqZc&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-jvOcxu4cQskARppQFqZc&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-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=wqMqmybm38ZiX4CuzJaNJPMea1Mf-pSgD-vdgAHk850&e= _______________________________________________ BIER mailing list b...@ietf.org<mailto:b...@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-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU&e= _______________________________________________ BIER mailing list b...@ietf.org<mailto:b...@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 b...@ietf.org<mailto:b...@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 b...@ietf.org<mailto:b...@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 b...@ietf.org<mailto:b...@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 b...@ietf.org<mailto:b...@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 b...@ietf.org<mailto:b...@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<mailto:Isis-wg@ietf.org> https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ BIER mailing list b...@ietf.org<mailto:b...@ietf.org> https://www.ietf.org/mailman/listinfo/bier
_______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
