Subject: [Bier] Spencer Dawkins' No Objection on draft-ietf-bier-architecture-08: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Mon, 25 Sep 2017 17:27:31 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-bier-architecture-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just asking for my own understanding ...

In this text,

   If, at some time, the routing underlay is not providing a loop free
   path between BFIR-A and BFER-B, then BIER encapsulated packets may
   loop while traveling from BFIR-A to BFER-B.  However, such loops will
   never result in delivery of duplicate packets to BFER-B.

I'm assuming that these loops could result in out of order delivery of packets to BFER-B?

No document change requested, of course. And either answer is fine.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 26 Sep 2017 08:57:24 -0700

Hi Spencer,

Its correct there is no duplicate delivery of packets, which is a great benefit of BIER over traditional multicast protocols. The loop behaves just like with Unicast, for a particular BFER that is effected, the traffic is back holed. As soon as the loop is broken, normal delivery of packets resumes. I don’t think that will result in out-of-order packets.

Thx,

Ice.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 26 Sep 2017 13:36:21 -0400

> Its correct there is no duplicate delivery of packets, which is a great benefit of BIER over traditional multicast protocols. The loop behaves just like with Unicast, for a particular BFER that is…

The looping traffic is only blackholed if the loop still exists by the 
time the TTL becomes zero.  If the loop ends while some looping packets 
are still in flight, with TTLs still large enough to reach the 
destination, those packets will get delivered.

Note that misordering is always possible (even in unicast) when there is 
a topology change.  Consider packets P1 and P2, where P1 entered the 
network first and is closer to the destination.  If there is a topology 
change while both packets are in flight, it might happen that P2 is now 
closer to the destination than P1.  This would result in out of order 
delivery.  And a packet, P3, that entered the network after the change, 
could conceivably get delivered before either P1 or P2.

So I think Spencer's observation is correct.  But  this sort of 
misordering is not specific to multicast or to BIER.

The big problem with loops in conventional multicast is not misordering, 
but duplication.  In conventional multicast, if a packet travels around 
a loop 100 times, 100 copies of it could get delivered to each 
destination.  This can't happen in BIER, because when a packet is 
replicated, the BitStrings are disjoint.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Sep 2017 01:52:20 +0800

On Sep 27, 2017 01:36, "Eric C Rosen" <[email-masked]> wrote:

On 9/26/2017 11:57 AM, IJsbrand Wijnands wrote:

> Its correct there is no duplicate delivery of packets, which is a great
> benefit of BIER over traditional multicast protocols. The loop behaves just
> like with Unicast, for a particular BFER that is effected, the traffic is
> back holed. As soon as the loop is broken, normal delivery of packets
> resumes. I don’t think that will result in out-of-order packets.
>

The looping traffic is only blackholed if the loop still exists by the time
the TTL becomes zero.  If the loop ends while some looping packets are
still in flight, with TTLs still large enough to reach the destination,
those packets will get delivered.

Note that misordering is always possible (even in unicast) when there is a
topology change.  Consider packets P1 and P2, where P1 entered the network
first and is closer to the destination.  If there is a topology change
while both packets are in flight, it might happen that P2 is now closer to
the destination than P1.  This would result in out of order delivery.  And
a packet, P3, that entered the network after the change, could conceivably
get delivered before either P1 or P2.

So I think Spencer's observation is correct.  But  this sort of misordering
is not specific to multicast or to BIER.

The big problem with loops in conventional multicast is not misordering,
but duplication.  In conventional multicast, if a packet travels around a
loop 100 times, 100 copies of it could get delivered to each destination.
This can't happen in BIER, because when a packet is replicated, the
BitStrings are disjoint.

Thank you both for helping me understand.

So the situation when out of order packet delivery happens is no worse with
BIER.

Spencer