Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Jeffrey (Zhaohui) Zhang]

Hi Alia,

Thanks for articulating it very clearly, and bring out the issue of having a 
clear specification on the interaction.

I need one clarification from you though – is it possible that the you actually 
meant BART when you said BARM, and vice versa, in the following?

--
With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the 
constraints are empty.

For the BARM, all the necessary constraints can be applied first.

To define a code-point for BARM, the following information is necessary:
   i) Constraints
   ii) Can constraints be additive  (default yes unless specified otherwise)
   iii) What is the algorithm - or is it "empty"
-

I’ll try to work with Les on the text to specify the interaction.

Jeffrey

From: Alia Atlas [mailto:akat...@gmail.com]
Sent: Wednesday, February 21, 2018 9:45 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: IJsbrand Wijnands (iwijnand) ; 
ext-arkadiy.gu...@thomsonreuters.com ; 
b...@ietf.org; IJsbrand Wijnands ; isis-wg@ietf.org; Eric Rosen 

Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

First, I greatly appreciate the rapid education I have gotten on why the 
different aspects of this are important.

Let us explore some details on the plan for an 8-bit BART and an 8-bit BARM 
that are independent.  Jeffrey,
I really appreciate your bringing this option to the list.  It simplifies the 
option B idea of subtypes away and there
seems to be a good amount of interest in it.

My concern is that we specify adequately how the codepoints in BART and BARM 
interact.

One of the challenges with doing so has been, IMHO, a bit of terminology where 
we are describing these as
algorithms but in fact these are tuples consisting of a set of constraints and 
a base algorithm.

BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us describe 
this as BART =  (BC, BA).

BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us 
describe this as BARM = (RC, RA).

Let me give some concrete examples.

Consider a case of BART=4 which is known to mean (prune non-BIER routers, use 
SPF).
BARM = 200, which is known to mean (prune links with BW <10G, use SPF)

It is desirable to have an outcome that is (prune non-BIER routers and links 
with BW < 10G, use SPF).

This can work algorithmically because the constraints are the types that we've 
seen before for RSVP-TE.

What I think we need to make the independent 8-bit BART plus 8-bit BARM work is 
a clear specification
of the interaction. I think that is:

Start with the topology Topology.
1) Apply the constraints represented by the BART  BC(Topology)
2) Apply the constraints represented by the BARM  RC(BC(Topology))
3) Select the algorithm A as follows:  use BA or if BA is "empty", use RA.
Run A on RC(BC(Topology)) to get the next-hops and information for the BIFT.

Key points on the algorithm aspect are:
a) BIER is the higher layer, so it is assumed to know better which algorithm 
should be used.
b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so that 
the algorithm
falls through to whatever is RA.

With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the 
constraints are empty.

For the BARM, all the necessary constraints can be applied first.

To define a code-point for BARM, the following information is necessary:
   i) Constraints
   ii) Can constraints be additive  (default yes unless specified otherwise)
   iii) What is the algorithm - or is it "empty"

I am bringing forth this description now because I am concerned that the 
interaction between
BARM and BART is not adequately defined to be published - but I see the strong 
interest in
this as the solution and, from my understanding of the problem, agree.

Please comment ASAP.

Jeffrey & Les, is this something that you can turn into clear text for the 
drafts?

Regards,
Alia




On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang 
> wrote:
To make it absolutely clear using an example: even with  it 
is still that the two fields are independent of each other.
This particular combination means “apply BART 1” to “Flexible-Algo 200”, where 
“Flexible-Algo 200” could be “exclude red links”, while “BART 1” could be “skip 
BIER incapable routers”.

This is a very practical and concrete example showing the advantage of having 
two separate fields. Other ways could be used to achieve the same result, but 
they’re more cumbersome.

Jeffrey

From: BIER [mailto:bier-boun...@ietf.org] On 
Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Wednesday, February 21, 2018 8:40 AM
To: Jeffrey (Zhaohui) Zhang 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Hi Jeffrey,

Yes, I was rushing & may have mangled the terminology in the final bit.

The routing layer 8-bit field can be from the IGP Algorithm registry.

Thanks for catching it & for your willingness to write this up more clearly!

Regards,
Aka

On Feb 21, 2018 10:05 AM, "Jeffrey (Zhaohui) Zhang" 
wrote:

> Hi Alia,
>
>
>
> Thanks for articulating it very clearly, and bring out the issue of having
> a clear specification on the interaction.
>
>
>
> I need one clarification from you though – is it possible that the you
> actually meant BART when you said BARM, and vice versa, in the following?
>
>
>
> --
>
> With that, the BART can be exactly the IGP Algorithms registry.
>
> All the IGP Algorithms are available.   For the 2 currently defined, the
> constraints are empty.
>
>
>
> For the BARM, all the necessary constraints can be applied first.
>
>
>
> To define a code-point for BARM, the following information is necessary:
>
>i) Constraints
>
>ii) Can constraints be additive  (default yes unless specified
> otherwise)
>
>iii) What is the algorithm - or is it "empty"
>
> -
>
>
>
> I’ll try to work with Les on the text to specify the interaction.
>
>
>
> Jeffrey
>
>
>
> *From:* Alia Atlas [mailto:akat...@gmail.com]
> *Sent:* Wednesday, February 21, 2018 9:45 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* IJsbrand Wijnands (iwijnand) ;
> ext-arkadiy.gu...@thomsonreuters.com ;
> b...@ietf.org; IJsbrand Wijnands ; isis-wg@ietf.org; Eric
> Rosen 
> *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> First, I greatly appreciate the rapid education I have gotten on why the
> different aspects of this are important.
>
>
>
> Let us explore some details on the plan for an 8-bit BART and an 8-bit
> BARM that are independent.  Jeffrey,
>
> I really appreciate your bringing this option to the list.  It simplifies
> the option B idea of subtypes away and there
>
> seems to be a good amount of interest in it.
>
>
>
> My concern is that we specify adequately how the codepoints in BART and
> BARM interact.
>
>
>
> One of the challenges with doing so has been, IMHO, a bit of terminology
> where we are describing these as
>
> algorithms but in fact these are tuples consisting of a set of constraints
> and a base algorithm.
>
>
>
> BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us
> describe this as BART =  (BC, BA).
>
>
>
> BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us
> describe this as BARM = (RC, RA).
>
>
>
> Let me give some concrete examples.
>
>
>
> Consider a case of BART=4 which is known to mean (prune non-BIER routers,
> use SPF).
>
> BARM = 200, which is known to mean (prune links with BW <10G, use SPF)
>
>
>
> It is desirable to have an outcome that is (prune non-BIER routers and
> links with BW < 10G, use SPF).
>
>
>
> This can work algorithmically because the constraints are the types that
> we've seen before for RSVP-TE.
>
>
>
> What I think we need to make the independent 8-bit BART plus 8-bit BARM
> work is a clear specification
>
> of the interaction. I think that is:
>
>
>
> Start with the topology Topology.
>
> 1) Apply the constraints represented by the BART  BC(Topology)
>
> 2) Apply the constraints represented by the BARM  RC(BC(Topology))
>
> 3) Select the algorithm A as follows:  use BA or if BA is "empty", use RA.
>
> Run A on RC(BC(Topology)) to get the next-hops and information for the
> BIFT.
>
>
>
> Key points on the algorithm aspect are:
>
> a) BIER is the higher layer, so it is assumed to know better which
> algorithm should be used.
>
> b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so
> that the algorithm
>
> falls through to whatever is RA.
>
>
>
> With that, the BART can be exactly the IGP Algorithms registry.
>
> All the IGP Algorithms are available.   For the 2 currently defined, the
> constraints are empty.
>
>
>
> For the BARM, all the necessary constraints can be applied first.
>
>
>
> To define a code-point for BARM, the following information is necessary:
>
>i) Constraints
>
>ii) Can constraints be additive  (default yes unless specified
> otherwise)
>
>iii) What is the algorithm - or is it "empty"
>
>
>
> I am bringing forth this description now because I am concerned that the
> interaction between
>
> BARM and BART is not adequately defined to be published - but I see the
> strong interest in
>
> this as the solution and, from my understanding of the problem, agree.
>
>
>
> Please comment ASAP.
>
>
>
> Jeffrey & Les, is this something that you can turn into clear text for the
> drafts?
>
>
>
> Regards,
>
> Alia
>
>
>
>
>
>
>
>
>
> On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang <
> zzh...@juniper.net> wrote:
>
> To make it absolutely clear using an 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

First, I greatly appreciate the rapid education I have gotten on why the
different aspects of this are important.

Let us explore some details on the plan for an 8-bit BART and an 8-bit BARM
that are independent.  Jeffrey,
I really appreciate your bringing this option to the list.  It simplifies
the option B idea of subtypes away and there
seems to be a good amount of interest in it.

My concern is that we specify adequately how the codepoints in BART and
BARM interact.

One of the challenges with doing so has been, IMHO, a bit of terminology
where we are describing these as
algorithms but in fact these are tuples consisting of a set of constraints
and a base algorithm.

BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us
describe this as BART =  (BC, BA).

BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us
describe this as BARM = (RC, RA).

Let me give some concrete examples.

Consider a case of BART=4 which is known to mean (prune non-BIER routers,
use SPF).
BARM = 200, which is known to mean (prune links with BW <10G, use SPF)

It is desirable to have an outcome that is (prune non-BIER routers and
links with BW < 10G, use SPF).

This can work algorithmically because the constraints are the types that
we've seen before for RSVP-TE.

What I think we need to make the independent 8-bit BART plus 8-bit BARM
work is a clear specification
of the interaction. I think that is:

Start with the topology Topology.
1) Apply the constraints represented by the BART  BC(Topology)
2) Apply the constraints represented by the BARM  RC(BC(Topology))
3) Select the algorithm A as follows:  use BA or if BA is "empty", use RA.
Run A on RC(BC(Topology)) to get the next-hops and information for the
BIFT.

Key points on the algorithm aspect are:
a) BIER is the higher layer, so it is assumed to know better which
algorithm should be used.
b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so
that the algorithm
falls through to whatever is RA.

With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the
constraints are empty.

For the BARM, all the necessary constraints can be applied first.

To define a code-point for BARM, the following information is necessary:
   i) Constraints
   ii) Can constraints be additive  (default yes unless specified otherwise)
   iii) What is the algorithm - or is it "empty"

I am bringing forth this description now because I am concerned that the
interaction between
BARM and BART is not adequately defined to be published - but I see the
strong interest in
this as the solution and, from my understanding of the problem, agree.

Please comment ASAP.

Jeffrey & Les, is this something that you can turn into clear text for the
drafts?

Regards,
Alia




On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang  wrote:

> To make it absolutely clear using an example: even with 
> it is still that the two fields are independent of each other.
>
> This particular combination means “apply BART 1” to “Flexible-Algo 200”,
> where “Flexible-Algo 200” could be “exclude red links”, while “BART 1”
> could be “skip BIER incapable routers”.
>
>
>
> This is a very practical and concrete example showing the advantage of
> having two separate fields. Other ways could be used to achieve the same
> result, but they’re more cumbersome.
>
>
>
> Jeffrey
>
>
>
> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *IJsbrand
> Wijnands (iwijnand)
> *Sent:* Wednesday, February 21, 2018 8:40 AM
> *To:* Jeffrey (Zhaohui) Zhang 
> *Cc:* b...@ietf.org; isis-wg@ietf.org; IJsbrand Wijnands ;
> ext-arkadiy.gu...@thomsonreuters.com ;
> Eric Rosen 
> *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
>
>
>
>
> Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.
>
>
>
> Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.
>
>
>
> Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.
>
>
>
> Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and
> v.s., if BART is used, BARM will just be 0.
>
>
>
> Thx,
>
>
>
> Ice.
>
>
>
>
>
> THx,
>
>
>
> Ice.
>
>
>
>
>
> Jeffrey
>
>
>
> Registry Algorithm a.k.a as BARM then ... Without this section we would be
> mandating that BARM is always an IGP algorithm or FA so basically it would
> mandate IGP
>
>
>
> Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the
> people on the list who are of the opinion that aligning with IGP is
> important.
>
>
>
> Algorithm registry as the only option to perform a calculation making BART
> possibly pretty much useless ... Having a registry being mapped 1:1 into
> another registry known
>
>
>
> Ice: I don't understand why you are saying this. If BARM is 0, BART 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands (iwijnand)]

Jeffrey,

To make it absolutely clear using an example: even with  it 
is still that the two fields are independent of each other.
This particular combination means “apply BART 1” to “Flexible-Algo 200”, where 
“Flexible-Algo 200” could be “exclude red links”, while “BART 1” could be “skip 
BIER incapable routers”.

This is a very practical and concrete example showing the advantage of having 
two separate fields. Other ways could be used to achieve the same result, but 
they’re more cumbersome.

I agree.

But, which combinations are supported must be documented in an IETF draft. We 
don't assume any combinations to just work without being specified.

Thx,

Ice.


Jeffrey

From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of IJsbrand Wijnands 
(iwijnand)
Sent: Wednesday, February 21, 2018 8:40 AM
To: Jeffrey (Zhaohui) Zhang >
Cc: b...@ietf.org; 
isis-wg@ietf.org; IJsbrand Wijnands 
>; 
ext-arkadiy.gu...@thomsonreuters.com
 >; 
Eric Rosen >
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions



Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.

Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.

Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and v.s., 
if BART is used, BARM will just be 0.

Thx,

Ice.



THx,

Ice.



Jeffrey


Registry Algorithm a.k.a as BARM then ... Without this section we would be 
mandating that BARM is always an IGP algorithm or FA so basically it would 
mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on 
the list who are of the opinion that aligning with IGP is important.


Algorithm registry as the only option to perform a calculation making BART 
possibly pretty much useless ... Having a registry being mapped 1:1 into  
another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all 
yours. Its unfortunate that a large part of the discussion is dominated by 
perceived functionality in the form of BIER Algorithm, while there is no 
architecture draft that describes how it should work and no discussion has 
happen in any IETF meeting, which leaves us all guessing. I think Alia asked a 
very good question on the list regarding "constraints". It is not at all clear 
if BART is a Algorithm or a Constraint. I think from your response you're 
saying its both, which seems wrong IMO.. To me Alia's question is still open, 
but that that may be because I could not decipher the rest of your response.


as identity makes them both them the same thing by another name.
So, to get anywhere close to consensus let's get bit less creative maybe and 
stick to the four letters of the alphabet that the AD extended as a wide 
playing field and the WG seems to converge around ... Or otherwise stick to 
option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what 
we are doing, and that is how you can converge on a solution and reach 
consensus. That is better compared to a vote on an option and everybody walks 
away with a different interpretation of it.

Thx,

Ice.
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Jeffrey (Zhaohui) Zhang]

To make it absolutely clear using an example: even with  it 
is still that the two fields are independent of each other.
This particular combination means “apply BART 1” to “Flexible-Algo 200”, where 
“Flexible-Algo 200” could be “exclude red links”, while “BART 1” could be “skip 
BIER incapable routers”.

This is a very practical and concrete example showing the advantage of having 
two separate fields. Other ways could be used to achieve the same result, but 
they’re more cumbersome.

Jeffrey

From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of IJsbrand Wijnands 
(iwijnand)
Sent: Wednesday, February 21, 2018 8:40 AM
To: Jeffrey (Zhaohui) Zhang 
Cc: b...@ietf.org; isis-wg@ietf.org; IJsbrand Wijnands ; 
ext-arkadiy.gu...@thomsonreuters.com ; Eric 
Rosen 
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions



Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.

Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.

Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and v.s., 
if BART is used, BARM will just be 0.

