Internet DRAFT - draft-dhs-spring-pce-sr-p2mp-policy
draft-dhs-spring-pce-sr-p2mp-policy
Network Working group H. Bidgoli, Ed.
Internet Draft Nokia
Intended status: Standard Track D. Yoyer, Ed.
Bell Canada
S. Rajarathinam
J. Kotalwar
Nokia
S. Sivabalan
Cisco System, Inc.
Expires: September 12, 2019 March 11, 2019
PCEP extensions for p2mp sr policy
draft-dhs-spring-pce-sr-p2mp-policy-00
Abstract
SR P2MP policies are set of policies that enable architecture for
P2MP service delivery.
This document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) that allow a stateful PCE to compute
and initiate P2MP paths from a Root to a set of Leaves.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." The list
of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Bidgoli, et al. Expires September 12, 2019 [Page 1]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
This Internet-Draft will expire on October 8, 2017.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Overview of PCEP Operation in SR P2MP Network . . . . . . . . . 3
3.1. P2MP Identification . . . . . . . . . . . . . . . . . . . . 4
3.2 High-Level Procedures for P2MP SR LSP Instantiation . . . . 4
3.2.1. New Objects for SR P2MP LSP instantiation . . . . . . . 5
3.3. High-Level Procedures for P2MP Global Optimization . . . . 5
3.4. High-Level Procedures for Fast Reroute . . . . . . . . . . 6
4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Open Message and Capability Exchange . . . . . . . . . . . 7
4.2. Symbolic Name in PCInitiate message from PCC . . . . . . . 7
4.3. PCE Update, Root Report message . . . . . . . . . . . . . . 8
4.3.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . . . 8
4.3.2 END-POINTS Objects . . . . . . . . . . . . . . . . . . . 9
4.4. PCInitiate Message and P2MP Tree Instantiation . . . . . . 12
4.4.1. New SR-P2MP-CCI Object . . . . . . . . . . . . . . . . 13
4.4.2. New Optional IPv4-ADDRESS TLV . . . . . . . . . . . . . 13
4.4.3. UNNUMBERED IPV4-ID-ADDRESS TLV: . . . . . . . . . . . . 15
4.4.4. New Optional IPv6-ADDRESS TLV . . . . . . . . . . . . . 15
4.5. Global Optimization and Make Before Break . . . . . . . . . 15
4.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 16
5. Example workflow . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
Bidgoli, et al. Expires September 12, 2019 [Page 2]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The draft draft-voyer-spring-sr-p2mp-policy defines a variant of the
SR Policy [I-D. ietf-spring-segment-routing-policy] for constructing
a P2MP segment to support multicast service delivery. We call it an
SR Replication Policy.
A Point-to-Multipoint (P2MP) segment connects a Root node to a set of
Leaf nodes in a Segment Routing Domain. We define two types of a P2MP
segment: Spray and Tree.
Spray P2MP segment enables a Root node to directly replicate a packet
using a SR path to each Leaf node.
For a TreeSID P2MP segment, a controller computes a tree from a Root
node to a set of Leaf nodes via a set of Replication nodes. A packet
is replicated at the Root node and on Replication nodes towards each
Leaf node.
For a TreeSID the tree can be built manually via the PCE or PCC by
indicating the root and the leaves or dynamically via MVPN
procedures, where the root of a tree discovers the leafs via MVPN
procedures and updates the PCE of the root and the set of leaves. In
either case the PCE computes and programs the P2MP Tree on the PCCs.
In all of above cases a set of new PCEP object and TLVs are needed to
update and instantiate the P2MP tree. This draft explains the
procedure needed to instantiate a P2MP TreeSID.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Overview of PCEP Operation in SR P2MP Network
For a Tree P2MP SR policy, TreeSID network, a PCE calculates a P2MP
tree and programs the Root, Replication and Leaf nodes with
information needed to forward a multicast stream from the root to a
set of leaves. The PCE discovers the Root and the set of the Leaves
via manual configuration on the PCE or PCC providing the PCE with the
relevant information. The PCC can discover the Root and the leaves
via MVPN procedures or via manual configuration.
Bidgoli, et al. Expires September 12, 2019 [Page 3]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
After discovering the Root and Leaves and computing the MPLS P2MP
Tree and identifying the Replication routers, the PCE programs the
PCCs with relevant information needed to create a P2MP Tree from the
Root to the set of the Leaves. This information specifies label
operation on the relevant nodes. As an example for a label Push
operation, outgoing interface and their corresponding labels are
programmed on the PCC via the PCE. In the case of swap operation, an
incoming label and a set of outgoing interfaces and their
corresponding labels are programmed on the PCCs. In the Case of pop
operation, incoming label that needs to be removed is programmed. PCE
could also calculate and download additional information such as
next-hops for link/node protection or initiate a make-before-brake
for P2MP Path optimization.
3.1. P2MP Identification
The key to identify a P2MP LSP is in LSP object and is as follow:
PLSP-ID: RFC 8231, is assigned by PCC and is unique per LSP that is
constant for the lifetime of a PCEP session. When an LSP is being
globally optimized it will maintain its PLSP-ID over the 2 instances
of the LSP, the current LSP and the new optimized LSP. It is possible
to establish standby P2MP LSPs to protect primary P2MP SR policies,
and standby P2MP LSPs can be co-exist along with primary P2MP LSP.
Since PLSP-ID is unique per LSP, each standby P2MP LSP has a unique
PLSP-ID.
LSP-ID: is assigned by PCE for each PLSP-ID. It is used for global
optimization of an existing LSP via Make-Before-Break (MBB)
procedures. An optimized P2MP LSP is instantiated with the same PLSP-
ID but a unique LSP-ID. MBB procedures first switches traffic from
the previous to the new P2MP LSP, and then destroys the previous P2MP
LSP.
P2MP-ID: is equivalent to Path Identifier which identifies a unique
P2MP segment at a ROOT and is advertised via the PTA in the BGP AD
route.
IPv4/IPv6 Sender Address: is equivalent to the first MPLS node on the
path, as per [RFC3209], Section 4.6.2.1
3.2 High-Level Procedures for P2MP SR LSP Instantiation
A P2MP LSP's ROOT and Leaves can be discovered via MVPN procedures or
static configuration of the ROOT and Leaves on the PCE or PCC.
In case of MVPN Procedures, PCC will use Report messages to update
Bidgoli, et al. Expires September 12, 2019 [Page 4]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
the PCE with discovered leaf or a set of leaves as per P2MP [draft-
sr-mvpn-procedure or alike]. PCC will assign a PLSP-ID and use the
P2MP-ID it had specified in the BGP MVPN PTA. PCC will update the PCE
with the root and discovered leaves via a PCRpt message. Note the
LSP-ID will be set to 0 or NA in this first report message as the PCE
has not instantiated the P2MP LSP yet.
PCE will instantiate the P2MP LSP and update PCC (root, transit and
leaves) via a PCInit message. The PCInit message will contain a valid
LSP-ID assigned by PCE for this P2MP path. It will also download the
corresponding label and local protection (Fast Re-Route) information.
In short, each P2MP LSP will have a unique PLSP-ID assigned by PCC
and LSP-ID assigned by PCE. This is true for LSP redundancy where the
Primary LSP is protected by one or multiple backup LSPs. The backup
LSPs will have a unique PLSP-ID and LSP-ID. PCE will use the same
PLSP-ID and LSP-ID for any new leaves that are discovered from here
on. If these leaves are discovered on routers that are part of the
P2MP LSP path, then PCUpd is sent from PCE to necessary PCCs (root,
transit and leaves) with the PLSP-ID and LSP-ID. If the new leaves
are discovered that are not part of the P2MP Tree yet, then an PCInit
message is sent down to the relevant transit and/or leaf nodes with
the current PLSP-ID and LSP-ID.
3.2.1. New Objects for SR P2MP LSP instantiation
A new object <SR-P2MP-CCI> is defined for the controller to specify
the forwarding instructions (label instructions). This can be
included in PcRpt, PcInitiate and PcUpd messages.
It should be noted that every PcRpt, PcInitiate and PCUpd messages
will contain full list of the Leaves and labels and forwarding
information that is needed to build the P2MP LSP. They will never
send the delta information related to the new leaves that need to be
added or updated. This is necessary to ensure that PCE or any new
discovered PCE is in sync with the PCC.
As such when a PcReport, PcInitiate and PCUPdate messages is send via
PCEP it maintains the previous instruction CC-IDs and create new CC-
ID for the new instruction. This means the CC-IDs are maintained for
each specific forwarding and label instructions until these
instructions are deleted.
3.3. High-Level Procedures for P2MP Global Optimization
When a P2MP LSP needs to be optimized for any reason (i.e. it is
taking a FRR Path or new routers are added to the network) a global
optimization is possible. After the optimized LSP is downloaded a MBB
Bidgoli, et al. Expires September 12, 2019 [Page 5]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
procedure is performed and the previous instance of the LSP is
deleted and removed from the corresponding PCCs. The globally
optimized LSP is instantiated via the PCInitiate message. The PLSP-ID
of this optimized LSP is same as the Current LSP which is being
optimized. That said the LSP-ID of the optimize LSP is uniquely
assigned by PCE and is different from that of thecurrent LSP which is
being optimized. In short, the LSP-ID uniquely identifies sub-
instances of an LSP for optimization. After the optimized LSP has
been downloaded and verified via PCC PCRpt message, the MBB procedure
can be performed to switch between the 2 instances of the LSP. The
previous instance will be removed from PCCs.
3.4. High-Level Procedures for Fast Reroute
Currently this draft identifies the Facility FRR procedures. In
addition, only LINK Protection procedures are defined. How the
Facility Path is built and instantiated is beyond the scope of this
document.
R
| |
T
|
---
| |
L1 L2
Figure 1
R---F1
| |
T---F2
|
---
| |
L1 L2
Figure 2
As an example, the bypass path (unicast bypass) between the PLR and
MP can be constructed via SR. The PCE needs to only update the PLR
PCC with bypass path outgoing label and nexthop information, also PCE
needs to update the MP PCC with bypass path ILM information. This
information is presented via a P bit in the optional IPv4/IPv6-
Address object as per section 4.4.2, 4.4.3, 4.4.4.
If one to one FRR is needed, then a second flag O should be defined
Bidgoli, et al. Expires September 12, 2019 [Page 6]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
in the IPv4/IPv6-Address object in future.
As an example, in figure 1 the detour path between R and T is the 2nd
fiber between these nodes. As such the bypass path could be setup on
the 2nd fiber using treeSID procedures. That said in figure 2 the
bypass path is traversing multiple nodes and this example a unicast
SR path might be ideal for setting up the detour path. The PCE can
download the prefix SID for F2 as a bypass path for R-T to R.
Downloading the prefix SID for F2 will ensure an LFA detour for R-T.
In addition, PHP procedure and implicit null label on the bypass path
can be implemented to reduce the PCE programming on the MP PCC.
4. Object Format
4.1. Open Message and Capability Exchange
Format of the open object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the nodes need to establish a PCEP connection with the PCE.
During PCEP session establishment phase, PCEP Speakers advertise
their capabilities to support PCECC extensions to include the new
Path Setup Type as per draft-ietf-pce-pcep-extension-for-pce-
controller-00. In addition they need to set flags N, M, P in the
STATEFUL-PCE-CAPABILITY TLV as defined in draft-ietf-pce-stateful-
pce-p2mp-08 section-5.2.
We extend the PCEP OPEN object by defining an optional TLV to
indicate the PCE's capability to perform SR-P2MP path computations,
New IANA capability type. The inclusion of this TLV in an OPEN object
indicates that the sender can perform SR-P2MP path computations. This
will be similar to the P2MP-CAPABILITY defined in rfc8306 section-
3.1.2 and a new value needs to be defined for SR-P2MP.
4.2. Symbolic Name in PCInitiate message from PCC
As per RFC8231 section 7.3.2. a Symbolic Path Name TLV should
uniquely identify the P2MP path on the PCC. This symbolic path name
is a human-readable string that identifies an P2MP LSP in the
Bidgoli, et al. Expires September 12, 2019 [Page 7]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
network. It needs to be constant through the life time of the P2MP
path.
As an example in the case of P2MP LSP the symbolic name can be the
source IP + P2MP-ID of the LSP. The P2MP-ID is a unique ID that
identifies the P2MP on the Root (Source) as such the combination of
Source IP + P2MP-ID will provide the P2MP LSP with a unique
identification throughout the network. Depending on the Source IP,
IPv4 vs. IPv6, the length of the TLV will vary.
4.3. PCE Update, Root Report message
The Root node on reception of a P2MP path request, via MVPN
procedures or manual Configuration on the PCCs, will initiates an
Report to PCE through a PCRpt message.
The format of the PC Report message is as follows:
<Common Header>
[<SRP>]
<LSP>
[<end-points-list> | <SR-P2MP-CCI>]
4.3.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV
The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies
the PLSP-ID to uniquely identify an LSP that is constant for the life
time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID
identify a P2MP TE LSP uniquely.
The LSP Object MUST include the new SR-P2MP-LSPID-TLV (IPV4/IpV6).
This is a variation to the P2MP object defined in draft-ietf-pce-
stateful-pce-p2mp-08
SR-IPV4-P2MP-LSP-IDENTIFIER TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID(color) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bidgoli, et al. Expires September 12, 2019 [Page 8]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
SR-IPV6-P2MP-LSP-IDENTIFIER TLV :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID(color) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type (16-bit) of the TLV is TBD (need allocation by IANA).
LDS ID: is a unique ID assigned by PCE to indicate sub-instances of
an P2MP LSP for global or local optimization
IPv4/IPv6 Sender address: contains the sender node's IP address (Root
Node)
P2MP ID (Color): contains the 32-bit 'P2MP ID' identifier used in the
PTA of BGP AD Route.
4.3.2 END-POINTS Objects
In order for the Root to indicate the leaves and its corresponding
operation (Add/Remove/Modify/DoNotModify), the PC Report message is
extended to include P2MP End Point <P2MP End-points> Object which is
defined in rfc8306
IPV4-P2MP END-POINTS:
Bidgoli, et al. Expires September 12, 2019 [Page 9]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPV6-P2MP END-POINTS:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leaf Types (derived from RFC 8306 section 3.3.2) :
1.New leaves to add (leaf type = 1)
2.Old leaves to remove (leaf type = 2)
3.Old leaves whose path can be modified/reoptimized (leaf type
= 3), Future reserved not used for tree SID as of now.
4.Old leaves whose path must be left unchanged (leaf type = 4)
A given P2MP END-POINTS object gathers the leaves of a given type.
Bidgoli, et al. Expires September 12, 2019 [Page 10]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
Note that a P2MP report can mix the different types of leaves by
including several P2MP END-POINTS objects. The END-POINTS object body
has a variable length. These are multiples of 4 bytes for IPv4,
multiples of 16 bytes, plus 4 bytes, for IPv6.
A sample Report message of a P2MP tunnel request, and leaf Add
report is noted below:
Note as it was mentioned before:
P2MP-ID (color) = Tunnel Identifier color which identifies a
unique P2MP segment at the Root and is advertised via the PTA
(BGP)
LSP ID is used for Global optimization of the P2MP Tree.
contains the 16-bit 'LSP ID' identifier
P2MP Tunnel Request, Report generated by the Root to the PCE. The
Root should populate the Tunnel-sender Addr, P2MP-ID(color), PLSP-ID.
While the LSP ID is set to 0 for the PCE to assign.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 28 (PathSetupType)| TLV Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PST = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID = X | A:1,D:1,N:1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID = 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address = x.y.z.w |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP_ID(color) = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report generated by the Root to the PCE for Leaf Add
Bidgoli, et al. Expires September 12, 2019 [Page 11]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 28 (PathSetupType)| TLV Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PST = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID = X | A:1,D:1,N:1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID = 0 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address = x.y.z.w |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP_ID(color) = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address = x.y.z.w |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address = a.b.c.d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address = a.b.c.e |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4. PCInitiate Message and P2MP Tree Instantiation
In response to a new leaf add PCRpt message, the PCE calculates the
path and assigns labels along the path and sets up the path by
sending a PCInitiate Message(label download) to each node along the
path (Root, transits nodes and leaves). A new object <SR-P2MP-CCI> is
defined for the controller to specify the forwarding instructions
(label instructions). This can be included in PCRpt, PcInitiate and
PcUpdate messages.
For optimization it is recommended for the PCE to send the PCInitiate
message starting from the LEAVES to the Transit nodes and finally the
Root.
The transit and leaf nodes generate a Path Computation State Report
(PCRpt) with SR-P2MP-LSP-ID TLV and SR-P2MP-CCI object to indicate
the state of the label download. Once the controller gets a report
from all the leaves and transit nodes that the label download was
Bidgoli, et al. Expires September 12, 2019 [Page 12]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
successful, it will send a PCInit Message with the SR-P2MP-CCI
object(label instruction) to the Root node.
A successful report (including SR-P2MP-CCI object and P2MP LSP ID
TLV) back from the root for the label download, means the P2MP policy
is successfully UP. The PLSP-ID used in the PCInitiate message is the
original identifier used by the ingress PCC, so the transit LSR could
have multiple central controller instructions that have the same
PLSP-ID. The PLSP-ID in combination with the SR-P2MP-LSP-ID-TLV MUST
be unique.
Format of PC Initiate Message:
<Common Header>
<SRP>
<LSP>
<SR-P2MP-CCI>
Format of Pc Update Message: is like PC Initiate Message, but the
Create Bit in the LSP Object will be Set to 0.
4.4.1. New SR-P2MP-CCI Object
This is a variation of the CC-ID object defined in draft-ietf-pce-
pcep-extension-for-pce-controller-00 SR-P2MP-CCI Object-Class is TBD.
CCI Object-Type is 1 for the MPLS Label.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC-ID: A PCEP-specific identifier for the CCI information. A PCE
creates an CC-ID for each instruction, the value is unique within
the scope of the PCE and is constant for the lifetime of a PCEP
session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be
used.
Flags: O - 0 - Down - means label download was not successful 1 -
Up - means label download was successful
4.4.2. New Optional IPv4-ADDRESS TLV
Bidgoli, et al. Expires September 12, 2019 [Page 13]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
The IP-Address TLVs download the label and its instructions to the
PCC. These instructions could include information about local
Protection information or if the label is an incoming label or an
outgoing label. Additionally they could identify a node as a BUD node
or just a transit node.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Rsvd | Flag|I|B|S|E|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags:
I - Incoming Label: If set means In Label, If not set means
Out Label.
B - Bud Node Label: If set this label is a bud node, the
payload needs to be processed locally and also replicated if
the S bit is set. In short if B is set then S needs to set
also.
S - SWAP label:
0: If I bit is set and S bit is 0 it means pop the label
and if the label's S bit is set do a recursive lookup.
1 - If I bit is set and S bit is 1 it means swap this
label with out label.
P - Protection NextHop
0 - Label information is not w.r.t protection next-hop.
1 - Label information is w.r.t protection next-hop.
Note: P flag is used at the PLR and MP to identify the
facility tunnel.
E - Protected LTN, This bit is usually set with the an
outgoing label, when the outgoing label is protected via a
Bidgoli, et al. Expires September 12, 2019 [Page 14]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
protection nextHop
0 - Label information does not have a protection next-
hop.
1 - Label information has a protection next-hop.
IPV4 address and Interface Id: correspond to the next-hop information
in case of an OUT Label, and it corresponds to incoming interface
information if it is an IN Label.
4.4.3. UNNUMBERED IPV4-ID-ADDRESS TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Rsvd | Flag|I|B|S|E|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.4. New Optional IPv6-ADDRESS TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Rsvd | Flag|I|B|S|E|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv6 address (16 bytes) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5. Global Optimization and Make Before Break
If controller optimizes a tree for any reason, it will download the
tree with same PLSP-ID and P2MP-ID (Color) but a new LSP-ID .
Bidgoli, et al. Expires September 12, 2019 [Page 15]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
The new optimize LSP is downloaded via the same mechanisms explained
above and a new LSP-ID for this instance of the LSP.
After the new tree is established and the report messages arrive from
the source, transit and leaf nodes confirming successful download,
the previous tree is deleted starting from the root. This delete of
the previous LSP-ID will force the root to do a switch (MBB) to the
new LSP-ID P2MP tree.
4.6. Tree Deletion
To delete the entire tree (P2MP LSP) , Root send a PCRpt message with
the R bit of the LSP object set and all the fields of the SR-P2MP-
LSP-ID TLV set to 0(indicating to remove all state associated with
this P2MP tunnel). The controller in response sends a PCInitiate
message with R bit in the SRP object SET to all nodes along the path
to indicate deletion of a label entry.
4.7. Fragmentation
The Fragmentation bit in the LSP object (F bit) can be used to
indicate a fragmented PCEP message.
5. Example workflow
In the workflow below after discovering the root and leaf nodes via
MVPN procedures the root generates a PCRpt message to the PCE with
the discovered root and leaves via the endpoint objects, which in
order forces the PCE to compute the P2MP Tree and generates a
PCInititate to the Root, downloading the label information to the
Root, Bud/Transit and Leaves.
A PC Initiate message on Root,transit and leaf nodes - indicates a
new label instruction and the existing label instruction should
remain unmodified(if any present). If the old instructions are no
longer needed, a PC Update message indicating the old label
instructions and the R bit in the LSP object SET is sent to the
nodes(to remove the labels).
A PCUpd message on any node (root, transit or leaf) - indicates an
overwrite of the existing label instruction if any present.
A sample message flow is depicted below:
When leaves(C,D) are discovered, at R a PCInitiate with 2 label
instruction is instantiated by the PCE. The two labels correspond to
an egress label and a protection nextHop for FRR. The PCE will
download a PCInitiate message with CC-ID X, egress label(A), flag
Bidgoli, et al. Expires September 12, 2019 [Page 16]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
E(as the Protection NextHOP CCID will Follow) and a IPv4 nextHop of
N1, in addition CC-ID Y = egress label (B), flag P(as it is a
protection NextHOP) and IPv4 nextHop of N2, are instantiated by the
PCE.
The Root will use a PCRpt message to acknowledge this initiate.
The PC will also download the necessary information to the
BUD/Transit router. In case of the BUD/Transit router the flags
<I,B,S> are set. This means that for the incoming label the label
should be swapped with an outgoing label, but also the payload should
be replicated and a copy forwarded locally as there is a BUD present
on this router.
The BUD/Transit node will use a PCRpt message to acknowledge this
update as well. The Leafs (not shown) will also get the PCInit
message with Flag of only <I> which indicates a pop and forward
operation.
Bidgoli, et al. Expires September 12, 2019 [Page 17]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
N4--------------------
| |
| +-------+ +-------+ +-------+
| N3--|LEAF C | |LEAF D | | PCE |
| | | | | | +-------+
+------| | | | |
N2---- | | | | |
|N1-- | Bud/ +-------+ +-------+ |
| | | Transit| | | |
+------| B | | | |
|ROOT +--------+ | | |
|A | | | | |
+--------+ | | | |
| | | | |
| MVPN Procedures to discover the ROOT and the LEAVES |
| | | | |
|---PCRpt:SRP-ID=TBD,PLSP-ID=1,S=A,P2MP-ID=A,LSP-ID=NA |
| endpoint=<LT=1,S=A,L=C,B>------------------->|
| | | | |
| | | | |
|<--PCInit:SRP-ID=1,PLSP-ID=1,S=A,P2MP-ID=A,LSP-ID=1 |
| | P2MPCCI:CCID=X,Flag=E,Label=A,IPv4=N1 -----|
| | P2MPCCI:CCID=Y,Flag=P,Label=B,IPv4=N2 |
| | | | |
|---PCRpt:SRP-ID=1,PLSP-ID=1,S=A,P2MP-ID=1,LSP-ID=1 |
| P2MPCCI:CCID=X,Y---------------------------->|
| | | | |
| | | | |
| |<-PCInit:SRP-ID=2,PLSP-ID=1,S=A,P2MP-ID=A |
| | | LSP-ID=1,---------------------- |
| | | P2MPCCI:CCID=X2,FLAG=<I,B,S>,Label=C |
| | | P2MPCCI:CCID=Y2,FLAG=0,Label=D, |
| | | IPv4=N3 |
| | | P2MPCCI:CCID=Z2,FLAG=0,Label=E, |
| | | IPv4=N4 |
| | | | |
| | PCRpt:SRP-ID=2,PLSP-ID=1,S=A,P2MP-ID=A, |
| |------ LSP-ID=1,--------------------------->|
| | | P2MPCCI:CCID=X2,Y2,Z2 |
| | | | |
6. IANA Considerations
This document contains no actions for IANA.
7. Security Considerations
TBD
Bidgoli, et al. Expires September 12, 2019 [Page 18]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
8. References
8.1. Normative References
8.2. Informative References
[sr-p2mp-policy] D. Yoyer, Ed., C. Hassen, K. Gillis, C. Filsfils, R.
Parekh, H.Bidgoli, "SR Replication Policy for P2MP Service Delivery",
draft-voyer-spring-sr-p2mp-policy-01, April 2019.
7. Acknowledgments
The authors would like to thank Tanmoy Kundu at Nokia for his
feedback and major contribution to this draft.
Authors' Addresses
Hooman Bidgoli
Nokia
600 March Rd.
Ottawa, Ontario K2K 2E6
Canada
Email: hooman.bidgoli@nokia.com
Daniel Voyer
Bell Canada
Montreal
CA
Email: daniel.voyer@bell.ca
Siva Sivabalan
Cisco Systems
Ottawa
Canada
Email: msiva@cisco.com
Jayant Kotalwar
Nokia
380 N Bernardo Ave,
Mountain View, CA 94043
US
Email: jayant.kotalwar@nokia.com
Bidgoli, et al. Expires September 12, 2019 [Page 19]
Internet-Draft MLDP Stitching Through BIER Core March 11, 2019
Saranya Rajarathinam
Nokia
380 N Bernardo Ave,
Mountain View, CA 94043
US
Email: saranya.rajarathinam@nokia.com
Bidgoli, et al. Expires September 12, 2019 [Page 20]