From nobody Thu Jun 3 04:26:41 2021 Return-Path: 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 ; 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 ; 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 ; Thu, 3 Jun 2021 04:26:36 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id ce15so8699560ejb.4 for ; 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 Date: Thu, 3 Jun 2021 04:26:22 -0700 Message-ID: To: BIER WG Content-Type: multipart/alternative; boundary="00000000000003ddba05c3dad9ae" Archived-At: 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 11:26:39 -0000 --00000000000003ddba05c3dad9ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BIER WG summary of draft-xie-bier-ipv6-encapsulation Technical Summary: =E2=80=A2 BIER and IPv6 tightly coupled for BIER/lower layer: =E2=80=A2 BIER header as option in IPv6 DOH =E2=80=A2 Proto field is not used. This seems to leave BIER-ping undefined.= =E2=80=9CHow BIER-PING is supported in BIERv6 encapsulation without using this Proto field is outside the scope of this document=E2=80=9D =E2=80=93 not clear if= this might need another set of procedures. =E2=80=A2 IPv6 encapsulation from BFIR to BFER. IPv6 is used even between d= irectly connected BFRs =E2=80=A2 Service over BIER tightly coupled with SRv6 (protocol/layer depen= dency) =E2=80=A2 But with different SRv6 behavior =E2=80=93 Source address instead= of DA is used on BFER for service delimiting, which has its own complications Issues: =E2=80=A2 BIER encoding is already specified in RFC8296 =E2=80=A2 Alia Atlas: =E2=80=9CIANA code-points don=E2=80=99t change. This= is the reason why BIER began as experimental - narrow point in hourglass=E2=80=9D =E2=80=A2 The encoding at the =E2=80=9Cnarrow point of the hourglass=E2=80= =9D =E2=80=93 the forwarding plane =E2=80=93 is the foundation from which the rest of the architecture = grows. =E2=80=A2 This was the position of the IESG and the BIER WG ADs at the time= of the original WG Experimental Charter. =E2=80=A2 This is admittedly historic/institutional knowledge of those invo= lved 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. =E2=80=A2 MPLS encaps and non-MPLS encaps clearly show BIER is L2: no check= sums, no fragmentation, no security on frames, none of which is needed or encompassed as necessary by the BIER architecture. =E2=80=A2 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. =E2=80=A2 The draft describes a completely new fast-path for what was origi= nally 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 =3D 60 and HopLimit > 0 2. IF (OptType1 =3D BIER) and (OptLength1 =3D 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=3DICMPv6 or (NH=3D60 and Dest_NH=3DICMPv6) 8. Send to CPU. 9. ELSE 10. Drop the packet. =E2=80=A2 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. =E2=80=A2 It is still unclear whether hop-by-hop header options modificatio= n 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. =E2=80=A2 When encoding BIER as one option in HBH or DOH, other options can= also be carried, making BIER encoding inconsistent and difficult to locate. =E2=80=A2 A variable BIER header location makes hardware implementations di= fficult, and potentially more expensive and lower performance =E2=80=A2 When BIER is encoded in DOH, the Next Header field in DOH is dupl= icated 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 =E2=80=93 BIER. Everythi= ng 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) --00000000000003ddba05c3dad9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BIER WG summary of draft-xie-bier-ip= v6-encapsulation

Technical Summary:

=
= =E2=80=A2 BIER and IPv6 tightly coupled for BIER/lower layer:
<= span class=3D"gmail-Apple-tab-span" style=3D"white-space:pre"> =E2= =80=A2 BIER header as option in IPv6 DOH
=E2=80=A2 Proto field is not used. Thi= s seems to leave BIER-ping undefined. =E2=80=9CHow BIER-PING is supported i= n BIERv6 encapsulation without using this Proto field is outside the scope = of this document=E2=80=9D =E2=80=93 not clear if this might need another se= t of procedures.
=E2=80=A2 IPv6 encapsulation from BFIR to BFER. IPv6 is = used even between directly connected BFRs
=E2=80=A2 Service over BIER tigh= tly coupled with SRv6 (protocol/layer dependency)=C2=A0
=E2=80=A2 But with= different SRv6 behavior =E2=80=93 Source address instead of DA is used on = BFER for service delimiting, which has its own complications