Thx,

Ice.



THx,

Ice.



Jeffrey


Registry Algorithm a.k.a as BARM then ... Without this section we would be 
mandating that BARM is always an IGP algorithm or FA so basically it would 
mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on 
the list who are of the opinion that aligning with IGP is important.


Algorithm registry as the only option to perform a calculation making BART 
possibly pretty much useless ... Having a registry being mapped 1:1 into  
another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all 
yours. Its unfortunate that a large part of the discussion is dominated by 
perceived functionality in the form of BIER Algorithm, while there is no 
architecture draft that describes how it should work and no discussion has 
happen in any IETF meeting, which leaves us all guessing. I think Alia asked a 
very good question on the list regarding "constraints". It is not at all clear 
if BART is a Algorithm or a Constraint. I think from your response you're 
saying its both, which seems wrong IMO.. To me Alia's question is still open, 
but that that may be because I could not decipher the rest of your response.


as identity makes them both them the same thing by another name.
So, to get anywhere close to consensus let's get bit less creative maybe and 
stick to the four letters of the alphabet that the AD extended as a wide 
playing field and the WG seems to converge around ... Or otherwise stick to 
option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what 
we are doing, and that is how you can converge on a solution and reach 
consensus. That is better compared to a vote on an option and everybody walks 
away with a different interpretation of it.

Thx,

Ice.
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands (iwijnand)]

Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.

Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.

Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and v.s., 
if BART is used, BARM will just be 0.

Thx,

Ice.


THx,

Ice.


Jeffrey


Registry Algorithm a.k.a as BARM then ... Without this section we would be 
mandating that BARM is always an IGP algorithm or FA so basically it would 
mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on 
the list who are of the opinion that aligning with IGP is important.


Algorithm registry as the only option to perform a calculation making BART 
possibly pretty much useless ... Having a registry being mapped 1:1 into  
another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all 
yours. Its unfortunate that a large part of the discussion is dominated by 
perceived functionality in the form of BIER Algorithm, while there is no 
architecture draft that describes how it should work and no discussion has 
happen in any IETF meeting, which leaves us all guessing. I think Alia asked a 
very good question on the list regarding "constraints". It is not at all clear 
if BART is a Algorithm or a Constraint. I think from your response you're 
saying its both, which seems wrong IMO.. To me Alia's question is still open, 
but that that may be because I could not decipher the rest of your response.


as identity makes them both them the same thing by another name.
So, to get anywhere close to consensus let's get bit less creative maybe and 
stick to the four letters of the alphabet that the AD extended as a wide 
playing field and the WG seems to converge around ... Or otherwise stick to 
option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what 
we are doing, and that is how you can converge on a solution and reach 
consensus. That is better compared to a vote on an option and everybody walks 
away with a different interpretation of it.

Thx,

Ice.
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Jeffrey (Zhaohui) Zhang]

Hi Ice,

From: IJsbrand Wijnands (iwijnand) [mailto:iwijn...@cisco.com]
Sent: Wednesday, February 21, 2018 8:16 AM
To: Tony Przygienda 
Cc: IJsbrand Wijnands ; Jeffrey (Zhaohui) Zhang 
; ext-arkadiy.gu...@thomsonreuters.com 
; b...@ietf.org; isis-wg@ietf.org; Eric Rosen 

Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

Inline.


Future specifications may specify BART values that change the
interpretation of the BARM octet. Those specifications must handle backwards

ICE: This creates a potential dependency which I think we should avoid. I think 
there are possible use-cases where the combination of the two values could be 
valuable. But since we don’t yet know what that is, lets not speculate on it. 
Let keep both values as equal importance without interdependency.

And I happen to think that if this proposal has any merit this is precisely the 
paragraph we have to keep to make sure that not every possible BART value is 
being slaved to IGP

Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.

Jeffrey


Registry Algorithm a.k.a as BARM then ... Without this section we would be 
mandating that BARM is always an IGP algorithm or FA so basically it would 
mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on 
the list who are of the opinion that aligning with IGP is important.


Algorithm registry as the only option to perform a calculation making BART 
possibly pretty much useless ... Having a registry being mapped 1:1 into  
another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all 
yours. Its unfortunate that a large part of the discussion is dominated by 
perceived functionality in the form of BIER Algorithm, while there is no 
architecture draft that describes how it should work and no discussion has 
happen in any IETF meeting, which leaves us all guessing. I think Alia asked a 
very good question on the list regarding "constraints". It is not at all clear 
if BART is a Algorithm or a Constraint. I think from your response you're 
saying its both, which seems wrong IMO.. To me Alia's question is still open, 
but that that may be because I could not decipher the rest of your response.


as identity makes them both them the same thing by another name.
So, to get anywhere close to consensus let's get bit less creative maybe and 
stick to the four letters of the alphabet that the AD extended as a wide 
playing field and the WG seems to converge around ... Or otherwise stick to 
option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what 
we are doing, and that is how you can converge on a solution and reach 
consensus. That is better compared to a vote on an option and everybody walks 
away with a different interpretation of it.

Thx,

Ice.
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands (iwijnand)]

Inline.


Future specifications may specify BART values that change the
interpretation of the BARM octet. Those specifications must handle backwards

ICE: This creates a potential dependency which I think we should avoid. I think 
there are possible use-cases where the combination of the two values could be 
valuable. But since we don’t yet know what that is, lets not speculate on it. 
Let keep both values as equal importance without interdependency.


And I happen to think that if this proposal has any merit this is precisely the 
paragraph we have to keep to make sure that not every possible BART value is 
being slaved to IGP

Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Registry Algorithm a.k.a as BARM then ... Without this section we would be 
mandating that BARM is always an IGP algorithm or FA so basically it would 
mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on 
the list who are of the opinion that aligning with IGP is important.

Algorithm registry as the only option to perform a calculation making BART 
possibly pretty much useless ... Having a registry being mapped 1:1 into  
another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all 
yours. Its unfortunate that a large part of the discussion is dominated by 
perceived functionality in the form of BIER Algorithm, while there is no 
architecture draft that describes how it should work and no discussion has 
happen in any IETF meeting, which leaves us all guessing. I think Alia asked a 
very good question on the list regarding "constraints". It is not at all clear 
if BART is a Algorithm or a Constraint. I think from your response you're 
saying its both, which seems wrong IMO.. To me Alia's question is still open, 
but that that may be because I could not decipher the rest of your response.

as identity makes them both them the same thing by another name.

So, to get anywhere close to consensus let's get bit less creative maybe and 
stick to the four letters of the alphabet that the AD extended as a wide 
playing field and the WG seems to converge around ... Or otherwise stick to 
option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what 
we are doing, and that is how you can converge on a solution and reach 
consensus. That is better compared to a vote on an option and everybody walks 
away with a different interpretation of it.

Thx,

Ice.
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

>
> Future specifications may specify BART values that change the
> interpretation of the BARM octet. Those specifications must handle
> backwards
>
>
> ICE: This creates a potential dependency which I think we should avoid. I
> think there are possible use-cases where the combination of the two values
> could be valuable. But since we don’t yet know what that is, lets not
> speculate on it. Let keep both values as equal importance without
> interdependency.
>


And I happen to think that if this proposal has any merit this is precisely
the paragraph we have to keep to make sure that not every possible BART
value is being slaved to IGP Registry Algorithm a.k.a as BARM then ...
Without this section we would be mandating that BARM is always an IGP
algorithm or FA so basically it would mandate IGP Algorithm registry as the
only option to perform a calculation making BART possibly pretty much
useless ... Having a registry being mapped 1:1 into  another registry known
as identity makes them both them the same thing by another name.

So, to get anywhere close to consensus let's get bit less creative maybe
and stick to the four letters of the alphabet that the AD extended as a
wide playing field and the WG seems to converge around ... Or otherwise
stick to option F) unmodified and see who's interested in it unless you
insist on creating an option G) ...

thanks

--- tony
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Hi Jeffrey,

> When I said I prefer Option B earlier, I was actually referring to something 
> similar to what was discussed below between Eric and Arkadiy, though with 
> some differences.

ICE: Yes, I think this proposal has merit and a possible consensus for those 
who prefer to align with IGP and those who like to have BIER specific 
algorithms.

>  
> Whether we call it Option F or whatever, I have the following text prepared 
> for everyone to review and comment. Ironically, I started with the OSPF spec J
>  
> 2.1.  BIER Sub-TLV
>  
>0   1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Type | Length|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Sub-domain-ID | MT-ID |  BFR-id   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|BART   | BARM  |Reserved   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Sub-TLVs (variable)  |
>+- -+
>|   |
>  
> BART: A single-octet specifying the Bier AlgoRiThm used to calculate underlay
>   paths to reach BFERs. Values are allocated from the BIER Algorithm 
> Registry.
>  Value 0 indicates the basic Shortest Path First algorithm using IGP 
> metric.
>  
> BARM: A single-octet specifying the BIER AlgoRithm Modififer that can be used
>   to either modify, enhance or replace calculation of underlay paths to
>   reach BFERs as defined by the BART value.

ICE: In write up below its more clear on what BARM is, maybe change the name to 
make it more explicit this is the IGP Algorithm registry. Maybe call it BIER 
IGP AlgoriThm (BIAT)?

>  
> In this document version, both the BART and BARM octets MUST be zero. If an
> implementation based on this document receives a non-zero BART or BARM octet,
> it MUST treat it as an error and ignore the received BIER sub-TLV.
>  
> BART and BARM are independent of each other, and the BARM value identify
> an IGP Algorithm (either those 0~128 values registered in the “IGP Algorithm 
> Type”
> registry, or a number that identifies a Flexible Algorithm [],
> which is also considered as an IGP Algorithm.

ICE: Ok, I like that. Both values are independent of each other. This means the 
developments for both BIER Algorithm and IGP Algorithm can move forward without 
blocking each other.

>  
> Future specifications may specify BART values that change the
> interpretation of the BARM octet. Those specifications must handle backwards

ICE: This creates a potential dependency which I think we should avoid. I think 
there are possible use-cases where the combination of the two values could be 
valuable. But since we don’t yet know what that is, lets not speculate on it. 
Let keep both values as equal importance without interdependency.

> compatibility issues (or simply declare that backwards compatibility is not
> required - the deployment will then require the operator to make sure that all
> routers in the subdomain conform to the same specification).
>  
> [note that will not be added to the spec: if someone wants define a BART value
> in the future that changes the meaning of BARM, he would need
> to write a spec to explicitly state that and get the spec approved. W/o that,
> the BARM field is always interpreted as an IGP Algorithm]
>  
> 4.  IANA Considerations
>  
>   IANA is requested to set up a registry called "BIER Algorithm Registry". 
>   The registration policies for this registry are
>* "Standards Action" ([RFC5226] and [RFC7120]) for values 0-240
>* "Experimental Use" for values 240-255
>  
>The initial values in the BIER Algorithm Registry are:
>  
>0: Shortest Path First (SPF) algorithm based on IGP link metric
>1-255: Unassigned

ICE: We should probably create a registry for BIAT, and make clear in the draft 
the values are identical to the IGP Algorithm registry. In an ideal world we 
would like to point to it, but that might get the draft stuck. Or, if there are 
other ideas on how to deal with that, would be good to know...

> Comments?

I think this is good, making the two values of equal importance makes sure 
nobody is blocked on each other and we can move on.

Thanks Jeffrey,

Ice.

>  
> Jeffrey
>  
> From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Eric C Rosen
> Sent: Tuesday, February 20, 2018 2:43 PM
> To: e

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

+1 obviously ...

On Tue, Feb 20, 2018 at 10:39 AM, Alia Atlas  wrote:

> Hi Acee,
>
> Thanks for your feedback.  I appreciate and agree with the perspective.
>
> Regards,
> Alia
>
>
> On Tue, Feb 20, 2018 at 1:36 PM, Acee Lindem (acee) 
> wrote:
>
>> Hi Alia,
>> I support Peter's position on the draft. While I believe at 8 bit space
>> is more than enough to support  variations of the BIER algorithm for the
>> foreseeable future, I think reaching consensus is more critical than the
>> precise encoding.
>>
>> Thanks,
>> Acee
>>
>> On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" <
>> isis-wg-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>>
>> Hi Alia,
>>
>> 1. I see a benefit in having the BIER a way to map to any of the IGP
>> algorithms. Simply because IGPs already provide paths to all nodes in
>> the domain and BIER can simply use these paths instead of computing
>> its own.
>>
>> 2. Not sure if people plan to deploy the BIER in a model where it does
>> its own topology related computations, independent of IGPs. If they
>> do,
>> I'm not objecting that.
>>
>> The encoding of the BAR though must be done in a way that it easily
>> supports both (1) and (2).
>>
>> my 2c,
>> Peter
>>
>>
>>
>> On 19/02/18 22:51 , Alia Atlas wrote:
>> > As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
>> > draft-ietf-bier-ospf-extensions-12, I have been following the
>> discussion
>> > on the mailing list with interest.
>> >
>> > I have not seen clear consensus for any change.
>> >
>> > Let me be clear on what I see the options are from the discussion.
>> Then
>> > I'll elaborate
>> > a bit on how you can express your perspective most usefully.
>> >
>> > 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.
>> Currently,
>> > only value 0 is specified.  The drafts do not have an IANA registry
>> -
>> > with the expectation that one will be created when the first
>> additional
>> > use is clear.  It is possible that there will be objections from the
>> > IESG to progressing without an IANA registry.  Given the lack of
>> clarity
>> > for future use-cases and after discussion, I decided not to force
>> one
>> > after my AD review - but I will not push back against having a BIER
>> IANA
>> > registry if raised by others.
>> >
>> > 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
>> > current TLVs.
>> > Define an IANA registry for the BAR type.  The meaning of the
>> BAR
>> > sub-type derives
>> > from the BAR type.   We can debate over the registration policy
>> for
>> > the BAR type.
>> >
>> > 3) Option C: Change the BAR field to be 16 bits and define an IANA
>> > registry.  Part of the range can be FCFS with Expert Review, part
>> can be
>> > Specification Required, and part can be IETF Consensus.
>> >
>> > 4) Option D: At some point in the future, if there is an actual
>> > understood and documented need, a BAR sub-type could be added a
>> > sub-TLV.  The length of the BAR sub-type could be determined when
>> the
>> > sub-TLV is defined.
>> >
>> > Given
>> >
>> >a) option D exists
>> >b) there is currently only one defined value for BAR
>> >c) I do not see strong consensus for change to one particular
>> other
>> > option
>> >
>> > I see no current reason for a change and I certainly see absolutely
>> no
>> > reason for
>> > a delay in progressing the documents.
>> >
>> > I do want to be clear about what the WG wants to do on this issue.
>> > Therefore, here is
>> > my following request.
>> >
>> > Please send your feedback to the mailing list as follows:
>> >
>> > IF you prefer or can accept the current status, please say so.  No
>> more
>> > justification
>> > or reasoning is required. I just don't want the bulk of folks who
>> are
>> > content to be
>> > overlooked by those suggesting change.
>> >
>> > IF you prefer or can accept the current status, but think there
>> should
>> > be an IANA registry
>> > as is usual for managing code-points, please say so.  No more
>> > justification is needed.
>> >
>> > IF you prefer Option B, C, and/or D, please say so with your
>> > explanation.  More technical depth than "'we might need it" would be
>> > helpful; the availability of sub-TLVs already
>> > provides future proofing.
>> >
>> > IF you have a clear technical objection to why the Current Status
>> is not
>> > acceptable,
>> > please express that - with clear details.
>> >
>> > IF you feel that additional code-points should be allocated in a BAR
>> > IANA Registry or
>> > have thoughts on the appropriate policy, please say so with your
>> > explanation for what

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Hi Acee,

Thanks for your feedback.  I appreciate and agree with the perspective.

Regards,
Alia


On Tue, Feb 20, 2018 at 1:36 PM, Acee Lindem (acee)  wrote:

> Hi Alia,
> I support Peter's position on the draft. While I believe at 8 bit space is
> more than enough to support  variations of the BIER algorithm for the
> foreseeable future, I think reaching consensus is more critical than the
> precise encoding.
>
> Thanks,
> Acee
>
> On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" <
> isis-wg-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>
> Hi Alia,
>
> 1. I see a benefit in having the BIER a way to map to any of the IGP
> algorithms. Simply because IGPs already provide paths to all nodes in
> the domain and BIER can simply use these paths instead of computing
> its own.
>
> 2. Not sure if people plan to deploy the BIER in a model where it does
> its own topology related computations, independent of IGPs. If they do,
> I'm not objecting that.
>
> The encoding of the BAR though must be done in a way that it easily
> supports both (1) and (2).
>
> my 2c,
> Peter
>
>
>
> On 19/02/18 22:51 , Alia Atlas wrote:
> > As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
> > draft-ietf-bier-ospf-extensions-12, I have been following the
> discussion
> > on the mailing list with interest.
> >
> > I have not seen clear consensus for any change.
> >
> > Let me be clear on what I see the options are from the discussion.
> Then
> > I'll elaborate
> > a bit on how you can express your perspective most usefully.
> >
> > 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
> > only value 0 is specified.  The drafts do not have an IANA registry -
> > with the expectation that one will be created when the first
> additional
> > use is clear.  It is possible that there will be objections from the
> > IESG to progressing without an IANA registry.  Given the lack of
> clarity
> > for future use-cases and after discussion, I decided not to force one
> > after my AD review - but I will not push back against having a BIER
> IANA
> > registry if raised by others.
> >
> > 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
> > current TLVs.
> > Define an IANA registry for the BAR type.  The meaning of the BAR
> > sub-type derives
> > from the BAR type.   We can debate over the registration policy
> for
> > the BAR type.
> >
> > 3) Option C: Change the BAR field to be 16 bits and define an IANA
> > registry.  Part of the range can be FCFS with Expert Review, part
> can be
> > Specification Required, and part can be IETF Consensus.
> >
> > 4) Option D: At some point in the future, if there is an actual
> > understood and documented need, a BAR sub-type could be added a
> > sub-TLV.  The length of the BAR sub-type could be determined when the
> > sub-TLV is defined.
> >
> > Given
> >
> >a) option D exists
> >b) there is currently only one defined value for BAR
> >c) I do not see strong consensus for change to one particular
> other
> > option
> >
> > I see no current reason for a change and I certainly see absolutely
> no
> > reason for
> > a delay in progressing the documents.
> >
> > I do want to be clear about what the WG wants to do on this issue.
> > Therefore, here is
> > my following request.
> >
> > Please send your feedback to the mailing list as follows:
> >
> > IF you prefer or can accept the current status, please say so.  No
> more
> > justification
> > or reasoning is required. I just don't want the bulk of folks who are
> > content to be
> > overlooked by those suggesting change.
> >
> > IF you prefer or can accept the current status, but think there
> should
> > be an IANA registry
> > as is usual for managing code-points, please say so.  No more
> > justification is needed.
> >
> > IF you prefer Option B, C, and/or D, please say so with your
> > explanation.  More technical depth than "'we might need it" would be
> > helpful; the availability of sub-TLVs already
> > provides future proofing.
> >
> > IF you have a clear technical objection to why the Current Status is
> not
> > acceptable,
> > please express that - with clear details.
> >
> > IF you feel that additional code-points should be allocated in a BAR
> > IANA Registry or
> > have thoughts on the appropriate policy, please say so with your
> > explanation for what
> > those should be.
> >
> > Unless I see clear and strong consensus for something other than the
> > Current Status,
> > that will remain.
> >
> > IF there is clear and strong consensus for Option B, C, or D, or
> 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

On Tue, Feb 20, 2018 at 9:56 AM,  wrote:

> Alia,
>


> ...
>
> It sort of Option-B but allow more independence between BAR(BUAM) from IGP
> Algo, which personally attracts me since one cannot screw up another one
> and at the same time complement each other as part of constraints only.  It
> might lock thing out for future development but it might bring stability.
>
> But regardless, we need to understand which use cases we are trying to
> cover and how the proposed option-B will apply.  I would reiterate your
> request for specific recommendation for the draft from folks that recommend
> option B.
>
>
Arkadiy, such a text was extended as strawman in consensus building process
and I include it here on your request. Observe that this represents no
consensus, just further input into building consensus on this list from my
personal side so you have more "meat" to see what we're talking about ...

--- tony


StrawManBART.rtf
Description: RTF file
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Acee Lindem (acee)]

Hi Alia, 
I support Peter's position on the draft. While I believe at 8 bit space is more 
than enough to support  variations of the BIER algorithm for the foreseeable 
future, I think reaching consensus is more critical than the precise encoding. 

Thanks,
Acee

On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" 
 wrote:

Hi Alia,

1. I see a benefit in having the BIER a way to map to any of the IGP 
algorithms. Simply because IGPs already provide paths to all nodes in 
the domain and BIER can simply use these paths instead of computing its own.

2. Not sure if people plan to deploy the BIER in a model where it does 
its own topology related computations, independent of IGPs. If they do, 
I'm not objecting that.

The encoding of the BAR though must be done in a way that it easily 
supports both (1) and (2).

my 2c,
Peter



On 19/02/18 22:51 , Alia Atlas wrote:
> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
> draft-ietf-bier-ospf-extensions-12, I have been following the discussion
> on the mailing list with interest.
>
> I have not seen clear consensus for any change.
>
> Let me be clear on what I see the options are from the discussion.  Then
> I'll elaborate
> a bit on how you can express your perspective most usefully.
>
> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
> only value 0 is specified.  The drafts do not have an IANA registry -
> with the expectation that one will be created when the first additional
> use is clear.  It is possible that there will be objections from the
> IESG to progressing without an IANA registry.  Given the lack of clarity
> for future use-cases and after discussion, I decided not to force one
> after my AD review - but I will not push back against having a BIER IANA
> registry if raised by others.
>
> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
> current TLVs.
> Define an IANA registry for the BAR type.  The meaning of the BAR
> sub-type derives
> from the BAR type.   We can debate over the registration policy for
> the BAR type.
>
> 3) Option C: Change the BAR field to be 16 bits and define an IANA
> registry.  Part of the range can be FCFS with Expert Review, part can be
> Specification Required, and part can be IETF Consensus.
>
> 4) Option D: At some point in the future, if there is an actual
> understood and documented need, a BAR sub-type could be added a
> sub-TLV.  The length of the BAR sub-type could be determined when the
> sub-TLV is defined.
>
> Given
>
>a) option D exists
>b) there is currently only one defined value for BAR
>c) I do not see strong consensus for change to one particular other
> option
>
> I see no current reason for a change and I certainly see absolutely no
> reason for
> a delay in progressing the documents.
>
> I do want to be clear about what the WG wants to do on this issue.
> Therefore, here is
> my following request.
>
> Please send your feedback to the mailing list as follows:
>
> IF you prefer or can accept the current status, please say so.  No more
> justification
> or reasoning is required. I just don't want the bulk of folks who are
> content to be
> overlooked by those suggesting change.
>
> IF you prefer or can accept the current status, but think there should
> be an IANA registry
> as is usual for managing code-points, please say so.  No more
> justification is needed.
>
> IF you prefer Option B, C, and/or D, please say so with your
> explanation.  More technical depth than "'we might need it" would be
> helpful; the availability of sub-TLVs already
> provides future proofing.
>
> IF you have a clear technical objection to why the Current Status is not
> acceptable,
> please express that - with clear details.
>
> IF you feel that additional code-points should be allocated in a BAR
> IANA Registry or
> have thoughts on the appropriate policy, please say so with your
> explanation for what
> those should be.
>
> Unless I see clear and strong consensus for something other than the
> Current Status,
> that will remain.
>
> IF there is clear and strong consensus for Option B, C, or D, or adding
> an IANA registry with particular values, then it will be possible to
> have a change up through this Weds night - with a 1 week WGLC on that
> particular technical change.
>
> My priority is to have the base BIER specifications published as
> Proposed Standards so that more BIER implementations and deployment can
> be done.  I would like the WG to 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

On Tue, Feb 20, 2018 at 10:25 AM, IJsbrand Wijnands  wrote:

> Tony,
>
> > Now, what BAR registry would give us is a "layering of constraints" if
> you want, i.e.  BAR=1 (since this is a very tanglible example, another one
> would be max. degree of fanout or things like max-label-depth e.g.)  would
> take care of the BIER specific constraints without IGP knowing about it in
> architectural terms.  On top of that IGP applies its constraints (BW,
> delay, whatever) but it's really not  BIER problem, we are just happy
> riders on coattails of the hard IGP work ;-)
>
> If you want to build a table for BIER, you need to have a way to
> associate/signal the different constraints that need to be used. In my
> mind, this is not coming from the IGP, but needs to be signalled in the
> context BIER. Like how you signal BIER-ONLY as algorithm. Or, statically
> configured as part of the Sub-Domain. Obviously what is required here is a
> architecture draft that explains how this all should work.
>

yes, staticially configured BIER computaton constraints could work but then
routers cannot detect mismatch. A very heavy disadvantage ...

Architecture is something we can talk in London if you see value in that,
sure. For the record, I however vastly prefered the direction (mainly)
you/Eric gave from start on which was "enough architecture to get important
first application done", hence I was never pushing some some grand
cathedral building scheme. Maybe after this is in place we should have this
in London, it's the call of the day one core group that carried the banner
where there was nothing but first hill to take ;-)

My suggestion is, let us work out either option B) or Eric's proposal as
flexible and orthogonal scheme to ground the IGPs and then fall out the
rest over it ...  As you observed, I'm big believer in maybe overbuilding a
tad in flexibility or size in control plane to have architectural wiggle
room while in forwarding path one has to be extremely frugal to get the
silicon @ cost ...


>
> >
> > To address the "efficienty" constraint one has to be very deeply steeped
> into IGP SPF computations but the result is that an implementation can
> easily incorporate constraints of all layers into a single computation (SPF
> practically speaking) unless they lead to NP complete combinations (so
> .e.g. having something that is max-bw @ guaranteed delay is far from
> simple) ...
> >
> > So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm
> building one ;-)  and we do not want to shake their whole IGP standard
> saying "hey, you know, we have this BIER Stuff you must encode on your IGP
> elements (beside us being a subTLV) and put in your registries to do the
> right thing", if we have BAR we can just tell them, ok, encoding wise, jsut
> give us your SPF-on-steroids registry and we use that as subtype,
> underneath that we plug in BAR in our encoding, i.e. we just use them as
> signalling channel while constraining the SPF. We're done.  Obviously the
> SPF has to be modified to respect the union of all constraints but the
> alternative is worse, i.e. I have to be running multiple passes prunning
> things (which are practically far less desirable since we are loosing very
> cool stuff like LFA which I'm sure we could solve as well but get for free
> if we just prune the SPF @ runtime)
> >
> > I do hope that parses and I  make sense. I tried to be as terse as I
> managed and I know I am bad at that …
>
> You lost me, sorry…
>

sorry, email is limited ... Not sure how to deal with that ...

--- tony
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Tony,

> Now, what BAR registry would give us is a "layering of constraints" if you 
> want, i.e.  BAR=1 (since this is a very tanglible example, another one would 
> be max. degree of fanout or things like max-label-depth e.g.)  would take 
> care of the BIER specific constraints without IGP knowing about it in 
> architectural terms.  On top of that IGP applies its constraints (BW, delay, 
> whatever) but it's really not  BIER problem, we are just happy riders on 
> coattails of the hard IGP work ;-) 

If you want to build a table for BIER, you need to have a way to 
associate/signal the different constraints that need to be used. In my mind, 
this is not coming from the IGP, but needs to be signalled in the context BIER. 
Like how you signal BIER-ONLY as algorithm. Or, statically configured as part 
of the Sub-Domain. Obviously what is required here is a architecture draft that 
explains how this all should work.

> 
> To address the "efficienty" constraint one has to be very deeply steeped into 
> IGP SPF computations but the result is that an implementation can easily 
> incorporate constraints of all layers into a single computation (SPF 
> practically speaking) unless they lead to NP complete combinations (so .e.g. 
> having something that is max-bw @ guaranteed delay is far from simple) ... 
> 
> So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm 
> building one ;-)  and we do not want to shake their whole IGP standard saying 
> "hey, you know, we have this BIER Stuff you must encode on your IGP elements 
> (beside us being a subTLV) and put in your registries to do the right thing", 
> if we have BAR we can just tell them, ok, encoding wise, jsut give us your 
> SPF-on-steroids registry and we use that as subtype, underneath that we plug 
> in BAR in our encoding, i.e. we just use them as signalling channel while 
> constraining the SPF. We're done.  Obviously the SPF has to be modified to 
> respect the union of all constraints but the alternative is worse, i.e. I 
> have to be running multiple passes prunning things (which are practically far 
> less desirable since we are loosing very cool stuff like LFA which I'm sure 
> we could solve as well but get for free if we just prune the SPF @ runtime) 
> 
> I do hope that parses and I  make sense. I tried to be as terse as I managed 
> and I know I am bad at that … 

You lost me, sorry…

Thx,

Ice.

> 
> Now, whether you believe that IGP signalling must be used for IGP dictated 
> unicast computations only and IGP must be aware of BIER elements in its 
> registries/encoding is a matter of taste to a degree (architecture of 
> protocols is as much craft as art) but as to technial advantages of that I 
> see none while I see unnecessary coupling ...
> 
> --- tony 
> 


___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

>
> BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint
> or even an IGP registry value, this is a unicast computation
> BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP
> metric or constraint specification, this is a unicast computation
> BAR = X (some unicast computation type)  same as 0/1
>
> BAR = Y (multicast specific computation that IGP cnanot perform), subtype
> can be anything
>
> What is important to observe that SPF with additional constraints is as
> efficient as SPF without those constraints (as long we're talking certain
> convex properties AFAIR but I don't want to bore anyone with math, most of
> the stuff we use today like max. BW, min. delay has this property).
>
>
> My first observation is that what is documented here as “BIER Algorithm
> Registry” is not an Algorithm, but a constraint. Suppose you want to build
> a topology with {BIER-ONLY, LOWEST-DELAY, BW}. From an architecture POV,
> any combination should be allowed. Would you propose to create BAR values
> to capture every possible combination? I don’t think that scales very well.
> Constraints would be better served with a BitMask IMO.
>
>
Ice, I assume we talk the unicast computation case. Let's discuss that in
architectural terms that easily map down to the case on hand IMO:

When faced with a combinatorial problem that you mention (often caused by
coupling of many things to each other) a good approach is layering (or
think about it as indirection), i.e. the layers become decoupled and can be
developed/progressed independently. Problem with decoupling is that it
often is inefficient (indirections).

