< draft-ietf-bier-php-02.txt   draft-ietf-bier-php-03.txt >
BIER Z. Zhang BIER Z. Zhang
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track May 29, 2019 Intended status: Standards Track October 3, 2019
Expires: November 30, 2019 Expires: April 5, 2020
BIER Penultimate Hop Popping BIER Penultimate Hop Popping
draft-ietf-bier-php-02 draft-ietf-bier-php-03
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 MVPN/GTM [RFC6514] [RFC7716] or EVPN BUM [RFC7432]. It is for Multicast Virtual Private Network (MVPN) [RFC6514], Global
possible that not all routers in the provider network support BIER Table Multicast [RFC7716] or Ethernet Virtual Private Network (EVPN)
and there are various methods to handle BIER incapable transit [RFC7432]. It is possible that not all routers in the provider
routers. However the MVPN/EVPN PEs are assumed to be BIER capable - network support BIER and there are various methods to handle BIER
they are BFIRs/BFERs. This document specifies a method to allow BIER incapable transit routers. However those methods assume the MVPN/
incapable routers to act as MVPN/EVPN PEs with BIER as the transport, EVPN Provider Edges (PEs) are BIER capable. This document specifies
by having the upstream BFR (connected directly or indirectly via a a method to allow BIER incapable routers to act as MVPN/EVPN PEs with
tunnel) of a PE remove the BIER header and send the payload to the BIER as the transport, by having the upstream BIER Forwarding Router
PE. (BFR) that is connected directly or indirectly via a tunnel to a BIER
incapable PE remove the 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 45 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 November 30, 2019. This Internet-Draft will expire on April 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Terminologies 1. Introduction
Familiarity with BIER/MVPN/EVPN protocols and procedures is assumed.
Some terminologies are listed below for convenience.
[To be added].
2. Introduction
The BIER architecture includes three layers: the "routing underlay", The BIER architecture includes three layers: the "routing underlay",
the "BIER layer", and the "multicast flow overlay". The multicast the "BIER layer", and the "multicast flow overlay". The multicast
flow overlay is responsible for the BFERs to signal to BFIRs that flow overlay is responsible for the BIER Forwarding Egress Routers
(BFERs) to signal to BIER Forwarding Ingress Routers (BFIRs) that
they are interested in receiving certain multicast flows so that they are interested in receiving certain multicast flows so that
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 P/PE routers are BIER Consider an MVPN/EVPN deployment where enough provider routers are
capable for BIER to become the preferred the choice of provider BIER capable for BIER to become the preferred the 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
indiretly via a tunnel to the PE). This is similar to MPLS PHP indirectly via any type of tunnel to the PE). This is similar to
though it is the BIER header that is popped. In case of MPLS Multi-Protocol Label Switching (MPLS) PHP though it is the BIER
encapsulation, even the signaling is similar - a BIER incapable header that is popped.
router signals as if it supported BIER, but to request PHP at the
penultimate hop, it signals an Implicit Null label instead of a
regular BIER label as the Label Range Base in its BIER MPLS
Encapsulation sub-TLV.
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. router does not support BIER, as long as the edge router does not
need to know the transmitting BFIR.
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.
3. Specifications 2. Specifications
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 MPLS packet with downstream-assigned label at top of stack header is one of the following:
(i.e., 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 o MPLS packets with downstream-assigned label at top of stack (i.e.,
[I-D.ietf-bess-mvpn-evpn-aggregation-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-
D.ietf-bess-mvpn-evpn-aggregation-label].
o Packets with VXLAN/NVGRE/GENEVE header [I-D.ietf-bier-evpn] (i.e.
the Proto field in the BIER header specifies VXLAN/NVGRE/GENEVE
per IANA assignments to be done for [I-D.ietf-bier-evpn]).
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
[I-D.ietf-bier-ospf-bier-extensions] or [I-D.ietf-bier-idr- [RFC8444] or [I-D.ietf-bier-idr-extensions], with a PHP sub-sub-TLV
extensions], with a PHP sub-sub-TLV included in the BIER sub-TLV included in the BIER sub-TLV attached to the BIER incapable router's
attached to the BIER incapable router's BIER prefix to request BIER BIER prefix to request BIER PHP from other BFRs. The sub-sub-TLV's
PHP from other BFRs. The sub-sub-TLV's type is TBD, and the length type is TBD, and the length is 0.
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 Range Base in BIER MPLS Encapsulation sub-sub-TLV to the Label field in BIER MPLS Encapsulation sub-sub-TLV to Implicit
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 Range Base 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 Range routers, it must treat a router as BIER incapable if the label
Base dvertised 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 as the prefix with a PHP sub-sub-TLV or with an Implicit Null Label in
the Label Range Base in its BIER MPLS Encapsulation sub-sub-TLV, then the Label field in its BIER MPLS Encapsulation sub-sub-TLV, then when
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,
either directly or over a tunnel. either directly or over any type of tunnel.
4. Security Considerations 3. Security Considerations
This specification does not introduce additional security concerns This specification does not introduce additional security concerns
beyond those already discussed in BIER architecture and OSPF/ISIS/BGP beyond those already discussed in BIER architecture and OSPF/ISIS/BGP
exentions for BIER signaling. extensions for BIER signaling.
5. IANA Considerations 4. IANA Considerations
This document requests a new sub-sub-TLV type value from the "Sub- This document requests a new sub-sub-TLV type value from the "Sub-
sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV
Codepoints" registry: Codepoints" registry:
Type Name Type Name
---- ---- ---- ----
TBD BIER PHP Request TBD BIER PHP Request
This document also requests a new sub-TLV type value from the OSPFv2 This document also requests a new sub-TLV type value from the OSPFv2
Extended Prefix TLV Sub-TLV registry: Extended Prefix TLV Sub-TLV registry:
Type Name Type Name
---- ---- ---- ----
TBD BIER PHP Request TBD BIER PHP Request
6. Acknowledgements 5. Acknowledgements
The author wants to thank Eric Rosen and Antonie Przygienda for their The author wants to thank Eric Rosen and Antonie Przygienda for their
review, comments and suggestions. The author also wants to thank review, comments and suggestions. The author also wants to thank
Senthil Dhanaraj for his suggestion of requesting PHP if a BFER does Senthil Dhanaraj for his suggestion of requesting PHP if a BFER does
not support certain BSL. not support certain BSL.
7. References 6. References
7.1. Normative References 6.1. Normative References
[I-D.ietf-bess-mvpn-evpn-aggregation-label] [I-D.ietf-bess-mvpn-evpn-aggregation-label]
Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands,
"MVPN/EVPN Tunnel Aggregation with Common Labels", draft- "MVPN/EVPN Tunnel Aggregation with Common Labels", draft-
ietf-bess-mvpn-evpn-aggregation-label-02 (work in ietf-bess-mvpn-evpn-aggregation-label-02 (work in
progress), December 2018. progress), December 2018.
[I-D.ietf-bier-evpn]
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", draft-ietf-bier-evpn-01 (work in
progress), April 2018.
[I-D.ietf-bier-idr-extensions] [I-D.ietf-bier-idr-extensions]
Xu, X., Chen, M., Patel, K., Wijnands, I., and T. Xu, X., Chen, M., Patel, K., Wijnands, I., and T.
Przygienda, "BGP Extensions for BIER", draft-ietf-bier- Przygienda, "BGP Extensions for BIER", draft-ietf-bier-
idr-extensions-06 (work in progress), January 2019. idr-extensions-07 (work in progress), September 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
skipping to change at page 6, line 22 skipping to change at page 6, line 16
Zhang, "Bit Index Explicit Replication (BIER) Support via Zhang, "Bit Index Explicit Replication (BIER) Support via
IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
<https://www.rfc-editor.org/info/rfc8401>. <https://www.rfc-editor.org/info/rfc8401>.
[RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
Extensions for Bit Index Explicit Replication (BIER)", Extensions for Bit Index Explicit Replication (BIER)",
RFC 8444, DOI 10.17487/RFC8444, November 2018, RFC 8444, DOI 10.17487/RFC8444, November 2018,
<https://www.rfc-editor.org/info/rfc8444>. <https://www.rfc-editor.org/info/rfc8444>.
7.2. Informative References 6.2. Informative References
[I-D.ietf-bess-evpn-optimized-ir] [I-D.ietf-bess-evpn-optimized-ir]
Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A.
Sajassi, "Optimized Ingress Replication solution for Sajassi, "Optimized Ingress Replication solution for
EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in
progress), October 2018. progress), October 2018.
[I-D.keyupate-bess-evpn-virtual-hub] [I-D.keyupate-bess-evpn-virtual-hub]
Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W. Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W.
Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft- Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft-
keyupate-bess-evpn-virtual-hub-01 (work in progress), keyupate-bess-evpn-virtual-hub-02 (work in progress),
October 2018. September 2019.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
 End of changes. 29 change blocks. 
71 lines changed or deleted 71 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/