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 <zzh...@juniper.net<mailto:zzh...@juniper.net>>
Cc: b...@ietf.org<mailto:b...@ietf.org>; 
isis-wg@ietf.org<mailto:isis-wg@ietf.org>; IJsbrand Wijnands 
<i...@cisco.com<mailto:i...@cisco.com>>; 
ext-arkadiy.gu...@thomsonreuters.com<mailto:ext-arkadiy.gu...@thomsonreuters.com>
 <arkadiy.gu...@thomsonreuters.com<mailto:arkadiy.gu...@thomsonreuters.com>>; 
Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>
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

[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

[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: ext-arkadiy.gu...@thomsonreuters.com ; 
> akat...@gmail.com; b...@ietf.org
> Cc: isis-wg@ietf.org
> Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 
> draft-ietf-bier-ospf-extensions
>  

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

[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 <akat...@gmail.com> 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 <i...@cisco.com> 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

[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

[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 <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 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 <akat...@gmail.com> 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 lis

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] WGLC: draft-ietf-bier-isis-extensions-04

[IJsbrand Wijnands]

Alia,

> Please tell that to Tony, its not me who started that discussion.
> 
> Tony is BIER WG Chair.  Managing the draft authors and different perspectives 
> is part of his role.

Nice twist/try!

> BUT changes to WG drafts are based upon transparent mailing list discussion - 
> so all are included.
> You know all of this, of course :-) but sometimes the details get losts in 
> copious email threads.

Who can disagree with that...

Enjoy the weekend,

Thx,

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