Now, what BAR registry would give us is a "layering of constraints" if you
want, i.e.  BAR=1 (since this is a very tanglible example, another one
would be max. degree of fanout or things like max-label-depth e.g.)  would
take care of the BIER specific constraints without IGP knowing about it in
architectural terms.  On top of that IGP applies its constraints (BW,
delay, whatever) but it's really not  BIER problem, we are just happy
riders on coattails of the hard IGP work ;-)

To address the "efficienty" constraint one has to be very deeply steeped
into IGP SPF computations but the result is that an implementation can
easily incorporate constraints of all layers into a single computation (SPF
practically speaking) unless they lead to NP complete combinations (so
.e.g. having something that is max-bw @ guaranteed delay is far from
simple) ...

So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm
building one ;-)  and we do not want to shake their whole IGP standard
saying "hey, you know, we have this BIER Stuff you must encode on your IGP
elements (beside us being a subTLV) and put in your registries to do the
right thing", if we have BAR we can just tell them, ok, encoding wise, jsut
give us your SPF-on-steroids registry and we use that as subtype,
underneath that we plug in BAR in our encoding, i.e. we just use them as
signalling channel while constraining the SPF. We're done.  Obviously the
SPF has to be modified to respect the union of all constraints but the
alternative is worse, i.e. I have to be running multiple passes prunning
things (which are practically far less desirable since we are loosing very
cool stuff like LFA which I'm sure we could solve as well but get for free
if we just prune the SPF @ runtime)

I do hope that parses and I  make sense. I tried to be as terse as I
managed and I know I am bad at that ...

Now, whether you believe that IGP signalling must be used for IGP dictated
unicast computations only and IGP must be aware of BIER elements in its
registries/encoding is a matter of taste to a degree (architecture of
protocols is as much craft as art) but as to technial advantages of that I
see none while I see unnecessary coupling ...

--- tony
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[arkadiy.gulko]

proposed options since I saw a lot of 
support for it on the WG.
It sort of Option-B but allow more independence between BAR(BUAM) from IGP 
Algo, which personally attracts me since one cannot screw up another one and at 
the same time complement each other as part of constraints only.  It might lock 
thing out for future development but it might bring stability.
But regardless, we need to understand which use cases we are trying to cover 
and how the proposed option-B will apply.  I would reiterate your request for 
specific recommendation for the draft from folks that recommend option B.
Thanks
Arkadiy


From: BIER <bier-boun...@ietf.org> on behalf of Alia Atlas <akat...@gmail.com>
Date: Tuesday, February 20, 2018 at 12:03 PM
To: BIER WG <b...@ietf.org>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

Thanks for the feedback.

There is one additional aspect here that I think needs further clarification 
and discussion.

In the current proposed charter, the first work-item says "Operation of BIER in
non-congruent topologies, i.e. topologies where not all routers are BIER capable
can also be addressed."

The newly posted individual draft-zzhang-bier-algorithm-00 suggests having an 
algorithm
which is doing an SPF after removing from the topology any non-BIER capable
routers.  This is an example of a BIER-specific constraint.

The individual flex-algo drafts also support adding constraints (similar to the 
familiar
constraints from RSVP-TE).

I believe that the need for BIER-specific constraints is one factor driving the 
requirement
for a BAR that is specified by the BIER WG.

From an architectural view, the idea of having the IGP/routing layer have to 
understand
BIER specifics seems an undesirable coupling.

Could someone walk me through how this would be supported in each of the 
different options?

For Option D, where there is a sub-TLV and that sub-TLV can supply the 
additional non-BIER
constraints, I understand it.

For Option B - which some folks are preferring, I do not see understand how it 
would work.
For Option A, I do not understand how it would work.

Obviously, this is going far out on a design limb - where flex-algo does not 
yet have any IETF
support or adoption, but since it is clear that people's perspectives are being 
strongly influenced
by what that might morph into, I think this is important for the whole WG to 
understand.

Regards,
Alia




On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda 
<tonysi...@gmail.com<mailto:tonysi...@gmail.com>> wrote:
all the implementations I am aware off can adjust to Option A) with BAR 
registry without problems, neither do I see a problem with option B) given we 
are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony

On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>> wrote:
I have one additional question for those with implementations or testing them.

What is the impact of going with your preferred option in terms of 
interoperability?  It may be early enough that changes can happen, but more 
feedback is needed.

For those favoring Option B, could you send email to the list providing exact 
text so we have the details?

For those favoring the current status without an IANA registry, are you able to 
handle one being imposed during IESG Review?  It is an obvious concern to 
raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka



On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" 
<senthil.dhana...@huawei.com<mailto:senthil.dhana...@huawei.com>> wrote:
+1 to Option-B
Seems future proof to me.

Thanks,
Senthil



From: BIER [mailto:bier-boun...@ietf.org<mailto:bier-boun...@ietf.org>] On 
Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG <b...@ietf.org<mailto:b...@ietf.org>>; 
isis-wg@ietf.org<mailto:isis-wg@ietf.org> list 
<isis-wg@ietf.org<mailto:isis-wg@ietf.org>>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the 
mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then I'll 
elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
value 0 is specified.  The drafts do not have an IANA registry - with the 
expectation that one will be created when the first additional use is clear.  
It is possible that there will be objections from the IESG to progressing 
without an IANA registry.  Given the lack of clarity for future use-cases and 
after discussion, I dec

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

On Tue, Feb 20, 2018 at 9:27 AM, Peter Psenak  wrote:

> Hi Alia,
>
> 1. I see a benefit in having the BIER a way to map to any of the IGP
> algorithms. Simply because IGPs already provide paths to all nodes in the
> domain and BIER can simply use these paths instead of computing its own.
>

+1

Things like BAR 0/1 are clearly unicast computations (SPFs basically given
we're on link-state), many other BARs may be. We have to fully provide for
extended metrics and future constraints like FlexAlgo to make sure that
advanced unicast computations are possible on top of any BIER-specific
computation. This will be choice for many for years to come & the workhorse
of BIER for now.  BIER without IGPs lending its topology
distribution/signalling & first computation help would have not be an easy
thing to introduce.  All kudos to people who had the practical wisdom to go
down that path.


>
> 2. Not sure if people plan to deploy the BIER in a model where it does its
> own topology related computations, independent of IGPs. If they do, I'm not
> objecting that.
>

Discussions came up, not only about specific computations but also about
things where IGP is just signalling and something else completely is doing
computation and it only needs to have all nodes signal that they are using
this off-line computation. Do please read the bier-algorithm draft for
first cases discussed with people seriously interested in deployments.
Yes, we could tell them that IGP is not a viable signalling then and ask
them e.g. to use PCEP to install BIFTs into routers (and some may like this
total control) but that limits the appeal of BIER significantly since we
now do not provide several very important architectural pieces (topology
distribution and simple signalling) or rather would make both inseparable
for no technical beneficial reason I can discern ...


>
> The encoding of the BAR though must be done in a way that it easily
> supports both (1) and (2).
>

+1

thanks Peter

--- tony


>
> my 2c,
> Peter
>
>
>
>
> On 19/02/18 22:51 , Alia Atlas wrote:
>
>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
>> draft-ietf-bier-ospf-extensions-12, I have been following the discussion
>> on the mailing list with interest.
>>
>> I have not seen clear consensus for any change.
>>
>> Let me be clear on what I see the options are from the discussion.  Then
>> I'll elaborate
>> a bit on how you can express your perspective most usefully.
>>
>> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
>> only value 0 is specified.  The drafts do not have an IANA registry -
>> with the expectation that one will be created when the first additional
>> use is clear.  It is possible that there will be objections from the
>> IESG to progressing without an IANA registry.  Given the lack of clarity
>> for future use-cases and after discussion, I decided not to force one
>> after my AD review - but I will not push back against having a BIER IANA
>> registry if raised by others.
>>
>> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
>> current TLVs.
>> Define an IANA registry for the BAR type.  The meaning of the BAR
>> sub-type derives
>> from the BAR type.   We can debate over the registration policy for
>> the BAR type.
>>
>> 3) Option C: Change the BAR field to be 16 bits and define an IANA
>> registry.  Part of the range can be FCFS with Expert Review, part can be
>> Specification Required, and part can be IETF Consensus.
>>
>> 4) Option D: At some point in the future, if there is an actual
>> understood and documented need, a BAR sub-type could be added a
>> sub-TLV.  The length of the BAR sub-type could be determined when the
>> sub-TLV is defined.
>>
>> Given
>>
>>a) option D exists
>>b) there is currently only one defined value for BAR
>>c) I do not see strong consensus for change to one particular other
>> option
>>
>> I see no current reason for a change and I certainly see absolutely no
>> reason for
>> a delay in progressing the documents.
>>
>> I do want to be clear about what the WG wants to do on this issue.
>> Therefore, here is
>> my following request.
>>
>> Please send your feedback to the mailing list as follows:
>>
>> IF you prefer or can accept the current status, please say so.  No more
>> justification
>> or reasoning is required. I just don't want the bulk of folks who are
>> content to be
>> overlooked by those suggesting change.
>>
>> IF you prefer or can accept the current status, but think there should
>> be an IANA registry
>> as is usual for managing code-points, please say so.  No more
>> justification is needed.
>>
>> IF you prefer Option B, C, and/or D, please say so with your
>> explanation.  More technical depth than "'we might need it" would be
>> helpful; the availability of sub-TLVs already
>> provides future proofing.
>>
>> IF you have a clear technical objection to why the Current Status is not
>> acceptable,
>> please express that 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Peter Psenak]

Hi Alia,

1. I see a benefit in having the BIER a way to map to any of the IGP 
algorithms. Simply because IGPs already provide paths to all nodes in 
the domain and BIER can simply use these paths instead of computing its own.


2. Not sure if people plan to deploy the BIER in a model where it does 
its own topology related computations, independent of IGPs. If they do, 
I'm not objecting that.


The encoding of the BAR though must be done in a way that it easily 
supports both (1) and (2).


my 2c,
Peter



On 19/02/18 22:51 , Alia Atlas wrote:

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
draft-ietf-bier-ospf-extensions-12, I have been following the discussion
on the mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then
I'll elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
only value 0 is specified.  The drafts do not have an IANA registry -
with the expectation that one will be created when the first additional
use is clear.  It is possible that there will be objections from the
IESG to progressing without an IANA registry.  Given the lack of clarity
for future use-cases and after discussion, I decided not to force one
after my AD review - but I will not push back against having a BIER IANA
registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
current TLVs.
Define an IANA registry for the BAR type.  The meaning of the BAR
sub-type derives
from the BAR type.   We can debate over the registration policy for
the BAR type.

3) Option C: Change the BAR field to be 16 bits and define an IANA
registry.  Part of the range can be FCFS with Expert Review, part can be
Specification Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual
understood and documented need, a BAR sub-type could be added a
sub-TLV.  The length of the BAR sub-type could be determined when the
sub-TLV is defined.

Given

   a) option D exists
   b) there is currently only one defined value for BAR
   c) I do not see strong consensus for change to one particular other
option

I see no current reason for a change and I certainly see absolutely no
reason for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.
Therefore, here is
my following request.

Please send your feedback to the mailing list as follows:

IF you prefer or can accept the current status, please say so.  No more
justification
or reasoning is required. I just don't want the bulk of folks who are
content to be
overlooked by those suggesting change.

IF you prefer or can accept the current status, but think there should
be an IANA registry
as is usual for managing code-points, please say so.  No more
justification is needed.

IF you prefer Option B, C, and/or D, please say so with your
explanation.  More technical depth than "'we might need it" would be
helpful; the availability of sub-TLVs already
provides future proofing.

IF you have a clear technical objection to why the Current Status is not
acceptable,
please express that - with clear details.

IF you feel that additional code-points should be allocated in a BAR
IANA Registry or
have thoughts on the appropriate policy, please say so with your
explanation for what
those should be.

Unless I see clear and strong consensus for something other than the
Current Status,
that will remain.

IF there is clear and strong consensus for Option B, C, or D, or adding
an IANA registry with particular values, then it will be possible to
have a change up through this Weds night - with a 1 week WGLC on that
particular technical change.

My priority is to have the base BIER specifications published as
Proposed Standards so that more BIER implementations and deployment can
be done.  I would like the WG to wrap up the core work (as expressed in
the proposed recharter) so that you all can look
at how to use it.

Given this topic was raised last Weds and given that there are no
technical objections raised to the documents as are, there isn't much
time - so please just respond to this email ASAP.  My deadline for a
decision is 6pm EST on Weds.

Regards,
Alia



___
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

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

>
> From an architectural view, the idea of having the IGP/routing layer have
> to understand
> BIER specifics seems an undesirable coupling.
>

very much so, in stark terms one could say that IGP is BIER signalling
while the fact that we use SPF to perform BIER nexthop calculations is a
convenient first artifact. The architecture RFC does not separate that
clearly IMO but is rather an "example" of practical BIER architecture
embodiment ;-) I do absolutely prefer it that way from practical
standpoint, abstract architectures with all degrees of flexibility written
first are hard to understand and slow to build. BIER delivered on a real
problem but after this first delivery needs the flexibility to spread its
wings into fields where IGP unicast may not be enough IMO and in any case,
IGP unicast computation coupling to BIER specific elements is unnecessary
and undesirable unless one believes e'thing is better off centralized. It
would be _highly_ unfortunate and immense waste of resources if we ended up
building another signalling just so we can perform non unicast IGP
computations.

Could someone walk me through how this would be supported in each of the
> different options?
>
> For Option D, where there is a sub-TLV and that sub-TLV can supply the
> additional non-BIER
> constraints, I understand it.
>
> For Option B - which some folks are preferring, I do not see understand
> how it would work.
>

BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint or
even an IGP registry value, this is a unicast computation
BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP
metric or constraint specification, this is a unicast computation
BAR = X (some unicast computation type)  same as 0/1

BAR = Y (multicast specific computation that IGP cnanot perform), subtype
can be anything

What is important to observe that SPF with additional constraints is as
efficient as SPF without those constraints (as long we're talking certain
convex properties AFAIR but I don't want to bore anyone with math, most of
the stuff we use today like max. BW, min. delay has this property).



> For Option A, I do not understand how it would work.
>

replace subtype with a sub-TLV so it's basically option D). I explained in
my +1/+2 my reasoning why option B) is more preferrable if you are
concerned about backwards compatibility but it's nothing architecturally
important. IGPs were muddling for years without clear distinction between
mandatory/optional TLVs are IDR has and we lived to tell the tale ;-) ...


>
> Obviously, this is going far out on a design limb - where flex-algo does
> not yet have any IETF
> support or adoption, but since it is clear that people's perspectives are
> being strongly influenced
> by what that might morph into, I think this is important for the whole WG
> to understand.
>
>
 AFAIU we have BIER RFCs that form a solid foundation to deliver now.
Things to be done in the future can obviously morph into many directions
and claim to cover any problem presented to them without much risk ...

thanks

--- tony
___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Thanks for the feedback.

There is one additional aspect here that I think needs further
clarification and discussion.

In the current proposed charter, the first work-item says "Operation of
BIER in
non-congruent topologies, i.e. topologies where not all routers are BIER
capable
can also be addressed."

The newly posted individual draft-zzhang-bier-algorithm-00 suggests having
an algorithm
which is doing an SPF after removing from the topology any non-BIER capable
routers.  This is an example of a BIER-specific constraint.

The individual flex-algo drafts also support adding constraints (similar to
the familiar
constraints from RSVP-TE).

