Subject: [Roll-bier-dt] roll-bier-dt

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Oct 2018 04:56:23 +0200

Had just small audience this week, Michael Richardson, Greg Shepherd myself.

Trying to get more organized. Will try to keep all roll-bier docs now
organized on github:

www.github.com/toerless/roll-bier

Notes from this week:

https://raw.githubusercontent.com/toerless/roll-bier/master/notes/181017-roll-bier-notes.txt

Slide deck i started for this week, will try to incooperate ongoing
results from DT meeting and then use at IETF102. Hopefully includes most
of what we've concluded so far. Also added today a long to be reviewed
section on the IP MUlticast overlay.

https://github.com/toerless/roll-bier/raw/master/roll-bier-dt-slides.pptx

Feel free to contribute/modify, just send requests to be added to repo,
don't want to bothre trying to figure out all your github emails.

Cheers
    Toerless

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Oct 2018 07:45:50 +0200

> https://raw.githubusercontent.com/toerless/roll-bier/master/notes/181017-roll-bier-notes.txt

What do you mean with “RPL does not support multicast.”?  MOP=3?
(That is of course storing mode only, and storing mode doesn’t exist :-), so you have a point.
That’s why we did ccast, to fill in multicast for non-storing mode.)

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Oct 2018 14:21:20 +0200

That was me taking notes what Michael said, and maybe i didn't
transcribe it correctly. Hope Michael is subscribed here to answer.

I think i was more wondering about the suport of compressed IP multicast
headders in 6LowPan because that is unclear to me and we probably
need to take one of the DT meetings to detail more what extensions
we need to do for 6LowPan to support BIER.

Cheers
    Toerless

On Fri, Oct 19, 2018 at 07:45:50AM +0200, Carsten Bormann wrote:
> What do you mean with ???RPL does not support multicast.????  MOP=3?
> (That is of course storing mode only, and storing mode doesn???t exist :-), so you have a point.
> That???s why we did ccast, to fill in multicast for non-storing mode.)
> 
> Grüße, Carsten

-- 
---
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Oct 2018 12:36:06 +0000

Hello Toerless:

Well, there is as Carsten says a multicast support for RPL storing mode, but not for non-storing. This is where Carsten's draft comes in to play.
In normal BIER, the bits indicate the routers, don't they? So there's an IP packet inside, correct, like in my tunnel mode? But then I expect it is the same packet for all destinations. So how does htat work, is it a mcast packet or do all the destination have a same IP address?

Pascal

> -----Original Message-----
> From: Roll-bier-dt <[email-masked]> On Behalf Of Toerless Eckert
> Sent: vendredi 19 octobre 2018 14:21
> To: Carsten Bormann <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Roll-bier-dt] roll-bier-dt
> 
> That was me taking notes what Michael said, and maybe i didn't transcribe it
> correctly. Hope Michael is subscribed here to answer.
> 
> headders in 6LowPan because that is unclear to me and we probably need to
> take one of the DT meetings to detail more what extensions we need to do for
> 6LowPan to support BIER.
> 
> Cheers
>     Toerless
> 
> _______________________________________________
> Roll-bier-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll-bier-dt

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Oct 2018 15:14:12 +0200

> Well, there is as Carsten says a multicast support for RPL storing mode, but not for non-storing. This is where Carsten's draft comes in to play.

Sure. As said, i may not have correctly captured what Mcr was explaining,

> In normal BIER, the bits indicate the routers, don't they? So there's an IP packet inside, correct, like in my tunnel mode? But then I expect it is the same packet for all destinations. So how does…

"Proper BIER" (TM) (the stuff done by BIER-WG) has defined its own
encapsulation header (RFC8296) that sits on top of MPLS or ethernet and
that has its own next-proto field/registry, so it can be followed
by IP or anything else that BIER-WG feels deserves a code point in
that registry.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Oct 2018 13:20:11 +0000

