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

From: <[email-masked]>
Date: Wed, 14 Feb 2018 00:42:11 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 09, 2018 5:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt

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

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

Abstract:
   Specification of an ISIS extension to support BIER domains and sub-
   domains.

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Disis-2Dextensions_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=3qPmQav_QUBjHi7KygPVk9bIhVZ7TL2Z3xfHOo_Cjwc&e= 

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=_nTFvlAW24snrkMm3aQ2uWLFsLCajYeW4HO3DdEiwvs&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4&e= 

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbier-2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=pDVWzZrYzGia4WKiA_cSF0P5isUmMeojSvHJIGgdOTk&e= 

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
BIER mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU&e=

---

From: Xiejingrong <[email-masked]>
Date: Wed, 14 Feb 2018 09:06:24 +0000

Hi Arkadiy,

I checked the latest <draft-ietf-ospf-segment-routing-extensions-24> and <draft-ietf-isis-segment-routing-extensions-15> 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:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 14, 2018 8:42 AM
To: [email-masked]; [email-masked]
Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

Hello Working Group,

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 09, 2018 5:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt

Abstract:

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 15 Feb 2018 02:15:35 +0000

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 <[email-masked]> on behalf of Xiejingrong <[email-masked]>
Date: Wednesday, February 14, 2018 at 5:06 PM
To: Arkadiy Gulko <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

    Hi Arkadiy,

    
    Regards,
    XieJingrong

    -----Original Message-----
    From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Wednesday, February 14, 2018 8:42 AM
    To: [email-masked]; [email-masked]
    Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
    
    Hello Working Group,

    -----Original Message-----
    From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Friday, February 09, 2018 5:11 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt

    
    Abstract:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Feb 2018 02:30:44 +0000

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)" <[email-masked] on behalf of [email-masked]> wrote:

    Guys,

    Andrew
    
    -----Original Message-----
    From: BIER <[email-masked]> on behalf of Xiejingrong <[email-masked]>
    Date: Wednesday, February 14, 2018 at 5:06 PM
    To: Arkadiy Gulko <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
    
        Hi Arkadiy,

        
        Regards,
        XieJingrong

        -----Original Message-----
        From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
        Sent: Wednesday, February 14, 2018 8:42 AM
        To: [email-masked]; [email-masked]
        Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
        
        Hello Working Group,

        -----Original Message-----
        From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]
        Sent: Friday, February 09, 2018 5:11 PM
        To: [email-masked]
        Cc: [email-masked]
        Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt

        
        Abstract:

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 14 Feb 2018 22:24:02 -0800

+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) <[email-masked]> wrote:
>

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Thu, 15 Feb 2018 08:11:44 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

+1

Regards,
Jeff

On Feb 14, 2018, at 18:30, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Acee

On 2/14/18, 9:15 PM, "BIER on behalf of Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

  Guys,

  Andrew

  -----Original Message-----
  From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Xiejingrong <[email-masked]<mailto:[email-masked]>>
  Date: Wednesday, February 14, 2018 at 5:06 PM
  To: Arkadiy Gulko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
  Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

      Hi Arkadiy,

      Regards,
      XieJingrong

      -----Original Message-----
      From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
      Sent: Wednesday, February 14, 2018 8:42 AM
      To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
      Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

      Hello Working Group,

      -----Original Message-----
      From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
      Sent: Friday, February 09, 2018 5:11 PM
      To: [email-masked]<mailto:[email-masked]>
      Cc: [email-masked]<mailto:[email-masked]>
      Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt

      Abstract:

      Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

      _______________________________________________
      BIER mailing list
      [email-masked]<mailto:[email-masked]>
      https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU&e=

      _______________________________________________
      BIER mailing list
      [email-masked]<mailto:[email-masked]>
      https://www.ietf.org/mailman/listinfo/bier

      _______________________________________________
      BIER mailing list
      [email-masked]<mailto:[email-masked]>
      https://www.ietf.org/mailman/listinfo/bier

  _______________________________________________
  BIER mailing list
  [email-masked]<mailto:[email-masked]>
  https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Feb 2018 09:46:47 -0500

Ice's reasoning makes sense to me.

On 2/15/2018 3:11 AM, IJsbrand Wijnands (iwijnand) wrote:
> 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 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dospf-2Dsegment-2Drouting-2Dextensions-2D24-23section-2D8.5&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=wFHQGdbIofGfam7tl7rnRjckYdcPp1WR-BqnaNE1mV8&e=> 
>
>
> 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
>
>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_igp-2Dparameters_igp-2Dparameters.xhtml-23igp-2Dalgorithm-2Dtypes&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=5yaJPFqWpr5V5oBQ4O7o779WCOla79NlPw5FEfmRAUY&e=>
>>>
>>> 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)" <[email-masked] <mailto:[email-masked]> 
>>> on behalf of [email-masked] 
>>> <mailto:[email-masked]>> 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
>>>
>>>   From: BIER <[email-masked] <mailto:[email-masked]>> 
>>> on behalf of Xiejingrong <[email-masked] 
>>> <mailto:[email-masked]>>
>>>   To: Arkadiy Gulko <[email-masked] 
>>> <mailto:[email-masked]>>, "[email-masked] 
>>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
>>> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>>> <mailto:[email-masked]>>
>>>       I checked the latest 
>>> <draft-ietf-ospf-segment-routing-extensions-24> and 
>>> <draft-ietf-isis-segment-routing-extensions-15> for reference and 
>>> comparing, and they both use a 8 bits Algorithm.
>>> <mailto:[email-masked]>
>>>       To: [email-masked] <mailto:[email-masked]>; [email-masked] 
>>> <mailto:[email-masked]>
>>>       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.
>>>       From: BIER [mailto:[email-masked]] On Behalf Of 
>>> [email-masked] <mailto:[email-masked]>
>>>       To: [email-masked] <mailto:[email-masked]>
>>>       Cc: [email-masked] <mailto:[email-masked]>
>>>       Please note that it may take a couple of minutes from the time 
>>> of submission until the htmlized version and diff are available at 
>>> tools.ietf.org 
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=qZ3p2sAIpzRPXfiRBbzrB1rPAkaJXEKiz43EmIKO03Y&e=>.
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>>
>> [email-masked] <mailto:[email-masked]>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 15 Feb 2018 08:25:19 -0800

