PCE for BIER-TE Path

1.1. Terminologies

The following terminologies are used in this document.¶

PCE:

Path Computation Element¶

PCEP:

PCE communication Protocol¶

PCC:

Path Computation Client¶

CE:

Customer Edge¶

PE:

Provider Edge¶

BIER:

Bit Index Explicit Replication.¶

BIER-TE:

BIER Traffic/Tree Engineering.¶

BFR:

Bit-Forwarding Router.¶

BFIR:

Bit-Forwarding Ingress Router.¶

BFER:

Bit-Forwarding Egress Router.¶

BFR-id:

BFR Identifier. It is a number in the range [1,65535].¶

BFR-NBR:

BFR Neighbor.¶

BFR-prefix:

An IP address (either IPv4 or IPv6) of a BFR.¶

BIRT:

Bit Index Routing Table. It is a table that maps from the BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix of that BFER, and to the BFR-NBR on the path to that BFER.¶

BIFT:

Bit Index Forwarding Table.¶

LSP-DB:

Label Switching Path DataBase.¶

TED:

Traffic/Tree Engineering DataBase.¶

2.1. Example BIER-TE Topology with PCE

An example BIER-TE topology for a BIER-TE domain with a PCE is shown in Figure 1. There are 8 nodes/BFRs A, B, C, D, E, F, G and H in the domain. Nodes/BFRs A, H, E, F and D are BFIRs (i.e., ingress nodes) or BFERs (i.e., egress nodes). There is a connection (i.e., PCE session) between the PCE and the PCC running on each of the possible ingress and egress nodes in the domain. Note that some of connections and the PCC on each node are not shown in the figure.¶

                    +------------------------------------+
                    |                 PCE                |
                    +------------------------------------+
                    /        ...                         \
                   /                                      \
                  /                    4'      17'    18'  \
                 /            /-----------( G )----------( H )
                /            /           19'\_______   12'/4
               /            /                _______)____/
              /            /                /      (_____
             /            /3'              /             \
            /   1'   2'  /    5'     6'   /11'  13'    20'\
 (CE) --- ( A )--------( B )------------( C )------------( D )
            5            \7'              \15'       14'   1
                          \                \
                           \8'   9'    10'  \16'
                          ( E )------------( F )
                            3                2

Nodes/BFRs D, F, E, H and A are BFERs (or BFIRs) and have local decap adjacency BitPositions 1, 2, 3, 4, and 5 respectively. For simplicity, these BPs are represented by (SI:BitString), where SI = 0 and BitString is of 8 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0:00000001), 2 (0:00000010), 3 (0:00000100), 4 (0:00001000) and 5 (0:00010000) respectively.¶

The BitPositions for the forward connected adjacencies are represented by i', where i is from 1 to 20. In one option, they are encoded as (n+i), where n is a power of 2 such as 32768. For simplicity, these BitPositions are represented by (SI:BitString), where SI = (6 + (i-1)/8) and BitString is of 8 bits. BitPositions i' (i from 1 to 20) are represented by 1'(6:00000001), 2'(6:00000010), 3'(6:00000100), 4'(6:00001000), 5'(6:00010000), 6'(6:00100000), 7'(6:01000000), 8'(6:10000000), 9'(7:00000001), 10'(7:00000010), . . . , 16'(7:10000000), 17'(8:00000001), 18'(8:00000010), . . . , 20'(8:00001000).¶

For a link between two nodes X and Y, there are two BitPositions for two forward connected adjacencies. These two forward connected adjacency BitPositions are assigned on nodes X and Y respectively. The BitPosition assigned on X is the forward connected adjacency of Y. The BitPosition assigned on Y is the forward connected adjacency of X.¶

For example, for the link between nodes B and C in the figure, two forward connected adjacency BitPositions 5' and 6' are assigned to two ends of the link. BitPosition 5' is assigned on node B to B's end of the link. It is the forward connected adjacency of node C. BitPosition 6' is assigned on node C to C's end of the link. It is the forward connected adjacency of node B.¶

2.2. A Brief Flow of PCEP Messages for a BIER-TE Path

For a BIER-TE Path to transport the packets with a given multicast group/address and source in a BIER-TE domain, a sequence of PCEP messages are exchanged between the PCE for the domain and the PCEs for the domains containing the source, and between the PCE for the domain and the PCCs running on the BFERs/BFIRs of the domain.¶

