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

Jeffrey,


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.

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

[IJsbrand Wijnands (iwijnand)]

Hi Folks,

I support 16 bits because of the following reasons.

For me it would make sense to align the Algorithm value to the "IGP Algorithm" 
registry. This registry is defined in: 
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-8.5

In my opinion, this is going to cover 90% of the use-cases because BIER is 
defined to run over a unicast underlay, so what ever is done for Unicast, it 
will work for BIER automatically (like Flex Algo), and avoids to duplicate 
registries. However, this registry is also 8 bits. That means there is no room 
for anything else and I already know there are different options about this.

To avoid an other long debate/fight over these 8 bits, lets get more bits now 
so we don't corner our selfs. Its a minor change to the draft.

Lets not start a debate now on how BAR is used, as I'm sure we will not reach 
agreement  in time and we're gonna delay the IGP drafts. We can start a 
discussion after the IGP draft are through and what all the use-cases are we 
need to cover. I already look forward to those discussions :-)

Thx,

Ice.

Sent from my iPad

On 15 Feb 2018, at 07:24, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:

+1

I’d really like to see justification for anything larger than 8 bits.

Regards,
Jeff

On Feb 14, 2018, at 18:30, Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

I agree. As a point of reference, we've only have defined two IGP algorithms so 
far and the segment routing draft dates back about 4 years.

https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types

Even with more artistic freedom afforded to multicast,  I still believe 256 
standard algorithms are enough.

Thanks,
Acee

On 2/14/18, 9:15 PM, "BIER on behalf of Dolganow, Andrew (Nokia - 
SG/Singapore)" mailto:bier-boun...@ietf.org> on behalf 
of andrew.dolga...@nokia.com> wrote:

  Guys,

  I would think 8 bits are sufficient. Others (like SegRtg mentioned below also 
use 8). 8 bits gives us tons of room to grow - especially since we have only a 
single value defined currently (SFP 0). If we have clear use cases that show us 
running out of 8 bits or getting close to that we can/should discuss and 
evaluate extensions in light of that but increasing the space "just in case" is 
not a prudent way to go.

  Andrew

  -Original Message-
  From: BIER mailto:bier-boun...@ietf.org>> on behalf of 
Xiejingrong mailto:xiejingr...@huawei.com>>
  Date: Wednesday, February 14, 2018 at 5:06 PM
  To: Arkadiy Gulko 
mailto:arkadiy.gu...@thomsonreuters.com>>, 
"b...@ietf.org" mailto:b...@ietf.org>>, 
"isis-wg@ietf.org" 
mailto:isis-wg@ietf.org>>
  Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

  Hi Arkadiy,

  I checked the latest  and 
 for reference and comparing, 
and they both use a 8 bits Algorithm.
  One of the description: "Algorithm: Single octet identifying the 
algorithm."

  Interesting to use more than 8 bits for BIER's future flexibility :-)

  Regards,
  XieJingrong


  -Original Message-
  From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of 
arkadiy.gu...@thomsonreuters.com
  Sent: Wednesday, February 14, 2018 8:42 AM
  To: b...@ietf.org; 
isis-wg@ietf.org
  Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

  Hello Working Group,
  After initial discussions between multiple participants of the working 
group, we consolidated that BIER's future flexibility would be well served if 
we extend the IGP signaling BAR field to 16 bits. We are currently reviewing 
various use-cases that can greatly benefit from this enhancement.
  I would appreciate if the proposed change could be considered as part of 
IETF Last Call review.
  Thanks,
  Arkadiy


  -Original Message-
  From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
  Sent: Friday, February 09, 2018 5:11 PM
  To: i-d-annou...@ietf.org
  Cc: b...@ietf.org
  Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt


  A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Bit Indexed Explicit Replication WG of 
the IETF.

  Title   : BIER support via ISIS
  Authors : Les Ginsberg
Tony Przygienda
Sam Aldrin
Jeffrey (Zhaohui) Zhang
  Filename: draft-ietf-bier-isis-extensions-07.txt
  Pages   : 10
  Date: 2018-02-09

  Abstract:
 Specification of an ISIS extension to support BIER domai

Re: [Isis-wg] [Bier] WGLC: draft-ietf-bier-isis-extensions-04

[IJsbrand Wijnands (iwijnand)]

Greg,

I think there is a confusion here, there is no consensus to remove BAR! We want 
to keep it, but might change the format a little...

Sent from my iPhone

On 9 Feb 2018, at 17:49, Greg Shepherd 
mailto:gjs...@gmail.com>> wrote:

Les,
draft-ietf-bier-isis-extensions still mentions BAR. Is this intentional? Then 
consensus on the thread was to remove BAR.