Under 8-bit artistic license granted by Acee herewith ;-)

First, I want to emphasize that this is IETF LC (called by Greg as
shepherding WG chair) which means chairs have no further function so we all
can only speak as individuals only .

2nd, I oppose any suggestion to align any kind of SR registry with BAR
registry using 8 bits on couple of very simple grounds that my
co-participants may have missed

a)       No IGP or SR working group has any charter to mandate any of the
BIER technology so as well-meant the suggestion seems to be, it has no
standing in IETF working procedures as far as I can see unless according
charters are extended by ADs. Unless I'm missing something here.
b)       More as a question: Can we even publish an RFC now (experimental)
pointing to an SR draft as normative? And if, how do we move it to intended
standards track unless SR draft is a standards RFC?
c)       Probably most importantly, technically, In case any of the SR
computations starts to rely on elements advertised in SR to perform the
computations, deployment of BIER will precondition deployment of SR in the
network. Worse, if we need computation that needs BIER specific elements in
its course, that would mean we have SR becoming aware of a multicast
technology underneath. Unicast computations are simply not multicast
computations longer-term  (and I had discussions about couple such cases
already). Having multicast specific elements being considered in unicast
computations and multicast computations being "standardized" in unicast
computations couples everything with everything again known as the
big-ball-of-yarn (unless THAT is the intention). In long experience things
like this are simply a very bad architecture (TM ;-).

3rd, I thought about the issues involved in BAR probably longer than anyone
on the list here (remember Tree ID ;-) and I have a meta issue to make and
then a finer one

a)      Independent of whether we end up with 8 or 16 bits I think we need
a firm BIER BAR registry in place here (expert review?) and some document
to gather the BAR ideas. Sooner the better. Ideas as in this thread are
coming in it would be good to channelize them to prevent codepoint
squatting or replicated effort. In fact we have a draft we circulated and
we decided to push out today to give a strawman framework to the discussed
use-cases. Granted, only the new charter (if given to us) would allow this
work to be adopted but it’s good to have a vessel to contain the ideas
already IMO. So check the new-publication queue ;-)
b)      Then, if we consider BAR as purely “special BIER nexthop
computation” 8 bits sounds plenty but never underestimate new technology to
stretch artistic boundaries and ideas you see here ;-) So if we think e.g.
about things like the above mentioned
draft-ietf-isis-segment-routing-extensions-15 proposal playing a role one
could imagine that the “SR algorithm registry” specifies an algorithm that
BAR registry likes to use as well 1:1. Simple, we just allocate a BIER BAR
codepoint that is mapped (or even same) to the SR UCAST codepoint in this
case (well, let discussion whether we would have the charter to do that or
go ask for permission in SPRING outstanding for now). And that could be
done of course via a TLV as well by using a single “BAR # meaning it’s an
SR algorithm” and then a BIER sub-tlv saying which one of those. But things
get finer. Let’s say we use a BAR=1 as BIER computation saying “avoid all
non-BIER routers”. Now, that’s cool but maybe SR defined an algorithm we
want to use on top as in “compute SPF with enough bandwidth”. For that
could have a funky TLV saying “any BAR computation should stack this SR
computation on top” but it would be then way more elegant to have a 16 bit
with 8bit BAR from registry and then 8 bits of some context (in this
example SR computation# to be stacked on top of the necessary BAR
computation). Yes, that would precondition in such case simultaneous BIER
and SR deployment but since then no technology forces mandatory use of
another it’s flexible, open and nicely smelling. I hope at least some
people could follow that and old IGP hands will see that this is actually
as efficient in terms of actual implementation as a single set of
constraints despite seeming complex.

I won’t stretch my artistic license further than 16 bits albeit there are
even more interesting ideas I saw that would blow through this ;-) I
probably owe Acee a beer in London already as it is.

So, in shorter form for the non-IGP cracks, I think 8 bits looks good but I
see how 16 could have an elegance to channelize some of the suggestions
(and get a "goldilocks solution"), if we e.g. decide to “stack algorithmic
constraints from multiple technologies optionally on top of each other,
each with its own registry that can refer to another”. This would
accommodate also the proposal extended by Ice in a simple, clean, loosely
coupled way by having 16 bits, *first 8 bits as BIER type being a BIER BAR
registry and 8 bits after that being “open” so e.g. being SR unicast
registry number*.

I do also think that if we get to such a consensus, adding text introducing
test adding a BAR type/BAR subtype 16-bits field with a BAR type BIER
registry into the documents is just a bit of text ...

As  I said, our draft will follow later today since some co-authors are in
funky timezones ;-) …

--- tony

On Thu, Feb 15, 2018 at 6:46 AM, Eric C Rosen <[email-masked]> wrote:

> 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 <[email-masked]> wrote:
>
> +1
>
> algorithms so far and the segment routing draft dates back about 4 years.
>
>
> SG/Singapore)" <[email-masked] on behalf of
> [email-masked]> 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
>
>
>   To: Arkadiy Gulko <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>
>       I checked the latest <draft-ietf-ospf-segment-routing-extensions-24>
> and <draft-ietf-isis-segment-routing-extensions-15> for reference and
>       From: BIER [mailto:[email-masked] <[email-masked]>]
> On Behalf Of [email-masked]
>
> 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.
>
>       From: BIER [mailto:[email-masked] <[email-masked]>]
> On Behalf Of [email-masked]
>
>       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Disis-
> 2Dextensions_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=
> JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_
> 27M4FMDvmv6fa9xveuyL5HyTvYs&s=3qPmQav_QUBjHi7KygPVk9bIhVZ7TL2Z3xfHOo
> _Cjwc&e=
>
>
>       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dbier-2Disis-
> 2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-
> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=
> TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=_
> nTFvlAW24snrkMm3aQ2uWLFsLCajYeW4HO3DdEiwvs&e=
>
>       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-
> 2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-
> GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-
> jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=
> zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4&e=
>
>
>       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbier-
> 2Disis-2Dextensions-2D07&d=DwICAg&c=4ZIZThykDLcoWk-
> GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-
> jvOcxu4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=
> pDVWzZrYzGia4WKiA_cSF0P5isUmMeojSvHJIGgdOTk&e=
>
>
>
>       Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org
>       https://urldefense.proofpoint.com/v2/url?u=ftp-
> 3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-
> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=
> TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=
> wqMqmybm38ZiX4CuzJaNJPMea1Mf-pSgD-vdgAHk850&e=
>
>
>       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-
> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=
> TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=
> kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU&e=
>
>
> BIER mailing [email-masked]
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 15 Feb 2018 08:38:52 -0800