Sure, but the mystery to me is what goes transported with BIER.
Because that is the heart of the problem we are facing in this DT.
If BIER transports a same IP packet to multiple destinations, then they must all accept the same packet.
Moreover, if the destination is not the router indicated by the bit but a neighbor or a set of neighbors to that router, then the inner packet must indicate that.
All in all, that tells me that the transported packet is IP multicast.

What do I miss?

Take care,

Pascal

> From: Toerless Eckert <[email-masked]>
> Sent: vendredi 19 octobre 2018 15:14
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>; [email-masked]
> > Well, there is as Carsten says a multicast support for RPL storing mode, but not
> for non-storing. This is where Carsten's draft comes in to play.
> 
> > In normal BIER, the bits indicate the routers, don't they? So there's an IP
> packet inside, correct, like in my tunnel mode? But then I expect it is the same
> packet for all destinations. So how does htat work, is it a mcast packet or do all
> the destination have a same IP address?
> 
> encapsulation header (RFC8296) that sits on top of MPLS or ethernet and that
> has its own next-proto field/registry, so it can be followed by IP or anything else
> that BIER-WG feels deserves a code point in that registry.
> 
> Cheers
>     Toerless
> 
> > Pascal
> >
> > > I think i was more wondering about the suport of compressed IP
> > > multicast headders in 6LowPan because that is unclear to me and we
> > > probably need to take one of the DT meetings to detail more what
> > > extensions we need to do for 6LowPan to support BIER.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > > > https://raw.githubusercontent.com/toerless/roll-bier/master/note
> > > > > s/18
> > > > > 1017-roll-bier-notes.txt
> > > >
> > > > (That is of course storing mode only, and storing mode doesn???t
> > > > exist :-), so
> > > you have a point.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Oct 2018 15:52:15 +0200

> Sure, but the mystery to me is what goes transported with BIER.

As said, BIER proper can encapsulate anything deemed important enough to
get a code point in the BIER encap. I am saying "proper" because ROLL
may not want to take RFC8296 given the likely competition with 6LowPan.

> If BIER transports a same IP packet to multiple destinations, then they must all accept the same packet.

More a property of the larger clas of multicasting overall assuming
tojust copy the payload - and not to modify it.

I thought we had killed in last weeks meeting the idea of trying to come
up with a mechanism that manages to use packet replication (BIER) and then
modding received copies to fake different per-receiver IP unicast packets
- because of the problem of making this architecturally work well with 
higher layers like UDP that also have a notion of an IP (pseudo) header.
Too much faking needed. At least thats what i tried to summarize in my slides.

Aka: We use BIER-TE for unicast packets but then the expectation is
that there is just one destination, and the whole purpose of BIER-TE is
not replication but source routing. And we use BIER-TE(/BIER) for IP
multicast packets where there can be 1 or more destinations.

[ Of course there are fun extensions later, e.g.: a unicast packet could
 still be sent to redundant nodes sharing an IP adddress and therefore
 able to receive/process the same packet, but i think thats less likely
 something one would do in a ROLL domain. ]

> Moreover, if the destination is not the router indicated by the bit
> but a neighbor or a set of neighbors to that router, then the inner
> packet must indicate that.

Yes, we have two layers. The BIER layer that only reaches nodes with
an assigned BIER bit, and they can communicate potentially any
payload across BIER, IP or other. And then on top of that there
is IP multicast between the BIER edge nodes and IP unicast/multicast
only nodes. The pictures in the slide deck posted intend to show that (that
IP multicast building block picture still TBD).

> What do I miss?

I think primarily me wanting to figure out the encap we use within
the BIER-ROLL domain: RFC8296 vs. 6LowPan+extensions.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:54:10 +0000

Please consider this then :)

https://datatracker.ietf.org/doc/draft-thubert-6lo-bier-dispatch/

take care,

Pascal

