Re: [Bier] [babel] About bierin6 and signalling of encapsulation

1. If we follow today's downstream assigned IGP signalling, each BFR can
choose whatever they want to the next hop as long they have a binding. They
know what the next router supports from its advertisements.  Observe that
the SD binding is encapsulation neutral (i.e. it can advertise multiple
encapsulations per same SI,BML).
2. If BIER relies on the non-MPLS-hard-coded-global-"label" then yes, we
either provision per next neighbor what are viable encapsulations or need
somehow to advertise those. Given we have to advertise whether a router
supports BIER advertising supported encaps doesn't seem to make much
difference to me.
3. I would also abstain from extending hellos

--- tony

On Mon, Nov 20, 2017 at 7:47 AM, Eric C Rosen <erosen@juniper.net> wrote:

> I think the model is that a BFR knows by virtue of provisioning what
> encapsulation to use by default when transmitting a BIER packet.  If a BFR
> has certain interfaces that lead, e.g., from an MPLS network to an
> IPv6-only network, those interfaces can be provisioned so that the BFR
> knows to use a specified non-default encapsulation when transmitting a BIER
> packet over those interfaces.
>
> In that model, there is no real need for every BFR to know the set of
> encapsulations that every other BFR can receive.
>
> To transition a backbone from one encapsulation to another, one would have
> to first provision all the BFRs to be able to receive both encapsulations.
> Then one could change the default transmission encapsulation on the BFRs
> one by one.
>
> This model doesn't really support hop-by-hop changing of the encapsulation
> very well, since there is no signaling of the supported encapsulation.  But
> is there really a practical need to optimize for the situation in which
> every hop uses a different encapsulation than the one before?
>
> Juliusz> I'm probably missing something, but I only see three solutions:
>>
>>    1. statically configured (e.g. a given BIER domain is statically
>>       configured to use a given encapsulation);
>>
>
> As suggested above.
>
>
>>    2. carried by a specific signalling protocol (call it the BIER Hello
>>       Protocol for now);
>>
>
> I would avoid this.  Hello protocols always seem like they're going to be
> simple, and then turn up being nightmares.  Note that BIER neighbors are
> not necessarily layer 2  neighbors, and once we start sending Hellos that
> are not link-local, the Hellos are easy to attack and we end up with some
> thorny security issues.  I'd certainly want to avoid creating new soft
> state flooding mechanisms for passing BIER control information, as we're
> supposed to be simplifying things rather than making them more complicated.
>
>
>>    3. carried by the routing protocol (e.g. carried by a sub-TLV of the
>> IHU
>>       TLV in Babel, or using RFC 5613 signalling in OSPF).
>>
>
> IF there is really a practical need for dynamic signaling of "here is the
> list of BIER encapsulations I can parse", adding that information to the
> existing BIER control signaling mechanisms makes sense.  (It's analogous to
> the distribution of information about the supported Disposition BSLs).
>
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>