< draft-xie-bier-mvpn-mpls-p2mp-00.txt   draft-xie-bier-mvpn-mpls-p2mp-01.txt >
Network Working Group J. Xie Network Working Group J. Xie
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track October 27, 2017 Intended status: Standards Track M. McBride
Expires: April 30, 2018 Expires: September 6, 2018 Huawei Technologies
M. Chen
Huawei
L. Geng
China Mobile
March 5, 2018
Multicast VPN Using MPLS P2MP and BIER Multicast VPN Using MPLS P2MP and BIER
draft-xie-bier-mvpn-mpls-p2mp-00 draft-xie-bier-mvpn-mpls-p2mp-01
Abstract Abstract
The Multicast Virtual Private Network (MVPN) specifications defines The MVPN specifications allow the use of several different kinds of
P-tunnels for carrying multicast traffic across the backbone. A P-tunnel technology, such as mLDP P2MP, RSVP-TE P2MP and PIM SSM. It
variety of P-tunnel types are supported. Bit Index Explicit is common for such a P-tunnel having a multicast-specific path. Bit
Replication (BIER) is a new architecture that provides optimal Index Explicit Replication (BIER) is an architecture that provides
multicast forwarding through a "multicast domain", without requiring optimal multicast forwarding without requiring intermediate routers
intermediate routers to maintain any per-flow state. The purpose of to maintain any per-flow state by using a multicast-specific BIER
the current document is to specify one way of carrying multicast header.
traffic over an SP MPLS backbone network using compatible method and
encapsulation of BIER. It uses a pre-build P2MP as the BIER [I-D.ietf-bier-mvpn] delivers a solution of MVPN using SPF based BIER
topology, and uses mLDP/RSVP-TE protocol extension to build BIER- defined in [RFC8279]. It can not, however, support a multicast-
related underlay routing and forwarding information in-band when specific path well, something common in legacy MVPN deployment.
building the P2MP topology. [RFC8279] provides a solution to support mid nodes without BIER-
capability. It can not, however, support deployment on a network
that has edge nodes without BIER-capability, which is common in some
SP-networks.
This document introduces a seamless transition mechanism from legacy
MVPN to MVPN using P2MP based BIER while preserving existing features
such as multicast-specific PATH and Live-Live protection. It also
introduces a seamless Live-Live protection mechanism by re-using the
Entropy field of the BIER header, and two methods to deploy BIER when
edge nodes and/or mid nodes don't have BIER-capability.
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 47 skipping to change at page 2, line 20
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 April 30, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use of the PTA in MVPN Routes . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 4. MVPN using P2MP based BIER . . . . . . . . . . . . . . . . . 5
3.2. Use of the PTA in x-PMSI A-D Routes . . . . . . . . . . . 4 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Use of the PTA in Leaf A-D routes . . . . . . . . . . . . 6 4.2. MVPN Transition from P2MP to P2MP based BIER . . . . . . 6
4. P2MP LSP based BIER Forwarding Procedures . . . . . . . . . . 7 4.2.1. Use of the PTA in x-PMSI A-D Routes . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Use of the PTA in Leaf A-D routes . . . . . . . . . . 9
4.2. Building P2MP LSP based BIER forwarding state . . . . . . 8 4.3. Building P2MP based BIER forwarding state . . . . . . . . 10
4.3. Live-Live protection . . . . . . . . . . . . . . . . . . 9 4.4. Inheriting and Developing of Live-Live protection . . . . 11
5. Provisioning Considerations . . . . . . . . . . . . . . . . . 9 5. P2MP based BIER Forwarding Procedures . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.2. P2MP based BIER forwarding customization . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5.3. When Mid, Leaf or Bud nodes do not support P-CAPABILITY . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. When Leaf or Bud nodes do not support D-CAPABILITY . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 6. Provisioning Considerations . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC6513] and [RFC6514] specify the protocols and procedures that a [RFC6513] and [RFC6514] specify the protocols and procedures that a
Service Provider (SP) can use to provide Multicast Virtual Private Service Provider (SP) can use to provide Multicast Virtual Private
Network (MVPN) service to its customers. Multicast tunnels are Network (MVPN) service to its customers. Multicast tunnels are
created through an SP's backbone network; these are known as created through an SP's backbone network; these are known as
"P-tunnels". The P-tunnels are used for carrying multicast traffic "P-tunnels". The P-tunnels are used for carrying multicast traffic
across the backbone. The MVPN specifications allow the use of across the backbone. The MVPN specifications allow the use of
several different kinds of P-tunnel technology. In an MPLS network, several different kinds of P-tunnel technology, such as mLDP P2MP,
such P-tunnel can be mLDP P2MP or RSVP-TE P2MP. RSVP-TE P2MP and PIM SSM. It is common for such a P-tunnel having a
multicast-specific path.
Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
an architecture that provides optimal multicast forwarding through a that provides optimal multicast forwarding through a "multicast
"multicast domain", without requiring intermediate routers to domain", without requiring intermediate routers to maintain any per-
maintain any per-flow state. flow state, by using a multicast-specific BIER header (per
[RFC8296]).
BIER architecture requires routers participating in BIER to exchange [I-D.ietf-bier-mvpn] delivers a solution of MVPN using SPF based BIER
BIER related information within a given domain. BIER architecture defined in [RFC8279]. It can not, however, support a multicast-
permits IGP/BGP or any other routing protocols to perform specific path well, something common in legacy MVPN deployment.
distribution of such information. Such routing protocols are defined
as Underlay protocols.
In an MPLS network, [I-D.ietf-bier-mpls-encapsulation] define a BIER [RFC8279] provides a solution to support mid nodes without BIER-
Header within it an initial 4 octets MPLS-Label, to encapsulate capability. It cannot, however, support deployment on a network that
Multicast packet and transport through the MPLS network. has edge nodes without BIER-capability, which may be common in some
SP-networks, especially when most of the nodes in a network or part
of a network are edge or service nodes.
The purpose of the current document is to specify one way of carrying This document introduces a seamless transition mechanism from legacy
multicast traffic over an SP MPLS backbone network, using compatible MVPN to MVPN using P2MP based BIER, by applying a BIER encapsulation
method and encapsulation described in the above BIER documents. It in data-plane to eliminate per-flow states, while preserving existing
uses a pre-build P2MP as the BIER topology, and uses mLDP/RSVP-TE features such as multicast-specific PATH and Live-Live protection by
protocol extension to build BIER-related underlay routing and using existing protocols.
forwarding information in-band when building the P2MP topology.
It also introduces a seamless Live-Live protection developped from
existing Live-Live protection scheme, by re-using the Entropy field
of the BIER header, for the ECMP/Entropy feature is not supported in
P2MP (per RFC6790).
It also introduces a seamless deployment solution on networks with
Non-BIER-capability Edge nodes and/or Mid nodes, by exploring the
P2MP/tree based BIER forwarding procedure in detail. Such a P2MP/
tree based BIER is mentioned but not explored in detail in RFC8279.
2. Terminology 2. Terminology
Readers of this document are assumed to be familiar with the Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative terminology and concepts of the documents listed as Normative
References. For convenience, some of the more frequently used terms References. For convenience, some of the more frequently used terms
and new terms list below. and new terms list below.
o LSP: Label Switch Path o LSP: Label Switch Path
skipping to change at page 3, line 51 skipping to change at page 4, line 34
SPs. P-tunnels are used to transport MVPN multicast data. SPs. P-tunnels are used to transport MVPN multicast data.
o PMSI: Provider Multicast Service Interface o PMSI: Provider Multicast Service Interface
o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an o x-PMSI A-D route: a route that is either an I-PMSI A-D route or an
S-PMSI A-D route. S-PMSI A-D route.
o PTA: PMSI Tunnel attribute. A type of BGP attribute known as the o PTA: PMSI Tunnel attribute. A type of BGP attribute known as the
PMSI Tunnel attribute. PMSI Tunnel attribute.
o P2MP LSP based BIER: BIER using P2MP LSP as topology o P2MP based BIER: BIER using P2MP LSP as topology
3. Use of the PTA in MVPN Routes o P-CAPABILITY: A capability to Process BitString in BIER Header of
a packet.
3.1. Overview o D-CAPABILITY: A capability to Disposit BIER Header of a packet,
including or excluding the BIER Label.
According to [I-D.ietf-bier-architecture], the P2MP LSP based BIER is o BSL: Bit String Length, that is 64, 128, 256, etc (per [RFC8279]).
a REAL BIER, which using a P2MP LSP as the underlay topology. The
P2MP LSP is not only a LSP, but also a topology as the BIER underlay.
The P2MP LSP based BIER is P-tunnel, which is used for bearing
multicast flows. Every flow can think as binding to an independent
tunnel, which is constructed by the BitString in the BIER header of
every packet of the flow. Multicast flows are transported in SPMSI-
only mode, on P2MP LSP based BIER tunnels, and never directly on P2MP
LSP tunnel.
3.2. Use of the PTA in x-PMSI A-D Routes 3. Applicability Statement
The BIER architecture document [RFC8279] describes how each node
forwards BIER packets hop by hop to neighboring nodes without
generating duplicate packets. This forwarding is for the case where
a form of underlay called "many to many " and built by IGP is used.
Obviously, the case of underlay of "one to many" or P2MP is a simpler
scenario, and the forwarding procedure naturally applies. However,
as is well-known, such a forwarding procedure requires the support of
hardware. The usage of the same forwarding method for both complex
scenarios and simple scenarios will inevitably require complex
hardware forwarding.
This document describes how BIER forwarding can be customized and
simplified with an underlay of "one to many" or P2MP (see chapter 5).
This customization and simplification eliminates some of the
unnecessary data plane processing and so is easier to implement with
existing hardware. Based on this customization of the forwarding
method for P2MP-based BIER, a variety of Partial Deployment methods
are given for the different capabilities of the hardware to support
BIER forwarding. Compared with RFC8279, when there is no BIER
forwarding capability on edge nodes, Partial Deployment can be
carried out ; For the case where the intermediate node has no BIER
forwarding capability, P2MP forwarding can be used without the need
for unicast replication.
This document also describes a MVPN Transition solution that
eliminates the per-flow state by introducing BIER MPLS encapsulation
and forwarding in data-plane, while preserving the original control-
plane protocol and its features, especially when some sort of path
customizing being used. The said path customization include RSVP-TE
P2MP using an explicit path, PIM-SSM tree using an explicit path ,
and MLDP P2MP where static route was used. These features Can
continue to retain, making the transition process seamless.
This document also describes a seamless redundancy mechanism for the
widely deployed MVPN Live-Live protection, by using the added
information in the BIER header as a sequence-number of per packet.
This will bring additional benefit to the transition process from
traditional MVPN using PIM-SSM/mLDP/RSVP-TE to MVPN using P2MP based
BIER.
4. MVPN using P2MP based BIER
4.1. Overview
According to [RFC8279], the P2MP based BIER is a BIER which using a
form of tree as the underlay. The P2MP LSP is not only a LSP, but
also a topology as the BIER underlay. The P2MP based BIER is
P-tunnel, which is used for bearing multicast flows. Every flow can
think as binding to an independent tunnel, which is constructed by
the BitString in the BIER header of every packet of the flow.
Multicast flows are transported in SPMSI-only mode, on P2MP based
BIER tunnels, and never directly on P2MP LSP tunnel.
Section 4.2 describes the overall principle of transitioning a Legacy
MVPN using P2MP to a MVPN using BIER. We call it a tick-tock
transitioning. It also descirbes the detail use of new types of PTA
in BGP MVPN routes to indicate PEs to initialize the building of P2MP
based BIER forwarding.
Section 4.3 describes the Underlay protocols to build P2MP based BIER
forwarding briefly.
Section 4.4 describes how the widely deployed Live-Live protection in
MVPN can be inherited and developed. This will introduce a new
function to BIER Layer by re-using the Entropy field of the BIER
encapsulation.
4.2. MVPN Transition from P2MP to P2MP based BIER
This section describes a MVPN transitioning solution that eliminates
the per-flow state by introducing BIER MPLS encapsulation and
forwarding procedure in data-plane, while preserving the originally
deployed control-plane protocol and its features, especially when
some sort of path customizing being used.
When transitioning a MVPN using mLDP P2MP P-tunnel, then continue
using mLDP to build a P2MP based BIER forwarding, preserving the
original mLDP features. For example, mLDP uses static route to
specify a path other than the path of IGP.
When transitioning a MVPN using RSVP-TE P2MP P-tunnel, then continue
using RSVP-TE to build a P2MP based BIER forwarding, preserving the
original RSVP-TE features. For example, RSVP-TE use explicit path to
specify a path other than the path of IGP.
When transitioning a MVPN using PIM-SSM p-tunnel, then continue using
PIM-SSM to build a P2MP based BIER forwarding, preserving the
original PIM features. For example, PIM use explicit vector to
specify a path other than the path of IGP.
It is called a tick-tock transitioning, that is to introduce a new
standard BIER encapsulation defined in [RFC8296], while preserving
old control-plane protocols, features, and most of the devices. When
all or most of the devices in a network support BIER forwarding, then
we can do a further tick-tock transitioning, that is to introducing a
new control-plane protocol while preserving old data-plane
encapsulation, when the control-plane protocol can provide all the
needed features of the old ones.
4.2.1. Use of the PTA in x-PMSI A-D Routes
As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by
an x-PMSI A-D route identifies the P-tunnel that is used to an x-PMSI A-D route identifies the P-tunnel that is used to
instantiate a particular PMSI. If a PMSI is to be instantiated by instantiate a particular PMSI. If a PMSI is to be instantiated by
P2MP LSP based BIER, the PTA is constructed by a BFIR, which is also P2MP LSP based BIER, the PTA is constructed by a BFIR, which is also
a Ingress LSR. This document defines the following Tunnel Types: a Ingress LSR. This document defines the following Tunnel Types:
+ TBD - RSVP-TE P2MP LSP based BIER + TBD - RSVP-TE built P2MP BIER
+ TBD - mLDP P2MP LSP based BIER + TBD - mLDP built P2MP BIER
+ TBD - PIM-SSM built P2MP BIER
Allocation is expected from IANA for two new tunnel type codepoints Allocation is expected from IANA for two new tunnel type codepoints
from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel
Types" registry. These codepoints will be used to indicate that the Types" registry. These codepoints will be used to indicate that the
PMSIs is instantiated by MLDP or RSVP-TE extension with support of PMSIs is instantiated by MLDP or RSVP-TE or PIM extension with
BIER. support of BIER.
When the Tunnel Type is set to RSVP-TE P2MP LSP based BIER, the When the Tunnel Type is set to RSVP-TE built P2MP BIER, the Tunnel
Tunnel Identifier include two parts, as follows: Identifier include two parts, as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSL | Tunnel Number | Must Be Zero | |BS Len | Max SI | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel Range Base | | MUST be zero | Tunnel Range Base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PTA of RSVP-TE P2MP LSP based BIER Figure 1: PTA of RSVP-TE built P2MP BIER
BSL: A 4 bits field. The values allowed in this field are specified BS Len: A 4 bits field. The values allowed in this field are
in section 2 of [I-D.ietf-bier-mpls-encapsulation]. specified in section 2 of [RFC8296].
Tunnel Number: A 1 octet field encoding the Number of the Tunnel Max SI: A 1 octet field. Maximum Set Identifier (section 1 of
range. It MUST be greater than 0. [RFC8279]) used in the encapsulation for this BIER sub-domain.
<Extended Tunnel ID, Reserved, Tunnel Range Base, P2MP ID>: A ID as <Extended Tunnel ID, Reserved, Tunnel Range Base, P2MP ID>: A ID as
carried in the RSVP-TE P2MP LSP SESSION Object defined in [RFC4875]. carried in the RSVP-TE P2MP LSP SESSION Object defined in [RFC4875].
The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel
Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1). Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1).
A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID
implicited by the P2MP. implicited by the P2MP.
The size of the Tunnel Range is determined by the number of Set The size of the Tunnel Range is determined by the number of Set
Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that are Identifiers (SI) (section 1 of [RFC8279]) that are used in the
used in the topology of the P2MP-LSP. Each SI maps to a single topology of the P2MP-LSP. Each SI maps to a single Tunnel in the
Tunnel in the Tunnel Range. The first Tunnel is for SI=0, the second Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for
Tunnel is for SI=1, etc. SI=1, etc.
When the Tunnel Type is set to mLDP P2MP LSP based BIER, the Tunnel When the Tunnel Type is set to mLDP built P2MP BIER, the Tunnel
Identifier include two parts, as follows: Identifier include two parts, as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSL | Tunnel Number | Must Be Zero | |BS Len | Max SI | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type(0x06)| Address Family | Address Length| |P2MP Type(0x06)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~ ~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length(0x0007) | OV Type(0x01) |OV Len(High 8b)| | Opaque Length(0x0007) | OV Type(0x01) |OV Len(High 8b)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Low 8b)(0x04)| Tunnel Range Base(High 24b) | | (Low 8b)(0x04)| Tunnel Range Base(High 24b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Low 8b) | | (Low 8b) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: PTA of MLDP P2MP LSP based BIER Figure 2: PTA of MLDP built P2MP BIER
BSL: A 4 bits field. The values allowed in this field are specified BS Len: A 4 bits field. The values allowed in this field are
in section 2 of [I-D.ietf-bier-mpls-encapsulation]. specified in section 2 of [RFC8296].
Tunnel Number: A 1 octet field encoding the Number of the Tunnel Max SI: A 1 octet field. Maximum Set Identifier (section 1 of
range. It MUST be greater than 0. [RFC8279]) used in the encapsulation for this BIER sub-domain.
<Type=0x06, AF, AL, RootNodeAddr, Opqeue Length=0x0007, OV Type=0x01, <Type=0x06, AF, AL, RootNodeAddr, Opqeue Length=0x0007, OV Type=0x01,
OV Len=0x04, Tunnel Range Base>: A P2MP Forwarding Equivalence Class OV Len=0x04, Tunnel Range Base>: A P2MP Forwarding Equivalence Class
(FEC) Element, with a Generic LSP Identifier TLV as the opaque value (FEC) Element, with a Generic LSP Identifier TLV as the opaque value
element, defined in [RFC6388]. element, defined in [RFC6388].
The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel The "Tunnel Range" is the set of P2MP LSPs beginning with the Tunnel
Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1). Range base and ending with ((Tunnel Range base)+(Tunnel Number)- 1).
A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID A unique Tunnel Range is allocated for the BSL and a Sub-domain-ID
implicited by the P2MP. implicited by the P2MP.
The size of the Tunnel Range is determined by the number of Set The size of the Tunnel Range is determined by the number of Set
Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that are Identifiers (SI) (section 1 of [RFC8279]) that are used in the
used in the topology of the P2MP-LSP. Each SI maps to a single topology of the P2MP-LSP. Each SI maps to a single Tunnel in the
Tunnel in the Tunnel Range. The first Tunnel is for SI=0, the second Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for
Tunnel is for SI=1, etc. SI=1, etc.
When the Tunnel Type is any of the above two, The "MPLS label" field When the Tunnel Type is set to PIM-SSM built P2MP BIER, the Tunnel
Identifier include two parts, as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|BS Len | Max SI | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P-Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P-Multicast Group Base ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PTA of PIMSSM built P2MP BIER
BS Len: A 4 bits field. The values allowed in this field are
specified in section 2 of [RFC8296].
Max SI: A 1 octet field. Maximum Set Identifier (section 1 of
[RFC8279]) used in the encapsulation for this BIER sub-domain.
<P-Root Node Address, P-Multicast Group Base>: A ID to build a PIM-
SSM tree when build the P2MP BIER information for a specified SI.
Use a consecutive number of Groups from P-Multicast Group Base,
multiple PIM-SSM trees will be built for multiple SIs, and multiple
P2MP BIER information will be built accordingly.
When the Tunnel Type is any of the above, The "MPLS label" field
OPTIONAL contain an upstream-assigned non-zero MPLS label. It is OPTIONAL contain an upstream-assigned non-zero MPLS label. It is
assigned by the router (a BFIR) that constructs the PTA. Absence of assigned by the router (a BFIR) that constructs the PTA. Absence of
an MPLS Label is indicated by setting the MPLS Label field to zero. an MPLS Label is indicated by setting the MPLS Label field to zero.
When the Tunnel Type is any of the above two, two of the flags, LIR When the Tunnel Type is any of the above, two of the flags, LIR and
and LIR-pF, in the PTA "Flags" field are meaningful. Details about LIR-pF, in the PTA "Flags" field are meaningful. Details about the
the use of these flags can be found in [RFC6513], use of these flags can be found in [RFC6513],
[I-D.ietf-bess-mvpn-expl-track] and [I-D.ietf-bier-mvpn]]. [I-D.ietf-bess-mvpn-expl-track] and [I-D.ietf-bier-mvpn]].
3.3. Use of the PTA in Leaf A-D routes 4.2.2. Use of the PTA in Leaf A-D routes
Before an egress PE can receive a (C-S,C-G) flow from a given ingress Before an egress PE can receive a (C-S,C-G) flow from a given ingress
PE via RSVP-TE/MLDP P2MP LSP based BIER, the egress PE must have PE via RSVP-TE/MLDP P2MP LSP based BIER, the egress PE must have
received one of the following x-PMSI A-D routes from the ingress PE: received one of the following x-PMSI A-D routes from the ingress PE:
o A "more specific" x-PMSI A-D route, (C-S,C-G) S-PMSI A-D route. o A "more specific" x-PMSI A-D route, (C-S,C-G) S-PMSI A-D route.
o A "less specific" x-PMSI A-D route, (C-*,C-*), (C-*,C-G), or o A "less specific" x-PMSI A-D route, (C-*,C-*), (C-*,C-G), or
(C-S,C-*) S-PMSI A-D route. (C-S,C-*) S-PMSI A-D route.
skipping to change at page 7, line 31 skipping to change at page 10, line 44
the Originating Router's IP Addr field of the NLRI of the Leaf the Originating Router's IP Addr field of the NLRI of the Leaf
A-D route. A-D route.
When an ingress PE receives such a Leaf A-D route, it learns the BFR- When an ingress PE receives such a Leaf A-D route, it learns the BFR-
Prefix of the egress PE from the PTA. The ingress PE does not make Prefix of the egress PE from the PTA. The ingress PE does not make
any use the value of the PTA's MPLS label field. any use the value of the PTA's MPLS label field.
Failure to properly construct the PTA cannot always be detected by Failure to properly construct the PTA cannot always be detected by
the protocol, and will cause improper delivery of the data packets. the protocol, and will cause improper delivery of the data packets.
4. P2MP LSP based BIER Forwarding Procedures 4.3. Building P2MP based BIER forwarding state
When P2MP based BIER are used, then it is not nessary to use IGP or
BGP to build the BIER routing table and forwarding table. Instead,
the BIER layer information is carried by MLDP or RSVP-TE or PIM, when
they building the P2MP tree or PIM tree.
The detail procedure for building P2MP based BIER forwarding state
using mLDP, RSVP-TE or PIM is outside the scope of this document.
4.4. Inheriting and Developing of Live-Live protection
Multicast has its special service protection requirement, especially
when multicast service is compressed or uncompressed video.
Accordingly, there are some multicast-specific methods of protection,
such as Live-Live. [RFC7431] defines a method of detecting failure
locally by comparing the packets received from live-live paths, but
it depends on a APP level encapsulation, which may not always be
satisfied in any deploment. Furthermore, it is inconsequential and
inefficient to do such a deep detecting in a data-plane forwarding
procedure. [I-D.ietf-bess-mvpn-fast-failover] also defines a Live-
Live method for protecting Multicast in MVPN, in which a method of
determining the status of a tunnel using "(S,G) counter information"
is defined, but it does not describe how to get such a (S,G) counter.
This document specifies one OPTIONAL extension to enhance Live-Live
protection, re-using the Entropy field of BIER header as a Sequence
number of multicast packet, on the condition that the field is not
used for ECMP, such as in the P2MP LSP topology. Currently ECMP is
not used for P2MP LSP, as per [RFC6790].
This is an optional function of BIER Layer. If this function is
enabled, every BFR of the domain is required to support, which means:
1. The BFIR (and Ingress LSR) will push a sequence-number in the
Entropy field, per-flow per-packet.
2. The middle BFR will ignore the Entropy field, and not do the
selection of multi-tables.
3. The BFER (and Egress LSR) will do packet check from live-live
paths, and do forward packet with zero packet loss, on a per-flow
basis.
5. P2MP based BIER Forwarding Procedures
The MVPN application plays the role of the "multicast flow overlay" The MVPN application plays the role of the "multicast flow overlay"
as described in [I-D.ietf-bier-architecture]. as described in [RFC8279].
This section specifies some OPTIONAL rules for forwarding a BIER- This section specifies some OPTIONAL rules for forwarding a BIER-
encapsulated data packet within a P2MP topology underlay. encapsulated data packet within a P2MP topology underlay. It is part
of the "BIER Layer" function, which is mentioned as an alternative
deployment of BIER on some sort of multicast-specific tree, but not
detailedly explorered in [RFC8279].
These rules will produce the same results as the procedures in [I- These OPTIONAL rules are some sort of customization and
D.ietf-bier-architecture], on condition that the underlay topology is simplification to the common BIER forwarding procedures, and will
a P2MP. produce the same results as the procedures in [RFC8279], on condition
that the underlay topology is a P2MP.
4.1. Overview These OPTIONAL rules will lead to some new methods to deploy when
some nodes do not support BIER forwarding. These new methods and its
effects will be introduced as well.
As [I-D.ietf-bier-architecture] describes: 5.1. Overview
As [RFC8279] describes:
1. BIER support using the default topology of the unicast IGP as the 1. BIER support using the default topology of the unicast IGP as the
routing underlay. To quote from [I-D.ietf-bier-architecture]: routing underlay. To quote from [RFC8279]: "By default, each
"By default, each sub-domain uses the default topology of the sub-domain uses the default topology of the unicast IGP as the
unicast IGP as the routing underlay." routing underlay."
2. BIER also support using other topologies as the routing underlay, 2. BIER also support using other topologies as the routing underlay,
including a tree topology. To quote from [I-D.ietf-bier- including a tree topology. To quote from [RFC8279]:
architecture]: "Alternatively, one could deploy a routing "Alternatively, one could deploy a routing underlay that creates
underlay that creates a multicast-specific tree of some sort. a multicast-specific tree of some sort. Then BIER could be used
Then BIER could be used to forward multicast data packets along to forward multicast data packets along the multicast-specific
the multicast-specific tree, while unicast packets follow the tree, while unicast packets follow the 'ordinary' OSPF best
'ordinary' OSPF best path." path."
This document specifies one OPTIONAL Forwarding Procedure of BIER This document specifies one OPTIONAL Forwarding Procedure of BIER
encapsulation packet, on the condition that the BIER underlay encapsulation packet, on the condition that the BIER underlay
topology is P2MP LSP, as describes in the above sections. Comparing topology is P2MP LSP, as describes in the above sections. It is in
to the Forwarding Procedure, which is described in [I-D.ietf-bier- fact a customized forwarding procedure, and a detail exploration of
architecture], and which is on a underlay of unicast IGP topology, BIER forwarding along a multicast-specific tree. Comparing to the
there is some simplification: common Forwarding Procedure described in [RFC8279], there is some
considerable simplification:
1. Not need to Edit the BitString when forwarding packet to 1. Not need to Edit the BitString when forwarding packet to
Neighbor, for the underlay P2MP topology is already loop-free. Neighbor, for the underlay P2MP topology is already loop-free and
duplicate-free. This can further lead to a method to by-pass the
BIER encapsulation packet when a node does not support the
BitString process.
2. Not need to use Entropy in the BIER Header, for current P2MP 2. Not need to do a disposition function by parsing the BitString,
topology is already ECMP-eliminate. for a P2MP can identify a disposition function by a node's Label
when the P2MP is built. This can further reduce the complex
BitString processing for legacy hardware on edge, and lead to a
method to deploy on exist network when an edge node does not
support BitString process.
The optional BIER forwarding procedure is, on the basis of P2MP 3. Not need to use Entropy in the BIER Header, for current P2MP
forwarding procedure according to the BIER-MPLS label, and use the topology is ECMP-excluding as per [RFC6790]. This can make it
BitString to prune the undesired P2MP downstream. possible to re-use the field for other function, and lead to a
method of inheriting and developing of the Live-Live protection,
as described in charter 4.
The main principle of the optional forwarding procedure of the P2MP
based BIER is, on the basis of P2MP forwarding procedure according to
the BIER-MPLS label, to use the BitString to prune the undesired P2MP
downstream. This is an enhancement to the standard P2MP forwarding.
The enhancement to the P2MP forwarding is to add a Forwarding BitMask The enhancement to the P2MP forwarding is to add a Forwarding BitMask
to existing NHLFE defined in [RFC3031], for checking with the to existing NHLFE defined in [RFC3031], for checking with the
BitString in a packet, to determin whether the packet is to be BitString in a packet, to determin whether the packet is to be
forwarded or pruned. If the checking result by AND'ing a packet's forwarded or pruned. If the checking result by AND'ing a packet's
BitString with the F-BM of the NHLFE (i.e., Packet->BitString &= BitString with the F-BM of the NHLFE (i.e., Packet->BitString &=
F-BM) is non-zero, then forward the packet to the next-hop indicated F-BM) is non-zero, then forward the packet to the next-hop indicated
by the NHLFE entry, and the Label is switched to the proper one in by the NHLFE entry, and the Label is switched to the proper one in
the NHLFE. If the result is zero, then do not forward the packet to the NHLFE. If the result is zero, then do not forward the packet to
the next-hop indicated by the NHLFE entry. the next-hop indicated by the NHLFE entry.
4.2. Building P2MP LSP based BIER forwarding state 5.2. P2MP based BIER forwarding customization
When RSVP-TE/MLDP P2MP LSP based BIER are used, then it is not For a P2MP tree, every node has a role of Root, Branch, Leaf, or Bud,
nessary to use IGP or BGP to build the BIER routing table and as specified in [RFC4611].
forwarding table. Instead, the BIER layer information is carried by
MLDP or RSVP-TE, and when MLDP or RSVP-TE build P2MP LSP, it build
the BIER forwarding state in-band.
The procedure for building RSVP-TE/MLDP P2MP LSP based BIER EXAMPLE 1: Take the following figure as an example.
forwarding state using mLDP or RSVP-TE is outside the scope of this
document.
4.3. Live-Live protection ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
(Root) \ \ 1 (0:0001)
\ \
( E ) ( F )
3 (0:0100) 2 (0:0010)
As described above, loop and redundancy, ECMP and Entropy, are all Figure 4: P2MP-based BIER Topology without BUD nodes
not supported in current P2MP LSP underlay. There will be extra P2MP
LSP convergence, after IGP convergence, in the case of link or node
failure.
On the other hand, Multicast has special Service Level Forwarding Table on A:
Aggrement(SLA), especially when multicast service is compressed or
uncompressed video. Accordingly, there are some multicast-specific
methods of protection, such as Live-Live. [RFC7431] defines a method
of detecting failure locally by comparing the packets received from
live-live paths. [I-D.ietf-bess-mvpn-fast-failover] defines a Live-
Live method for protecting Multicast in MVPN.
This document specifies one OPTIONAL extension to enhance Live-Live NHLFE(TreeID, OutInterface<toB>, OutLabel<alloc by B>, F-BM<0111>)
protection, re-using the Entropy field of BIER header as a Sequence
number of multicast packet, on the condition that the field is not
used for ECMP, such as in the P2MP LSP topology described above.
This is an optional function of BIER Layer. If this function is Forwarding Table on C:
enabled, every BFR of the domain is required to support, which means:
1. The BFIR (and Ingress LSR) will push a sequence-number in the ILM (inLabel<alloc by C>, action<Replication to TreeID>,
Entropy field, per-flow per-packet. Flag=Branch|CheckBS, BSL)
2. The middle BFR will ignore the Entropy field, and not do the NHLFE(TreeID, OutInterface<toD>, OutLabel<alloc by D>, F-BM<0001>)
selection of multi-tables.
3. The BFER (and Egress LSR) will do packet check from live-live NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>, F-BM<0010>)
paths, and do forward packet with zero packet loss, on a per-flow
basis.
5. Provisioning Considerations For Node C, the ability to receive a MPLS-encapsulation BIER packet,
match ILM and get a TreeID, replicate to NHLFE Entries of the TreeID
according to the result of AND'ing the BitString of packet and the
F-BM of a NHLFE Entry, is called a P-CAPABILITY, which means to
Process BitString in each packet.
P2MP LSP based BIER use concepts of both RSVP-TE/MLDP and BIER. Some Forwarding Table on B is the same to C.
Forwarding Table on D:
ILM (inLabel<alloc by D>, action<Replication to TreeID>,
Flag=Leaf|CheckBS, BSL)
LEAF(TreeID, F-BM<0001>, flag=PopBIERincluding)
When Node D receive a MPLS-encapsulation BIER packet, it get the
Label and match ILM, then do a replication according to the LEAF and
check whether to proceed by AND'ing the BitString in the replicated
packet and the F-BM in the LEAF entry. When the AND'ing result is
non-zero then do a POP to the packet to disposit the whole BIER
header Including the BIER Label, which has a length of (12+BSL/8)
octets.
Node D need to have a P-CAPABILITY, for it need to Process BitString
in each packet to determin whether to replicate to a special LEAF,
and then disposit the whole BIER hearder Including the BIER Label and
forward the IP multicast packet further. Node D also need to do the
disposition as well, which is called a D-CAPABILITY. D-CAPABILITY
means to disposit the BIER header including or excluding the BIER
Label in the begining. Here PopBIERincluding means pop the BIER
header including the BIER Label, while PopBIERexcluding means pop the
BIER header excluding the BIER Label.
Forwarding Tables on E and F are same to D.
Comparing to the forwarding procedure defined in [RFC8279], there are
two benefits of using the customized P2MP based BIER forwarding:
1. Not need to walk every physical neighbor, but only need to walk
downstream neighbors on a P2MP tree.
2. Not need to edit the BitString in every packet, but only need to
swap the BIER Label.
EXAMPLE 2: Another example with P2MP BUD Nodes.
( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
(Root) \ 1 (0:0001)
\
( E ) ------------ ( F )
3 (0:0100) 2 (0:0010)
Figure 5: P2MP-based BIER Topology with BUD nodes
Forwarding Table on B (Branch Node):
ILM (inLabel<alloc by B>, action<Replication to TreeID>,
Flag=Branch|CheckBS, BSL)
NHLFE(TreeID, OutInterface<toE>, OutLabel<alloc by E>, F-BM<0110>)
NHLFE(TreeID, OutInterface<toC>, OutLabel<alloc by C>, F-BM<0001>)
Node B, which is a Branch Node, only need to use its P-CAPABILITY.
Forwarding Table on E (BUD Node):
ILM (inLabel<alloc by E>, action<Replication to TreeID>,
Flag=Bud|CheckBS, BSL)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>, F-BM<0010>)
LEAF(TreeID, F-BM<0100>, flag=PopBIERincluding)
When Node E receive a MPLS-encapsulation BIER packet, it get the
Label and match ILM, then do a replication according to the NHLFEs
and check whether to proceed by AND'ing the BitString in the
replicated packet and the F-BM in the NHLFE/LEAF entry. When the
AND'ing result is non-zero for the second LEAF then do a POP to the
packet to disposit the whole BIER header, which has a length of
(12+BSL/8) octets.
Node E, which is a BUD Node, has both the two capacities:
P-CAPABILITY and D-CAPABILITY. P-CAPABILITY is need to be used for
every NHLFE/LEAF, and D-CAPABILITY is need for the NHLFE that has a
PopBIERincluding flag.
5.3. When Mid, Leaf or Bud nodes do not support P-CAPABILITY
The procedures of Section 5.2 presuppose that, within a given BIER
domain, all the nodes adjacent to a given BFR in a given routing
underlay are also BFRs. However, it is possible to use BIER even
when this is not the case. In this section, we describe procedures
that can be used if the routing underlay is a P2MP tree with BIER
information in the domain.
For a P2MP tree, every node has a role of Root, Branch, Leaf, or Bud.
The role is determined when the tree is built. The method is
suitable for conditions when Mid, Leaf or Bud nodes do not support
P-CAPABILITY.
EXAMPLE 1: Take Figure 4 as an example.
If D, F, E support BIER, and C don't support BIER, then we can
configure on C to indicate it to use P2MP for BIER packets
forwarding. Then C build a P2MP forwarding entry, while still pass
the BIER information in control-plane. For example, D send a P2MP
FEC Mapping message to C with a BitMask 0001, F send a P2MP FEC
Mapping message to C with a BitMask 0010, and C send a P2MP FEC
Mapping message to B with a BitMask, but C build a P2MP forward entry
like this:
ILM (inLabel<alloc by C>, action<Replication to TreeID>,
Flag=Branch)
NHLFE(TreeID, OutInterface<toD>, OutLabel<alloc by D>)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>)
If D don't support BIER P-CAPABILITY, but it support BIER
D-CAPABILITY, then the above method is still valid.
Forwarding Table on D when D don't have a P-CAPABILITY:
ILM (inLabel<alloc by D>, action<Replication to TreeID>,
Flag=Leaf, BSL)
NHLFE(TreeID, flag=PopBIERincluding)
When Node D receive a MPLS-encapsulation BIER packet, it get the
Label and match ILM, then do a replication according to the NHLFE but
don't do the check by AND'ing the BitString in the replicated packet
and the F-BM in the NHLFE entry. And then do a POP to the packet to
disposit the whole BIER header, which has a length of (12+BSL/8)
octets.
Another alternative form of Forwarding Table on D can also be the
following when D don't have a P-CAPABILITY:
ILM (inLabel<alloc by D>, action<PopBIERincluding>, Flag=Leaf,
BSL)
When Node D receive a MPLS-encapsulation BIER packet, it get the
Label and match ILM, then do a POP action according to the ILM to pop
the whole (12+BSL/8) octets from the Label position.
EXAMPLE 2: Take BUD Node E in Figure 5 as another example.
Forwarding Table on Bud Node E when E don't have a P-CAPABILITY:
Forwarding Table on E when E don't have a P-CAPABILITY:
ILM (inLabel<alloc by E>, action<Replication to TreeID>, Flag=Bud,
BSL)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>)
LEAF(TreeID, flag=PopBIERincluding)
One can see that, this method can support widely Non-BIER Nodes in a
network, no matter the node has a Mid, Leaf or Bud role, and would
never result in any ingress-replication through unicast tunnel, which
may cause a overload on a link.
One can also see that, [RFC8279] only support Non BIER-capability
nodes being the Mid nodes, and never allow a BFER nodes to be Non
BIER-capability.
5.4. When Leaf or Bud nodes do not support D-CAPABILITY
A more tolerant variant of the above, when Leaf or Bud nodes do not
support D-CAPABILITY, would be the following:
EXAMPLE 1: Take Figure 4 as an example.
If D even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP
the whole BIER Header except the first four octets Label field of a
packet before it come to D. This requires C to build a forwarding
table like this:
Forwarding Table on C (Branch Node):
ILM (inLabel<alloc by E>, action<Replication to TreeID>,
Flag=Branch|CheckBS, BSL)
NHLFE(TreeID, OutInterface<toD>, OutLabel<alloc by D>, F-BM<0001>,
Flag=PopBIERexcluding)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>, F-BM<0010>)
The Flag PopBIERexcluding means POP the BIER Header excluding the
first 4 octets BIER Label in a packet, that is a Length of (8+BSL/8)
If D don't support BIER P-CAPABILITY or D-CAPABILITY, and C don't
support BIER P-CAPABILITY, then it requires B to build a forwarding
table, to ensure the BIER Header except the first four octets Label
field of a packet is popped before replicated to C, and requires C to
build a forwarding table of a pure P2MP branch, and requires F to
build a forwarding table of a pure P2MP Leaf. Their forwarding
tables are like below:
Forwarding Table on B (Branch Node):
ILM (inLabel<alloc by B>, action<Replication to TreeID>,
Flag=Branch|CheckBS, BSL)
NHLFE(TreeID, OutInterface<toC>, OutLabel<alloc by C>, F-MB<0011>,
Flag=PopBIERexcluding)
NHLFE(TreeID, OutInterface<toE>, OutLabel<alloc by E>, F-BM<0100>)
Forwarding Table on C (Branch Node):
ILM (inLabel<alloc by C>, action<Replication to TreeID>,
Flag=Branch)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>)
Forwarding Table on D (Branch Node):
ILM (inLabel<alloc by D>, action<PopLabel>, Flag=Leaf)
Here PopLabel mean to pop the Label, which is in fact a P2MP LSP
Label. It is a basic capability of any LSR.
Forwarding Table on F (Branch Node):
ILM (inLabel<alloc by F>, action<PopLabel>, Flag=Leaf)
Here PopLabel mean to pop the Label, which is in fact a P2MP LSP
Label. It is a basic capability of any LSR, and the Forwarding table
on F is in fact a P2MP one.
Note that, alrough F support BIER, which means it can deal with a
BIER packet, but it must downshift its forwarding table to a pure
P2MP one, because the packet it received doesn't include a BIER
Header but a P2MP Label packet due to the POP behaving of its
upstream node.
EXAMPLE 2: Take Figure 5 as another example.
If E even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP
the whole BIER Header Except the first four octets Label field of a
packet before it come to D. This requires B to build a forwarding
table like this:
Forwarding Table on B (Branch Node):
ILM (inLabel<alloc by B>, action<Replication to TreeID>,
Flag=Branch|CheckBS, BSL)
NHLFE(TreeID, OutInterface<toC>, OutLabel<alloc by C>, F-MB<0011>)
NHLFE(TreeID, OutInterface<toE>, OutLabel<alloc by E>, F-BM<0100>,
Flag=PopBIERexcluding)
Forwarding Table on E (Bud Node):
ILM (inLabel<alloc by E>, action<Replication to TreeID>, Flag=Bud)
NHLFE(TreeID, OutInterface<toF>, OutLabel<alloc by F>)
LEAF(TreeID, flag=PopLabel)
Forwarding Table on F (Branch Node):
ILM (inLabel<alloc by F>, action<PopLabel>, Flag=Leaf)
Note that, alrough F support BIER, which means it can deal with a
BIER packet, but it must downshift its forwarding table to a pure
P2MP Leaf, because the packet it received doesn't include a BIER
Header but a P2MP Label packet due to the POP behaving of its
upstream node.
One can see that, when some Leaf or Bud nodes even don't have a
D-CAPABILITY, we can do a POP action to dispositing the BIER header
excluding the BIER Label in the begining before the packet arrive the
node. This is similar to a Penultimate Hop Popping in a P2P LSP, and
we call it Upstream Hop Popping in P2MP based BIER.
6. Provisioning Considerations
P2MP based BIER use concepts of both P2MP and BIER. Some
provisioning considerations list below: provisioning considerations list below:
Sub-domain: Sub-domain:
In P2MP LSP based BIER, every P2MP LSP is a specific BIER underlay In P2MP based BIER, every P2MP is a specific BIER underlay topology,
topology, and an implicit Sub-domain. RSVP-TE/MLDP build the BIER and an implicit Sub-domain. RSVP-TE/MLDP/PIM build the BIER
information of the implicit sub-domain when build P2MP LSP. MVPN get information of the implicit sub-domain when building the P2MP LSP or
the implicit sub-domain when specified with which RSVP-TE/MLDP P2MP PIM tree. MVPN get the implicit sub-domain by provisioning.
LSP.
In the following conditions, there may be requirements to configure In the following conditions, there may be requirements to configure
an explicit sub-domain ID for P2MP LSP based BIER: an explicit sub-domain ID for P2MP based BIER:
1. P2MP LSP based BIER, use the native procedure of forwarding 1. P2MP LSP based BIER, use the native procedure of forwarding
described in [I-D.ietf-bier-architecture], which require described in [RFC8279], which require Consistent Per-Sub-domain
Consistent Per-Sub-domain BIFT. BIFT.
2. P2MP LSP based BIER is shared by multiple VPNs, and an explicit 2. P2MP LSP based BIER is shared by multiple VPNs, and an explicit
sub-domain ID is configured as anchor for using by these VPNs. sub-domain ID is configured as anchor for using by these VPNs.
When explicitly configing a sub-domain ID for P2MP LSP based BIER, When explicitly configing a sub-domain ID for P2MP LSP based BIER,
the ID should be great than 255. For the [0-255] has been defined to the ID should be great than 255. For the [0-255] has been defined to
use by IGP, BGP and MVPN, as specified in use by IGP, BGP and MVPN, as specified in
[I-D.ietf-bier-ospf-bier-extensions], [I-D.ietf-bier-ospf-bier-extensions],
[I-D.ietf-bier-isis-extensions], [I-D.ietf-bier-idr-extensions] and [I-D.ietf-bier-isis-extensions], [I-D.ietf-bier-idr-extensions] and
[I-D.ietf-bier-mvpn]. [I-D.ietf-bier-mvpn].
skipping to change at page 10, line 42 skipping to change at page 21, line 11
every Egress Nodes. every Egress Nodes.
BSL and BIER-MPLS Label Block Size: BSL and BIER-MPLS Label Block Size:
In P2MP LSP based BIER, Every P2MP LSP or implicit sub-domain In P2MP LSP based BIER, Every P2MP LSP or implicit sub-domain
requires a single BSL, and a specific BIER-MPLS Label block size for requires a single BSL, and a specific BIER-MPLS Label block size for
this BSL. this BSL.
VPN-Label: VPN-Label:
In P2MP LSP based BIER, a P2MP LSP based BIER 'P-tunnel' can be The P2MP based BIER 'P-tunnel' can be shared by multiple VPNs or a
shared by multiple VPNs or a single VPN. When a P2MP LSP based BIER single VPN. When a P2MP based BIER being shared by multiple VPNs, an
being shared by multiple VPNs, an Upstream-assigned VPN-Label is Upstream-assigned VPN-Label is required. It can be auto-provisioned
required. It can be auto-provisioned or manual configured by the or manual configured by the BFIR or Ingress LSR.
BFIR or Ingress LSR.
6. IANA Considerations In fact, [RFC6513] has defined the method of "Aggregating Multiple
MVPNs on a Single P-Tunnel". But unfortunately it is not widely
deployed because of the serious trade-off between state saving and
bandwidth waste. The BIER encapsulation and forwarding method give
it a chance to eliminate the trade-off while gaining a completely
state saving.
Even when such an aggregating is not used, it is still adequate to
use BIER to save state by sharing one P2MP based BIER "p-tunnel" for
multi flows in one specific VPN.
For seamless transitioning from legacy MVPN deployment and existing
network, it is recommended not to use such an aggregating, as well as
to use such an aggregating.
7. IANA Considerations
Allocation is expected from IANA for two new tunnel type codepoints Allocation is expected from IANA for two new tunnel type codepoints
for "RSVP-TE P2MP LSP based BIER" and "MLDP P2MP LSP based BIER" from for "RSVP-TE built P2MP based BIER", "MLDP built P2MP based BIER" and
the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" "PIM built P2MP based BIER" from the "P-Multicast Service Interface
registry. Tunnel (PMSI Tunnel) Tunnel Types" registry.
7. Security Considerations 8. Security Considerations
This document does not introduce any new security considerations This document does not introduce any new security considerations
other than already discussed in [I-D.ietf-bier-architecture]. other than already discussed in [RFC8279].
8. Acknowledgements 9. Acknowledgements
TBD TBD
9. References 10. References
10.1. Normative References
9.1. Normative References
[I-D.ietf-bess-mvpn-expl-track] [I-D.ietf-bess-mvpn-expl-track]
Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
"Explicit Tracking with Wild Card Routes in Multicast "Explicit Tracking with Wild Card Routes in Multicast
VPN", draft-ietf-bess-mvpn-expl-track-03 (work in VPN", draft-ietf-bess-mvpn-expl-track-08 (work in
progress), September 2017. progress), February 2018.
[I-D.ietf-bess-mvpn-fast-failover] [I-D.ietf-bess-mvpn-fast-failover]
Morin, T. and R. Kebler, "Multicast VPN fast upstream Morin, T. and R. Kebler, "Multicast VPN fast upstream
failover", draft-ietf-bess-mvpn-fast-failover-02 (work in failover", draft-ietf-bess-mvpn-fast-failover-02 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-08 (work in
progress), September 2017.
[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-03 (work in progress), August 2017. idr-extensions-05 (work in progress), March 2018.
[I-D.ietf-bier-isis-extensions] [I-D.ietf-bier-isis-extensions]
Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang,
"BIER support via ISIS", draft-ietf-bier-isis- "BIER support via ISIS", draft-ietf-bier-isis-
extensions-06 (work in progress), October 2017. extensions-09 (work in progress), February 2018.
[I-D.ietf-bier-mpls-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J.,
Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Explicit Replication in MPLS and non-MPLS Networks",
draft-ietf-bier-mpls-encapsulation-11 (work in progress),
October 2017.
[I-D.ietf-bier-mvpn] [I-D.ietf-bier-mvpn]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- Przygienda, "Multicast VPN Using BIER", draft-ietf-bier-
mvpn-08 (work in progress), October 2017. mvpn-10 (work in progress), February 2018.
[I-D.ietf-bier-ospf-bier-extensions] [I-D.ietf-bier-ospf-bier-extensions]
Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions
for BIER", draft-ietf-bier-ospf-bier-extensions-09 (work for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work
in progress), October 2017. in progress), February 2018.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
skipping to change at page 13, line 10 skipping to change at page 23, line 25
[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>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431, Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015, DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>. <https://www.rfc-editor.org/info/rfc7431>.
9.2. Informative References [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
10.2. Informative References
[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>.
Author's Address Authors' Addresses
Jingrong Xie Jingrong Xie
Huawei Huawei
Q15 Huawei Campus, No.156 Beiqing Rd. Q15 Huawei Campus, No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: xiejingrong@huawei.com Email: xiejingrong@huawei.com
Mike McBride
Huawei Technologies
Email: mmcbride7@gmail.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
Liang Geng
China Mobile
Beijing 100053
China
Email: gengliang@chinamobile.com
 End of changes. 80 change blocks. 
208 lines changed or deleted 712 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/