For the record, there is no SR Registry. There is only an IGP Algo Type
Registry as defined in draft-ietf-ospr-segment-routing-extensions-24
section 8.5

More inline:

> charters are extended by ADs. Unless I'm missing something here.

If a WG points to a registry of any kind, a draft is all that is needed to
justify an new entry in the registry.

> standards track unless SR draft is a standards RFC?

Nobody is asking to reference it now. The current issue on the table to to
leave it undefined with only default value, so let's stick with the current
issue.

> like this are simply a very bad architecture (TM ;-).

Again, it's an IGP Algo registry. It's documentation. There are no
dependencies other than our references, which right now we don't have any.

> 3rd, I thought about the issues involved in BAR probably longer than
> anyone on the list here (remember Tree ID ;-) and I have a meta issue to
> make and then a finer one
>

> about things like the above mentioned draft-ietf-isis-segment-routing-extensions-15
> proposal playing a role one could imagine that the “SR algorithm registry”
> specifies an algorithm that BAR registry likes to use as well 1:1. Simple,
> we just allocate a BIER BAR codepoint that is mapped (or even same) to the
> SR UCAST codepoint in this case (well, let discussion whether we would have
> the charter to do that or go ask for permission in SPRING outstanding for
> now). And that could be done of course via a TLV as well by using a single
> “BAR # meaning it’s an SR algorithm” and then a BIER sub-tlv saying which
> one of those. But things get finer. Let’s say we use a BAR=1 as BIER
> computation saying “avoid all non-BIER routers”. Now, that’s cool but maybe
> SR defined an algorithm we want to use on top as in “compute SPF with
> enough bandwidth”. For that could have a funky TLV saying “any BAR
> computation should stack this SR computation on top” but it would be then
> way more elegant to have a 16 bit with 8bit BAR from registry and then 8
> bits of some context (in this example SR computation# to be stacked on top
> of the necessary BAR computation). Yes, that would precondition in such
> case simultaneous BIER and SR deployment but since then no technology
> forces mandatory use of another it’s flexible, open and nicely smelling. I
> hope at least some people could follow that and old IGP hands will see that
> this is actually as efficient in terms of actual implementation as a single
> set of constraints despite seeming complex.
>
> So, in shorter form for the non-IGP cracks, I think 8 bits looks good but
> I see how 16 could have an elegance to channelize some of the suggestions
> coupled way by having 16 bits, *first 8 bits as BIER type being a BIER
> BAR registry and 8 bits after that being “open” so e.g. being SR unicast
> registry number*.
>
> I do also think that if we get to such a consensus, adding text
> introducing test adding a BAR type/BAR subtype 16-bits field with a BAR
> type BIER registry into the documents is just a bit of text ...
>

thanks,
Greg

>> 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
>> 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
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Disis-2Dextens
>> ions_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY
>> &r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8R
>> eKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=3qPmQav_QUBjHi7KygPVk9bIh
>> VZ7TL2Z3xfHOo_Cjwc&e=
>>
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> tools.ietf.org_html_draft-2Dietf-2Dbier-2Disis-2Dextensions-
>> 2D07&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&
>> r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=TOz3rr3No8Re
>> KzE_27M4FMDvmv6fa9xveuyL5HyTvYs&s=_nTFvlAW24snrkMm3aQ2uWLFsL
>> CajYeW4HO3DdEiwvs&e=
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> datatracker.ietf.org_doc_html_draft-2Dietf-2Dbier-2Disis-
>> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4
>> cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&
>> s=zHWCGuyM-GSX-slbFtCv4fs9ml5gPQBeXohosuyhpx4&e=
>>
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbier-2Disis-
>> 1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4
>> cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvYs&
>> s=pDVWzZrYzGia4WKiA_cSF0P5isUmMeojSvHJIGgdOTk&e=
>>
>>
>>
>>       https://urldefense.proofpoint.com/v2/url?u=ftp-3A__
>> ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=4ZIZThykDLcoWk-
>> GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcx
>> u4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvY
>> s&s=wqMqmybm38ZiX4CuzJaNJPMea1Mf-pSgD-vdgAHk850&e=
>>
>>
>>       https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> www.ietf.org_mailman_listinfo_bier&d=DwICAg&c=4ZIZThykDLcoWk
>> -GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcx
>> u4cQskARppQFqZc&m=TOz3rr3No8ReKzE_27M4FMDvmv6fa9xveuyL5HyTvY
>> s&s=kxUz28mTxGjbNsEQMGi8SMZ93LSiMt_bMFzqkWJJZnU&e=
>>
>>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 15 Feb 2018 08:53:10 -0800

> Registry as defined in draft-ietf-ospr-segment-routing-extensions-24

So is that a good idea, having multiple drafts in flight with fields
expecting to have magic couplings to each other while leaving e'thing
"unspecified" to "publish RFCs" while we "decide things later"?

> justify an new entry in the registry.

Forthcoming today as I said ... For all practical purposes having a _single
value_ in a field that can accommodate more in the future can mandate a
registry and we already have 0 BTW. And it looks we will/may have more so I
can't follow the apparent logic here that we don't need a registry because
"we don't have values today" but so we publish an RFC without registry
which implies we don't need a registry later in case we have values?

>
>
>> b)       More as a question: Can we even publish an RFC now
>> (experimental) pointing to an SR draft as normative? And if, how do we move
>> it to intended standards track unless SR draft is a standards RFC?
>>
>

