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

[Tony Przygienda <[e-mail]>]

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 <[e-mail]> wrote:

> Ice's reasoning makes sense to me.
>
>
> On 2/15/2018 3:11 AM, IJsbrand Wijnands (iwijnand) wrote:
>
> 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
> <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
>
> On 15 Feb 2018, at 07:24, Jeff Tantsura <[e-mail]> 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) <[e-mail]> 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
> <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)" <[e-mail] on behalf of
> [e-mail]> 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 <[e-mail]> on behalf of Xiejingrong <
> [e-mail]>
>
>   Date: Wednesday, February 14, 2018 at 5:06 PM
>
>   To: Arkadiy Gulko <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
>
>   Subject: Re: [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
>
>
>       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:[e-mail] <[e-mail]>]
> On Behalf Of [e-mail]
>
>       Sent: Wednesday, February 14, 2018 8:42 AM
>
>       To: [e-mail]; [e-mail]
>
>       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:[e-mail] <[e-mail]>]
> On Behalf Of [e-mail]
>
>       Sent: Friday, February 09, 2018 5:11 PM
>
>       To: [e-mail]
>
>       Cc: [e-mail]
>
>       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
> <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=>
> .
>
>
>       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
>
>       [e-mail]
>
>       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
>
>       [e-mail]
>
>       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
>
>       [e-mail]
>
>       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
>
>   [e-mail]
>
>   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
>
> [e-mail]
>
> 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
> [e-mail]
> 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 [e-mail]
> 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=
>
>
>
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>