[Bier] [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-bier-php-11

["Gunter van de Velde (Nokia)" <[e-mail]>]

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bier-php-11

Hi Jeffrey and BIER WG,

Please find here a shepherding AD review of draft-ietf-bier-php-11

Many thanks to Xiao Min for the excellent Shepherd write-up. It was great to see that the work has been validated with the MPLS Working Group. I also noted from the email archive that Loa provided some valuable feedback, which has been thoughtfully incorporated.

When running idnits, a few messages appeared, likely due to the references being slightly outdated over time. You can view the idnits report here: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bier-php-11.txt

The document currently lacks an operational considerations/implication section. To assist with this, I've added some initial thoughts on the operational aspects associated with PHP operation at the very end of this AD review for inspiration and to discuss if they apply to the BIER use-case.

The security section is somewhat brief. I've included some ideas to help expand on the security considerations related to PHP and its application within BIER. Not all the suggested observations will apply strongly for this BIER use case.

While the document effectively outlines the operational procedures, it could benefit from some grammatical enhancements to improve clarity. Given that this draft is concise, I thought it would be more convenient to propose the revised text section by section rather than suggesting edits paragraph by paragraph. This approach should make it easier to incorporate the suggestions into the XML.


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

10	Abstract
11
12	   Bit Index Explicit Replication (BIER) can be used as provider tunnel
13	   for Multicast Virtual Private Network (MVPN), Global Table Multicast
14	   or Ethernet Virtual Private Network (EVPN).  It is possible that not
15	   all routers in the provider network support BIER and there are
16	   various methods to handle BIER-incapable transit routers.  However
17	   those methods assume the MVPN/EVPN Provider Edges (PEs) are BIER-
18	   capable.  This document specifies a method to allow BIER-incapable
19	   routers to act as MVPN/EVPN PEs with BIER as the transport, by having
20	   the upstream BIER Forwarding Router (BFR) that is connected directly
21	   or indirectly via a tunnel to a BIER-incapable PE remove the BIER
22	   header and send the payload to the PE.

[major]
I think an abstract should cover the objective of the document in a high level style that the manager of your manager would understand and explains in simple words the purpose. I would assume that when people gp reda this document that they know what BIER is all about. Can I suggest the following abstract instead:

"
This document specifies a mechanism for Penultimate Hop Popping (PHP) in the Bit Index Explicit Replication (BIER) architecture. PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path. This extension to BIER enhances operational efficiency by optimizing packet forwarding in scenarios where the final hop's capabilities or requirements necessitate such handling. The document details the necessary extensions to the BIER encapsulation and forwarding processes to support PHP, providing guidance for implementation and deployment within BIER-enabled networks.
"

77	1.  Introduction
78
79	   The BIER architecture includes three layers: the "routing underlay",
80	   the "BIER layer", and the "multicast flow overlay".  The multicast
81	   flow overlay is responsible for the BIER Forwarding Egress Routers
82	   (BFERs) to signal to BIER Forwarding Ingress Routers (BFIRs) that
83	   they are interested in receiving certain multicast flows so that
84	   BFIRs can encode the correct bitstring for BIER forwarding by the
85	   BIER layer.
86
87	   MVPN [RFC6513] [RFC6514] and EVPN [RFC7432] are two similar overlays
88	   where BGP Auto-Discovery routes for MVPN/EVPN are exchanged among all
89	   PEs to signal which PEs need to receive multicast traffic for all or
90	   certain flows.  Typically the same provider tunnel type is used for
91	   traffic to reach all receiving PEs.
92
93	   Consider an MVPN/EVPN deployment where enough provider routers are
94	   BIER-capable for BIER to become the preferred choice of provider
95	   tunnel [RFC8556] [I-D.ietf-bier-evpn].  However, some PEs cannot be
96	   upgraded to support BIER forwarding.  While there are ways to allow
97	   an ingress PE to send traffic to some PEs with one type of tunnel and
98	   send traffic to some other PEs with a different type of tunnel, the
99	   procedure becomes complicated and forwarding is not optimized.
100
101	   One way to solve this problem is to use Penultimate Hop Popping (PHP)
102	   so that the upstream BFR can pop the BIER header [RFC8296] and send
103	   the payload "natively" (note that the upstream BFR can be connected
104	   directly or indirectly via any type of tunnel to the PE).  This is
105	   similar to Multi-Protocol Label Switching (MPLS) PHP though it is the
106	   BIER header that is popped.
107
108	   The transition of an existing MVPN/EVPN deployment with traditional
109	   provider tunnels to using BIER with some PEs not capable of receiving
110	   BIER packets can be incremental.  All PEs are first upgraded to
111	   support BIER at least in the control plane, with those not capable of
112	   BIER forwarding requesting PHP.  Then BIER-capable ingress PEs
113	   independently and incrementally switch to BIER transport.
114
115	   While the above text uses MVPN/EVPN as example, BIER PHP is
116	   applicable to any scenario where the multicast flow overlay edge
117	   router does not support BIER, as long as the edge router does not
118	   need to know the transmitting BFIR or participate in BIER OAM
119	   procedures.
120
121	   This works well if a BIER-incapable PE only needs to receive
122	   multicast traffic.  If it needs to send multicast traffic as well,
123	   then it must Ingress Replicate to a BIER-capable helper PE, who will
124	   in turn relay the packet to other PEs.  The helper PE is either a
125	   Virtual Hub as specified in [RFC7024] for MVPN and
126	   [I-D.ietf-bess-evpn-virtual-hub] for EVPN, or an AR-Replicator as
127	   specified in [I-D.ietf-bess-evpn-optimized-ir] for EVPN.

[major]
On the first line the "BIER architecture is mentioned, but there is no added reference to 
https://datatracker.ietf.org/doc/html/rfc8279 mentioned

[minor]
Suggested rewrite

"
The Bit Index Explicit Replication (BIER) architecture [RFC8279] consists of three layers: the "routing underlay," the "BIER layer," and the "multicast flow overlay." The multicast flow overlay is responsible for allowing BIER Forwarding Egress Routers (BFERs) to signal to BIER Forwarding Ingress Routers (BFIRs) their interest in receiving specific multicast flows, enabling BFIRs to encode the appropriate bitstring for forwarding by the BIER layer.

Multicast Virtual Private Network (MVPN) [RFC6513][RFC6514] and Ethernet VPN (EVPN) [RFC7432] are two analogous overlays in which BGP Auto-Discovery routes for MVPN/EVPN are exchanged among all Provider Edge (PE) routers to signal which PEs should receive multicast traffic for all or certain flows. Typically, a consistent provider tunnel type is used for traffic delivery to all receiving PEs.

In a deployment scenario where MVPN/EVPN is in use and a sufficient number of provider routers support BIER, BIER can become the preferred provider tunnel type [RFC8556][I-D.ietf-bier-evpn]. However, some PEs may lack the capability to support BIER forwarding. While it is possible for an ingress PE to send traffic to some PEs using one type of tunnel and to others using a different type, such a procedure can be complex and may result in suboptimal forwarding.

A potential solution to this issue is the use of Penultimate Hop Popping (PHP), whereby the upstream BFR pops the BIER header [RFC8296] and transmits the payload "natively." This transmission can occur either directly or indirectly through any type of tunnel to the PE. This mechanism is analogous to Multi-Protocol Label Switching (MPLS) PHP, except that the BIER header is removed.

The transition from an existing MVPN/EVPN deployment with traditional provider tunnels to a BIER-based solution, where some PEs are not BIER-capable, can be incremental. Initially, all PEs are upgraded to support BIER in the control plane, with those unable to perform BIER forwarding requesting PHP. Subsequently, BIER-capable ingress PEs can independently and incrementally switch to BIER transport.

While MVPN/EVPN is used as an example in the above discussion, BIER PHP is applicable to any scenario where the multicast flow overlay edge router does not support BIER, provided that the edge router does not need to identify the transmitting BFIR or participate in BIER Operations, Administration, and Maintenance (OAM) procedures.

This approach is effective when a BIER-incapable PE only needs to receive multicast traffic. However, if the PE also needs to send multicast traffic, it must perform Ingress Replication to a BIER-capable helper PE, which will then relay the packet to other PEs. The helper PE may be a Virtual Hub as defined in [RFC7024] for MVPN and [I-D.ietf-bess-evpn-virtual-hub] for EVPN, or an AR-Replicator as defined in [I-D.ietf-bess-evpn-optimized-ir] for EVPN.
"

129	2.  Specifications
130
131	   The BIER Penultimate Hop Popping is intended only for the scenario
132	   where a multicast flow overlay router for a BIER domain does not
133	   support BIER forwarding, either entirely or just for some particular
134	   BitStringLengths (BSL).  In the latter case, PHP is only for BIER
135	   packets with those BSL.  The flow overlay router would be a BFER if
136	   it did support BIER forwarding, and PHP would not be done by its
137	   penultimate hop.
138
139	   The procedures in this section apply only if, by means outside the
140	   scope of this document, it is known that all potential penultimate
141	   hop BFRs support PHP (i.e., able to pop the BIER header when sending
142	   to a requesting flow overlay router) , and that the payload after
143	   BIER header is one of the following:
144
145	   *  MPLS packets with downstream-assigned label at top of stack (i.e.,
146	      the Proto field in the BIER header is 1).  For example, a label
147	      from a Domain-wide Common Block (DCB) is used as specified in
148	      [I-D.ietf-bess-mvpn-evpn-aggregation-label].
149
150	   *  IPv4/IPv6 multicast packets for which Reverse Path Forwarding
151	      check is disabled.

[minor]
Suggested rewrite

"
The BIER Penultimate Hop Popping (PHP) mechanism is designed specifically for scenarios where a multicast flow overlay router within a BIER domain does not support BIER forwarding, either completely or for specific BitStringLengths (BSL). In the latter case, PHP applies only to BIER packets with those particular BSLs. If the flow overlay router were capable of BIER forwarding, it would function as a BFER, and PHP would not be performed by the penultimate hop.

The procedures outlined in this section are applicable only if, through means outside the scope of this document, it is established that all potential penultimate hop BFRs are capable of supporting PHP (i.e., able to remove the BIER header when forwarding to a requesting flow overlay router) and that the payload following the BIER header is one of the following:

* MPLS packets with a downstream-assigned label at the top of the stack (i.e., the Proto field in the BIER header is set to 1). For instance, a label from a Domain-wide Common Block (DCB) as specified in [I-D.ietf-bess-mvpn-evpn-aggregation-label].

* IPv4/IPv6 multicast packets for which the Reverse Path Forwarding (RPF) check is disabled.
"

153	2.1.  Signaling
154
155	   With IS-IS signaling, a sub-TLV in another sub-TLV is called sub-sub-
156	   TLV (and more sub-levels are possible like sub-sub-sub-TLV).  With
157	   other signaling protocols, a sub-TLV in another sub-TLV is still
158	   called sub-TLV.  For convenience, in this document we use sub-TLV
159	   even when it is sub-sub-TLV in IS-IS, as there is no ambiguity with
160	   the name itself (e.g.  MPLS Encapsulation).
161
162	   A BIER-incapable router, if acting as a multicast flow overlay router
163	   for BIER, MUST signal its BIER information as specified in [RFC8401],
164	   [RFC8444], [I-D.ietf-bier-ospfv3-extensions], or
165	   [I-D.ietf-bier-idr-extensions] with a PHP sub-TLV included in the
166	   BIER sub-TLV (or TLV in case of BGP) attached to the BIER-incapable
167	   router's BFR-prefix to request BIER PHP from other BFRs.  The type of
168	   the sub-TLV or sub-TLV is TBD, and the length is 0.
169
170	   With MPLS encapsulation, the BIER-incapable multicast flow overlay
171	   router MAY omit the BIER MPLS Encapsulation sub-LV, or MUST set the
172	   Label field in BIER MPLS Encapsulation sub-TLV to Implicit Null Label
173	   [RFC3032].
174
175	   With MPLS encapsulation, if a BFER (that does support BIER but) does
176	   not support a certain BSL, it MAY advertise a corresponding BIER MPLS
177	   Encapsulation sub-TLV with the Label field to Implicit Null Label to
178	   request PHP for that BSL.  It MUST NOT include the PHP sub-TLV in
179	   this case.
180
181	   With non-MPLS encapsulation [I-D.ietf-bier-lsr-non-mpls-extensions],
182	   the BIER-incapable multicast flow overlay router MAY omit the BIER
183	   non-MPLS Encapsulation sub-TLV, or MUST set the BIFT-id field in the
184	   BIER non-MPLS Encapsulation sub-TLV to 0.
185
186	   With non-MPLS encapsulation, if a BFER (that does support BIER but)
187	   does not support certain BSL, it MAY advertise a corresponding BIER
188	   non-MPLS Encapsulation sub-TLV but set the BIFT-id field to 0 to
189	   request PHP for that BSL.  It MUST NOT include the PHP sub-TLV in
190	   this case.

[minor]
Suggested rewrite

"
In IS-IS signaling, a sub-TLV nested within another sub-TLV is referred to as a sub-sub-TLV (and further levels are possible, such as sub-sub-sub-TLV). In other signaling protocols, a sub-TLV nested within another sub-TLV is still referred to as a sub-TLV. For convenience, this document uses the term "sub-TLV" even when referring to a sub-sub-TLV in IS-IS, as there is no ambiguity in the terminology (e.g., MPLS Encapsulation).

A BIER-incapable router, when functioning as a multicast flow overlay router for BIER, MUST signal its BIER information as specified in [RFC8401], [RFC8444], [I-D.ietf-bier-ospfv3-extensions], or [I-D.ietf-bier-idr-extensions], including a PHP sub-TLV within the BIER sub-TLV (or TLV in the case of BGP) attached to the BIER-incapable router's BFR-prefix to request BIER PHP from other BFRs. The type of the sub-TLV or sub-sub-TLV is TBD, and the length is 0.

For MPLS encapsulation, the BIER-incapable multicast flow overlay router MAY omit the BIER MPLS Encapsulation sub-TLV, or it MUST set the Label field in the BIER MPLS Encapsulation sub-TLV to the Implicit Null Label [RFC3032].

In the case of MPLS encapsulation, if a BFER (which supports BIER but not a specific BSL) does not support a particular BSL, it MAY advertise a corresponding BIER MPLS Encapsulation sub-TLV with the Label field set to the Implicit Null Label to request PHP for that BSL. In this scenario, the PHP sub-TLV MUST NOT be included.

For non-MPLS encapsulation [I-D.ietf-bier-lsr-non-mpls-extensions], the BIER-incapable multicast flow overlay router MAY omit the BIER non-MPLS Encapsulation sub-TLV, or it MUST set the BIFT-id field in the BIER non-MPLS Encapsulation sub-TLV to 0.

Similarly, for non-MPLS encapsulation, if a BFER (which supports BIER but not a specific BSL) does not support a particular BSL, it MAY advertise a corresponding BIER non-MPLS Encapsulation sub-TLV but set the BIFT-id field to 0 to request PHP for that BSL. In this scenario, the PHP sub-TLV MUST NOT be included.
"

192	2.2.  BIRT/BIFT Calculation
193
194	   If a BFR follows section 6.9 of [RFC8279] to handle BIER-incapable
195	   routers, it MUST treat a router as BIER-incapable for a BSL if the
196	   label in the corresponding MPLS Encapsulation sub-TLV advertised by
197	   the router is Implicit Null, or if the BIFT-id in the corresponding
198	   non-MPLS Encapsulation sub-TLV is 0.  It MUST treat the router as
199	   BIER-incapable for all BSLs if the router advertises a PHP sub-TLV.
200	   That way, the router will not used as a transit BFR for certain or
201	   for all BSLs.
202
203	   If the downstream neighbor (either resulting in IGP calculation or
204	   carried in the BIER Nexthop sub-TLV in case of BGP) for a BFR-prefix
205	   is the one advertising the prefix with a PHP sub-TLV or with an
206	   Implicit Null Label in its BIER MPLS Encapsulation sub-TLV, or with
207	   BIFT-id 0 in its BIER non-MPLS Encapsulation sub-TLV, then when the
208	   corresponding BIRT or BIFT entry is created/updated, the forwarding
209	   behavior MUST be that the BIER header is removed and the payload be
210	   sent to the downstream router without the BIER header, either
211	   directly or over any type of tunnel.

[minor]
Suggested rewrite

"
If a BFR adheres to Section 6.9 of [RFC8279] for handling BIER-incapable routers, it MUST treat a router as BIER-incapable for a specific BSL if the label in the corresponding MPLS Encapsulation sub-TLV advertised by the router is Implicit Null, or if the BIFT-id in the corresponding non-MPLS Encapsulation sub-TLV is 0. Additionally, the router MUST be treated as BIER-incapable for all BSLs if it advertises a PHP sub-TLV. Consequently, the router will not be utilized as a transit BFR for certain or all BSLs.

When the downstream neighbor (whether determined through IGP calculation or indicated in the BIER Nexthop sub-TLV in the case of BGP) for a BFR-prefix is the router that advertises the prefix with a PHP sub-TLV, an Implicit Null Label in its BIER MPLS Encapsulation sub-TLV, or a BIFT-id of 0 in its BIER non-MPLS Encapsulation sub-TLV, then, upon the creation or update of the corresponding BIRT or BIFT entry, the forwarding behavior MUST be that the BIER header is removed and the payload is forwarded to the downstream router without the BIER header, either directly or over any type of tunnel.
"

213	3.  Security Considerations
214
215	   This specification does not introduce additional security concerns
216	   beyond those already discussed in BIER architecture and OSPF/IS-IS/
217	   BGP extensions for BIER signaling.

[major]
>From a security perspective, this looks reasonable brief. Maybe something could be added about the impact of doing PHP operation and the impact upon BIER? To give some initial ideas:

* Loss of BIER Header Information
When PHP is applied, the BIER header is removed by the penultimate router, and only the payload is forwarded to the final destination. This removal could obscure the original the intended BIER forwarding path, making it difficult for the final hop or network monitoring tools to verify the origin and integrity of the packet.

* Reduced Visibility for Security Monitoring
The removal of the BIER header by the penultimate router reduces the visibility of BIER-specific information, e.g. the bitstring used for forwarding. This could hinder network operators' ability to perform deep packet inspection (DPI) or other security monitoring techniques that rely on the full packet header.

* Potential for Misconfiguration
Misconfiguration of PHP could lead to scenarios where the BIER header is removed prematurely, or where PHP is applied to traffic that should have retained the BIER header. This could result in unintended forwarding behavior, including traffic being misrouted or dropped.

* Complexity in Managing Access Control and Policy Enforcement
With the BIER header removed before the packet reaches its final destination, it may become more challenging to enforce certain access control policies or to apply security policies based on BIER-specific information.

* Impact on End-to-End Security Features
The removal of the BIER header could interfere with end-to-end security features, such as encryption or authentication mechanisms, that are designed to operate over the entire path, including BIER information.

* Operational Complexity
Implementing and managing PHP in a BIER domain adds operational complexity, which could increase the likelihood of configuration errors or vulnerabilities being introduced into the network.


Some thoughts on a section about "Operational Considerations"

[major]
There is no section discussing operational considerations and the impact when doing PHP.

PHP in the context of BIER introduces several operational concerns that network operators need to consider. These concerns stem from the changes in packet handling, potential impacts on network management, and the complexity introduced by implementing PHP in a BIER-enabled network.

1. Increased Complexity in Network Configuration
* Concern: Implementing PHP adds another layer of complexity to network configuration. Network operators must ensure that PHP is correctly applied only in appropriate scenarios, such as when the next hop is a BIER-incapable router or where specific traffic engineering requirements necessitate it.
* Operational Impact: Misconfigurations could lead to incorrect packet forwarding, either by prematurely stripping the BIER header or by failing to strip it when necessary, potentially disrupting traffic flows.

2. Troubleshooting and Diagnostics Challenges
* Concern: With PHP, the BIER header is removed before the packet reaches the final hop, which can make troubleshooting and diagnostics more challenging. Network operators may have difficulty tracing the path of BIER packets or understanding why certain packets were forwarded in a particular way.
* Operational Impact: The reduction in header information at the final hop could lead to longer troubleshooting times, increased difficulty in root cause analysis, and potentially unresolved issues in the network.

3. Impact on Network Visibility and Monitoring
* Concern: PHP reduces the visibility of BIER-specific information, e.g. the bitstring, at the final hop. This reduction can hinder network monitoring tools that rely on full packet visibility for traffic analysis and anomaly detection.
* Operational Impact: Reduced visibility may result in gaps in network monitoring, making it harder to detect and respond to issues such as traffic misrouting, network loops, or malicious activities.

4. Incompatibility with Existing Tools and Processes
* Concern: Existing network management tools and processes may not be fully compatible with the PHP mechanism. Adjusting these tools and processes to account for PHP could require significant updates or replacements.
* Operational Impact: The need to modify or replace existing tools could lead to operational disruptions, increased costs, and the need for additional training for network personnel.

5. Increased Risk of Misconfiguration
* Concern: PHP introduces additional configuration options, increasing the risk of misconfiguration. Network operators must ensure that PHP is applied correctly and consistently across all relevant devices in the network.
* Operational Impact: Misconfigurations could lead to traffic being misrouted, dropped, or delivered in a way that does not meet the intended quality of service (QoS) parameters.

6. Compatibility with BIER OAM Procedures
* Concern: The removal of the BIER header could interfere with BIER Operations, Administration, and Maintenance (OAM) procedures, which rely on the BIER header for monitoring and diagnostic purposes.
* Operational Impact: OAM processes may need to be adjusted or supplemented with additional tools to ensure that network health can be accurately monitored and maintained in environments where PHP is used.