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

[Tony Przygienda]

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) <
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)" 
> *Date: *Friday, February 16, 2018 at 11:08 PM
> *To: *Eric Rosen , Andrew Dolganow <
> andrew.dolga...@nokia.com>, "(Ice) IJsbrand Wijnands" 
> *Cc: *Greg Shepherd , "b...@ietf.org" , "
> isis-wg@ietf.org" , Xiejingrong ,
> Arkadiy Gulko 
> *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) ; Dolganow, Andrew
> (Nokia - SG/Singapore) ; IJsbrand Wijnands <
> i...@cisco.com>
> *Cc:* Greg Shepherd ; b...@ietf.org; isis-wg@ietf.org;
> Xiejingrong ; 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:  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  
> *Cc:* Greg Shepherd  ; b...@ietf.org;
> isis-wg@ietf.org; Xiejingrong 
> ; arkadiy.gu...@thomsonreuters.com; Eric C Rosen
>  
> *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 

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

[Eric C Rosen]

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: 
.


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 
*Cc:* Greg Shepherd ; b...@ietf.org; 
isis-wg@ietf.org; Xiejingrong ; 
arkadiy.gu...@thomsonreuters.com; Eric C Rosen 
*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 > 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 

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

[Les Ginsberg (ginsberg)]

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 
Cc: Greg Shepherd ; b...@ietf.org; isis-wg@ietf.org; 
Xiejingrong ; arkadiy.gu...@thomsonreuters.com; Eric C 
Rosen 
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 
> 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 
> wrote:



On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd 
> wrote:
On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda 
> wrote:


On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd 
> 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 

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

[Dolganow, Andrew (Nokia - SG/Singapore)]

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 
> 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 
> wrote:



On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd 
> wrote:
On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda 
> wrote:


On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd 
> 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

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

[Greg Shepherd]

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 
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 

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

[Tony Przygienda]

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.
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?
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 ;-).

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

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

[Acee Lindem (acee)]

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

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)"  
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  on behalf of Xiejingrong 

Date: Wednesday, February 14, 2018 at 5:06 PM
To: Arkadiy Gulko , "b...@ietf.org" 
, "isis-wg@ietf.org" 
Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Hi Arkadiy,

I checked the latest  
and  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
Sent: Wednesday, February 14, 2018 8:42 AM
To: b...@ietf.org; 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
Sent: Friday, February 09, 2018 5:11 PM
To: i-d-annou...@ietf.org
Cc: 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_=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=3qPmQav_QUBjHi7KygPVk9bIhVZ7TL2Z3xfHOo_Cjwc=
 

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=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=_nTFvlAW24snrkMm3aQ2uWLFsLCajYeW4HO3DdEiwvs=

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-2D07=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4=
 

A diff from the previous version is available at:

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

[Xiejingrong]

Hi Arkadiy,

I checked the latest  and 
 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
Sent: Wednesday, February 14, 2018 8:42 AM
To: b...@ietf.org; 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
Sent: Friday, February 09, 2018 5:11 PM
To: i-d-annou...@ietf.org
Cc: 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_=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=3qPmQav_QUBjHi7KygPVk9bIhVZ7TL2Z3xfHOo_Cjwc=
 

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=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=_nTFvlAW24snrkMm3aQ2uWLFsLCajYeW4HO3DdEiwvs=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-2D07=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4=
 

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=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=pDVWzZrYzGia4WKiA_cSF0P5isUmMeojSvHJIGgdOTk=
 


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.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=wqMqmybm38ZiX4CuzJaNJPMea1Mf-pSgD-vdgAHk850=
 

___
BIER mailing list
b...@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs=kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU=
 

___
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