I leave it to the judgement of IESG and AD then whether they progress
things to RFCs (intended for standards track) with undefined fields for
which the "interpretations" will come later. The issue was here 6 months
ago and was muscled, the issue is obviously now on an open consensus
building list. It will not magically go away. I still see a registry as a
long-time proven way to anchor multiple ideas coming into a technology
safely and fail to understand how we have things that will be "aligned" but
are not "depending to each other" while "documentations" are not
"registries" from the continuation of your email, Greg ...  And I lived
through enough codepoint squatting wars and WG charters stepping onto each
others feet to not having the desire to have one more on my hands, hence I
welcome the thread ...

--- tony

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 15 Feb 2018 09:20:07 -0800

> "unspecified" to "publish RFCs" while we "decide things later"?

That was a pivot, but still; there is no reference, there is no coupling.

Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around
for a while, and the IGP Algo registry will be tied to this draft and it's
fate. If anyone is expecting to use this registry outside of the scope of
this draft, it would be in their best interest to pull the registry
description out into a separate draft.

>> If a WG points to a registry of any kind, a draft is all that is needed
>> to justify an new entry in the registry.
>>
>
> Forthcoming today as I said ... For all practical purposes having a
> _single value_ in a field that can accommodate more in the future can
> mandate a registry and we already have 0 BTW. And it looks we will/may have
> more so I can't follow the apparent logic here that we don't need a
> registry because "we don't have values today" but so we publish an RFC
> without registry which implies we don't need a registry later in case we
> have values?
>

>> Nobody is asking to reference it now. The current issue on the table to
>> to leave it undefined with only default value, so let's stick with the
>> current issue.
>>
>

Which was the agreement a few months ago. Let the IESG decide.

Thanks,
Greg

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 15 Feb 2018 09:28:45 -0800

> description out into a separate draft.
OK, and I agree that if such a registry is pulled and under a clear charter
of mandating multiple technologies within an independent body then a
discussion starts to make sense and what the size of that should be given
that mandates algorithms over multiple technologies (SR, unicast, mcast,
whatever) and implies a "God's eye view" of all the elements of all the
technologies (and if a computation touches elements from two technologies
they become [optionally] coupled).  We are not talking IGP registry or
multicast computation registry or SR registry then but a "wider scope
registry". Yes, that is an intriguing thought with its own validity but
outside the scope of charter we're under as BIER.  Personally, I consider
multiple, if needed loosely coupled registries for each technology a less
centralized and hence "more Internet like" solution but I see how opinions
on such a thing can diverge ...

thanks

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 15 Feb 2018 18:35:03 +0000

And the registry has already been created:

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, February 15, 2018 8:39 AM
To: Tony Przygienda <[email-masked]>
Cc: [email-masked]; [email-masked]; Xiejingrong <[email-masked]>; Jeff Tantsura <[email-masked]>; [email-masked]; Eric C Rosen <[email-masked]>
Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

For the record, there is no SR Registry. There is only an IGP Algo Type Registry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8.5

More inline:

On Thu, Feb 15, 2018 at 8:25 AM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
Under 8-bit artistic license granted by Acee herewith ;-)

First, I want to emphasize that this is IETF LC (called by Greg as shepherding WG chair) which means chairs have no further function so we all can only speak as individuals only .

2nd, I oppose any suggestion to align any kind of SR registry with BAR registry using 8 bits on couple of very simple grounds that my co-participants may have missed

a)       No IGP or SR working group has any charter to mandate any of the BIER technology so as well-meant the suggestion seems to be, it has no standing in IETF working procedures as far as I can see unless according charters are extended by ADs. Unless I'm missing something here.

If a WG points to a registry of any kind, a draft is all that is needed to justify an new entry in the registry.

b)       More as a question: Can we even publish an RFC now (experimental) pointing to an SR draft as normative? And if, how do we move it to intended standards track unless SR draft is a standards RFC?

Nobody is asking to reference it now. The current issue on the table to to leave it undefined with only default value, so let's stick with the current issue.

c)       Probably most importantly, technically, In case any of the SR computations starts to rely on elements advertised in SR to perform the computations, deployment of BIER will precondition deployment of SR in the network. Worse, if we need computation that needs BIER specific elements in its course, that would mean we have SR becoming aware of a multicast technology underneath. Unicast computations are simply not multicast computations longer-term  (and I had discussions about couple such cases already). Having multicast specific elements being considered in unicast computations and multicast computations being "standardized" in unicast computations couples everything with everything again known as the big-ball-of-yarn (unless THAT is the intention). In long experience things like this are simply a very bad architecture (TM ;-).

Again, it's an IGP Algo registry. It's documentation. There are no dependencies other than our references, which right now we don't have any.

3rd, I thought about the issues involved in BAR probably longer than anyone on the list here (remember Tree ID ;-) and I have a meta issue to make and then a finer one

a)      Independent of whether we end up with 8 or 16 bits I think we need a firm BIER BAR registry in place here (expert review?) and some document to gather the BAR ideas. Sooner the better. Ideas as in this thread are coming in it would be good to channelize them to prevent codepoint squatting or replicated effort. In fact we have a draft we circulated and we decided to push out today to give a strawman framework to the discussed use-cases. Granted, only the new charter (if given to us) would allow this work to be adopted but it’s good to have a vessel to contain the ideas already IMO. So check the new-publication queue ;-)

b)      Then, if we consider BAR as purely “special BIER nexthop computation” 8 bits sounds plenty but never underestimate new technology to stretch artistic boundaries and ideas you see here ;-) So if we think e.g. about things like the above mentioned draft-ietf-isis-segment-routing-extensions-15 proposal playing a role one could imagine that the “SR algorithm registry” specifies an algorithm that BAR registry likes to use as well 1:1. Simple, we just allocate a BIER BAR codepoint that is mapped (or even same) to the SR UCAST codepoint in this case (well, let discussion whether we would have the charter to do that or go ask for permission in SPRING outstanding for now). And that could be done of course via a TLV as well by using a single “BAR # meaning it’s an SR algorithm” and then a BIER sub-tlv saying which one of those. But things get finer. Let’s say we use a BAR=1 as BIER computation saying “avoid all non-BIER routers”. Now, that’s cool but maybe SR defined an algorithm we want to use on top as in “compute SPF with enough bandwidth”. For that could have a funky TLV saying “any BAR computation should stack this SR computation on top” but it would be then way more elegant to have a 16 bit with 8bit BAR from registry and then 8 bits of some context (in this example SR computation# to be stacked on top of the necessary BAR computation). Yes, that would precondition in such case simultaneous BIER and SR deployment but since then no technology forces mandatory use of another it’s flexible, open and nicely smelling. I hope at least some people could follow that and old IGP hands will see that this is actually as efficient in terms of actual implementation as a single set of constraints despite seeming complex.

