Subject: [Bier] I-D Action: draft-ietf-bier-architecture-08.txt

From: [email-masked]
Date: Wed, 13 Sep 2017 07:46:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF.

        Title           : Multicast using Bit Index Explicit Replication
        Authors         : IJsbrand Wijnands
                          Eric C. Rosen
                          Andrew Dolganow
                          Tony Przygienda
                          Sam K Aldrin
	Filename        : draft-ietf-bier-architecture-08.txt
	Pages           : 40
	Date            : 2017-09-13

Abstract:
   This document specifies a new architecture for the forwarding of
   multicast data packets.  It provides optimal forwarding of multicast
   packets through a "multicast domain".  However, it does not require a
   protocol for explicitly building multicast distribution trees, nor
   does it require intermediate nodes to maintain any per-flow state.
   This architecture is known as "Bit Index Explicit Replication"
   (BIER).  When a multicast data packet enters the domain, the ingress
   router determines the set of egress routers to which the packet needs
   to be sent.  The ingress router then encapsulates the packet in a
   BIER header.  The BIER header contains a bitstring in which each bit
   represents exactly one egress router in the domain; to forward the
   packet to a given set of egress routers, the bits corresponding to
   those routers are set in the BIER header.  The procedures for
   forwarding a packet based on its BIER header are specified in this
   document.  Elimination of the per-flow state and the explicit tree-
   building protocols results in a considerable simplification.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bier-architecture-08
https://datatracker.ietf.org/doc/html/draft-ietf-bier-architecture-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-architecture-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 13 Sep 2017 10:52:23 -0400

This draft

- Adds Greg's "Operational Considerations" text

- Allows each encapsulation to specify its own default BitStringLength

- Contains various other little changes made as a result of the LC and 
IESG reviews.

On 9/13/2017 10:46 AM, [email-masked] wrote:
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 13 Sep 2017 20:42:20 +0200

Nice, Eric. 

The only section which IMHO is somewhat confusing and IMHO not well enough
descriptive is the new operational considerations text:

"(1) BIER packet forwarding/replication is along the unicast paths	
 to each bit position set in the packet, ensuring the encapsulated	
 multicast packets follow the same path as unicast to each set bit in	
 the header. (2) The BIER FIB can be derived from the unicast SPF	
 calculated unicast FIB, or any other forwarding path calculation in	
 or out of band. (3) Each bit will follow this unicast path from the	
 entry point of the BIER domain to edge device with that assigned bit"

I think this does not well highlight the BIER benefit for the
uninitiated reader (aka: the reader who does not know how and why IP multicast
in comparison sucks). It may also be misleading:

How is (2) different from PIM/mLDP ? You could say the same thing about
the RPF information for PIM/mLDP. And like multicast RPF, BIER FIB does
not require a unicast FIB, but could also use information from a RIB,
aka: YOu do not need to calculate a FIB (which often is interpreted to imply
unicast packet forwarding resources) to derive the BIER FIB.

(1) Is this true when ECMP is taken into consideration ? Especially given how
unicast ECMP can leverage all type of unicast payload fields.

Some suggested text:

Most IP multicast tree building (DVMRP, PIM, mLDP - except upstream Bidir-PIM/MP2MP mLDP)
makes IP multicast traffic follow the reverse direction of the paths calculated by the
routing protocol used. When unicast link metrics or path policies are set up to
take traffic utilization or policies such as hot-potato routing into account ,
the resulting routing tables can not be used for these IP multicast protocols
with the expectation that the IP multicast traffic will flow along the same paths
as IP unicast traffic. Instead, it will flow across the reserve direction of the
best paths, which are NOT the best reverse path whenever assymmetric routes exist.
This RPF problem of IP multicast makes it necessary in those situations to add 
routing protocol instances, topologies or SAFI  (BGP) for IP multicast or otherwise 
account for the bandwidth used by IP multicast.

None of this complexity is necessary with BIER because its forwarding is based
on sender-to-receiver hop-by-hop routing table lookup - like IP unicast. Except 
for ECMP policies that may differ between unicast and BIER, BIER traffic for a
specific bit will flow along the same path as IP unicast traffic to the BFER for
that bit - when using the same routing tables for BIER and IP unicast.

Wrt. to the monitoring: I would change the text as follows to be more crisp
to the benefit (again pbeing more descriptive to the IP multicast problem.

BIER does not have any user/application generated state such a (*,G) or (S,G)
in the network. This has two important benefits:

1. Diagnostics and troubleshooting of BIER is (like for IP unicast routing and forwarding)
independent of application activity. There are no (complex) (*,G), (S,G) or 
(S,G,RPbit-prune) states that need to be troubleshot - because they do not exist!

2. Convergence of BIER in the network is deterministic and solely depends on IP
unicast convergence and the number of BFER. In classical IP multicast, traffic
interruption during reconvergence is proportional to the number of (*,G)/(S,G)
in the network. In BIER it is the same as IP unicast reconvergence.

Operators with business criticial traffic such as IPTV or finance traffic often
rely on PIM or mLDP per-(S,G) counters not only to troubleshoot tree building, but
also as poor mans SLA tools for the traffic carried. With BIER, SLA dagnostics
needs to use the same tools available for IP unicast, such as IPFIX. Diagnostics
of BIER itself can include simple counters per neighboring BFR and/or per BFER/bit.

Cheers
    Toerless

On Wed, Sep 13, 2017 at 10:52:23AM -0400, Eric C Rosen wrote:
> - Contains various other little changes made as a result of the LC
> and IESG reviews.
> 
>

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 13 Sep 2017 11:49:51 -0700

Toerless,

The Operational Considerations section was added at the request of one
Discuss during IETF-LC. It is NOT intended to be a comprehensive piece
about the benefits and/or differences of BIER over other multi-point
solutions. The text has already been approved by the originator of the
Discuss. Let's please not open this up into a months long discussion about
what should or should not be in this section. It is an architecture draft.
The value of an operations section at all in an architecture draft is
debatable.

If you want an extensive informational draft on the differences and
benefits of BIER over IPMcast and/or MPLS please feel free to write it.
Your email seems to be a good start. ;-)

Greg