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

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

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

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)

Re: [Isis-wg] [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

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

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

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

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

Re: [Isis-wg] [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.,

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

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

Re: [Isis-wg] [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

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

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

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

h 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 <arkadiy.gu...@thomsonreuters.com>; > akat...@gmail

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gt; 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 addit

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

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

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

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

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

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

Re: [Isis-wg] [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

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

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

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

<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

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

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

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

+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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

"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