I won’t stretch my artistic license further than 16 bits albeit there are even more interesting ideas I saw that would blow through this ;-) I probably owe Acee a beer in London already as it is.

So, in shorter form for the non-IGP cracks, I think 8 bits looks good but I see how 16 could have an elegance to channelize some of the suggestions (and get a "goldilocks solution"), if we e.g. decide to “stack algorithmic constraints from multiple technologies optionally on top of each other, each with its own registry that can refer to another”. This would accommodate also the proposal extended by Ice in a simple, clean, loosely coupled way by having 16 bits, first 8 bits as BIER type being a BIER BAR registry and 8 bits after that being “open” so e.g. being SR unicast registry number.
I do also think that if we get to such a consensus, adding text introducing test adding a BAR type/BAR subtype 16-bits field with a BAR type BIER registry into the documents is just a bit of text ...

As  I said, our draft will follow later today since some co-authors are in funky timezones ;-) …

thanks,
Greg

--- tony

On Thu, Feb 15, 2018 at 6:46 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:
Ice's reasoning makes sense to me.

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dospf-2Dsegment-2Drouting-2Dextensions-2D24-23section-2D8.5&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=wFHQGdbIofGfam7tl7rnRjckYdcPp1WR-BqnaNE1mV8&e=>

Thx,

Ice.
Sent from my iPad

Regards,
Jeff

https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_igp-2Dparameters_igp-2Dparameters.xhtml-23igp-2Dalgorithm-2Dtypes&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=5yaJPFqWpr5V5oBQ4O7o779WCOla79NlPw5FEfmRAUY&e=>