I believe that the need for BIER-specific constraints is one factor driving
the requirement
for a BAR that is specified by the BIER WG.

>From an architectural view, the idea of having the IGP/routing layer have
to understand
BIER specifics seems an undesirable coupling.

Could someone walk me through how this would be supported in each of the
different options?

For Option D, where there is a sub-TLV and that sub-TLV can supply the
additional non-BIER
constraints, I understand it.

For Option B - which some folks are preferring, I do not see understand how
it would work.
For Option A, I do not understand how it would work.

Obviously, this is going far out on a design limb - where flex-algo does
not yet have any IETF
support or adoption, but since it is clear that people's perspectives are
being strongly influenced
by what that might morph into, I think this is important for the whole WG
to understand.

Regards,
Alia




On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda 
wrote:

> all the implementations I am aware off can adjust to Option A) with BAR
> registry without problems, neither do I see a problem with option B) given
> we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony
>
> On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas  wrote:
>
>> I have one additional question for those with implementations or testing
>> them.
>>
>> What is the impact of going with your preferred option in terms of
>> interoperability?  It may be early enough that changes can happen, but more
>> feedback is needed.
>>
>> For those favoring Option B, could you send email to the list providing
>> exact text so we have the details?
>>
>> For those favoring the current status without an IANA registry, are you
>> able to handle one being imposed during IESG Review?  It is an obvious
>> concern to raise.  Are you just prolonging or postponing the discussion?
>>
>> Regards,
>> Aka
>>
>>
>>
>> On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" 
>> wrote:
>>
>>> +1 to Option-B
>>>
>>> Seems future proof to me.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Senthil
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Alia Atlas
>>> *Sent:* 20 February 2018 03:21
>>> *To:* BIER WG ; isis-wg@ietf.org list 
>>> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions
>>> and draft-ietf-bier-ospf-extensions
>>>
>>>
>>>
>>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
>>> draft-ietf-bier-ospf-extensions-12, I have been following the
>>> discussion on the mailing list with interest.
>>>
>>>
>>>
>>> I have not seen clear consensus for any change.
>>>
>>>
>>>
>>> Let me be clear on what I see the options are from the discussion.  Then
>>> I'll elaborate
>>>
>>> a bit on how you can express your perspective most usefully.
>>>
>>>
>>>
>>> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
>>> only value 0 is specified.  The drafts do not have an IANA registry - with
>>> the expectation that one will be created when the first additional use is
>>> clear.  It is possible that there will be objections from the IESG to
>>> progressing without an IANA registry.  Given the lack of clarity for future
>>> use-cases and after discussion, I decided not to force one after my AD
>>> review - but I will not push back against having a BIER IANA registry if
>>> raised by others.
>>>
>>>
>>>
>>> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
>>> current TLVs.
>>>
>>>Define an IANA registry for the BAR type.  The meaning of the BAR
>>> sub-type derives
>>>
>>>from the BAR type.   We can debate over the registration policy for
>>> the BAR type.
>>>
>>>
>>>
>>> 3) Option C: Change the BAR field to be 16 bits and define an IANA
>>> registry.  Part of the range can be FCFS with Expert Review, part can be
>>> Specification Required, and part can be IETF Consensus.
>>>
>>>
>>>
>>> 4) Option D: At some point in the future, if there is an actual
>>> understood and documented need, a BAR sub-type could be added a sub-TLV.
>>> The length of the BAR sub-type could be determined when the sub-TLV is
>>> defined.
>>>
>>>
>>>
>>> Given
>>>
>>>
>>>
>>>   a) option D exists
>>>
>>>   b) there is currently only one defined value 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Tony Przygienda]

all the implementations I am aware off can adjust to Option A) with BAR
registry without problems, neither do I see a problem with option B) given
we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony

On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas  wrote:

> I have one additional question for those with implementations or testing
> them.
>
> What is the impact of going with your preferred option in terms of
> interoperability?  It may be early enough that changes can happen, but more
> feedback is needed.
>
> For those favoring Option B, could you send email to the list providing
> exact text so we have the details?
>
> For those favoring the current status without an IANA registry, are you
> able to handle one being imposed during IESG Review?  It is an obvious
> concern to raise.  Are you just prolonging or postponing the discussion?
>
> Regards,
> Aka
>
>
>
> On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" 
> wrote:
>
>> +1 to Option-B
>>
>> Seems future proof to me.
>>
>>
>>
>> Thanks,
>>
>> Senthil
>>
>>
>>
>>
>>
>>
>>
>> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Alia Atlas
>> *Sent:* 20 February 2018 03:21
>> *To:* BIER WG ; isis-wg@ietf.org list 
>> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions
>> and draft-ietf-bier-ospf-extensions
>>
>>
>>
>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
>> draft-ietf-bier-ospf-extensions-12, I have been following the discussion
>> on the mailing list with interest.
>>
>>
>>
>> I have not seen clear consensus for any change.
>>
>>
>>
>> Let me be clear on what I see the options are from the discussion.  Then
>> I'll elaborate
>>
>> a bit on how you can express your perspective most usefully.
>>
>>
>>
>> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
>> only value 0 is specified.  The drafts do not have an IANA registry - with
>> the expectation that one will be created when the first additional use is
>> clear.  It is possible that there will be objections from the IESG to
>> progressing without an IANA registry.  Given the lack of clarity for future
>> use-cases and after discussion, I decided not to force one after my AD
>> review - but I will not push back against having a BIER IANA registry if
>> raised by others.
>>
>>
>>
>> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
>> current TLVs.
>>
>>Define an IANA registry for the BAR type.  The meaning of the BAR
>> sub-type derives
>>
>>from the BAR type.   We can debate over the registration policy for
>> the BAR type.
>>
>>
>>
>> 3) Option C: Change the BAR field to be 16 bits and define an IANA
>> registry.  Part of the range can be FCFS with Expert Review, part can be
>> Specification Required, and part can be IETF Consensus.
>>
>>
>>
>> 4) Option D: At some point in the future, if there is an actual
>> understood and documented need, a BAR sub-type could be added a sub-TLV.
>> The length of the BAR sub-type could be determined when the sub-TLV is
>> defined.
>>
>>
>>
>> Given
>>
>>
>>
>>   a) option D exists
>>
>>   b) there is currently only one defined value for BAR
>>
>>   c) I do not see strong consensus for change to one particular other
>> option
>>
>>
>>
>> I see no current reason for a change and I certainly see absolutely no
>> reason for
>>
>> a delay in progressing the documents.
>>
>>
>>
>> I do want to be clear about what the WG wants to do on this issue.
>> Therefore, here is
>>
>> my following request.
>>
>>
>>
>> Please send your feedback to the mailing list as follows:
>>
>>
>>
>> IF you prefer or can accept the current status, please say so.  No more
>> justification
>>
>> or reasoning is required. I just don't want the bulk of folks who are
>> content to be
>>
>> overlooked by those suggesting change.
>>
>>
>>
>> IF you prefer or can accept the current status, but think there should be
>> an IANA registry
>>
>> as is usual for managing code-points, please say so.  No more
>> justification is needed.
>>
>>
>>
>> IF you prefer Option B, C, and/or D, please say so with your
>> explanation.  More technical depth than "'we might need it" would be
>> helpful; the availability of sub-TLVs already
>>
>> provides future proofing.
>>
>>
>>
>> IF you have a clear technical objection to why the Current Status is not
>> acceptable,
>>
>> please express that - with clear details.
>>
>>
>>
>> IF you feel that additional code-points should be allocated in a BAR IANA
>> Registry or
>>
>> have thoughts on the appropriate policy, please say so with your
>> explanation for what
>>
>> those should be.
>>
>>
>>
>> Unless I see clear and strong consensus for something other than the
>> Current Status,
>>
>> that will remain.
>>
>>
>>
>> IF there is clear and strong consensus for Option B, C, or D, or adding
>> an IANA registry with particular values, then it will be possible to have a
>> change up through 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

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

Alia,

As per below i am not aware of a commercial deployment.

Some  implementation assume ability to use BIER specific algorithm. So if we 
keep 8 bits only, the IANA registry needs to allow that.  The registry being 
suggested as an option on the list will not allow BIER specific option ( and 
does not even support experimental bits at all) That would create a functional 
conflict unless the registry we use is BIER specific. But, as I pointed out, 
this option does not satisfy others.

Extending field as per Option B would require implementation change but can be 
accommodated but technically satisfies everyone’s needs I believe.

Andrew

Sent from my iPhone

On Feb 20, 2018, at 4:34 PM, Senthil Dhanaraj 
<senthil.dhana...@huawei.com<mailto:senthil.dhana...@huawei.com>> wrote:

I’m not aware of any commercial (or sort of) deployments.

So I hope it’s early enough for the implementations to adjust - Just like the 
consensus we had on the other issue related to allowing 0 as a valid value for 
“label-range (now called as “max-si)” which in-fact had a interoperability 
issue for last SI.

I do understand/agree there would be backward/interop issue with older bier-igp 
drafts if we make a change (say option-B) now for BAR.
Peter Psenak / Ice – Comments ?

Thanks,
Senthil


From: Alia Atlas [mailto:akat...@gmail.com]
Sent: 20 February 2018 10:45
To: Senthil Dhanaraj 
<senthil.dhana...@huawei.com<mailto:senthil.dhana...@huawei.com>>
Cc: BIER WG <b...@ietf.org<mailto:b...@ietf.org>>; 
isis-wg@ietf.org<mailto:isis-wg@ietf.org> list 
<isis-wg@ietf.org<mailto:isis-wg@ietf.org>>
Subject: RE: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

I have one additional question for those with implementations or testing them.

What is the impact of going with your preferred option in terms of 
interoperability?  It may be early enough that changes can happen, but more 
feedback is needed.

For those favoring Option B, could you send email to the list providing exact 
text so we have the details?

For those favoring the current status without an IANA registry, are you able to 
handle one being imposed during IESG Review?  It is an obvious concern to 
raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka



On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" 
<senthil.dhana...@huawei.com<mailto:senthil.dhana...@huawei.com>> wrote:
+1 to Option-B
Seems future proof to me.

Thanks,
Senthil



From: BIER [mailto:bier-boun...@ietf.org<mailto:bier-boun...@ietf.org>] On 
Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG <b...@ietf.org<mailto:b...@ietf.org>>; 
isis-wg@ietf.org<mailto:isis-wg@ietf.org> list 
<isis-wg@ietf.org<mailto:isis-wg@ietf.org>>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the 
mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then I'll 
elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
value 0 is specified.  The drafts do not have an IANA registry - with the 
expectation that one will be created when the first additional use is clear.  
It is possible that there will be objections from the IESG to progressing 
without an IANA registry.  Given the lack of clarity for future use-cases and 
after discussion, I decided not to force one after my AD review - but I will 
not push back against having a BIER IANA registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current TLVs.
   Define an IANA registry for the BAR type.  The meaning of the BAR sub-type 
derives
   from the BAR type.   We can debate over the registration policy for the BAR 
type.

3) Option C: Change the BAR field to be 16 bits and define an IANA registry.  
Part of the range can be FCFS with Expert Review, part can be Specification 
Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual understood and 
documented need, a BAR sub-type could be added a sub-TLV.  The length of the 
BAR sub-type could be determined when the sub-TLV is defined.

Given

  a) option D exists
  b) there is currently only one defined value for BAR
  c) I do not see strong consensus for change to one particular other option

I see no current reason for a change and I certainly see absolutely no reason 
for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.  Therefore, 
here is
my following request.

Please send your feedback to the mailing list 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Senthil Dhanaraj]

I’m not aware of any commercial (or sort of) deployments.

So I hope it’s early enough for the implementations to adjust - Just like the 
consensus we had on the other issue related to allowing 0 as a valid value for 
“label-range (now called as “max-si)” which in-fact had a interoperability 
issue for last SI.

I do understand/agree there would be backward/interop issue with older bier-igp 
drafts if we make a change (say option-B) now for BAR.
Peter Psenak / Ice – Comments ?

Thanks,
Senthil


From: Alia Atlas [mailto:akat...@gmail.com]
Sent: 20 February 2018 10:45
To: Senthil Dhanaraj <senthil.dhana...@huawei.com>
Cc: BIER WG <b...@ietf.org>; isis-wg@ietf.org list <isis-wg@ietf.org>
Subject: RE: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

I have one additional question for those with implementations or testing them.

What is the impact of going with your preferred option in terms of 
interoperability?  It may be early enough that changes can happen, but more 
feedback is needed.

For those favoring Option B, could you send email to the list providing exact 
text so we have the details?

For those favoring the current status without an IANA registry, are you able to 
handle one being imposed during IESG Review?  It is an obvious concern to 
raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka



On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" 
<senthil.dhana...@huawei.com<mailto:senthil.dhana...@huawei.com>> wrote:
+1 to Option-B
Seems future proof to me.

Thanks,
Senthil



From: BIER [mailto:bier-boun...@ietf.org<mailto:bier-boun...@ietf.org>] On 
Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG <b...@ietf.org<mailto:b...@ietf.org>>; 
isis-wg@ietf.org<mailto:isis-wg@ietf.org> list 
<isis-wg@ietf.org<mailto:isis-wg@ietf.org>>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the 
mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then I'll 
elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
value 0 is specified.  The drafts do not have an IANA registry - with the 
expectation that one will be created when the first additional use is clear.  
It is possible that there will be objections from the IESG to progressing 
without an IANA registry.  Given the lack of clarity for future use-cases and 
after discussion, I decided not to force one after my AD review - but I will 
not push back against having a BIER IANA registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current TLVs.
   Define an IANA registry for the BAR type.  The meaning of the BAR sub-type 
derives
   from the BAR type.   We can debate over the registration policy for the BAR 
type.

3) Option C: Change the BAR field to be 16 bits and define an IANA registry.  
Part of the range can be FCFS with Expert Review, part can be Specification 
Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual understood and 
documented need, a BAR sub-type could be added a sub-TLV.  The length of the 
BAR sub-type could be determined when the sub-TLV is defined.

Given

  a) option D exists
  b) there is currently only one defined value for BAR
  c) I do not see strong consensus for change to one particular other option

I see no current reason for a change and I certainly see absolutely no reason 
for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.  Therefore, 
here is
my following request.

Please send your feedback to the mailing list as follows:

IF you prefer or can accept the current status, please say so.  No more 
justification
or reasoning is required. I just don't want the bulk of folks who are content 
to be
overlooked by those suggesting change.

IF you prefer or can accept the current status, but think there should be an 
IANA registry
as is usual for managing code-points, please say so.  No more justification is 
needed.

IF you prefer Option B, C, and/or D, please say so with your explanation.  More 
technical depth than "'we might need it" would be helpful; the availability of 
sub-TLVs already
provides future proofing.

IF you have a clear technical objection to why the Current Status is not 
acceptable,
please express that - with clear details.

IF you feel that additional code-points should be allocated in a BAR IANA 
Registry or
have thoughts on the appropriate policy, please say so with your explanation 
for what
those should be.

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Senthil Dhanaraj]

+1 to Option-B
Seems future proof to me.

Thanks,
Senthil



From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG ; isis-wg@ietf.org list 
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
draft-ietf-bier-ospf-extensions

As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
draft-ietf-bier-ospf-extensions-12, I have been following the discussion on the 
mailing list with interest.

I have not seen clear consensus for any change.

Let me be clear on what I see the options are from the discussion.  Then I'll 
elaborate
a bit on how you can express your perspective most usefully.