Suppose that each of nodes H, D and F receives a multicast join with a same multicast group/address and source, which are MGa and MSa respectively. For simplicity, assume that the multicast source MSa is in the left domain containing the CE in Figure 1. The following is a brief flow of PCEP messages for computing and creating a BIER-TE Path to transport the packets to H, D and F.¶

At first, the PCC running on each of nodes H, D and F sends the PCE a PCEP message such as PCRpt. The message contains the multicast group and source (i.e., MGa and MSa), which reports to the PCE that the node receives a multicast join with MGa and MSa. Note that a PCEP message is sent to the PCE from the PCC on a node to report that the node leaves when the node receives a multicast leave with MGa and MSa.¶

After receiving the PCEP messages from nodes H, D and F reporting multicast join with MGa and MSa, the PCE for the domain containing these nodes determines that nodes H, D and F are the egress nodes of a BIER-TE path since they have the same multicast group and source.¶

Second, the PCE for the domain sends a PCEP message such as PCReq to each of the PCEs for the domains that may contain the multicast source. This message requests the PCE (that may contain the source) to find an ingress node for the BIER-TE path having egress nodes H, D and F. The message contains the multicast group and source (i.e., MGa and MSa). For example, the PCE for the BIER-TE domain sends the PCEP message to the PCE (called PCE-L) for the left domain containing CE (note that this PCE is not shown in the figure).¶

After receiving the PCEP message requesting to find an ingress node, the PCE (e.g., PCE-L) for the domain containing the multicast source computes the ingress node that is reachable from the source with minimum cost (e.g., ingress node A). The PCE for the domain without the source can not find any ingress node.¶

Third, the PCE for the domain with the source sends the PCE for the BIER-TE domain a PCEP message such as PCRep with the ingress node. The PCE for the domain without the source sends the PCE for the BIER-TE domain a PCEP message such as PCRep with NO INGRESS FOUND.¶

After receiving the PCEP message with the ingress node, the PCE for the BIER-TE domain computes a P2MP path from the ingress node (e.g., A) to the egress nodes (e.g., H, D and F). The path has the optimal BitPositions and satisfies the constraints. The optimal BitPositions means the BitPositions for the path has the minimum number of bit sets and the minimum bit distance.¶

Fourth, the PCE for the BIER-TE domain sends a PCEP message such as PCInitiate to the PCC on the ingress node (e.g., A) for the ingress to create a BIER-TE path to transport the packets for the given multicast group and source. The message contains the BitPositions for the path, the multicast group and source.¶

After receiving the PCEP message with the path, the PCC on the ingress (e.g., A) creates the BIER-TE path, i.e., a forwarding entry that imports the packets with the multicast group/address and source into the BIER-TE path (i.e., encapsulates the packets with a BIER-TE header having the BitPositions of the path).¶

And then the PCC on the ingress sends the PCE a PCEP message such as PCRpt reporting the status of the path to the PCE.¶

After receiving the PCEP message with the status of the path, the PCE for the domain updates the information about the path accordingly.¶

2.3. Procedures on Ingress

This section introduces the procedures for the ingress node of a P2MP path to get the BitPositions representing the explicit P2MP path from the ingress node to its egress nodes from the PCE.¶

Suppose that node A in Figure 1 wants to have an explicit P2MP path from ingress node A to egress nodes H and F. The path satisfies a set of constraints. In one case, the PCC running on ingress node A sends a request for the path to the PCE. The request contains the set of constraints, objective functions, the ingress node and the egress nodes. After receiving the request, the PCE computes an explicit P2MP path, which satisfies the constraints and is from the given ingress node to the egress nodes. While computing the path, the PCE will optimize the BitPositions of the path. That is that, for a given length of BitString, the path computed uses the minimum number of BitStrings (i.e., bit sets) and satisfies the constraints. The length is given by the value in BitStrLen field in the PCE-BIER-TE-Path-Capability sub-TLV. The PCE sends a reply with the path to the PCC. The reply contains the BitPositions representing the explicit P2MP path.¶