Thanks,
Acee

  Guys,

  Andrew

  -----Original Message-----
  From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of Xiejingrong <[email-masked]<mailto:[email-masked]>>
  Date: Wednesday, February 14, 2018 at 5:06 PM
  To: Arkadiy Gulko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
  Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

      Hi Arkadiy,

      Regards,
      XieJingrong

      -----Original Message-----
      From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
      Sent: Wednesday, February 14, 2018 8:42 AM
      To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
      Subject: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

      Hello Working Group,

      -----Original Message-----
      From: BIER [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
      Sent: Friday, February 09, 2018 5:11 PM
      To: [email-masked]<mailto:[email-masked]>
      Cc: [email-masked]<mailto:[email-masked]>
      Subject: [Bier] I-D Action: draft-ietf-bier-isis-extensions-07.txt

      Abstract:

      Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=qZ3p2sAIpzRPXfiRBbzrB1rPAkaJXEKiz43EmIKO03Y&e=>.

      _______________________________________________
      BIER mailing list
      [email-masked]<mailto:[email-masked]>
      https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>

      _______________________________________________
      BIER mailing list
      [email-masked]<mailto:[email-masked]>
      https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>

  _______________________________________________
  BIER mailing list
  [email-masked]<mailto:[email-masked]>
  https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=IpRPsLKtgfyfQk0dyhyVNsVupKQyUKWP_faic5jyDyo&s=0xv4y5W1l17zAz77Pqu_Jjah0kcuvYCJnnZSv6lUBEU&e=>

BIER mailing list

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 15 Feb 2018 19:50:56 +0100

I think its clear from the discussion there are different opinions on the matter on how to make BIER use the BAR field. The reason for me to support 16 bits is that everybody seemed ok go move forward with an 8bits BAR without a registry, a 16bits BAR does not change anything, its just a bigger field. But at least with 16bits, we can split in Type, Value, and support different use-cases. IMO, pointing to whatever the Unicast underlay is providing is the main use-case, but it allows other ways to do things.

One thing is clear, with just 8bits, it will be very hard to reach an agreement what the registry would look like. If we make it 16bits, we know we can solve multiple use-cases. The main question (I think) is whether we document how a 16bit BAR is carved up now, or we defer that to later. And as I said, since everybody seemed ok with 8bit BAR without a registry, I don’t see why its now different for 16bits. It gives us time to workout exactly how to use it and get input from the WGs.

And, of course, the goal is to create a registry for the 16 bits through a new draft!

Thx,

Ice.

> On 15 Feb 2018, at 18:28, Tony Przygienda <[email-masked]> wrote:
> 
> 
> 
> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[email-masked]> wrote:
> 
> 
> So is that a good idea, having multiple drafts in flight with fields expecting to have magic couplings to each other while leaving e'thing "unspecified" to "publish RFCs" while we "decide things later"? 
> 
> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around for a while, and the IGP Algo registry will be tied to this draft and it's fate. If anyone is expecting to use this registry outside of the scope of this draft, it would be in their best interest to pull the registry description out into a separate draft.
> 
> 
> OK, and I agree that if such a registry is pulled and under a clear charter of mandating multiple technologies within an independent body then a discussion starts to make sense and what the size of that should be given that mandates algorithms over multiple technologies (SR, unicast, mcast, whatever) and implies a "God's eye view" of all the elements of all the technologies (and if a computation touches elements from two technologies they become [optionally] coupled).  We are not talking IGP registry or multicast computation registry or SR registry then but a "wider scope registry". Yes, that is an intriguing thought with its own validity but outside the scope of charter we're under as BIER.  Personally, I consider multiple, if needed loosely coupled registries for each technology a less centralized and hence "more Internet like" solution but I see how opinions on such a thing can diverge ... 
> 
> thanks
> 
> --- tony 
>  
> 
>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Fri, 16 Feb 2018 03:38:43 +0000

Well,

Now, there are multiple treads being discussed here under one topic:

- how big should the the field be?
- should there be common registry for all technologies?
- where should it be defined and which WG should standardize it?

To me the first question is totally dependent on the answer to the last two, since the use case pointed out suggests a common registry.

Now there may be different opinions (I believe there are from this exchange) whether we should or should not have a common registry, how complicated would it be and whether it would tax all groups trying to use that. But even before we go there, the basic question has to be answered:
- which WG would own that registry. It is not in a charter of BIER to own it nor it is in a charter of SR nor it is in a charter of ISIS. Do none of them should own and mandate use. We are chartering LSR now - should we add registry for all IGP algorithms, we have routing WG, others?  Would like to hear AD’s opinion. Note that although LSR appears obvious, the algorithms to compute BIER may be controller-based that do bot require LSR (same applies to SR).

- if we do agree to have a common registry, I would assume we all then tax everyone to signal that the same way. That would mean changes to SR and changes to BIER.

This seems a lot. We have implementations of both technologies, so are changes to those warranted or is it too late and we should pursue independent  alg definition and registry as it has been set-up in the existing drafts. And we are talking only of those two but more WG will come and want to define things for them as well.

Andrew

Sent from my iPhone

On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:

Thx,

Ice.

On 15 Feb 2018, at 18:28, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <[email-masked]<mailto:[email-masked]>> wrote:
For the record, there is no SR Registry. There is only an IGP Algo Type Registry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8.5

thanks

--- tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Feb 2018 05:51:18 +0000

Andrew –

There is no change being considered to the size of the algorithm field for Segment Routing.  That is 8 bits – there are mature SR documents and multiple implementations that use that encoding. There is also the IGP registry defined in an SR document (though not necessarily exclusively for SR use) which defines 8 bit values.

The only thing which is being discussed here is whether BIER should use an 8 bit or 16 bit algorithm field. Also, even if it is decided BIER should use a 16 bit algorithm, it is conceivable that the values defined in the IGP algorithm registry may still be of use to BIER.

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Thursday, February 15, 2018 7:39 PM
To: IJsbrand Wijnands <[email-masked]>
Cc: Greg Shepherd <[email-masked]>; [email-masked]; [email-masked]; Xiejingrong <[email-masked]>; [email-masked]; Eric C Rosen <[email-masked]>
Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Well,

Andrew

Sent from my iPhone

Thx,

Ice.

thanks

--- tony

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 16 Feb 2018 09:44:42 -0500

Perhaps the following would be a good compromise (or perhaps not).

Have an eight-bit field whose values are taken from the "IGP Algorithms" 
Registry.

Have another eight-bit field whose values are taken from a new 
BIER-specific registry.  I don't know, maybe call it the "BIER Underlay 
Algorithm Modifier" registry.  The way the underlay paths are computed 
for a given BIER sub-domain is determined by the pair of codepoints: 
<IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.

The default value for the "BIER Underlay Algorithm Modifier" field would 
be zero.   The value zero in this field would mean "just use the IGP 
Algorithms field to figure out how the underlay paths are computed."  
Non-zero values could be used to add additional nuance. Existing drafts 
can say "the use of non-zero values in this field is outside the scope 
of this document".

The registration policy for the new registry could save about  half the 
values for "standards action", and about half for FCFS.  And a few for 
Experimental.  (This would be a good policy for the IGP Algorithms 
registry as well, imho.)

This seems to have minimal impact on existing implementations, and 
leaves room for further development of BIER while avoiding entanglements 
(or peceived entanglements) with other technologies that might be 
considered controversial.

Now perhaps the WG can proceed to the really important issues, such as 
how to best design the T-shirts.  (Though frankly I'd rather get a few 
more home-brewed beers than a T-shirt.)

On 2/16/2018 12:51 AM, Les Ginsberg (ginsberg) wrote:
>
> Andrew –
>
> There is no change being considered to the size of the algorithm field 
> for Segment Routing.  That is 8 bits – there are mature SR documents 
> and multiple implementations that use that encoding. There is also the 
> IGP registry defined in an SR document (though not necessarily 
> exclusively for SR use) which defines 8 bit values.
>
> The only thing which is being discussed here is whether BIER should 
> use an 8 bit or 16 bit algorithm field. Also, even if it is decided 
> BIER should use a 16 bit algorithm, it is conceivable that the values 
> defined in the IGP algorithm registry may still be of use to BIER.
>
> Les
>
> *From:*BIER [mailto:[email-masked]] *On Behalf Of *Dolganow, 
> Andrew (Nokia - SG/Singapore)
> *Sent:* Thursday, February 15, 2018 7:39 PM
> *To:* IJsbrand Wijnands <[email-masked]>
> *Cc:* Greg Shepherd <[email-masked]>; [email-masked]; 
> [email-masked]; Xiejingrong <[email-masked]>; 
> [email-masked]; Eric C Rosen <[email-masked]>
> *Subject:* Re: [Bier] [Isis-wg] WGLC : 
> draft-ietf-bier-isis-extensions-07.txt
>
> Well,
>
> To me the first question is totally dependent on the answer to the 
> last two, since the use case pointed out suggests a common registry.
>
> Now there may be different opinions (I believe there are from this 
> exchange) whether we should or should not have a common registry, how 
> complicated would it be and whether it would tax all groups trying to 
> use that. But even before we go there, the basic question has to be 
> answered:
>
> - which WG would own that registry. It is not in a charter of BIER to 
> own it nor it is in a charter of SR nor it is in a charter of ISIS. Do 
> none of them should own and mandate use. We are chartering LSR now - 
> should we add registry for all IGP algorithms, we have routing WG, 
> others?  Would like to hear AD’s opinion. Note that although LSR 
> appears obvious, the algorithms to compute BIER may be 
> controller-based that do bot require LSR (same applies to SR).
>
> - if we do agree to have a common registry, I would assume we all then 
> tax everyone to signal that the same way. That would mean changes to 
> SR and changes to BIER.
>
> This seems a lot. We have implementations of both technologies, so are 
> changes to those warranted or is it too late and we should pursue 
> independent  alg definition and registry as it has been set-up in the 
> existing drafts. And we are talking only of those two but more WG will 
> come and want to define things for them as well.
>
> Andrew
>
> Sent from my iPhone
>
>
>     I think its clear from the discussion there are different opinions
>     on the matter on how to make BIER use the BAR field. The reason
>     for me to support 16 bits is that everybody seemed ok go move
>     forward with an 8bits BAR without a registry, a 16bits BAR does
>     not change anything, its just a bigger field. But at least with
>     16bits, we can split in Type, Value, and support different
>     use-cases. IMO, pointing to whatever the Unicast underlay is
>     providing is the main use-case, but it allows other ways to do things.
>
>     One thing is clear, with just 8bits, it will be very hard to reach
>     an agreement what the registry would look like. If we make it
>     16bits, we know we can solve multiple use-cases. The main question
>     (I think) is whether we document how a 16bit BAR is carved up now,
>     or we defer that to later. And as I said, since everybody seemed
>     ok with 8bit BAR without a registry, I don’t see why its now
>     different for 16bits. It gives us time to workout exactly how to
>     use it and get input from the WGs.
>
>         On Thu, Feb 15, 2018 at 9:20 AM, Greg
>         Shepherd <[email-masked] <mailto:[email-masked]>> wrote:
>         On Thu, Feb 15, 2018 at 8:53 AM, Tony
>         Przygienda <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>
>         On Thu, Feb 15, 2018 at 8:38 AM, Greg
>         Shepherd <[email-masked] <mailto:[email-masked]>> wrote:
>         For the record, there is no SR Registry. There is only an IGP
>         Algo Type Registry as defined in
>         draft-ietf-ospr-segment-routing-extensions-24 section 8.5
>
>         So is that a good idea, having multiple drafts in flight with
>         fields expecting to have magic couplings to each other while
>         leaving e'thing "unspecified" to "publish RFCs" while we
>         "decide things later"?
>
>         Tangental: draft-ietf-ospr-segment-routing-extensions-24 has
>         been around for a while, and the IGP Algo registry will
>         be tied to this draft and it's fate. If anyone is expecting to
>         use this registry outside of the scope of this draft, it
>         would be in their best interest to pull the registry
>         OK, and I agree that if such a registry is pulled and under a
>         clear charter of mandating multiple technologies within
>         an independent body then a discussion starts to make sense and
>         what the size of that should be given that mandates
>         algorithms over multiple technologies (SR, unicast, mcast,
>         whatever) and implies a "God's eye view" of all the elements
>         of all the technologies (and if a computation touches elements
>         from two technologies they become [optionally] coupled).  We
>         are not talking IGP registry or multicast computation registry
>         or SR registry then but a "wider scope registry". Yes, that is
>         an intriguing thought with its own validity but outside the
>         scope of charter we're under as BIER.  Personally, I
>         consider multiple, if needed loosely coupled registries for
>         each technology a less centralized and hence "more Internet
>         like" solution but I see how opinions on such a thing can
>         diverge ...
>
>         thanks
>
>         --- tony
>
>
>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=vxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_isis-2Dwg&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=gRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Feb 2018 15:08:38 +0000

Eric -

From: Eric C Rosen [mailto:[email-masked]]
Sent: Friday, February 16, 2018 6:45 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; IJsbrand Wijnands <[email-masked]>
Cc: Greg Shepherd <[email-masked]>; [email-masked]; [email-masked]; Xiejingrong <[email-masked]>; [email-masked]
Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Have an eight-bit field whose values are taken from the "IGP Algorithms" Registry.

Have another eight-bit field whose values are taken from a new BIER-specific registry.  I don't know, maybe call it the "BIER Underlay Algorithm Modifier" registry.  The way the underlay paths are computed for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.

[Les:] Makes sense – except I would think only when the BUAM == 0 do the values come from IGP registry. Other values for BUAM would require a different set of definitions for the algorithm value.
   Les

The default value for the "BIER Underlay Algorithm Modifier" field would be zero.   The value zero in this field would mean "just use the IGP Algorithms field to figure out how the underlay paths are computed."  Non-zero values could be used to add additional nuance.  Existing drafts can say "the use of non-zero values in this field is outside the scope of this document".

The registration policy for the new registry could save about  half the values for "standards action", and about half for FCFS.  And a few for Experimental.  (This would be a good policy for the IGP Algorithms registry as well, imho.)

This seems to have minimal impact on existing implementations, and leaves room for further development of BIER while avoiding entanglements (or peceived entanglements) with other technologies that might be considered controversial.

Now perhaps the WG can proceed to the really important issues, such as how to best design the T-shirts.  (Though frankly I'd rather get a few more home-brewed beers than a T-shirt.)

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Nokia - SG/Singapore)
Sent: Thursday, February 15, 2018 7:39 PM
To: IJsbrand Wijnands <[email-masked]><mailto:[email-masked]>
Cc: Greg Shepherd <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Xiejingrong <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Eric C Rosen <[email-masked]><mailto:[email-masked]>
Subject: Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Well,

Andrew

Sent from my iPhone

Thx,

Ice.

thanks

--- tony

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=vxlvDI3ihNiRYhMD9FOOhdgHsUytgoyTrVRAkLXqc5U&e=>

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_isis-2Dwg&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=6OA-v6Lzq8oR77r5sobl4BRPQbtAOImezBFZ2ljFIHA&s=gRpwwZhHBYgy3mRmJHvKkTmqciLemxC0YhCk0qAATNg&e=>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Sat, 17 Feb 2018 02:18:20 +0000

Agree, what Eric has is starting to look like a compromise. Let’s get the final text (wip) on the list asap.

Andrew

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Friday, February 16, 2018 at 11:08 PM
To: Eric Rosen <[email-masked]>, Andrew Dolganow <[email-masked]>, "(Ice) IJsbrand Wijnands" <[email-masked]>
Cc: Greg Shepherd <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Xiejingrong <[email-masked]>, Arkadiy Gulko <[email-masked]>
Subject: RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-extensions-07.txt

Eric -

   Les

Well,

Andrew

Sent from my iPhone

Thx,

Ice.

thanks

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 16 Feb 2018 18:29:31 -0800

I'm working on a strawman of what I understood we seem to agree on for
further comments in detail, ETA tommorow ...

On Fri, Feb 16, 2018 at 6:18 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

> *From: *"Les Ginsberg (ginsberg)" <[email-masked]>
> *Date: *Friday, February 16, 2018 at 11:08 PM
> *To: *Eric Rosen <[email-masked]>, Andrew Dolganow <
> [email-masked]>, "(Ice) IJsbrand Wijnands" <[email-masked]>
> *Cc: *Greg Shepherd <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, Xiejingrong <[email-masked]>,
> Arkadiy Gulko <[email-masked]>
> *Subject: *RE: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Eric -
>
>
>
> *From:* Eric C Rosen [mailto:[email-masked]]
> *Sent:* Friday, February 16, 2018 6:45 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Dolganow, Andrew
> (Nokia - SG/Singapore) <[email-masked]>; IJsbrand Wijnands <
> [email-masked]>
> *Cc:* Greg Shepherd <[email-masked]>; [email-masked]; [email-masked];
> Xiejingrong <[email-masked]>; [email-masked]
> *Subject:* Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Algorithm Modifier" registry.  The way the underlay paths are computed for
> a given BIER sub-domain is determined by the pair of codepoints: <IGP
> Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.
>
>
> *[Les:] Makes sense – except I would think only when the BUAM == 0 do the
> values come from IGP registry. Other values for BUAM would require a
> different set of definitions for the algorithm value.*
>
> *   Les*
>
>
> can say "the use of non-zero values in this field is outside the scope of
> this document".
>
> Experimental.  (This would be a good policy for the IGP Algorithms registry
> as well, imho.)
>
> This seems to have minimal impact on existing implementations, and leaves
> room for further development of BIER while avoiding entanglements (or
> peceived entanglements) with other technologies that might be considered
> controversial.
>
> Now perhaps the WG can proceed to the really important issues, such as how
> to best design the T-shirts.  (Though frankly I'd rather get a few more
> home-brewed beers than a T-shirt.)
>
>
>
> There is no change being considered to the size of the algorithm field for
> Segment Routing.  That is 8 bits – there are mature SR documents and
> multiple implementations that use that encoding. There is also the IGP
> registry defined in an SR document (though not necessarily exclusively for
> SR use) which defines 8 bit values.
>
>
>
> The only thing which is being discussed here is whether BIER should use an
> 8 bit or 16 bit algorithm field. Also, even if it is decided BIER should
> use a 16 bit algorithm, it is conceivable that the values defined in the
> IGP algorithm registry may still be of use to BIER.
>
>
>
>    Les
>
>
>
> *From:* BIER [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Dolganow, Andrew (Nokia - SG/Singapore)
> *To:* IJsbrand Wijnands <[email-masked]> <[email-masked]>
> *Cc:* Greg Shepherd <[email-masked]> <[email-masked]>; [email-masked];
> [email-masked]; Xiejingrong <[email-masked]>
> <[email-masked]>; [email-masked]; Eric C Rosen
> <[email-masked]> <[email-masked]>
> *Subject:* Re: [Bier] [Isis-wg] WGLC : draft-ietf-bier-isis-
> extensions-07.txt
>
>
>
> Well,
>
>
>
> To me the first question is totally dependent on the answer to the last
> two, since the use case pointed out suggests a common registry.
>
>
>
> complicated would it be and whether it would tax all groups trying to use
> that. But even before we go there, the basic question has to be answered:
>
> - which WG would own that registry. It is not in a charter of BIER to own
> it nor it is in a charter of SR nor it is in a charter of ISIS. Do none of
> them should own and mandate use. We are chartering LSR now - should we add
> registry for all IGP algorithms, we have routing WG, others?  Would like to
> hear AD’s opinion. Note that although LSR appears obvious, the algorithms
> to compute BIER may be controller-based that do bot require LSR (same
> applies to SR).
>
>
>
> - if we do agree to have a common registry, I would assume we all then tax
> everyone to signal that the same way. That would mean changes to SR and
> changes to BIER.
>
>
>
> existing drafts. And we are talking only of those two but more WG will come
> and want to define things for them as well.
>
>
>
> Andrew
>
>
>
> Sent from my iPhone
>
>
> On Feb 16, 2018, at 2:51 AM, IJsbrand Wijnands <[email-masked]> wrote:
>
> I think its clear from the discussion there are different opinions on the
> matter on how to make BIER use the BAR field. The reason for me to support
> 16 bits is that everybody seemed ok go move forward with an 8bits BAR
> without a registry, a 16bits BAR does not change anything, its just a
> bigger field. But at least with 16bits, we can split in Type, Value, and
> support different use-cases. IMO, pointing to whatever the Unicast underlay
> is providing is the main use-case, but it allows other ways to do things.
>
>
>
> One thing is clear, with just 8bits, it will be very hard to reach an
> agreement what the registry would look like. If we make it 16bits, we know
> we can solve multiple use-cases. The main question (I think) is whether we
> document how a 16bit BAR is carved up now, or we defer that to later. And
> as I said, since everybody seemed ok with 8bit BAR without a registry, I
> don’t see why its now different for 16bits. It gives us time to workout
> exactly how to use it and get input from the WGs.
>
>
>
> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <[email-masked]
> > wrote:
>
>
> OK, and I agree that if such a registry is pulled and under a clear
> charter of mandating multiple technologies within an independent body then
> a discussion starts to make sense and what the size of that should be given
> whatever) and implies a "God's eye view" of all the elements of all
> the technologies (and if a computation touches elements from two
> technologies they become [optionally] coupled).  We are not talking IGP
> registry or multicast computation registry or SR registry then but a "wider
> scope registry". Yes, that is an intriguing thought with its own validity
> but outside the scope of charter we're under as BIER.  Personally, I
> consider multiple, if needed loosely coupled registries for each technology
> a less centralized and hence "more Internet like" solution but I see how
> opinions on such a thing can diverge ...
>
> thanks
>
> --- tony
>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 17 Feb 2018 09:31:12 -0800

+1

Regards,
Jeff

> On Feb 16, 2018, at 18:18, Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]> wrote:
>