1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
value 0 is specified.  The drafts do not have an IANA registry - with the 
expectation that one will be created when the first additional use is clear.  
It is possible that there will be objections from the IESG to progressing 
without an IANA registry.  Given the lack of clarity for future use-cases and 
after discussion, I decided not to force one after my AD review - but I will 
not push back against having a BIER IANA registry if raised by others.

2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current TLVs.
   Define an IANA registry for the BAR type.  The meaning of the BAR sub-type 
derives
   from the BAR type.   We can debate over the registration policy for the BAR 
type.

3) Option C: Change the BAR field to be 16 bits and define an IANA registry.  
Part of the range can be FCFS with Expert Review, part can be Specification 
Required, and part can be IETF Consensus.

4) Option D: At some point in the future, if there is an actual understood and 
documented need, a BAR sub-type could be added a sub-TLV.  The length of the 
BAR sub-type could be determined when the sub-TLV is defined.

Given

  a) option D exists
  b) there is currently only one defined value for BAR
  c) I do not see strong consensus for change to one particular other option

I see no current reason for a change and I certainly see absolutely no reason 
for
a delay in progressing the documents.

I do want to be clear about what the WG wants to do on this issue.  Therefore, 
here is
my following request.

Please send your feedback to the mailing list as follows:

IF you prefer or can accept the current status, please say so.  No more 
justification
or reasoning is required. I just don't want the bulk of folks who are content 
to be
overlooked by those suggesting change.

IF you prefer or can accept the current status, but think there should be an 
IANA registry
as is usual for managing code-points, please say so.  No more justification is 
needed.

IF you prefer Option B, C, and/or D, please say so with your explanation.  More 
technical depth than "'we might need it" would be helpful; the availability of 
sub-TLVs already
provides future proofing.

IF you have a clear technical objection to why the Current Status is not 
acceptable,
please express that - with clear details.

IF you feel that additional code-points should be allocated in a BAR IANA 
Registry or
have thoughts on the appropriate policy, please say so with your explanation 
for what
those should be.

Unless I see clear and strong consensus for something other than the Current 
Status,
that will remain.

IF there is clear and strong consensus for Option B, C, or D, or adding an IANA 
registry with particular values, then it will be possible to have a change up 
through this Weds night - with a 1 week WGLC on that particular technical 
change.

My priority is to have the base BIER specifications published as Proposed 
Standards so that more BIER implementations and deployment can be done.  I 
would like the WG to wrap up the core work (as expressed in the proposed 
recharter) so that you all can look
at how to use it.

Given this topic was raised last Weds and given that there are no technical 
objections raised to the documents as are, there isn't much time - so please 
just respond to this email ASAP.  My deadline for a decision is 6pm EST on Weds.

Regards,
Alia

___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Jeff Tantsura]

Dear BIERers,

 

Andrew just took the words out of my hands, my position is very similar and for 
exactly same reasons as described below.

Option B is the technically sound and future proof choice.

 

Thanks!

 

Cheers,

Jeff

From: BIER <bier-boun...@ietf.org> on behalf of "Dolganow, Andrew (Nokia - 
SG/Singapore)" <andrew.dolga...@nokia.com>
Date: Monday, February 19, 2018 at 21:09
To: Alia Atlas <akat...@gmail.com>
Cc: BIER WG <b...@ietf.org>, IJsbrand Wijnands <i...@cisco.com>, 
"isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Bier] [Isis-wg] BAR field length in 
draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

 

All,

 

As we discussed here (as a WG) and in this topic:
We need to have ability to define way for independent BIER computation 
algorithms (for BIER specific computations or other use cases, some of which 
Alia highlighted in her email below)
We want to have extensibility to use other non-BIER specific algorithms (as 
others brought up)
 

The original draft can be argued not to provide both of those capabilities, and 
thus Option A below (marked as Current status) really just defers the issue. I 
find Option E that Ice added also counterproductive as it eliminates the top 
use case above. Thus we really left with options B, C, D as a compromise. From 
those, Option B seems to me the best:
It meets the requirements above
It allows a clean implementation (as opposed to Option C which is a bit more 
kludgy). Thanks to a sub-TLV defining what BAR field carries – a BIER-specific 
algorithm defined in BIER specific registry (a registry that should be BIER 
specific, regardless of IGP used), or something else to meet needs expressed by 
others, we meet the requirements from those who wanted to change the Current 
status
 

Option C/D are acceptable alternatives; however, Option B seems technically 
cleanest, most flexible, and meeting all requirements.

 

Andrew

 

 

From: Isis-wg <isis-wg-boun...@ietf.org> on behalf of Alia Atlas 
<akat...@gmail.com>
Date: Tuesday, February 20, 2018 at 12:05 PM
To: "(Ice) IJsbrand Wijnands" <i...@cisco.com>
Cc: BIER WG <b...@ietf.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] [Bier] BAR field length in 
draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

 

Ice,

 

On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands <i...@cisco.com> wrote:

Alia, 





I appreciate that you have finally decided to discuss this on the BIER mailing 
list.


I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00  and 
 draft-hegdeppsenak-isis-sr-flex-algo-02.
I see a bit of discussion on the is-is mailing list and at IETF 100, but, of 
course, no WG adoption.

I see BIER as a fundamental technology that can be used in different 
situations.  For instance, there is not merely 
discussion of how Babel and BIER could interact - but actual code (thanks 
Sandy!); of course, that is not a WG-adopted
draft yet either, so this is merely a thought experiment example.  How do the 
different algorithms
work for an IGP that isn't link-state?   What about the ideas around using BIER 
with caches?  Are there issues there? 
What about algorithms that make sense for BIER or multicast - but not for 
unicast?

IANA registries are not price prohibitive.  Why would we tie BIER to the 
link-state IGP registry?

 

We are talking about what needs to be advertised in OSPF and ISIS in order to 
select the BIER underlay. We are not discussing Babel or any other candidate 
underlay technologies for BIER. Moreover, we are not limiting any new 
innovation with BIER regarding the underlay. This discussion is strictly 
related to the drafts in the title.

 

I do not hear you making a technical argument.

 

This is an architectural argument!

 

An architectural argument can't also limit itself to the drafts in the title.

 

If it sounded like the IANA registry was suggested as separate for BIER OSPF  
and BIER ISIS, then your attempt to reframe the conversation might be 
reasonable.  Let me clarify - I see no current reason for an OSPF BAR registry 
and an ISIS BAR registry; it would just be a BAR registry.  Perhaps

that clarification is a good reason to get the IANA registry included in the 
next update?

 

The routing layer is separate from the BIER layer.  The BAR is for the BIER 
layer.

 

Regards,

Alia

 

 

Hope this clarifies,

 

Thx,

 

Ice.





Regards,
Alia


On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands <i...@cisco.com> wrote:
Hi Alia,

There is one more option that I think is not fully covered from the choice of 
options related to getting a registry.

The topic of the discussion is what information we need to pass in the IGP in 
order for BIER to select the correct underlay. What identifies the underlay is 
really what ever information is needed to select the Tabl

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

d to
> recall the emails discussing acquiring half of the IGP Algorithm space for
> flex-algo.  I do talk to my WG Chairs.
>
> Please engage substantively with technical arguments.  If you have them,
> you are more than capable of representing them
> accurately.
>
>
> So Option E seems best to me.
>
>
> That was not part of my listed options.
>
> Regards,
> Alia
>
>
>
>
>    Les
>
>
>
> From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Tony Przygienda
> Sent: Monday, February 19, 2018 6:20 PM
> To: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolga...@nokia.com>
> Cc: BIER WG <b...@ietf.org>; IJsbrand Wijnands <i...@cisco.com>;
> isis-wg@ietf.org list <isis-wg@ietf.org>
> Subject: Re: [Bier] [Isis-wg] BAR field length in 
> draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> My reaction to AD's options:
>
> IF you prefer or can accept the current status, but think there should be
> an IANA registry
> as is usual for managing code-points, please say so.  No more
> justification is needed.
>
>
>
>
> +1 to this option, i.e. current status with IANA BIER BAR registry.
>
> I think we have a clear and current case which is anchored already in the
> architecture RFC as section 6.9
>
> The draft https://tools.ietf.org/html/draft-zzhang-bier-algorithm-00 goes
> into more detail in this respect and I hope the draft being adopted and at
> least a single BAR value being assigned to deal with brownfield deployments
> today where not all routers support BIER.  This clearly necessitates a BIER
> BAR registry.
>
>
> IF you prefer Option B, C, and/or D, please say so with your explanation.
> More technical depth than "'we might need it" would be helpful; the
> availability of sub-TLVs already
> provides future proofing.
>
>
> +2 for Option B). Albeit we can meet future use cases with BAR subtype
> being a sub-TLV a bar type/bar subtype 16 bits field (subtype with or
> without registry and of course we can name those things differently) all
> sub-TLVs in IGPs are traditionally “optional”, i.e. adding sub-TLVs later
> _may_ cause backwards compatibility problems.  Defining the subtype today
> will allow us to specify that only type/subtype 0/0 is well defined & any
> unknown type/subtype combination must be avoided. The subtype will allow
> for BAR 0 or future BAR types to understand that subtype is in a sense a
> “mandatory sub-TLV” and the routers sending out such subtype must be
> avoided, even if the type itself is known.  Several possibilities come to
> mind immediately such as using Unicast IGP Algorithm Registry as subtype
> for certain BAR values or accommodate interesting, future work like Flex
> Algo into BIER right after IGP RFCs are available which IMO would present a
> very beneficial future direction for BIER technology cleanly governed by a
> BIER BAR registry.
>
> PS: I think we should control the urges of workgroup participants to
> explore the number of letters in the roman alphabet that we can use to
> introduce their preferred solutions if we want to get to some kind of
> consensus on this thread.
>
> PPS: Option E has been discussed in the last 16-bit thread to the point of
> logical conclusion of a "all routing protocols under the sun algorithm
> registry" and found to  be a rathole I thought ...
>
>
>
>
>
>
> On Mon, Feb 19, 2018 at 6:09 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
> andrew.dolga...@nokia.com> wrote:
>
> All,
>
>
>
> As we discussed here (as a WG) and in this topic:
>
> • We need to have ability to define way for independent BIER computation
> algorithms (for BIER specific computations or other use cases, some of
> which Alia highlighted in her email below)
> • We want to have extensibility to use other non-BIER specific algorithms
> (as others brought up)
>
>
> The original draft can be argued not to provide both of those
> capabilities, and thus Option A below (marked as Current status) really
> just defers the issue. I find Option E that Ice added also
> counterproductive as it eliminates the top use case above. Thus we really
> left with options B, C, D as a compromise. From those, Option B seems to me
> the best:
>
> • It meets the requirements above
> • It allows a clean implementation (as opposed to Option C which is a bit
> more kludgy). Thanks to a sub-TLV defining what BAR field carries – a
> BIER-specific algorithm defined in BIER specific registry (a registry that
> should be BIER specific, regardless of IGP used), or something else to meet
> needs expressed by others, we meet the requirements from those who
> wanted to change th

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Alia,

> I forgot to add - of course - that I understand you have already stated that 
> you don't have any technical objections to the current status.

That is true. Sticking with 8 bits BAR and not yet declare what is means is 
better than rushing into 16bit with a registry during LC.

Thx,

Ice.

> 
> Regards,
> Alia
> 
> On Mon, Feb 19, 2018 at 8:58 PM, Alia Atlas  wrote:
> Ice,
> 
> At this point in the process, it would be necessary to make an overwhelming 
> technical argument - that would sway almost the whole
> WG to your perspective.
> 
> I see you saying that you have a personal preference for having the IGP 
> Algorithm registry also be used for the BAR registry.   While
> I do, of course, respect where you have technical expertise, my response - 
> particularly from a process perspective - is "that's nice".
> 
> Regards,
> Alia
> 
> On Mon, Feb 19, 2018 at 8:15 PM, IJsbrand Wijnands  wrote:
> Alia,
> 
> > An architectural argument can't also limit itself to the drafts in the 
> > title.
> >
> > If it sounded like the IANA registry was suggested as separate for BIER 
> > OSPF  and BIER ISIS, then your attempt to reframe the conversation might be 
> > reasonable.  Let me clarify - I see no current reason for an OSPF BAR 
> > registry and an ISIS BAR registry; it would just be a BAR registry.  Perhaps
> > that clarification is a good reason to get the IANA registry included in 
> > the next update?
> 
> There is no reason for an individual BIER OSPF and BIER ISIS registry. The 
> point is to align with what ever ISIS and OSPF are using to identify the 
> algorithm.
> 
> > The routing layer is separate from the BIER layer.  The BAR is for the BIER 
> > layer.
> 
> The underlay is separate from the BIER layer, and each underlay can carry 
> BIER specific information that is needed for for BIER to make the selection.
> 
> Thx,
> 
> Ice.
> 
> 
> 



___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Alia,

> I am quite disappointed in the level of discourse; the BIER-WG has 
> traditionally worked very
> collegially with substantive technical points.

I don’t think its necessary to try and discredit people like this for speaking 
up.

If you ask for input from the WG, you should be honest enough to list all the 
options.

What Les and I say is because we think that is architecturally the right think 
to do. If you don’t understand the reasoning or disagree, that is fine. 

Some problems take time to converge on, clearly in this case there was not 
enough time, but the drafts are pushed through anyway, your call. We got 
informed through a draft that there was no consensus on how to use the BAR type 
4 weeks ago.

Les’s response to Andrew’s comments are spot on. Over the weekend we tried to 
converge over a 16 bit BAR, and how it would look like. We where not able to 
converge on the semantics, especially related to option B and the “BAR 
sub-type”. Its opening an other can of worms and will cause new discussion over 
the BIER architecture in the future. I know, not your problem.

Thx,

Ice.

> 
> Regards,
> Alia
> 
> On Mon, Feb 19, 2018 at 10:11 PM, Alia Atlas <akat...@gmail.com> wrote:
> Les,
> 
> On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> 
> wrote:
> I am very sympathetic to doing “as little as possible” given we are talking 
> about documents which are going through final reviews.
> 
> At the same time, I think defining the authoritative source for algorithm 
> values is important.
> 
>  
> 
> I therefore agree w Ice – let’s keep the current 8 bit algorithm value – but 
> make it clear that the identifiers come from the IGP Registry. 
> 
> 
> I do not hear from you or Ice a clear technical reason nor willingness to 
> address the concerns that I raised about the impact
> on the use of BIER. 
> 
> I see no technical reasons being used to recommend combining the BIER BAR 
> registry and the IGP Algorithms registry.
> 
> 
> Andrew – I do not think there is agreement on what the function of a “BAR 
> sub-type” is. Therefore I am not comfortable in adding it to the drafts.
> 
> Certainly this may prove to be useful, but let’s add it when we know how it 
> will be used and how to assign values to it. That requires more discussion 
> than can reasonably be had in the current context.
> 
>  
> 
> Tony / Alia – the argument that 256 algorithm values is not enough for all 
> use cases (BIER specific and IGP specific and Babel specific…) – or even that 
> 128 is not enough (if we allow the Flex-Algo proposal to reserve half of the 
> space) – simply does not ring true to me.
> 
> If I waited for  you to buy  me a beer when we reached 10 algorithms I likely 
> will go thirsty for a very long time. 
> 
> 
> It is fascinating to see that you believe me too busy to keep up on the side 
> discussions happening - or perhaps merely too distracted to
> recall the emails discussing acquiring half of the IGP Algorithm space for 
> flex-algo.  I do talk to my WG Chairs.
> 
> Please engage substantively with technical arguments.  If you have them, you 
> are more than capable of representing them
> accurately.
> 
> 
> So Option E seems best to me.
> 
> 
> That was not part of my listed options.
>  
> Regards,
> Alia
> 
> 
>  
> 
>Les
> 
>  
> 
> From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Tony Przygienda
> Sent: Monday, February 19, 2018 6:20 PM
> To: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolga...@nokia.com>
> Cc: BIER WG <b...@ietf.org>; IJsbrand Wijnands <i...@cisco.com>; 
> isis-wg@ietf.org list <isis-wg@ietf.org>
> Subject: Re: [Bier] [Isis-wg] BAR field length in 
> draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
> 
>  
> 
> My reaction to AD's options:
> 
> IF you prefer or can accept the current status, but think there should be an 
> IANA registry
> as is usual for managing code-points, please say so.  No more justification 
> is needed.
>  
> 
>  
> 
> +1 to this option, i.e. current status with IANA BIER BAR registry. 
>  
> I think we have a clear and current case which is anchored already in the 
> architecture RFC as section 6.9
>  
> The draft https://tools.ietf.org/html/draft-zzhang-bier-algorithm-00 goes 
> into more detail in this respect and I hope the draft being adopted and at 
> least a single BAR value being assigned to deal with brownfield deployments 
> today where not all routers support BIER.  This clearly necessitates a BIER 
> BAR registry. 
>  
> 
> IF you prefer Option B, C, and/or D, please say so with your explanation.  
> More technical de

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Les,

Let me clarify - rereading your email again where you clearly suggest using
128 values for
flex-algo.   (I've been working all evening - except for ducking out for
that 10 minutes to
chase the kids to bed in the middle of that last email.)

a) I found the need for an SR Algorithm field to be limited, given our
experience with different
IGP algorithms.  I would also be stunned if we got to 10 different
algorithms.

b) Having unclear semantics because an algorithm only makes sense for BIER
or only makes
sense for an IGP-specific technology is not good.

c) Adding the complexity to consider how and when to use an algorithm or
similar new feature
that makes sense for a link-state IGP - to then also consider if it can
apply to BIER and if it can
work in non-link-state IGPs - would only make sense if it were balanced by
an equal technical
benefit.

These drafts were WGLCed in June - with no BAR.  In October, I did not just
insist on a IANA
registry for the BAR in the BIER registries - because it was claimed that
would let the documents
progress and not force to an assumption.  I regret that decision - given
the poor efforts to force
a registry merge.

IF you and Ice truly believe that this is the technically correct thing to
do, then you would make
substantive technical arguments instead of this sophistry.

I have given several more chances to allow this WG to discuss whether any
changes are needed
or are desirable. I am pushing for technical discussion.

I am quite disappointed in the level of discourse; the BIER-WG has
traditionally worked very
collegially with substantive technical points.

Regards,
Alia

On Mon, Feb 19, 2018 at 10:11 PM, Alia Atlas <akat...@gmail.com> wrote:

> Les,
>
> On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
>> I am very sympathetic to doing “as little as possible” given we are
>> talking about documents which are going through final reviews.
>>
>> At the same time, I think defining the authoritative source for algorithm
>> values is important.
>>
>>
>>
>> I therefore agree w Ice – let’s keep the current 8 bit algorithm value –
>> but make it clear that the identifiers come from the IGP Registry.
>>
>
> I do not hear from you or Ice a clear technical reason nor willingness to
> address the concerns that I raised about the impact
> on the use of BIER.
>
> I see no technical reasons being used to recommend combining the BIER BAR
> registry and the IGP Algorithms registry.
>
> Andrew – I do not think there is agreement on what the function of a “BAR
>> sub-type” is. Therefore I am not comfortable in adding it to the drafts.
>>
>> Certainly this may prove to be useful, but let’s add it when we know how
>> it will be used and how to assign values to it. That requires more
>> discussion than can reasonably be had in the current context.
>>
>>
>>
>> Tony / Alia – the argument that 256 algorithm values is not enough for
>> all use cases (BIER specific and IGP specific and Babel specific…) – or
>> even that 128 is not enough (if we allow the Flex-Algo proposal to reserve
>> half of the space) – simply does not ring true to me.
>>
>> If I waited for  you to buy  me a beer when we reached 10 algorithms I
>> likely will go thirsty for a very long time.
>>
>
> It is fascinating to see that you believe me too busy to keep up on the
> side discussions happening - or perhaps merely too distracted to
> recall the emails discussing acquiring half of the IGP Algorithm space for
> flex-algo.  I do talk to my WG Chairs.
>
> Please engage substantively with technical arguments.  If you have them,
> you are more than capable of representing them
> accurately.
>
> So Option E seems best to me.
>>
>
> That was not part of my listed options.
>
> Regards,
> Alia
>
>
>>
>>Les
>>
>>
>>
>> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Tony
>> Przygienda
>> *Sent:* Monday, February 19, 2018 6:20 PM
>> *To:* Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolga...@nokia.com>
>> *Cc:* BIER WG <b...@ietf.org>; IJsbrand Wijnands <i...@cisco.com>;
>> isis-wg@ietf.org list <isis-wg@ietf.org>
>> *Subject:* Re: [Bier] [Isis-wg] BAR field length in
>> draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
>>
>>
>>
>> My reaction to AD's options:
>>
>> IF you prefer or can accept the current status, but think there should be
>> an IANA registry
>> as is usual for managing code-points, please say so.  No more
>> justification is needed.
>>
>>
>>
>>
>> +1 to this option, i.e. current status 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Les,

On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com
> wrote:

> I am very sympathetic to doing “as little as possible” given we are
> talking about documents which are going through final reviews.
>
> At the same time, I think defining the authoritative source for algorithm
> values is important.
>
>
>
> I therefore agree w Ice – let’s keep the current 8 bit algorithm value –
> but make it clear that the identifiers come from the IGP Registry.
>

I do not hear from you or Ice a clear technical reason nor willingness to
address the concerns that I raised about the impact
on the use of BIER.

I see no technical reasons being used to recommend combining the BIER BAR
registry and the IGP Algorithms registry.

Andrew – I do not think there is agreement on what the function of a “BAR
> sub-type” is. Therefore I am not comfortable in adding it to the drafts.
>
> Certainly this may prove to be useful, but let’s add it when we know how
> it will be used and how to assign values to it. That requires more
> discussion than can reasonably be had in the current context.
>
>
>
> Tony / Alia – the argument that 256 algorithm values is not enough for all
> use cases (BIER specific and IGP specific and Babel specific…) – or even
> that 128 is not enough (if we allow the Flex-Algo proposal to reserve half
> of the space) – simply does not ring true to me.
>
> If I waited for  you to buy  me a beer when we reached 10 algorithms I
> likely will go thirsty for a very long time.
>

It is fascinating to see that you believe me too busy to keep up on the
side discussions happening - or perhaps merely too distracted to
recall the emails discussing acquiring half of the IGP Algorithm space for
flex-algo.  I do talk to my WG Chairs.

Please engage substantively with technical arguments.  If you have them,
you are more than capable of representing them
accurately.

So Option E seems best to me.
>

That was not part of my listed options.

Regards,
Alia


>
>Les
>
>
>
> *From:* BIER [mailto:bier-boun...@ietf.org] *On Behalf Of *Tony Przygienda
> *Sent:* Monday, February 19, 2018 6:20 PM
> *To:* Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolga...@nokia.com>
> *Cc:* BIER WG <b...@ietf.org>; IJsbrand Wijnands <i...@cisco.com>;
> isis-wg@ietf.org list <isis-wg@ietf.org>
> *Subject:* Re: [Bier] [Isis-wg] BAR field length in 
> draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> My reaction to AD's options:
>
> IF you prefer or can accept the current status, but think there should be
> an IANA registry
> as is usual for managing code-points, please say so.  No more
> justification is needed.
>
>
>
>
> +1 to this option, i.e. current status with IANA BIER BAR registry.
>
> I think we have a clear and current case which is anchored already in the
> architecture RFC as section 6.9
>
> The draft https://tools.ietf.org/html/draft-zzhang-bier-algorithm-00 goes
> into more detail in this respect and I hope the draft being adopted and at
> least a single BAR value being assigned to deal with brownfield deployments
> today where not all routers support BIER.  This clearly necessitates a BIER
> BAR registry.
>
>
> IF you prefer Option B, C, and/or D, please say so with your explanation.
> More technical depth than "'we might need it" would be helpful; the
> availability of sub-TLVs already
> provides future proofing.
>
>
> +2 for Option B). Albeit we can meet future use cases with BAR subtype
> being a sub-TLV a bar type/bar subtype 16 bits field (subtype with or
> without registry and of course we can name those things differently) all
> sub-TLVs in IGPs are traditionally “optional”, i.e. adding sub-TLVs later
> _may_ cause backwards compatibility problems.  Defining the subtype today
> will allow us to specify that only type/subtype 0/0 is well defined & any
> unknown type/subtype combination must be avoided. The subtype will allow
> for BAR 0 or future BAR types to understand that subtype is in a sense a
> “mandatory sub-TLV” and the routers sending out such subtype must be
> avoided, even if the type itself is known.  Several possibilities come to
> mind immediately such as using Unicast IGP Algorithm Registry as subtype
> for certain BAR values or accommodate interesting, future work like Flex
> Algo into BIER right after IGP RFCs are available which IMO would present a
> very beneficial future direction for BIER technology cleanly governed by a
> BIER BAR registry.
>
> PS: I think we should control the urges of workgroup participants to
> explore the number of letters in the roman alphabet that we can use to
> introduce their preferred solutions if we want to get to

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Alia,

> An architectural argument can't also limit itself to the drafts in the title.
> 
> If it sounded like the IANA registry was suggested as separate for BIER OSPF  
> and BIER ISIS, then your attempt to reframe the conversation might be 
> reasonable.  Let me clarify - I see no current reason for an OSPF BAR 
> registry and an ISIS BAR registry; it would just be a BAR registry.  Perhaps
> that clarification is a good reason to get the IANA registry included in the 
> next update?

There is no reason for an individual BIER OSPF and BIER ISIS registry. The 
point is to align with what ever ISIS and OSPF are using to identify the 
algorithm.

> The routing layer is separate from the BIER layer.  The BAR is for the BIER 
> layer.

The underlay is separate from the BIER layer, and each underlay can carry BIER 
specific information that is needed for for BIER to make the selection.

Thx,

Ice.

___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Ice,

On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands  wrote:

> Alia,
>
> I appreciate that you have finally decided to discuss this on the BIER
> mailing list.
>
>
> I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00
>  and  draft-hegdeppsenak-isis-sr-flex-algo-02.
> I see a bit of discussion on the is-is mailing list and at IETF 100, but,
> of course, no WG adoption.
>
> I see BIER as a fundamental technology that can be used in different
> situations.  For instance, there is not merely
> discussion of how Babel and BIER could interact - but actual code (thanks
> Sandy!); of course, that is not a WG-adopted
> draft yet either, so this is merely a thought experiment example.  How do
> the different algorithms
> work for an IGP that isn't link-state?   What about the ideas around using
> BIER with caches?  Are there issues there?
> What about algorithms that make sense for BIER or multicast - but not for
> unicast?
>
> IANA registries are not price prohibitive.  Why would we tie BIER to the
> link-state IGP registry?
>
>
> We are talking about what needs to be advertised in OSPF and ISIS in order
> to select the BIER underlay. We are not discussing Babel or any other
> candidate underlay technologies for BIER. Moreover, we are not limiting any
> new innovation with BIER regarding the underlay. This discussion is
> strictly related to the drafts in the title.
>
> I do not hear you making a technical argument.
>
>
> This is an architectural argument!
>

An architectural argument can't also limit itself to the drafts in the
title.

If it sounded like the IANA registry was suggested as separate for BIER
OSPF  and BIER ISIS, then your attempt to reframe the conversation might be
reasonable.  Let me clarify - I see no current reason for an OSPF BAR
registry and an ISIS BAR registry; it would just be a BAR registry.  Perhaps
that clarification is a good reason to get the IANA registry included in
the next update?

The routing layer is separate from the BIER layer.  The BAR is for the BIER
layer.

Regards,
Alia



> Hope this clarifies,
>
> Thx,
>
> Ice.
>
>
> Regards,
> Alia
>
>
> On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands  wrote:
> Hi Alia,
>
> There is one more option that I think is not fully covered from the choice
> of options related to getting a registry.
>
> The topic of the discussion is what information we need to pass in the IGP
> in order for BIER to select the correct underlay. What identifies the
> underlay is really what ever information is needed to select the Table
> (MT-ID) and Algorithm. An example of Algorithm work that is going on is
> Flex-Algo. My preferred option is to align with what ever the IGPs are
> using to identify the Algorithm.
>
> Option E: Change BAR into “IGP Algorithm” registry as documented in
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-
> algorithm-types
>
> Thx,
>
> Ice.
>
> On 19 Feb 2018, at 13:51, Alia Atlas  wrote:
>
> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
> draft-ietf-bier-ospf-extensions-12, I have been following the discussion
> on the mailing list with interest.
>
> I have not seen clear consensus for any change.
>
> Let me be clear on what I see the options are from the discussion.  Then
> I'll elaborate
> a bit on how you can express your perspective most usefully.
>
> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only
> value 0 is specified.  The drafts do not have an IANA registry - with the
> expectation that one will be created when the first additional use is
> clear.  It is possible that there will be objections from the IESG to
> progressing without an IANA registry.  Given the lack of clarity for future
> use-cases and after discussion, I decided not to force one after my AD
> review - but I will not push back against having a BIER IANA registry if
> raised by others.
>
> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current
> TLVs.
>Define an IANA registry for the BAR type.  The meaning of the BAR
> sub-type derives
>from the BAR type.   We can debate over the registration policy for the
> BAR type.
>
> 3) Option C: Change the BAR field to be 16 bits and define an IANA
> registry.  Part of the range can be FCFS with Expert Review, part can be
> Specification Required, and part can be IETF Consensus.
>
> 4) Option D: At some point in the future, if there is an actual understood
> and documented need, a BAR sub-type could be added a sub-TLV.  The length
> of the BAR sub-type could be determined when the sub-TLV is defined.
>
> Given
>
>   a) option D exists
>   b) there is currently only one defined value for BAR
>   c) I do not see strong consensus for change to one particular other
> option
>
> I see no current reason for a change and I certainly see absolutely no
> reason for
> a delay in progressing the documents.
>
> I do want to be clear about what the WG 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Alia,

> I appreciate that you have finally decided to discuss this on the BIER 
> mailing list.
> 
> I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00  
> and  draft-hegdeppsenak-isis-sr-flex-algo-02.
> I see a bit of discussion on the is-is mailing list and at IETF 100, but, of 
> course, no WG adoption.
> 
> I see BIER as a fundamental technology that can be used in different 
> situations.  For instance, there is not merely 
> discussion of how Babel and BIER could interact - but actual code (thanks 
> Sandy!); of course, that is not a WG-adopted
> draft yet either, so this is merely a thought experiment example.  How do the 
> different algorithms
> work for an IGP that isn't link-state?   What about the ideas around using 
> BIER with caches?  Are there issues there? 
> What about algorithms that make sense for BIER or multicast - but not for 
> unicast?
> 
> IANA registries are not price prohibitive.  Why would we tie BIER to the 
> link-state IGP registry?

