Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT)

From: Alia Atlas <[email-masked]>
Date: Sat, 14 Feb 2015 19:19:45 -0500

Hi Joel,

On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli <[email-masked]> wrote:

> Joel Jaeggli has entered the following ballot position for
> charter-ietf-bier-00-01: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/charter-ietf-bier/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> So the size of the bier domain is bounded I suppose by the number of
> egress points you're willing to include in your header. given the
> inherent suitability of such a method for overlays it seems like it
> distinctly bounds the size of such an overlay based on the header size/
> if you chain bier domains (no subdomain) how do you do loop detection (or
> don't you).
>

The bier-ingress router can do a bit of ingress replication, if needed.
Basically,
only one "word" of the bitmap is in the packet and the bier-ingress
replicates once
for each different word that needs to be sent to.  One of the questions, of
course,
is how many bits are in a word.  At 1024 or 2048, that handles much larger
networks
but requires more bits in the header to be available for processing than at
256.

I haven't yet seen any ideas describing chaining bier domains.  I think
between
bier domains it would default up to the tree-building protocol.  Possibly
one of the
bier proponents will have more ideas.

Thanks for the early review!
Alia

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 15 Feb 2015 09:49:42 -0000

While Alia may be right that no-one has discussed chaining BIER domains, the charter wording gave me the impression that this was "perfectly reasonable." Thus, a packet exiting one domain might then be injected into a new domain.
 
<gratuitous analogy>
Consider, for example, the work that has been done on P2MP RSVP-TE where the ingress domain builds a tree to reach all of the egress nodes it owns and also each of the downstream domains. But it doesn't know the tree across the downstream domains.
</gratuitous analogy>
 
And Joel's concern about looping is valid.
Of course, a solution could be developed.
 
But how about this charter limit the work to a single domain?
 
Adrian

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: 15 February 2015 00:20
To: Joel Jaeggli
Cc: Greg Shepherd; [email-masked]; The IESG; Tony Przygienda
Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT)
 
Hi Joel,

 
The bier-ingress router can do a bit of ingress replication, if needed.  Basically,
only one "word" of the bitmap is in the packet and the bier-ingress replicates once
for each different word that needs to be sent to.  One of the questions, of course,
is how many bits are in a word.  At 1024 or 2048, that handles much larger networks
but requires more bits in the header to be available for processing than at 256.
 
I haven't yet seen any ideas describing chaining bier domains.  I think between
bier domains it would default up to the tree-building protocol.  Possibly one of the
bier proponents will have more ideas.

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Sun, 15 Feb 2015 16:24:25 +0000

Hi Folks,

Procedures for stitching such 'domains' together are documented in rfc6514 and called 'Segmented Inter-AS MVPN'. I think the exact same procedures can be applied to BIER domains. These procedures where developed in the context of L3VPN. If any updates are need I would think this work belongs in BESS. So limiting the scope to single domain in the BIER charter is ok with me.

Thx,

Ice.

Sent from my iPad

On 15 Feb 2015, at 10:50, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

<gratuitous analogy>

Adrian

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: 15 February 2015 00:20
To: Joel Jaeggli
Cc: Greg Shepherd; [email-masked]<mailto:[email-masked]>; The IESG; Tony Przygienda
Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT)

Hi Joel,

On Sat, Feb 14, 2015 at 4:47 PM, Joel Jaeggli <[email-masked]<mailto:[email-masked]>> wrote:
Joel Jaeggli has entered the following ballot position for
charter-ietf-bier-00-01: No Objection

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

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 15 Feb 2015 17:42:16 +0000

<hat type="individual cat of the herd">

are we talking a single AD ? or a single BIER domain ?  Out the context I read we're talking AD ? Then yes, I do think I agree with Ice here (as in this being basically inter-AS VPNs problem and with that probably BESS work).

I sent some explanations about the size of a BIER domain to reflect on Joel's comments and the chaining _within_ an AD (assuming e.g. that a BIER domain could be an IGP area only or two IGPs interact). Didn't see it pass the mailer. pasted below with minor editorials

</hat>

thanks

--- tony

