Subject: [babel] About BIER in Babel

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Mar 2017 15:47:21 -0500

Dear Sandy, dear all,

I think there are very good reasons why it would be interesting to
experiment with BIER and Babel.  As you explained, there are at least two
approaches worth considering:

  - announce BIER routing directly in Babel, as your draft suggests;
  - use MLD with Babel.

I am not competent to judge which approach is suitable, but it is clearly
attractive to run a single protocol.

As I mentioned at the mike, there are a number of problems with your
encoding.  My personal intuition would be to use a new AE number for BIER,
but of course someone would need to write it down and check the details.

As David mentioned, some of us would feel much more comfortable if there
were a prototype implementation before we are asked to adopt your draft.
I would be interested in helping, but I have neither the competence nor
the manpower to do the implementation on my own.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Tue, 28 Mar 2017 14:48:32 -0700

... up until this moment I was mostly ignorant of bier. I may well
still be overly ignorant, but read on.

> but of course someone would need to write it down and check the details.

However, leveraging this encoding over the others in the core draft seems
straightforward to encapsulate into an ae with no afteraffects
elsewhere in babel.

https://datatracker.ietf.org/doc/html/draft-pfister-bier-over-ipv6

4096 bits (maximum requirement for bier), on the other hand, breaks
everything (babel mtu requirement while still fitting in everything
else),

while (the minimum requirement) of 256 bits may well look a lot like
how the new source specific ae is formed.

if there are other docs in that wg worth reading, running code on
linux, or other use cases, please point me at em!

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

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Alia Atlas <[email-masked]>
Date: Tue, 28 Mar 2017 19:06:17 -0400

Hi Dave,

Take a look at
https://datatracker.ietf.org/doc/html/draft-ietf-bier-architecture
and https://datatracker.ietf.org/doc/html/draft-ietf-bier-mpls-encapsulation
.
The latter allows use over Ethernet (despite the old draft title).  The
IPv6 encapsulation does not have WG agreement to adopt and wasn't discussed
this IETF.

Regards,
Alia

---

From: Zhang Z <[email-masked]>
Date: Tue, 28 Mar 2017 23:14:43 +0000

Hi Juliusz and all,
At first I must apology about the misunderstanding caused by the two drafts. One is “draft-zhang-bier-babel-extensions-00”, it was presented in Seoul meeting; it is the BIER Routing underlay technology. The other one is “draft-zhang-pim-babel-ext-02”, it was presented in this meeting. It is multicast flow overlay technology. The two drafts focus on different aspect of BIER technology. And the two drafts are independent though we can use them together. The man who is not familiar with BIER will be confused about it. The first draft “draft-zhang-bier-babel-extensions-00” had been discussed in BIER working group and many people thought that it is worth implemented. The second draft “draft-zhang-pim-babel-ext-02” is just an idea for multicast flow overlay. And the implementation that we discussed today is “draft-zhang-bier-babel-extensions-00”.
I suggest strongly that the draft “draft-ietf-bier-architecture-05” should be read first. You will know the meaning of Routing underlay/ BIER layer/ Multicast Flow Overlay. The three layers are focus on different aspect of BIER technology. Routing underlay is used to transfer BFR-id corresponding information. There are OSPF/ ISIS/ BGP BIER extension in BIER working group. You can find them through the link “https://tools.ietf.org/wg/bier/”. In fact, the draft “draft-zhang-bier-babel-extensions-00” also belongs to Routing underlay layer. And this draft is worth implemented first.
The draft “draft-zhang-pim-babel-ext-02” belongs to Multicast Flow Overlay. This layer is used to transfer particular multicast flow information. And there is also a draft “draft-pfister-bier-mld-03” that is used to solve it. And the “draft-pfister-bier-mld-03” is the function that we call MLD in abbreviation.
So, you will see that we can use “draft-zhang-bier-babel-extensions-00” and “draft-pfister-bier-mld-03” together to solve the Routing Underlay and Multicast Flow Overlay. It is Babel + MLD solution. And many people include me think that it is a good way to achieve the multicast deployment.
The way that I said use one protocol to solve multicast problem is that we use “draft-zhang-bier-babel-extensions-00” and “draft-zhang-pim-babel-ext-02” at the same time. In this situation we only use one protocol Babel to solve Routing underlay and Multicast flow overlay. This function is just an idea. And it means nothing if there is no situation that we can only use one protocol to deploy multicast.
In a word, we should consider the implementation of “draft-zhang-bier-babel-extensions-00”. The BIER forwarding plane software had also been implemented by ZTE, and I think Cisco does it also. So at first it should be considered that how to merge Babel protocol and BIER forwarding software together. And then implement “draft-zhang-bier-babel-extensions-00”.

Thanks,
Sandy

________________________________
发件人: babel <[email-masked]> 代表 Juliusz Chroboczek <[email-masked]>
发送时间: 2017年3月29日 4:47
收件人: [email-masked]
抄送: [email-masked]
主题: [babel] About BIER in Babel

Dear Sandy, dear all,

-- Juliusz

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 28 Mar 2017 23:31:29 +0000

> On Mar 28, 2017, at 6:14 PM, Zhang Z <[email-masked]> wrote:
> 
>  Hi Juliusz and all,
> I suggest strongly that the draft “draft-ietf-bier-architecture-05” should be read first. You will know the meaning of Routing underlay/ BIER layer/ Multicast Flow Overlay. The three layers are focus on different aspect of BIER technology. Routing underlay is used to transfer BFR-id corresponding information. There are OSPF/ ISIS/ BGP BIER extension in BIER working group. You can find them through the link “https://tools.ietf.org/wg/bier/ <https://tools.ietf.org/wg/bier/>”. In fact, the draft “draft-zhang-bier-babel-extensions-00” also belongs to Routing underlay layer. And this draft is worth implemented first.

