Subject: [babel] About bierin6 and signalling of encapsulation

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 16 Nov 2017 15:44:19 +0100

Hi,

Crossposted between BIER and Babel.

Thanks a lot to Sandy for presenting bierin6 this morning at the Babel
meeting.  I asked a question about how encapsulation is signalled, and
Tony answered it doesn't matter.  He's probably right, but I need an
explanation.

Suppose a BIER router A has a neighbour B.  From the routing protocol, it
has learnt that frames with a given bit index set are to be forwarded to
B.  How does it know which among the different BIER encapsulations to use
in order to send its BIER frames to B?

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);

  2. carried by a specific signalling protocol (call it the BIER Hello
     Protocol for now);

  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).

So what's the vision here?

-- Juliusz

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 17 Nov 2017 01:06:04 +0800

you simply pick either one, it's a hop-by-hop decision. Sufficient. That
way we can simply run BIERin6 first and then add the ether cap TLV and
start to remove the BIERin6 encaps TLVs (given SD,SI,BML are same) ...

--- tony

On Thu, Nov 16, 2017 at 10:44 PM, Juliusz Chroboczek <[email-masked]> wrote:

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 16 Nov 2017 18:16:49 +0100

> you simply pick either one, it's a hop-by-hop decision.

What if A implements both encapsulations, and B only implements bierin6?
If A picks the native encapsulation, you've created a blackhole, no?

-- Juliusz

---

From: Zhang Z <[email-masked]>
Date: Fri, 17 Nov 2017 02:31:10 +0000

Hi Juliusz,

1. statically configured (e.g. a given BIER domain is statically
     configured to use a given encapsulation);
Sandy: Yes, static configuration provides a simple way to implement bier forwarding.

  2. carried by a specific signalling protocol (call it the BIER Hello
     Protocol for now);
Sandy: Bier node information is advertised by IGP/ BGP protocol (as you mentioned "Bier hello protocol"), Bift-id is the key to find the corresponding forwarding item. But there's no restriction for the out-layer encapsulation. In fact, the Bier packets can be executed correctly whatever the out-layer is, such as Mpls, Ethernet or IPv6, and so on. The out-layer encapsulation is only used to make sure the Bier packet can be received correctly by the next hop router.
To your example, A sends the bier packet with whatever encapsulation, indeed the packet will be received and executed correctly by B. A should choose a reasonable encapsulation method though it can choose the method optionally. In fact there's consensus in one bier domain.

  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).
Sandy: You needn't do that. But you can try if you insist on it.
________________________________
发件人: babel <[email-masked]> 代表 Juliusz Chroboczek <[email-masked]>
发送时间: 2017年11月17日 1:16:49
收件人: Tony Przygienda
抄送: [email-masked]; Babel at IETF
主题: Re: [babel] [Bier] About bierin6 and signalling of encapsulation

-- Juliusz

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 17 Nov 2017 11:34:23 +0100

> In fact there's consensus in one bier domain.

I'm not sure I'm happy with that.  For one, it means that you cannot
migrate a domain incrementally.

-- Juliusz

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 17 Nov 2017 23:33:19 +0800

either encapsulation can be picked and with that migration is trivial ...

Again, architecture doesn't spell that out but if SD/SI/BML match you can
use any encaps to reach the neighbor

--- tony

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 20 Nov 2017 10:47:33 -0500

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:
>

As suggested above.

>    2. carried by a specific signalling protocol (call it the BIER Hello

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.

>       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).

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 20 Nov 2017 13:07:31 -0800

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

> 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
> knows to use a specified non-default encapsulation when transmitting a BIER
> packet over those interfaces.
>
> 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?
>
> 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.
>
>
> 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).
>
>