Yes, ideas as to chaining & even translation between BIER domains are here, some even written down but have been withheld to not overwhelm the community before the WG is established properly. Yes, it will amount to same thing as OSPF area problem or a distance vector protocol if things get fancy (maybe piggy-backed on BGP even which I do not foresee).
As to size of a domain, it's pretty much arbitrary as far as practical problem addressed goes. What Alia calls 'word size' and we call 'bitstring length' only determines how many receivers can be marked up on a packet. It's only a 'partitioning' scheme of a sub-domain where each 'bitstring length' represents a subset of receivers. We have the limitation of a BFR-id being currently 2 bytes which leaves us with 65'535 BFER (receivers) but given the P-routers don't need one (BIER routers that do not have to act as receivers) we are talking much larger domain in terms of devices albeit surely not enough for large scale multicast in the millions of receivers (which as a problem, frankly, this technology should not be addressing currently)

Additionally, I forgot to mention, BIER supports the concept of a subdomain which, due to the fact that a BFR-id is subdomain-specifc can ultimately ;support 255*65'535 receivers over the same domain albeit those are separated into the said sub-domains. Multiply that with the fact that a subdomain can run on a different multi-topology (if signalled via IGP) and I think we have a very wide, albeit orthogonal 'addressing' scheme here that should support very wide number of implementations (pure P-routers with a single topology, single-subdomain support, single bitstring length) all the way to very sizable deployments separating BIER traffic based on topology and subdomain membership and allowing for provisioning of rich service infrastructures for providers.
Do I sound like a commercial, I probably do ;-)

From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Sunday, February 15, 2015 8:24 AM
To: <[email-masked]>
Cc: Joel Jaeggli; Greg Shepherd; [email-masked]; The IESG
Subject: Re: [Bier] Joel Jaeggli's No Objection on charter-ietf-bier-00-01: (with COMMENT)

Hi Folks,

Thx,

Ice.

Sent from my iPad

<gratuitous analogy>

Adrian

Hi Joel,

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 17 Feb 2015 10:13:00 -0500

On 2/15/2015 4:49 AM, Adrian Farrel wrote:
> how about this charter limit the work to a single domain?

I really don't see any reason for the charter to limit the work to a 
single domain.

If you look at draft-rosen-l3vpn-mvpn-bier, for example, it does support 
multiple domains.  One could argue whether that draft belongs in BIER or 
BESS, but of course the answer is "both".  We don't want to get into a 
situation where BIER can't consider it because it is "out of charter", 
and then BESS can't consider it because it is about BIER but outside 
BIER's charter.

This sort of issue can be left in the hands of the WG(s).  Too many 
details and restrictions in the charter just leads to a lot of politics. 
  (The real "poster child" for the dangers of an overly constraining 
charter is PPVPN.  All kinds of nonsense was put in the charter to 
ensure that the work that came out would be significantly different than 
the work that went in.  This delayed formal publication of the work for 
seven years, but in the end the work that came out was substantially the 
same as the work that went in, and market penetration was not at all 
delayed.  But there was lots and lots of annoying politics.)

One issue that the process wonks might want to think about is codepoint 
allocation.  If there is not going to be a mechanism for the early 
allocation of codepoints, one can anticipate that there will be lots of 
codepoint squatting, with the usual set of hassles arriving later.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 17 Feb 2015 15:51:29 +0000

> I really don't see any reason for the charter to limit the work to a single domain.
> 
> If you look at draft-rosen-l3vpn-mvpn-bier, for example, it does support multiple
> domains.  One could argue whether that draft belongs in BIER or BESS, but of
> course the answer is "both".  We don't want to get into a situation where BIER
> can't consider it because it is "out of charter", and then BESS can't consider it
> because it is about BIER but outside BIER's charter.

 [Tony said]  hmmm, good point. BESS are in fact busy gophers and it's not hypothetical. 

> allocation.  If there is not going to be a mechanism for the early allocation of
> codepoints, one can anticipate that there will be lots of codepoint squatting,
> with the usual set of hassles arriving later.

[Tony said]  hmmm, good point again. Within BIER itself, we can keep an informational and update it (works quite well is my experience) but in IGPs [and things like IMET/BESS] I fully agree. 

--- tony

---

From: "Joel Jaeggli" <[email-masked]>
Date: Sat, 14 Feb 2015 13:47:25 -0800