We are talking about what needs to be advertised in OSPF and ISIS in order to 
select the BIER underlay. We are not discussing Babel or any other candidate 
underlay technologies for BIER. Moreover, we are not limiting any new 
innovation with BIER regarding the underlay. This discussion is strictly 
related to the drafts in the title.

> I do not hear you making a technical argument.

This is an architectural argument!

Hope this clarifies,

Thx,

Ice.

> 
> Regards,
> Alia
> 
> 
> On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands  wrote:
> Hi Alia,
> 
> There is one more option that I think is not fully covered from the choice of 
> options related to getting a registry.
> 
> The topic of the discussion is what information we need to pass in the IGP in 
> order for BIER to select the correct underlay. What identifies the underlay 
> is really what ever information is needed to select the Table (MT-ID) and 
> Algorithm. An example of Algorithm work that is going on is Flex-Algo. My 
> preferred option is to align with what ever the IGPs are using to identify 
> the Algorithm.
> 
> Option E: Change BAR into “IGP Algorithm” registry as documented in 
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
> 
> Thx,
> 
> Ice.
> 
>> On 19 Feb 2018, at 13:51, Alia Atlas  wrote:
>> 
>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
>> draft-ietf-bier-ospf-extensions-12, I have been following the discussion on 
>> the mailing list with interest.
>> 
>> I have not seen clear consensus for any change.
>> 
>> Let me be clear on what I see the options are from the discussion.  Then 
>> I'll elaborate
>> a bit on how you can express your perspective most usefully.
>> 
>> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
>> value 0 is specified.  The drafts do not have an IANA registry - with the 
>> expectation that one will be created when the first additional use is clear. 
>>  It is possible that there will be objections from the IESG to progressing 
>> without an IANA registry.  Given the lack of clarity for future use-cases 
>> and after discussion, I decided not to force one after my AD review - but I 
>> will not push back against having a BIER IANA registry if raised by others.
>> 
>> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current 
>> TLVs.
>>Define an IANA registry for the BAR type.  The meaning of the BAR 
>> sub-type derives 
>>from the BAR type.   We can debate over the registration policy for the 
>> BAR type.
>> 
>> 3) Option C: Change the BAR field to be 16 bits and define an IANA registry. 
>>  Part of the range can be FCFS with Expert Review, part can be Specification 
>> Required, and part can be IETF Consensus.
>> 
>> 4) Option D: At some point in the future, if there is an actual understood 
>> and documented need, a BAR sub-type could be added a sub-TLV.  The length of 
>> the BAR sub-type could be determined when the sub-TLV is defined.
>> 
>> Given
>> 
>>   a) option D exists 
>>   b) there is currently only one defined value for BAR
>>   c) I do not see strong consensus for change to one particular other option
>> 
>> I see no current reason for a change and I certainly see absolutely no 
>> reason for
>> a delay in progressing the documents.
>> 
>> I do want to be clear about what the WG wants to do on this issue.  
>> Therefore, here is
>> my following request.
>> 
>> Please send your feedback to the mailing list as follows:
>> 
>> IF you prefer or can accept the current status, please say so.  No more 
>> justification
>> or reasoning is required. I just don't want the bulk of folks who are 
>> content to be
>> overlooked by those suggesting change.
>> 
>> IF you prefer or can accept the current status, but think there should be an 
>> IANA registry
>> as is usual for managing code-points, please say so.  No more justification 
>> is needed.
>> 
>> IF you 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Alia Atlas]

Hi Ice,

I appreciate that you have finally decided to discuss this on the BIER
mailing list.

I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00
 and  draft-hegdeppsenak-isis-sr-flex-algo-02.
I see a bit of discussion on the is-is mailing list and at IETF 100, but,
of course, no WG adoption.

I see BIER as a fundamental technology that can be used in different
situations.  For instance, there is not merely
discussion of how Babel and BIER could interact - but actual code (thanks
Sandy!); of course, that is not a WG-adopted
draft yet either, so this is merely a thought experiment example.  How do
the different algorithms
work for an IGP that isn't link-state?   What about the ideas around using
BIER with caches?  Are there issues there?
What about algorithms that make sense for BIER or multicast - but not for
unicast?

IANA registries are not price prohibitive.  Why would we tie BIER to the
link-state IGP registry?

I do not hear you making a technical argument.

Regards,
Alia


On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands  wrote:

> Hi Alia,
>
> There is one more option that I think is not fully covered from the choice
> of options related to getting a registry.
>
> The topic of the discussion is what information we need to pass in the IGP
> in order for BIER to select the correct underlay. What identifies the
> underlay is really what ever information is needed to select the Table
> (MT-ID) and Algorithm. An example of Algorithm work that is going on is
> Flex-Algo. My preferred option is to align with what ever the IGPs are
> using to identify the Algorithm.
>
> Option E: Change BAR into “IGP Algorithm” registry as documented in
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-
> algorithm-types
>
> Thx,
>
> Ice.
>
> On 19 Feb 2018, at 13:51, Alia Atlas  wrote:
>
> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
> draft-ietf-bier-ospf-extensions-12, I have been following the
> discussion on the mailing list with interest.
>
> I have not seen clear consensus for any change.
>
> Let me be clear on what I see the options are from the discussion.  Then
> I'll elaborate
> a bit on how you can express your perspective most usefully.
>
> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only
> value 0 is specified.  The drafts do not have an IANA registry - with the
> expectation that one will be created when the first additional use is
> clear.  It is possible that there will be objections from the IESG to
> progressing without an IANA registry.  Given the lack of clarity for future
> use-cases and after discussion, I decided not to force one after my AD
> review - but I will not push back against having a BIER IANA registry if
> raised by others.
>
> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current
> TLVs.
>Define an IANA registry for the BAR type.  The meaning of the BAR
> sub-type derives
>from the BAR type.   We can debate over the registration policy for the
> BAR type.
>
> 3) Option C: Change the BAR field to be 16 bits and define an IANA
> registry.  Part of the range can be FCFS with Expert Review, part can be
> Specification Required, and part can be IETF Consensus.
>
> 4) Option D: At some point in the future, if there is an actual understood
> and documented need, a BAR sub-type could be added a sub-TLV.  The length
> of the BAR sub-type could be determined when the sub-TLV is defined.
>
> Given
>
>   a) option D exists
>   b) there is currently only one defined value for BAR
>   c) I do not see strong consensus for change to one particular other
> option
>
> I see no current reason for a change and I certainly see absolutely no
> reason for
> a delay in progressing the documents.
>
> I do want to be clear about what the WG wants to do on this issue.
> Therefore, here is
> my following request.
>
> Please send your feedback to the mailing list as follows:
>
> IF you prefer or can accept the current status, please say so.  No more
> justification
> or reasoning is required. I just don't want the bulk of folks who are
> content to be
> overlooked by those suggesting change.
>
> IF you prefer or can accept the current status, but think there should be
> an IANA registry
> as is usual for managing code-points, please say so.  No more
> justification is needed.
>
> IF you prefer Option B, C, and/or D, please say so with your explanation.
> More technical depth than "'we might need it" would be helpful; the
> availability of sub-TLVs already
> provides future proofing.
>
> IF you have a clear technical objection to why the Current Status is not
> acceptable,
> please express that - with clear details.
>
> IF you feel that additional code-points should be allocated in a BAR IANA
> Registry or
> have thoughts on the appropriate policy, please say so with your
> explanation for what
> those should be.
>
> Unless I see clear and strong consensus for 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[IJsbrand Wijnands]

Hi Alia,

There is one more option that I think is not fully covered from the choice of 
options related to getting a registry.

The topic of the discussion is what information we need to pass in the IGP in 
order for BIER to select the correct underlay. What identifies the underlay is 
really what ever information is needed to select the Table (MT-ID) and 
Algorithm. An example of Algorithm work that is going on is Flex-Algo. My 
preferred option is to align with what ever the IGPs are using to identify the 
Algorithm.

Option E: Change BAR into “IGP Algorithm” registry as documented in 
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

Thx,

Ice.

> On 19 Feb 2018, at 13:51, Alia Atlas  wrote:
> 
> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and 
> draft-ietf-bier-ospf-extensions-12, I have been following the discussion on 
> the mailing list with interest.
> 
> I have not seen clear consensus for any change.
> 
> Let me be clear on what I see the options are from the discussion.  Then I'll 
> elaborate
> a bit on how you can express your perspective most usefully.
> 
> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only 
> value 0 is specified.  The drafts do not have an IANA registry - with the 
> expectation that one will be created when the first additional use is clear.  
> It is possible that there will be objections from the IESG to progressing 
> without an IANA registry.  Given the lack of clarity for future use-cases and 
> after discussion, I decided not to force one after my AD review - but I will 
> not push back against having a BIER IANA registry if raised by others.
> 
> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current 
> TLVs.
>Define an IANA registry for the BAR type.  The meaning of the BAR sub-type 
> derives 
>from the BAR type.   We can debate over the registration policy for the 
> BAR type.
> 
> 3) Option C: Change the BAR field to be 16 bits and define an IANA registry.  
> Part of the range can be FCFS with Expert Review, part can be Specification 
> Required, and part can be IETF Consensus.
> 
> 4) Option D: At some point in the future, if there is an actual understood 
> and documented need, a BAR sub-type could be added a sub-TLV.  The length of 
> the BAR sub-type could be determined when the sub-TLV is defined.
> 
> Given
> 
>   a) option D exists 
>   b) there is currently only one defined value for BAR
>   c) I do not see strong consensus for change to one particular other option
> 
> I see no current reason for a change and I certainly see absolutely no reason 
> for
> a delay in progressing the documents.
> 
> I do want to be clear about what the WG wants to do on this issue.  
> Therefore, here is
> my following request.
> 
> Please send your feedback to the mailing list as follows:
> 
> IF you prefer or can accept the current status, please say so.  No more 
> justification
> or reasoning is required. I just don't want the bulk of folks who are content 
> to be
> overlooked by those suggesting change.
> 
> IF you prefer or can accept the current status, but think there should be an 
> IANA registry
> as is usual for managing code-points, please say so.  No more justification 
> is needed.
> 
> IF you prefer Option B, C, and/or D, please say so with your explanation.  
> More technical depth than "'we might need it" would be helpful; the 
> availability of sub-TLVs already
> provides future proofing.
> 
> IF you have a clear technical objection to why the Current Status is not 
> acceptable,
> please express that - with clear details.
> 
> IF you feel that additional code-points should be allocated in a BAR IANA 
> Registry or
> have thoughts on the appropriate policy, please say so with your explanation 
> for what
> those should be.
> 
> Unless I see clear and strong consensus for something other than the Current 
> Status,
> that will remain.
> 
> IF there is clear and strong consensus for Option B, C, or D, or adding an 
> IANA registry with particular values, then it will be possible to have a 
> change up through this Weds night - with a 1 week WGLC on that particular 
> technical change.
> 
> My priority is to have the base BIER specifications published as Proposed 
> Standards so that more BIER implementations and deployment can be done.  I 
> would like the WG to wrap up the core work (as expressed in the proposed 
> recharter) so that you all can look
> at how to use it.
> 
> Given this topic was raised last Weds and given that there are no technical 
> objections raised to the documents as are, there isn't much time - so please 
> just respond to this email ASAP.  My deadline for a decision is 6pm EST on 
> Weds.
> 
> Regards,
> Alia
> 
> ___
> BIER mailing list
> b...@ietf.org
> https://www.ietf.org/mailman/listinfo/bier



___
Isis-wg 

Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

[Toerless Eckert]

"current status". 

Maybe folks should ask themselves: 
Whats the worst case that could happen when we stick to "current status" ?

IMHO, we can do whatever we want with future work in a backward compatible
fashion and would at most have wasted 7 bits of BAR field. Thats not bad
enough to delay these 2.5++ year old drafts any further IMHO.  Best case, we
will have more efficient encoding for future work than future/additional 
{sub-}sub-TLVs
if we'd shrunk/cut the field now. 

Cheers
   Toerless


On Mon, Feb 19, 2018 at 04:51:01PM -0500, Alia Atlas wrote:
> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
> draft-ietf-bier-ospf-extensions-12, I have been following the discussion on
> the mailing list with interest.
> 
> I have not seen clear consensus for any change.
> 
> Let me be clear on what I see the options are from the discussion.  Then
> I'll elaborate
> a bit on how you can express your perspective most usefully.
> 
> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently, only
> value 0 is specified.  The drafts do not have an IANA registry - with the
> expectation that one will be created when the first additional use is
> clear.  It is possible that there will be objections from the IESG to
> progressing without an IANA registry.  Given the lack of clarity for future
> use-cases and after discussion, I decided not to force one after my AD
> review - but I will not push back against having a BIER IANA registry if
> raised by others.
> 
> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the current
> TLVs.
>Define an IANA registry for the BAR type.  The meaning of the BAR
> sub-type derives
>from the BAR type.   We can debate over the registration policy for the
> BAR type.
> 
> 3) Option C: Change the BAR field to be 16 bits and define an IANA
> registry.  Part of the range can be FCFS with Expert Review, part can be
> Specification Required, and part can be IETF Consensus.
> 
> 4) Option D: At some point in the future, if there is an actual understood
> and documented need, a BAR sub-type could be added a sub-TLV.  The length
> of the BAR sub-type could be determined when the sub-TLV is defined.
> 
> Given
> 
>   a) option D exists
>   b) there is currently only one defined value for BAR
>   c) I do not see strong consensus for change to one particular other option
> 
> I see no current reason for a change and I certainly see absolutely no
> reason for
> a delay in progressing the documents.
> 
> I do want to be clear about what the WG wants to do on this issue.
> Therefore, here is
> my following request.
> 
> Please send your feedback to the mailing list as follows:
> 
> IF you prefer or can accept the current status, please say so.  No more
> justification
> or reasoning is required. I just don't want the bulk of folks who are
> content to be
> overlooked by those suggesting change.
> 
> IF you prefer or can accept the current status, but think there should be
> an IANA registry
> as is usual for managing code-points, please say so.  No more justification
> is needed.
> 
> IF you prefer Option B, C, and/or D, please say so with your explanation.
> More technical depth than "'we might need it" would be helpful; the
> availability of sub-TLVs already
> provides future proofing.
> 
> IF you have a clear technical objection to why the Current Status is not
> acceptable,
> please express that - with clear details.
> 
> IF you feel that additional code-points should be allocated in a BAR IANA
> Registry or
> have thoughts on the appropriate policy, please say so with your
> explanation for what
> those should be.
> 
> Unless I see clear and strong consensus for something other than the
> Current Status,
> that will remain.
> 
> IF there is clear and strong consensus for Option B, C, or D, or adding an
> IANA registry with particular values, then it will be possible to have a
> change up through this Weds night - with a 1 week WGLC on that particular
> technical change.
> 
> My priority is to have the base BIER specifications published as Proposed
> Standards so that more BIER implementations and deployment can be done.  I
> would like the WG to wrap up the core work (as expressed in the proposed
> recharter) so that you all can look
> at how to use it.
> 
> Given this topic was raised last Weds and given that there are no technical
> objections raised to the documents as are, there isn't much time - so
> please just respond to this email ASAP.  My deadline for a decision is 6pm
> EST on Weds.
> 
> Regards,
> Alia

> ___
> BIER mailing list
> b...@ietf.org
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
t...@cs.fau.de

___
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg