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

Greg Shepherd <gjshep@gmail.com> Thu, 03 June 2021 11:26 UTC

Return-Path: <gjshep@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5127B3A00E9 for <bier@ietfa.amsl.com>; Thu, 3 Jun 2021 04:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stX7AIiwT3Ua for <bier@ietfa.amsl.com>; Thu, 3 Jun 2021 04:26:37 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37A83A00E5 for <bier@ietf.org>; Thu, 3 Jun 2021 04:26:36 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id ce15so8699560ejb.4 for <bier@ietf.org>; Thu, 03 Jun 2021 04:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=T8cWprNl+kmbuxaXSmuB8rgvD7MXuEqtpFBFVTuYA/k=; b=ToBm+j+zSmWkTwhCRCvr+OzQneZj5rDeCd+MD+O1ynI3sNxmUdePi/Oae299rO4SjG KY37wojjcjKg7UhEjVQVeOGdXMSTrCJa53bV9fm/Fbj/XSdFUPMsZkkKUzF8sNJomX1l QtJazQJ8YCSN5X+4VNokU/LYAgqUrlbvS91kabBsyN5n3pHuWHOkgvdcHFmWP0Y+DkYU bFock63kI5IyFKCWDgOyNJlUlZSRDTXZc8eddD5QmBMzrgAvzsN6SUZTzGtCepTNEWZf WG7WsL8vkzf0tKU9IvWGz6YR0inKzmbkhBbkDani1090ohy/pEdCMCFnpORIDlNqtx7R JW0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=T8cWprNl+kmbuxaXSmuB8rgvD7MXuEqtpFBFVTuYA/k=; b=LLFFldrDH9jlkHeq1EJAkJlTPByU9v9mRDfgkXwMHp2LyOc1dwobyoeyiqJuIK86VA icp+kTPrdzZ4aJswIYIUMZoC8uaW5T1qZjqPn/vHbh1k+f29i8oVB159dm7fG2P+JBHZ kPoBfPKcs3UDKD01kBirSxVABncIzWB+tSRvbJjdd1y22n28qQCDqBQXlSW2MSHW56mn 2hkTYuTVT8EIOq+/l50bG0Ri3h4+A5pOMdkxdBsQCGDZZ6cCD//9NVv/FEQmH8hX11A4 QkxkOppUdT0q+uz0MYCEHjXkuA3VoKKMHvQPcdX2y0tL10cGDFCmT//2bp9fVwqleGig ccXQ==
X-Gm-Message-State: AOAM530HLAvHOWpzQTrYWbF4KslqaGcgp4WqMAXRzl6gkxWKgMEcT6fQ VJ8bQdrSUkj4PYTcSYFr93u38rM+Uj5cuN0fvjD4WLGZDV2EAQ==
X-Google-Smtp-Source: ABdhPJw0cekGkakZp1wUqK75yo2cz771Jr+TtS4gxd659N0qy+rFwVaIhH/qcLLRGOFeadncE6F3A/gbpUORS4kRHpM=
X-Received: by 2002:a17:906:4789:: with SMTP id cw9mr39018299ejc.325.1622719594748; Thu, 03 Jun 2021 04:26:34 -0700 (PDT)
MIME-Version: 1.0
Reply-To: gjshep@gmail.com
From: Greg Shepherd <gjshep@gmail.com>
Date: Thu, 3 Jun 2021 04:26:22 -0700
Message-ID: <CABFReBrbarxTLS9H0UuVvp1DuO4vxd4uO=4KV0=jM_KZkrYxvw@mail.gmail.com>
To: BIER WG <bier@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000003ddba05c3dad9ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/39LuZ20upGQFowuCKse3tz9hTUk>
Subject: [Bier] BIER WG summary of draft-xie-bier-ipv6-encapsulation
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 11:26:39 -0000

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)