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

[Tony Przygienda <[e-mail]>]

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) <
[e-mail]> 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)" <[e-mail]>
> *Date: *Friday, February 16, 2018 at 11:08 PM
> *To: *Eric Rosen <[e-mail]>, Andrew Dolganow <
> [e-mail]>, "(Ice) IJsbrand Wijnands" <[e-mail]>
> *Cc: *Greg Shepherd <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, Xiejingrong <[e-mail]>,
> Arkadiy Gulko <[e-mail]>
> *Subject: *RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Eric -
>
>
>
> *From:* Eric C Rosen [mailto:[e-mail]]
> *Sent:* Friday, February 16, 2018 6:45 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Dolganow, Andrew
> (Nokia - SG/Singapore) <[e-mail]>; IJsbrand Wijnands <
> [e-mail]>
> *Cc:* Greg Shepherd <[e-mail]>; [e-mail]; [e-mail];
> Xiejingrong <[e-mail]>; [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *Dolganow, Andrew (Nokia - SG/Singapore)
> *Sent:* Thursday, February 15, 2018 7:39 PM
> *To:* IJsbrand Wijnands <[e-mail]> <[e-mail]>
> *Cc:* Greg Shepherd <[e-mail]> <[e-mail]>; [e-mail];
> [e-mail]; Xiejingrong <[e-mail]>
> <[e-mail]>; [e-mail]; Eric C Rosen
> <[e-mail]> <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> wrote:
>
>
>
> On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <[e-mail]> wrote:
> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[e-mail]
> > wrote:
>
>
> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <[e-mail]> 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
> [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
>