Greg

On Tue, Feb 6, 2018 at 3:45 PM, Greg Shepherd 
mailto:gjs...@gmail.com>> wrote:
Thanks Les.

Any other feedback? Looks like the concerns have been addressed. Speak now.

Cheers,
Greg

On Thu, Feb 1, 2018 at 7:26 AM, Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Greg –

This thread is outdated.
In V6 of the draft we removed the restriction to limit IS-IS BIER support to 
area boundaries – so Toerless’s comment (and my proposed text) are no longer 
relevant.

Specifically:

Section 4.1:

“At present, IS-IS support for a given BIER domain/sub-domain is
   limited to a single area - or to the IS-IS L2 sub-domain.”

The above text was removed.

Section 4.2

o  BIER sub-TLVs MUST NOT be included when a prefix reachability
  advertisement is leaked between levels.

Was changed to

o  BIER sub-TLVs MUST be included when a prefix reachability
  advertisement is leaked between levels.

This aligns IS-IS and OSPF drafts in this regard.

Les

From: Greg Shepherd [mailto:gjs...@gmail.com]
Sent: Thursday, February 01, 2018 2:23 AM
To: Toerless Eckert mailto:t...@cs.fau.de>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Tony Przygienda mailto:tonysi...@gmail.com>>; Hannes 
Gredler (han...@gredler.at) 
mailto:han...@gredler.at>>; 
b...@ietf.org; isis-wg@ietf.org 
list mailto:isis-wg@ietf.org>>; Christian Hopps 
mailto:cho...@chopps.org>>

Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04

Have these changes been reflected in the draft? We're in WGLC but this 
discussion needs to come to a conclusion so we can progress.

Greg

On Tue, Jul 25, 2017 at 12:52 PM, Toerless Eckert 
mailto:t...@cs.fau.de>> wrote:
Thanks, Less, that would be lovely!

I didn't check the OSPF draft, if its similar state, explanatory text wold 
equally be appreciated.

On Sun, Jul 23, 2017 at 11:28:08PM +, Les Ginsberg (ginsberg) wrote:
> Toerless -
>
> I am thinking to add a statement in Section 4.1 - something like:
>
> "At present, IS-IS support for a given BIER domain/sub-domain is limited to a 
> single area - or to the IS-IS L2 sub-domain."
>
> If you believe this would be helpful I will spin a new version (subject to 
> review/agreement from my co-authors).
>
>Les
>
>
> > -Original Message-
> > From: Toerless Eckert [mailto:t...@cs.fau.de]
> > Sent: Saturday, July 22, 2017 6:34 AM
> > To: Les Ginsberg (ginsberg)
> > Cc: Tony Przygienda; Hannes Gredler 
> > (han...@gredler.at); Greg Shepherd;
> > b...@ietf.org; 
> > isis-wg@ietf.org list; Christian Hopps
> > Subject: Re: [Bier] WGLC: draft-ietf-bier-isis-extensions-04
> >
> > Thanks Les
> >
> > When searching various terms in the doc to figure out what happens i am not
> > sure why i missed this one.
> >
> > But: IMHO, RFCs can not only be the minimum number of words to get a
> > running implementation. It also needs to specify what this implementation
> > intends to achieve. Otherwise its not possible to do a useful review:
> > The reviewer can to verify whether the spec will achieve what it claims to
> > achieve is there no definitionn of what it claims to achieve.
> >
> > If i understand ISIS correctly, my reverse engineering of the intent is:
> >
> > - BIER TLVs stay within single ISIS areas. BFIR and BFER must therefore be
> >   in the same ISIS area: There is no inter-area BIER traffic possible
> >   with this specification. This is also true for ISIS area 0.
> >
> > - The same BIER sub-domain identifiers can be re-used
> >   across different ISIS areas without any current impact. If these BFR-IDs
> >   are non-overlapping, then this would allow in the future to create a 
> > single
> >   cross ISIS area BIER sub-domain by leaking TLVs for such a BIER sub-domain
> >   across ISIS levels. Leakage is outside the scope of this specificication.
> >
> > I actually even would like to do the following:
> >
> > - If BIER sub-domains are made to span multiple ISIS areas and BFR-ids
> > assignemtns
> >   are made such that all BFR-ids with the same SI are in the same ISIS ara,
> >   then it should be in the future reasonably easy to create inter-area BIER
> >   not by leaking of the BIER TLV but by having BFIR MPLS unicastBIER packets
> >   for different SIs to an appropriate L2L1 BFIR that is part of the 
> > destination
> > area/SI.
> >   (if you would use SI number that are the same as ISIS area numbers then
> >you could probably do this without any new sign