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

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi,
It seems that WG chairs insist to treat BIER as technology only for Layer 2 and layer 3 based solutions like BIERv6 using IPv6 extension header are not welcome.
We think this is the interpretation of BIER WG chair rather than the conclusion from the whole WG, especially when there are many WG members supporting the work of BIERv6 and clear requirements received from the customers and industry.
Though most of the points have been explained, it may still help to understand BIERv6 solution for those who are interested.
Please find my response below inline.

Best Regards,
Jingrong

From: BIER [mailto:[e-mail]] On Behalf Of Greg Shepherd
Sent: Thursday, June 3, 2021 7:26 PM
To: BIER WG <[e-mail]>
Subject: [Bier] BIER WG summary of draft-xie-bier-ipv6-encapsulation

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
[xjr] Proto field is not used (set to 0 upon transmission and ignored upon reception) in BIERv6, and the function is replaced by Next Header field in IPv6.  It is described in section 3.1 of the draft.
BIER-ping does not need new procedures except an UDP port as explained in https://mailarchive.ietf.org/arch/msg/bier/3d5RbWTlFk46iB6NjoC1DlhdzUE/.
BIERv6 refers to the design concept of SRv6, which makes it suitable for native IPv6 network. They could be used together for unicast and multicast respectively.


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.
[xjr] We respect the historic/institutional knowledge in the beginning of WG. In fact, using IPv6 ext hdr to carry BIER is also an idea from a respectable contributor back in 2016.
We also respect the IESG/IETF work, which produces the formal text of RFC8279 as BIER architecture.
It is not clear how the BIER architecture RFC8279 makes BIERv6 unacceptable, and why WG needs to update the BIER architecture...to make 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.
[xjr] The need of fragmentation, ESP, etc when deploying BIER is described in <draft-bier-ipv6-requirements> document. It may not need to be supported by BIER on its own, but it needs to be solved if it is requested in an IPv6 network.

    •   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.
[xjr] Including BIERv6 Ping, all the data plane and control plane extensions requested by BIERv6 have been implemented and tested in the existing network. More information could be found in section 7 of draft-xie-bier-ipv6-encapsulation-10. We also plan to publish more detailed test report to further explain the functions, test case and test result, which may help to further understand that BIERv6 could be implemented and deployed in a reasonable way.

    •   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:
[xjr] The draft found its usecase originally as “transition solution” and later it had spawned the use cases into a separate document per the WG discussion, which is now explained in the <draft-bier-ipv6-requirements>.

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.
[xjr] Homenet may not use BIERv6, but it does not prevent BIERv6 from being used in other scenarios, for example, in an network where SRv6 network programming is deployed.

    •   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.
[xjr] There have been more and more use cases that change DA hop-by-hop w/o using a routing header, for example <draft-ietf-pim-sr-p2mp-policy> and <draft-raszuk-teas-ip-te-np>. BIERv6 has been discussed in 6man mailing list and there is no technical concerns raised from 6man people.  BIERv6 is not designed as the “next-proto layering” of IPv6, but we think this solution can live with other alternatives.

    •   When encoding BIER as one option in HBH or DOH, other options can also be carried, making BIER encoding inconsistent and difficult to locate.
[xjr] The pseudo code above has illustrated how a router can handle the options right, and it is not complicated from the experience of implementation.

    •   A variable BIER header location makes hardware implementations difficult, and potentially more expensive and lower performance
[xjr] Same as above, and it is not complicated from the experience of implementation.

    •   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.
[xjr] As explained above, the Proto field in BIER header is no longer used in BIERv6, and the BIER-OAM has been implemented in BIERv6.


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)