< draft-ietf-bier-php-05.txt		draft-ietf-bier-php-06.txt >
	BIER Z. Zhang		BIER Z. Zhang
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Standards Track July 29, 2020		Intended status: Standards Track August 24, 2020
	Expires: January 30, 2021		Expires: February 25, 2021
	BIER Penultimate Hop Popping		BIER Penultimate Hop Popping
	draft-ietf-bier-php-05		draft-ietf-bier-php-06
	Abstract		Abstract
	Bit Index Explicit Replication (BIER) can be used as provider tunnel		Bit Index Explicit Replication (BIER) can be used as provider tunnel
	for Multicast Virtual Private Network (MVPN) [RFC6514], Global		for Multicast Virtual Private Network (MVPN). Global Table Multicast
	Table Multicast [RFC7716] or Ethernet Virtual Private Network (EVPN)		[RFC7716] or Ethernet Virtual Private Network (EVPN). It is possible
	[RFC7432]. It is possible that not all routers in the provider		that not all routers in the provider network support BIER and there
	network support BIER and there are various methods to handle BIER		are various methods to handle BIER-incapable transit routers.
	incapable transit routers. However those methods assume the MVPN/		However those methods assume the MVPN/EVPN Provider Edges (PEs) are
	EVPN Provider Edges (PEs) are BIER capable. This document specifies		BIER-capable. This document specifies a method to allow BIER-
	a method to allow BIER incapable routers to act as MVPN/EVPN PEs with		incapable routers to act as MVPN/EVPN PEs with BIER as the transport,
	BIER as the transport, by having the upstream BIER Forwarding Router		by having the upstream BIER Forwarding Router (BFR) that is connected
	(BFR) that is connected directly or indirectly via a tunnel to a BIER		directly or indirectly via a tunnel to a BIER-incapable PE remove the
	incapable PE remove the BIER header and send the payload to the PE.		BIER header and send the payload to the PE.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119.		document are to be interpreted as described in RFC2119.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 30, 2021.		This Internet-Draft will expire on February 25, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	BFIRs can encode the correct bitstring for BIER forwarding by the		BFIRs can encode the correct bitstring for BIER forwarding by the
	BIER layer.		BIER layer.
	MVPN and EVPN are two similar overlays where BGP Auto-Discovery		MVPN and EVPN are two similar overlays where BGP Auto-Discovery
	routes for MVPN/EVPN are exchanged among all PEs to signal which PEs		routes for MVPN/EVPN are exchanged among all PEs to signal which PEs
	need to receive multicast traffic for all or certain flows.		need to receive multicast traffic for all or certain flows.
	Typically the same provider tunnel type is used for traffic to reach		Typically the same provider tunnel type is used for traffic to reach
	all receiving PEs.		all receiving PEs.
	Consider an MVPN/EVPN deployment where enough provider routers are		Consider an MVPN/EVPN deployment where enough provider routers are
	BIER capable for BIER to become the preferred the choice of provider		BIER-capable for BIER to become the preferred choice of provider
	tunnel. However, some PEs cannot be upgraded to support BIER		tunnel. However, some PEs cannot be upgraded to support BIER
	forwarding. While there are ways to allow an ingress PE to send		forwarding. While there are ways to allow an ingress PE to send
	traffic to some PEs with one type of tunnel and send traffic to some		traffic to some PEs with one type of tunnel and send traffic to some
	other PEs with a different type of tunnel, the procedure becomes		other PEs with a different type of tunnel, the procedure becomes
	complicated and forwarding is not optimized.		complicated and forwarding is not optimized.
	One way to solve this problem is to use Penultimate Hop Popping (PHP)		One way to solve this problem is to use Penultimate Hop Popping (PHP)
	so that the upstream BFR can pop the BIER header and send the payload		so that the upstream BFR can pop the BIER header and send the payload
	"natively" (note that the upstream BFR can be connected directly or		"natively" (note that the upstream BFR can be connected directly or
	indirectly via any type of tunnel to the PE). This is similar to		indirectly via any type of tunnel to the PE). This is similar to
	Multi-Protocol Label Switching (MPLS) PHP though it is the BIER		Multi-Protocol Label Switching (MPLS) PHP though it is the BIER
	header that is popped.		header that is popped.
	The transition of an existing MVPN/EVPN deployment with traditional		The transition of an existing MVPN/EVPN deployment with traditional
	provider tunnels to using BIER with some PEs not capable of receiving		provider tunnels to using BIER with some PEs not capable of receiving
	BIER packets can be incremental. All PEs are first upgraded to		BIER packets can be incremental. All PEs are first upgraded to
	support BIER at least in the control plane, with those not capable of		support BIER at least in the control plane, with those not capable of
	BIER forwarding requesting PHP. Then BIER capable ingress PEs		BIER forwarding requesting PHP. Then BIER-capable ingress PEs
	independently and incrementally switch to BIER transport.		independently and incrementally switch to BIER transport.
	While the above text uses MVPN/EVPN as example, BIER PHP is		While the above text uses MVPN/EVPN as example, BIER PHP is
	applicable to any scenario where the multicast flow overlay edge		applicable to any scenario where the multicast flow overlay edge
	router does not support BIER, as long as the edge router does not		router does not support BIER, as long as the edge router does not
	need to know the transmitting BFIR or participate in BIER OAM		need to know the transmitting BFIR or participate in BIER OAM
	procedures.		procedures.
	This works well if a BIER incapable PE only needs to receive		This works well if a BIER-incapable PE only needs to receive
	multicast traffic. If it needs to send multicast traffic as well,		multicast traffic. If it needs to send multicast traffic as well,
	then it must Ingress Replicate to a BIER capable helper PE, who will		then it must Ingress Replicate to a BIER-capable helper PE, who will
	in turn relay the packet to other PEs. The helper PE is either a		in turn relay the packet to other PEs. The helper PE is either a
	Virtual Hub as specified in [RFC7024] for MVPN and [I-D.keyupate-		Virtual Hub as specified in [RFC7024] for MVPN and [I-D.keyupate-
	bess-evpn-virtual-hub] for EVPN, or an AR-Replicator as specified in		bess-evpn-virtual-hub] for EVPN, or an AR-Replicator as specified in
	[I-D.ietf-bess-evpn-optimized-ir] for EVPN.		[I-D.ietf-bess-evpn-optimized-ir] for EVPN.
	2. Specifications		2. Specifications
			The BIER Penultimate Hop Popping is intended only for the scenario
			where a multicast flow overlay router for a BIER domain does not
			support BIER forwarding, either entirely or just for some particular
			BitStringLengths. In the latter case, PHP is only for BIER packets
			with those BitStringLengths. The flow overlay router would be a BFER
			if it did support BIER forwarding, and PHP would not be done by its
			penultimate hop.
	The procedures in this section apply only if, by means outside the		The procedures in this section apply only if, by means outside the
	scope of this document, it is known that the payload after BIER		scope of this document, it is known that the payload after BIER
	header is one of the following:		header is one of the following:
	o MPLS packets with downstream-assigned label at top of stack (i.e.,		o MPLS packets with downstream-assigned label at top of stack (i.e.,
	the Proto field in the BIER header is 1). For example, a label		the Proto field in the BIER header is 1). For example, a label
	from a Domain-wide Common Block (DCB) is used as specified in [I-		from a Domain-wide Common Block (DCB) is used as specified in [I-
	D.ietf-bess-mvpn-evpn-aggregation-label].		D.ietf-bess-mvpn-evpn-aggregation-label].
	o IPv4/IPv6 multicast packets for which Reverse Path Forwarding		o IPv4/IPv6 multicast packets for which Reverse Path Forwarding
	check is disabled.		check is disabled.
	A BIER incapable router, if acting as a multicast flow overlay		A BIER-incapable router, if acting as a multicast flow overlay
	router, MUST signal its BIER information as specified in [RFC8401] or		router, MUST signal its BIER information as specified in [RFC8401] or
	[RFC8444] or [I-D.ietf-bier-idr-extensions], with a PHP sub-sub-TLV		[RFC8444] or [I-D.ietf-bier-idr-extensions], with a PHP sub-sub-TLV
	included in the BIER sub-TLV attached to the BIER incapable router's		included in the BIER sub-TLV attached to the BIER-incapable router's
	BIER prefix to request BIER PHP from other BFRs. The sub-sub-TLV's		BIER prefix to request BIER PHP from other BFRs. The sub-sub-TLV's
	type is TBD, and the length is 0.		type is TBD, and the length is 0.
	With MPLS encapsulation, the BIER incapable multicast flow overlay		With MPLS encapsulation, the BIER-incapable multicast flow overlay
	router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set		router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set
	the Label field in BIER MPLS Encapsulation sub-sub-TLV to Implicit		the Label field in BIER MPLS Encapsulation sub-sub-TLV to Implicit
	Null Label [RFC3032].		Null Label [RFC3032].
	With MPLS encapsulation, if a BFER does not support certain BSL, it		With MPLS encapsulation, if a BFER does not support certain BSL, it
	MAY still advertise a corresponding BIER MPLS Encapsulation sub-TLV		MAY still advertise a corresponding BIER MPLS Encapsulation sub-TLV
	but set the Label field to Implicit Null Label.		but set the Label field to Implicit Null Label.
	If a BFR follows section 6.9 of [RFC8279] to handle BIER incapable		If a BFR follows section 6.9 of [RFC8279] to handle BIER-incapable
	routers, it must treat a router as BIER incapable if the label		routers, it must treat a router as BIER-incapable if the label
	advertised by the router is Implicit Null, or if the router		advertised by the router is Implicit Null, or if the router
	advertises a PHP sub-sub-TLV, so that the router is not used as a		advertises a PHP sub-sub-TLV, so that the router is not used as a
	transit BFR.		transit BFR.
	If the downstream neighbor for a BIER prefix is the one advertising		If the downstream neighbor for a BIER prefix is the one advertising
	the prefix with a PHP sub-sub-TLV or with an Implicit Null Label in		the prefix with a PHP sub-sub-TLV or with an Implicit Null Label in
	the Label field in its BIER MPLS Encapsulation sub-sub-TLV, then when		the Label field in its BIER MPLS Encapsulation sub-sub-TLV, then when
	the corresponding BIRT or BIFT entry is created/updated, the		the corresponding BIRT or BIFT entry is created/updated, the
	forwarding behavior MUST be that the BIER header is removed and the		forwarding behavior MUST be that the BIER header is removed and the
	payload be sent to the downstream router without the BIER header,		payload be sent to the downstream router without the BIER header,
End of changes. 13 change blocks.
	23 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/