For example, assume that the explicit P2MP path computed by the PCE traverses the link/adjacency from A to B (indicated by BP 2'), the link/adjacency from B to G (indicated by BP 4') and the link/adjacency from B to C (indicated by BP 6'), the link/adjacency from G to H (indicated by BP 18'), and the link/adjacency from C to F (indicated by BP 16'). This path is represented by {2', 4', 6', 16', 18', 2, 4}, where BitPositions 2 and 4 indicate egress nodes F and H respectively. The reply sent to the PCC on node A by the PCE contains the path represented by {2', 4', 6', 16', 18', 2, 4}.¶

In another case, a request for a P2MP path is from a user or application. After receiving the request, the PCE finds an ingress node if no ingress is given, and computes an explicit P2MP path from the ingress node to the egress nodes and sends the path to the PCC running on the ingress node.¶

After receiving the P2MP path, for any packet from CE to be transported by the path, such as the packet with the multicast address, the ingress node encapsulates the packet with the BitPositions representing the path and forwards the packet according to its BIFT.¶

For example, when ingress node A receives the path represented by BitPositions {2', 4', 6', 16', 18', 2, 4}, it encapsulates every packet from CE with the multicast address with the BitPositions and then forwards the packet along the P2MP path according to its BIFT.¶

A forwards the packet to B according to the forwarding entry for BP 2' in its BIFT.¶

After receiving the packet from A, B forwards the packet to G and C according to the forwarding entries for BPs 4' and 6' in B's BIFT respectively. The packet received by G has path {16', 18', 2, 4}. The packet received by C has path {16', 18', 2, 4}.¶

After receiving the packet from B, G sends the packet to H according to the forwarding entry for BP 18' in G's BIFT.¶

After receiving the packet from B, C sends the packet to F according to the forwarding entry for BP 16' in C's BIFT.¶

Egress node H of the P2MP path receives the packet with BitPosition 4. It decapsulates the packet and pass the payload of the packet to the packet's NextProto.¶

Egress node F of the P2MP path receives the packet with BitPosition 2. It decapsulates the packet and pass the payload of the packet to the packet's NextProto.¶

3.1. BIER-TE Path Capability

During a PCEP session establishment, PCEP Speakers (PCE or PCC) indicate their ability to support BIER-TE paths. The OPEN object in the Open message contains the PATH-SETUP-TYPE-CAPABILITY TLV, which is defined in [RFC8408]. The TLV contains a list of Path Setup Types (PSTs) and optional sub-TLVs associated with the PSTs. The sub-TLVs convey the parameters that are associated with the PSTs supported by a PCEP speaker.¶

This document defines a new PST value:¶

* PST = TBD1:

Path is setup using BIER-TE.¶

A new sub-TLV associated with this new PST is defined, which is called PCE-BIER-TE-Path-Capability sub-TLV. The format of this new sub-TLV is illustrated in the figure below.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type = TBD2           |            Length = 4         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Reserved                |  SILen  |   BitStrLen   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type - 16 bits:

TBD2 is to be assigned by IANA.¶

Length - 16 bits:

4 is the total length in bytes of the remainder of the TLV, excluding the Type and Length fields.¶

SILen (SI Length) - 5 bits:

The length in bits of the SI field.¶

BitStrLen (Bit String Length) - 8 bits:

The length in bits of the BitString field according to [RFC8296]. If k is the length of the BitString, the value of BitStrLen is log2(k)-5. For example, BitStrLen = 1 indicates k = 64, BitStrLen = 7 indicates k = 4096.¶

Reserved - 19 bits:

MUST be set to zero by the sender and MUST be ignored by the receiver.¶

A PCEP speaker supporting BIER-TE paths includes the new PST and sub-TLV in the PATH-SETUP-TYPE-CAPABILITY TLV.¶

3.2. Extensions to SRP

For a PCEP message, when it is used for a BIER-TE path, the SRP (Stateful PCE Request Parameters) object in the message MUST include the PATH-SETUP-TYPE TLV defined in [RFC8408]. The TLV MUST contain the PST = TBD1 for path setup using BIER-TE.¶

Three contiguous bits in SRP Object Flag Field are defined to indicate one of the assistant operations for a BIER-TE path. This three bits field is called AOP (Assistant Operations). In addition, the Multicast Flow Specification TLV defined in [I-D.ietf-pce-pcep-flowspec] is re-used in the SRP object for indicating Multicast Traffic.¶

  AOP Value    Meaning (Assistant Operation)
  0x001 (J):  Join with Multicast Group and Source
  0x010 (L):  Leave from Multicast Group and Source
  0x011 (I):  Ingress node computation

3.3. Ingress Node Object

To represent an ingress node, a new ingress node object is defined. The format of the new object for IPv4 (OT = 1) is 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |ObjectClass=TBD|  OT=1 |Res|P|I|      Object Length (bytes)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Ingress Node IPv4 address                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Cost to Ingress Node                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                         Optional TLVs                         ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ObjectClass:

TBD is to be assigned by IANA.¶

OT:

1 for IPv4.¶

Res, P, I and Object Length:

Same as those defined in Common Object Header in [RFC5440].¶

Ingress Node IPv4 address:

Indicates an IPv4 address of an ingress node.¶

Cost to Ingress Node:

Indicates the cost from the multicast source to the ingress node.¶

No optional TLV is defined so far.¶

The format of the new object for IPv6 (OT = 2) is 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |ObjectClass=TBD|  OT=2 |Res|P|I|      Object Length (bytes)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Ingress Node IPv6 address                   |
  |                                                               |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Cost to Ingress Node                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                         Optional TLVs                         ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TBD, Res, P, I, Object Length, and Cost to Ingress Node:

Same as those defined in Ingress Node Object for IPv4.¶

OT:

2 for IPv6.¶

Ingress Node IPv6 address:

Indicates an IPv6 address of an ingress node.¶

No optional TLV is defined so far.¶

3.4. Objective Functions

[RFC5541] defines a mechanism to specify an objective function (OF) that is used by a PCE when it computes a path. For a BIER-TE path, the following new OF is defined.¶

    Objective Function Code: TBD8
    Name: Minimum Bit Sets (MBS)
    Description: Find a path represented by BitPositions that has
                 the minimum number of bit sets.

    Objective Function Code: TBD9
    Name: Minimum Bits (MB)
    Description: Find a path represented by BitPositions that has
                 the minimum bit distance. The bit distance of
                 BitPositions is the distance from the lowest bit
                 to the highest bit in BitPositions.

3.5. BIER-TE Path Subobject

A BIER-TE path is represented by the BitPositions for the adjacencies through which the path traverses. A BitPosition is represented by a SI:BitString or a number.¶

A new subobject, called BIER-TE Path subobject (or BIER-TE-ERO subobject), is defined to contain the information about one or more BitPositions.¶

The format of a BIER-TE Path subobject in a ERO is shown in the figure below.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |L| Type = TBDa |     Length    | sub-domain-id |     MT-ID     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                          BitPositions                         :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L Flag (1 bit):

It indicates whether the subobject represents a loose-hop in the path.¶

Type (7 bits):

It is to be assigned by IANA. It identifies the BIER subobject type.¶

Length (8 bits):

It contains the total length of the subobject in octets. The Length MUST be at least 4.¶

sub-domain-id:

Unique value identifying the BIER sub-domain within the BIER domain.¶

MT-ID:

Multi-Topology ID identifying the topology that is associated with the BIER sub-domain.¶

BitPositions:

It MUST be at least one BitPosition.¶

For the subobject in a message received from a PCEP session, the format of the BitPositions in the subobject is determined by the values of SILen and BitStrLen in the PCE-BIER-TE-Path-Capability sub-TLV exchanged during the establishment of the session. When both SILen and BitStrLen are greater than zero, each of the BitPositions has two parts SI and BitString, where SI occupies SILen bits and BitString occupies BitStrLen bits. When both SILen and BitStrLen are zeros, each of the BitPositions is a number of 16 bits.¶

For example, when SILen = 8 and BitStrLen = 1 (indicating BitString is of 64 bits), each BitPosition has a SI of 8 bits and a BitString of 64 bits. For simplicity, BitString of 8 bits is used below. The BitPositions for a BIER-TE path are sorted in descending order before they are put into a BIER-TE path subobject. For BIER-TE path {2', 4', 6', 16', 18', 2, 4}, when its BitPositions are sorted, it is {18', 16', 6', 4', 2', 4, 2}, which is {18'(8:00000010), 16'(7:10000000), 6'(6:00100000), 4'(6:00001000), 2'(6:00000010), 4 (0:00001000), 2 (0:00000010)}. The BitPositions with the same SI are stored in one BitString. For example, 6'(6:00100000), 4'(6:00001000) and 2'(6:00000010) are stored in (SI:BitString) = (6:00101010), where SI = 6. BIER-TE path {18', 16', 6', 4', 2', 4, 2} is encoded in the BIER-TE path subobject in the figure below. The path uses four BitStrings of 8 bits.¶

  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| Type = TBDa |  Length = 10  |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       8       |0 0 0 0 0 0 1 0|       7       |1 0 0 0 0 0 0 0|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       6       |0 0 1 0 1 0 1 0|       0       |0 0 0 0 1 0 1 0|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.6. BIER-TE Path Subobject in ERO

The ERO defined in [RFC5440] may contain a BIER-TE Path subobject for the BitPositions of a BIER-TE path. The BitPositions in the BIER-TE Path subobject for the BIER-TE path MUST be in descending order. When an ERO contains one or more BIER-TE Path subobjects for a BIER-TE path, the ERO MUST NOT include any other type of subobjects (i.e., it MUST include only BIER-TE Path subobjects). The first one is used and the others are ignored.¶

3.7. BIER-TE Path Subobject in RRO

A BIER-TE Path Subobject in a RRO (Record Route Object) has the same format as a BIER-TE Path subobject in a ERO except for L flag. The former does not have L flag. The format of a BIER-TE Path Subobject in a RRO is shown in the firgure below.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type = TBDa  |     Length    | sub-domain-id |     MT-ID     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         BitPositions                          |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A PCC may send a PCE a message such as a PCRpt message defined in [RFC8231]. The message contains a RRO with one BIER-TE Path subobject having the BitPositions for the actual BIER-TE path that is used to transport the traffic in the BIER-TE domain. The BitPositions in the BIER-TE Path subobject for the BIER-TE path MUST be in descending order.¶

4.1. BIER-TE Path Creation

For PCC-Initiated BIER-TE path, a PCC MUST delegate the path by sending a path computation report (PCRpt) message with its demanded resources to a stateful PCE. Note the PCC MAY use the PCReq/PCRep before delegating.¶

Upon receiving the delegation via PCRpt message, the stateful PCE MUST compute a path based on the network resource availability stored in the TED.¶

The stateful PCE will send a PCUpd message for the BIER-TE path to the PCC. The stateful PCE MUST update its local LSP-DB and TED and would need to synchronize the information with other PCEs in the domain.¶

For PCE-Initiated BIER-TE path, the stateful PCE MUST compute a BIER-TE path per request from network management systems or applications automatically based on the network resource availability in the TED and send a PCInitiate message with the path information to the PCC. After receiving the PCInitiate message, the PCC creates the BIER-TE path.¶

For both PCC-Initiated and PCE-Initiated BIER-TE paths:¶

• The stateful PCE MUST update its local LSP-DB and TED with the paths.¶
• Upon receiving the PCUpd message or PCInitiate message for the path from the PCE with a found path, the PCC determines that it is a BIER-TE path by the PST = TBD1 for path setup using BIER-TE in the PATH-SETUP-TYPE TLV of the SRP object in the message.¶

4.2. BIER-TE Path Update

After a BIER-TE path is created in a BIER-TE domain, when some network events such as a node failure happen on the path (called old path) or a leaf/egress joins/leaves, the PCE computes a new BIER-TE path and replaces the old path with the new path. The new path satisfies the same constraints as the old path.¶

The PCE sends a PCUpd message to the PCC running on the ingress node. The message contains the information about the new BIER-TE path. After receiving the message, the PCC overwrites (or replaces) the BIER-TE path with the new BIER-TE path.¶

4.3. BIER-TE Path Deletion

For a BIER-TE path that has been created in a BIER-TE domain, after receiving a request for deleting the path from a user or application, the PCE MUST send a PCInitiate or PCUpd message to the PCC running on the ingress node of the path to remove the path.¶

9.1. Normative References

[I-D.ietf-bier-te-arch]

Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", Work in Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 July 2021, <https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-10.txt>.

[I-D.ietf-pce-pcep-flowspec]

Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow Specification", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-flowspec-13, 14 October 2021, <https://www.ietf.org/archive/id/draft-ietf-pce-pcep-flowspec-13.txt>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5440]

Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.

[RFC5541]

Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.

[RFC8231]

Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.

[RFC8232]

Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>.

[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>.

[RFC8281]

Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.

[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>.

[RFC8408]

Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, <https://www.rfc-editor.org/info/rfc8408>.

9.2. Informative References

[I-D.chen-pce-bier]

Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and A. Wang, "PCEP Extensions for BIER-TE", Work in Progress, Internet-Draft, draft-chen-pce-bier-09, 12 July 2021, <https://www.ietf.org/archive/id/draft-chen-pce-bier-09.txt>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.