+ 10E3

> The way that I said use one protocol to solve multicast problem is that we use “draft-zhang-bier-babel-extensions-00” and “draft-zhang-pim-babel-ext-02” at the same time. In this situation we only…

overlays will be plentiful and they will be a continuum between simplicity and scale … 

> In a word, we should consider the implementation of “draft-zhang-bier-babel-extensions-00”. The BIER forwarding plane software had also been implemented by ZTE, and I think Cisco does it also. So a…

There is an interesting ongoing discussion about Linux kernel software implementation to some extent/socket APIs … 

— tony

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 28 Mar 2017 23:43:26 +0000

+ 10E3

— tony

---

From: Dave Taht <[email-masked]>
Date: Tue, 28 Mar 2017 17:09:50 -0700

On Tue, Mar 28, 2017 at 4:06 PM, Alia Atlas <[email-masked]> wrote:
> and
> https://datatracker.ietf.org/doc/html/draft-ietf-bier-mpls-encapsulation.
> The latter allows use over Ethernet (despite the old draft title).  The IPv6
> encapsulation does not have WG agreement to adopt and wasn't discussed this
> IETF.

Even after reading more, I don't really "get it".  The list of use cases

https://datatracker.ietf.org/doc/html/draft-ietf-bier-use-cases

do not include most of babel's existing ones - I don't imagine more
than 5 tvs per household carrying the superbowl, nor a home with
thousands of cameras and hard disks streaming. At a data-center or
city-scale, I can see how some of this technology would be helpful
(but it's still difficult for me to wrap my head around using up 4096
bits in a single message)

Furthermore, babel is a dv protocol and doesn't need to carry all that
many bits, all the time. One bit pointing at the multicast superbowl
group within the local network would be enough.

I will read on, and perhaps enlightenment will strike.

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 28 Mar 2017 22:50:41 -0500

Hello Alia and Dave,

> Le 28 mars 2017 à 18:06, Alia Atlas <[email-masked]> a écrit :
> 
> Hi Dave,
> 
> Take a look at https://datatracker.ietf.org/doc/html/draft-ietf-bier-architecture <https://datatracker.ietf.org/doc/html/draft-ietf-bier-architecture>
> and https://datatracker.ietf.org/doc/html/draft-ietf-bier-mpls-encapsulation <https://datatracker.ietf.org/doc/html/draft-ietf-bier-mpls-encapsulation>.
> The latter allows use over Ethernet (despite the old draft title).  The IPv6 encapsulation does not have WG agreement to adopt and wasn't discussed this IETF.

It was not discussed this IETF indeed, but was discussed the ietf before, and very extensively during the design team meeting. I wouldn't dare contradicting the responsible AD, but although we can objectively say that the document hasn't been adopted (he has been presented only once), saying that it has no "WG agreement" is more prone to discussion. I would be happy to see more discussion on BIER ML about that.

Anyway... More interesting information for Dave inlined ...

> 
> Regards,
> Alia
> 
> On Tue, Mar 28, 2017 at 5:48 PM, Dave Taht <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Mar 28, 2017 at 1:47 PM, Juliusz Chroboczek <[email-masked] <mailto:[email-masked]>> wrote:
> > Dear Sandy, dear all,
> >
> https://datatracker.ietf.org/doc/html/draft-pfister-bier-over-ipv6 <https://datatracker.ietf.org/doc/html/draft-pfister-bier-over-ipv6>
> 

256 is the minimum requirement for BIER over MPLS and Ethernet.
There was discussion and, IMHO, consensus, that the minimum bit-string length
requirement would depend on the encap used.
Obviously, in the case of bier-over-ipv6, 256 doesn't make sense. 4096 even less so.
Using BIERoIPv6, bitstring lengths between 32 and 64 are more reasonable.

> linux, or other use cases, please point me at em!

I implemented a very rudimentary version of BIERoIPv6 a while ago, for testing and learning purposes:
https://github.com/Oryon/bier6 <https://github.com/Oryon/bier6>

But this implementation has nothing to do with Babel, or Zhang's proposal.

Cheers,

- Pierre

> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
> 
> 
> 
> --
> Dave Täht
> http://blog.cerowrt.org <http://blog.cerowrt.org/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 29 Mar 2017 14:34:22 -0400

Pierre,

Just to clarify - of course the bier over IPv6 is an interesting draft that
the WG has discussed - in some aspects extensively.  There were also
aspects that needed consultation with 6man.  It is still an individual
draft.

I'm glad to hear about the implementation, of course. :-)

Regards,
Alia

On Tue, Mar 28, 2017 at 11:50 PM, Pierre Pfister <[email-masked]>
wrote:

> Take a look at https://datatracker.ietf.org/doc/html/draft-ietf-bier-
> architecture
> and https://datatracker.ietf.org/doc/html/draft-ietf-bier-
> mpls-encapsulation.
> It was not discussed this IETF indeed, but was discussed the ietf before,
> and very extensively during the design team meeting. I wouldn't dare
> contradicting the responsible AD, but although we can objectively say that
> the document hasn't been adopted (he has been presented only once), saying
> that it has no "WG agreement" is more prone to discussion. I would be happy
> to see more discussion on BIER ML about that.
>
> https://github.com/Oryon/bier6
>