> Sent: vendredi 19 octobre 2018 15:52
> As said, BIER proper can encapsulate anything deemed important enough to get
> a code point in the BIER encap. I am saying "proper" because ROLL may not
> want to take RFC8296 given the likely competition with 6LowPan.
> 
> More a property of the larger clas of multicasting overall assuming tojust copy
> the payload - and not to modify it.
> 
> I thought we had killed in last weeks meeting the idea of trying to come up with
> a mechanism that manages to use packet replication (BIER) and then modding
> received copies to fake different per-receiver IP unicast packets
> - because of the problem of making this architecturally work well with higher
> layers like UDP that also have a notion of an IP (pseudo) header.
> Aka: We use BIER-TE for unicast packets but then the expectation is that there is
> just one destination, and the whole purpose of BIER-TE is not replication but
> source routing. And we use BIER-TE(/BIER) for IP multicast packets where there
> can be 1 or more destinations.
> 
> [ Of course there are fun extensions later, e.g.: a unicast packet could  still be
> sent to redundant nodes sharing an IP adddress and therefore  able to
> receive/process the same packet, but i think thats less likely  something one
> would do in a ROLL domain. ]
> 
> Yes, we have two layers. The BIER layer that only reaches nodes with an
> assigned BIER bit, and they can communicate potentially any payload across
> BIER, IP or other. And then on top of that there is IP multicast between the BIER
> edge nodes and IP unicast/multicast only nodes. The pictures in the slide deck
> posted intend to show that (that IP multicast building block picture still TBD).
> 
> > What do I miss?
> 
> I think primarily me wanting to figure out the encap we use within the BIER-
> ROLL domain: RFC8296 vs. 6LowPan+extensions.
> 
> Cheers
>     Toerless
> 
> > Take care,
> >
> > Pascal
> >
> > > packet inside, correct, like in my tunnel mode? But then I expect it
> > > is the same packet for all destinations. So how does htat work, is
> > > it a mcast packet or do all the destination have a same IP address?
> > >
> > > encapsulation header (RFC8296) that sits on top of MPLS or ethernet
> > > and that has its own next-proto field/registry, so it can be
> > > followed by IP or anything else that BIER-WG feels deserves a code point in
> that registry.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > > Pascal
> > > >
> > > > > multicast headders in 6LowPan because that is unclear to me and
> > > > > we probably need to take one of the DT meetings to detail more
> > > > > what extensions we need to do for 6LowPan to support BIER.
> > > > >
> > > > > Cheers
> > > > >     Toerless
> > > > >
> > > > > > (That is of course storing mode only, and storing mode
> > > > > > doesn???t exist :-), so
> > > > > you have a point.
> > > > > > That???s why we did ccast, to fill in multicast for
> > > > > > non-storing
> > > > > > mode.)
> > > > > >
> > > > > > Grüße, Carsten
> > > > >
> > > > > --
> > > > > ---
> > > > > [email-masked]
> > > > >

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 24 Oct 2018 08:46:24 -0700

I won't be on the call today, sorry.

Greg

On Fri, Oct 19, 2018 at 7:54 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> get
> > > If BIER transports a same IP packet to multiple destinations, then
> they must all
> > accept the same packet.
> >
> up with
> higher

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 24 Oct 2018 09:06:42 -0700

I thought it was all delayed until f2f in thailand ?

On Wed, Oct 24, 2018 at 8:46 AM Greg Shepherd <[email-masked]> wrote:

>> > > Because that is the heart of the problem we are facing in this DT..
>> that there is
>> > > > > > To: Carsten Bormann <[email-masked] <cabo@tzi..org>>
>> https://raw.githubusercontent.com/toerless/roll-bier/master/
>> <https://raw.githubusercontent..com/toerless/roll-bier/master/>
>> > > > > > > > note
>> > > > > > > > s/18
>> > > > > > > > 1017-roll-bier-notes.txt
>> > > > > > >