=
Issues:

=E2=80=A2 BIER encoding is already speci= fied in RFC8296
=E2=80=A2 Alia Atlas: =E2=80=9CIANA code-points don=E2= =80=99t change.=C2=A0 This is the reason why BIER began as experimental - n= arrow point in hourglass=E2=80=9D
=E2=80=A2 The encoding at the =E2=80=9Cn= arrow point of the hourglass=E2=80=9D =E2=80=93 the forwarding plane =E2=80= =93 =C2=A0is the foundation from which the rest of the architecture grows.<= /div>
<= /span>=E2=80=A2 This was the position of the IESG and the BIER WG ADs at the tim= e of the original WG Experimental Charter.=C2=A0
=E2=80=A2 This is admitte= dly historic/institutional knowledge of those involved in the WG from the b= eginning. But it is also a core tenant of the layered and scalable architec= ture of the Internet and was erroneously assumed as well-understood by the = original WG contributors. The WG needs to update the BIER architecture to m= ake this responsibility clear for all future contributors.

=E2=80=A2 MPLS encaps and non-MPLS encaps clearly show BIER is L2: no check= sums, no fragmentation, no security on frames, none of which is needed or e= ncompassed as necessary by the BIER architecture.=C2=A0

=E2=80=A2 = OAM is already in BIER. IPv6 may have its own OAM, so BIERV6 OAM sol= ution has to bypass BIER, or have SRv6 OAM include BIER? These pose unneces= sary complications and risks.

=E2=80=A2 The draft describes= a completely new fast-path for what was originally described as a "tr= ansition solution", without any clear use case that cannot be met by s= imple layered encapsulation:

The following is an e= xample pseudo-code of the End.BIER function:
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. IF NH =3D 60 and HopLimit >= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. =C2=A0 IF (OptType1 =3D BIER) a= nd (OptLength1 =3D HdrExtLen*8 + 4) =C2=A0 =C2=A0 =C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. =C2=A0 =C2=A0 Loo= kup the BIER Header inside the BIER option TLV. =C2=A0 =C2=A0 =C2=A0
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. =C2=A0= =C2=A0 Forward via the matched entry. =C2=A0 =C2=A0 =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05. =C2=A0 ELSE = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06. =C2=A0 =C2=A0 Drop the packet a= nd end the process. =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07. ELSE IF NH=3DICMPv6 or (NH=3D60 an= d Dest_NH=3DICMPv6) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A08. =C2=A0 Send t= o CPU. =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A09. ELSE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10. =C2=A0 Drop the pa= cket.=C2=A0

=E2=80=A2 Homenet needs a BIER solution, and ho= menet 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.=C2=A0

=E2=80=A2 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? W= hat 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 ot= her options may vanish/go, then the option will always be in a different pl= ace and there is really no advantage compared to simple next-proto layering= . The ongoing discussions have not cleared this up.

= =E2=80=A2 When encoding BIER as one option in HBH or DOH, other options can also= be carried, making BIER encoding inconsistent and difficult to locate.=C2= =A0
=E2=80=A2 A variable BIER header location makes hardware implementatio= ns difficult, and potentially more expensive and lower performance=C2=A0

=E2=80=A2 When BIER is encoded in DOH, the Next Header field = in DOH is duplicated with the proto field in BIER header, and the two value= s 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:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dra= ft-xie-bier-ipv6-encapsulation is an unnecessary complication to a rather y= oung Standards Track forwarding model =E2=80=93 BIER. Everything it claims = to address can be accomplished through well proven, layered architecture so= lutions, and by using encapsulation methods already standardized by the IET= F, so none of what the draft describes is necessary. It is the conclusion o= f the BIER WG Chairs that all the above technical summary has been presente= d and discussed on the list extensively. It is also the conclusion of the C= hairs that creating a layer dependency - fusion/melding of overlay forwardi= ng layer, BIER forwarding layer, and lower transport layer - would take the= standard in the wrong direction. Replication has been bound to unicast for= warding 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 o= n the Experimental Track now that it has just started to develop on the Sta= ndards Track.=C2=A0

Thanks everyone for your i= nput and patience.

Cheers,
Greg
(Chairs)

--00000000000003ddba05c3dad9ae--