Subject: [Bier] architecture rev 3

From: Eric C Rosen <[email-masked]>
Date: Tue, 27 Jan 2015 15:54:52 -0500

I've just posted rev 3 of the architecture draft.

In this rev, I've tried to clarify a number of issues having to do with 
the BitStringLength, and have added a section about choosing the 
BitStringLength, and what to do when there is a BitStringLength mismatch 
between a BFR and its next hop BFR.

I don't know if I've correctly captured the consensus (or if there is a 
consensus to capture), but hopefully what we do or do not agree on will 
become clearer ;-)

I have also added a section incorporating the "What if not all nodes 
support BIER" material outlined in my Jan 6 message to the mailing list. 
  (Albert Tian, in his reply to my message, had an excellent suggestion 
for how to integrate that material seamlessly into the architecture. 
However, for the time being I thought it might be better to call 
attention to it explicitly by keeping it in a separate section.)

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 28 Jan 2015 04:56:40 +0000

read, agree with all. 

1. I don't think that MUST'ing of a specific mapping on the node to a specific bitstringlength is necessary (i.e. it is sufficient but not necessary). A node can easily compute the bitstringlength that all support & it prefers or otherwise use 256 (this in case of IGP).   
2. The draft is still non-committal whether encapsualtion translation (beside bitstring length for same encapsulation type) is supported by architecture. I think it should not, given that we imply then that every BFR MUST support all encapsulations lest it cannot forward to the next neighbor. 
3. The unicast tunneling is indeed clever and seems to hold up on first read. 

thanks   

--- tony 

> -----Original Message-----
> From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
> Sent: Tuesday, January 27, 2015 12:55 PM
> To: BIER
> Cc: [email-masked]
> Subject: [Bier] architecture rev 3
> 
> In this rev, I've tried to clarify a number of issues having to do with the
> BitStringLength, and have added a section about choosing the BitStringLength,
> and what to do when there is a BitStringLength mismatch between a BFR and its
> next hop BFR.
> 
> I don't know if I've correctly captured the consensus (or if there is a consensus
> to capture), but hopefully what we do or do not agree on will become clearer ;-)
> 
> I have also added a section incorporating the "What if not all nodes support
> BIER" material outlined in my Jan 6 message to the mailing list.
>   (Albert Tian, in his reply to my message, had an excellent suggestion for how to
> integrate that material seamlessly into the architecture.
> However, for the time being I thought it might be better to call attention to it
> explicitly by keeping it in a separate section.)
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier