+1 Regards, Jeff
> On Feb 16, 2018, at 18:18, Dolganow, Andrew (Nokia - SG/Singapore) > <andrew.dolga...@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)" <ginsb...@cisco.com> > Date: Friday, February 16, 2018 at 11:08 PM > To: Eric Rosen <ero...@juniper.net>, Andrew Dolganow > <andrew.dolga...@nokia.com>, "(Ice) IJsbrand Wijnands" <i...@cisco.com> > Cc: Greg Shepherd <gjs...@gmail.com>, "b...@ietf.org" <b...@ietf.org>, > "isis-wg@ietf.org" <isis-wg@ietf.org>, Xiejingrong <xiejingr...@huawei.com>, > Arkadiy Gulko <arkadiy.gu...@thomsonreuters.com> > Subject: RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt > > Eric - > > From: Eric C Rosen [mailto:ero...@juniper.net] > Sent: Friday, February 16, 2018 6:45 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Dolganow, Andrew (Nokia - > SG/Singapore) <andrew.dolga...@nokia.com>; IJsbrand Wijnands <i...@cisco.com> > Cc: Greg Shepherd <gjs...@gmail.com>; b...@ietf.org; isis-wg@ietf.org; > Xiejingrong <xiejingr...@huawei.com>; arkadiy.gu...@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-boun...@ietf.org] On Behalf Of Dolganow, Andrew > (Nokia - SG/Singapore) > Sent: Thursday, February 15, 2018 7:39 PM > To: IJsbrand Wijnands <i...@cisco.com> > Cc: Greg Shepherd <gjs...@gmail.com>; b...@ietf.org; isis-wg@ietf.org; > Xiejingrong <xiejingr...@huawei.com>; arkadiy.gu...@thomsonreuters.com; Eric > C Rosen <ero...@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 <i...@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 <tonysi...@gmail.com> wrote: > > > > On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <gjs...@gmail.com> wrote: > On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <tonysi...@gmail.com> wrote: > > > On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <gjs...@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 > b...@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > <PastedGraphic-6.png> > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ > BIER mailing list > 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
