[Bier] BIER WG summary of draft-xie-bier-ipv6-encapsulation

[Greg Shepherd <[e-mail]>]

BIER WG summary of draft-xie-bier-ipv6-encapsulation

Technical Summary:

• BIER and IPv6 tightly coupled for BIER/lower layer:
• BIER header as option in IPv6 DOH
• Proto field is not used. This seems to leave BIER-ping undefined. “How
BIER-PING is supported in BIERv6 encapsulation without using this Proto
field is outside the scope of this document” – not clear if this might need
another set of procedures.
• IPv6 encapsulation from BFIR to BFER. IPv6 is used even between directly
connected BFRs
• Service over BIER tightly coupled with SRv6 (protocol/layer dependency)
• But with different SRv6 behavior – Source address instead of DA is used
on BFER for service delimiting, which has its own complications

Issues:

• BIER encoding is already specified in RFC8296
• Alia Atlas: “IANA code-points don’t change.  This is the reason why BIER
began as experimental - narrow point in hourglass”
• The encoding at the “narrow point of the hourglass” – the forwarding
plane –  is the foundation from which the rest of the architecture grows.
• This was the position of the IESG and the BIER WG ADs at the time of the
original WG Experimental Charter.
• This is admittedly historic/institutional knowledge of those involved in
the WG from the beginning. But it is also a core tenant of the layered and
scalable architecture of the Internet and was erroneously assumed as
well-understood by the original WG contributors. The WG needs to update the
BIER architecture to make this responsibility clear for all future
contributors.

• MPLS encaps and non-MPLS encaps clearly show BIER is L2: no checksums, no
fragmentation, no security on frames, none of which is needed or
encompassed as necessary by the BIER architecture.

• OAM is already in BIER. IPv6 may have its own OAM, so BIERV6 OAM solution
has to bypass BIER, or have SRv6 OAM include BIER? These pose unnecessary
complications and risks.

• The draft describes a completely new fast-path for what was originally
described as a "transition solution", without any clear use case that
cannot be met by simple layered encapsulation:

The following is an example pseudo-code of the End.BIER function:
                 1. IF NH = 60 and HopLimit > 0

                 2.   IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 +
4)
                 3.     Lookup the BIER Header inside the BIER option TLV.

                 4.     Forward via the matched entry.
                 5.   ELSE

                 6.     Drop the packet and end the process.
                 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6)

                 8.   Send to CPU.
                 9. ELSE
                10.   Drop the packet.

• Homenet needs a BIER solution, and homenet will not run SRv6. It's
unlikely cheap silicon will do extensive processing on options with
modifications in flight. A simple next-protocol pointer is the proven,
safe, and scalable approach.

• It is still unclear whether hop-by-hop header options modification is
allowed. Can the DA be changed hop by hop w/o using a routing header? What
is to be done with all the DOH options at each hop (that changes the
DA).The draft describes copying DOH router to router or abuse DOH as a
router options since each router processes it. If the option is copied
because other options may vanish/go, then the option will always be in a
different place and there is really no advantage compared to simple
next-proto layering. The ongoing discussions have not cleared this up.

• When encoding BIER as one option in HBH or DOH, other options can also be
carried, making BIER encoding inconsistent and difficult to locate.
• A variable BIER header location makes hardware implementations difficult,
and potentially more expensive and lower performance

• When BIER is encoded in DOH, the Next Header field in DOH is duplicated
with the proto field in BIER header, and the two values must be kept
consistent. But because IPv6 has no OAM type in next header definition, the
OAM type will only be kept in the BIER header. This further complicates
coding and execution.


Conclusion:

          draft-xie-bier-ipv6-encapsulation is an unnecessary complication
to a rather young Standards Track forwarding model – BIER. Everything it
claims to address can be accomplished through well proven, layered
architecture solutions, and by using encapsulation methods already
standardized by the IETF, so none of what the draft describes is necessary.
It is the conclusion of the BIER WG Chairs that all the above technical
summary has been presented and discussed on the list extensively. It is
also the conclusion of the Chairs that creating a layer dependency -
fusion/melding of overlay forwarding layer, BIER forwarding layer, and
lower transport layer - would take the standard in the wrong direction.
Replication has been bound to unicast forwarding planes for more than 30
years. BIER has finally brought a dedicated, independent replicating
forwarding plane to the Internet Architecture. It would be irresponsible to
ignore the original concerns that started BIER on the Experimental Track
now that it has just started to develop on the Standards Track.

Thanks everyone for your input and patience.

Cheers,
Greg
(Chairs)