I'm working on a strawman of what I understood we seem to agree on for further comments in detail, ETA tommorow ...
On Fri, Feb 16, 2018 at 6:18 PM, Dolganow, Andrew (Nokia - SG/Singapore) < [email protected]> 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)" <[email protected]> > *Date: *Friday, February 16, 2018 at 11:08 PM > *To: *Eric Rosen <[email protected]>, Andrew Dolganow < > [email protected]>, "(Ice) IJsbrand Wijnands" <[email protected]> > *Cc: *Greg Shepherd <[email protected]>, "[email protected]" <[email protected]>, " > [email protected]" <[email protected]>, Xiejingrong <[email protected]>, > Arkadiy Gulko <[email protected]> > *Subject: *RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis- > extensions-07.txt > > > > Eric - > > > > *From:* Eric C Rosen [mailto:[email protected]] > *Sent:* Friday, February 16, 2018 6:45 AM > *To:* Les Ginsberg (ginsberg) <[email protected]>; Dolganow, Andrew > (Nokia - SG/Singapore) <[email protected]>; IJsbrand Wijnands < > [email protected]> > *Cc:* Greg Shepherd <[email protected]>; [email protected]; [email protected]; > Xiejingrong <[email protected]>; [email protected] > *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:[email protected] <[email protected]>] *On > Behalf Of *Dolganow, Andrew (Nokia - SG/Singapore) > *Sent:* Thursday, February 15, 2018 7:39 PM > *To:* IJsbrand Wijnands <[email protected]> <[email protected]> > *Cc:* Greg Shepherd <[email protected]> <[email protected]>; [email protected]; > [email protected]; Xiejingrong <[email protected]> > <[email protected]>; [email protected]; Eric C Rosen > <[email protected]> <[email protected]> > *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 <[email protected]> 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 <[email protected]> wrote: > > > > On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <[email protected]> wrote: > On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[email protected] > > wrote: > > > On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <[email protected]> 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 > [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=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=vxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=> > > > > <PastedGraphic-6.png> > > > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_isis-2Dwg&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=gRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=> > > > > _______________________________________________ > 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
