Subject: [Bier] Interim WG Results - Direction

From: Greg Shepherd <[email-masked]>
Date: Fri, 30 Sep 2016 15:05:07 -0700

Thank you to everyone who participated in the Interim BIER WG Interim
meeting / encap design team both in person and remote. I feel we were
quite productive this week, and have moved the work along much faster
than would have happened over email alone.

The minutes and slides are all posted, and the links to the recordings
have been sent out to the list. The summary results are posted below.
Please read and review and provide any feedback on the direction
recommendations for the WG at large.

Chairs

---------
IETF BIER WG
Interim Meeting
Sept 27-29, 2016

Recommendations for the WG direction

1) Unify encapsulation (MPLS, Eth, Generic) under MPLS Ethertype

The interim reached the conclusion that the MPLS encapsulation can be
carried into rfc5332 and with that the drafts eth/generic can be
unified into one draft that suggests the necessary DSCP bit additions
to it and explains how the label value can be used to encode
SI/BSL/subdomain if so desired. This will solve the "BIER over
ethernet" without any needs of a new encapsulation. Necessary
discussions need to be closed whether rfc5332 is enough or some reason
exists for a new EtherType carrying MPLS encapsulation inside for BIER
has to be requested.  On Tony P to unify the parties towards a draft
and drive it forward towards suggested adoption by the WG.

2) BIER in-band membership signaling

Both draft-pfister-bier-mld and draft-wang-bier-VXLAN outline a
solution for signaling membership over the BIER domain by sending
MLD/IGMP messages over BIER. Authors of both drafts to converge the
work under a single draft.

IJsbrand Wijnands <[email-masked]>
Pierre Pfister (ppfister) <[email-masked]>

3) Host-to-host use-case and problem statement draft

The interim agreed that host-to-first-BFR router or host-to-host and
with that simplification of a host BIER API presents a valid and
valuable work item and should be attacked by a problem statement
draft/use-cases and suggestions for solutions, be it novel encaps or
BFR-host mechanisms to achieve such an API. The results should be
presented in the WG and further consensus sought with the group and AD
as to adoption/further work.

The use case statement should make distinction of the case of
virtualized hosts in the data-center where a VM uses BIER uncap to
indicate the replication desired inside its own VNI, and the case of
the hypervisor using BIER to replicate packets to Network Virtualized
Edges (NVEs) over a BIER underlay, and/or any translation, interaction
or dependancies between the two cases.

IJsbrand Wijnands <[email-masked]>
Toerless Eckert <[email-masked]>
Jeff Tantsura <[email-masked]>

4) Continue exploring IPv6 encoding w/ IETF IPv6 expert input

Suggested IPv6 encapsulation was perceived during the interim as
having lots of desired capabilities of a host L3 based encapsulation
but will need exposure towards IPv6 flame keepers to ratify whether
the implications on IPv6 architecture are viable and secure. A clear
use-case statement to focus the discussion around the various
components of the proposed solutions - i.e. being able to send traffic
from outside the BIER domain without tunneling. The proposal and any
progressing work needs input from the 6MAN WG.

Pierre Pfister (ppfister) <[email-masked]>