idnits 2.17.1 draft-xie-mpls-rsvp-bier-extension-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([I-D.xie-bier-mvpn-mpls-p2mp]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2018) is 2061 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-bier-mvpn' is defined on line 499, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4461 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Chen 5 Expires: March 9, 2019 R. Li 6 Huawei 7 September 5, 2018 9 RSVP-TE Extensions for P2MP-based BIER 10 draft-xie-mpls-rsvp-bier-extension-01 12 Abstract 14 Bit Index Explicit Replication (BIER) is a new architecture that 15 provides optimal multicast forwarding without requiring intermediate 16 routers to maintain any per-flow state by using a multicast-specific 17 BIER header. This document describes extensions to Resource 18 Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up 19 of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched 20 Paths (LSPs) with BIER infomation, which is called P2MP based BIER in 21 [I-D.xie-bier-mvpn-mpls-p2mp]. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 9, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Example of signaling the P2MP-BIER . . . . . . . . . . . 3 67 3.2. PATH Message . . . . . . . . . . . . . . . . . . . . . . 4 68 3.3. RESV Message . . . . . . . . . . . . . . . . . . . . . . 5 69 3.4. SESSION Object . . . . . . . . . . . . . . . . . . . . . 7 70 3.4.1. P2MP BIER Tunnel IPv4 SESSION Object . . . . . . . . 7 71 3.4.2. P2MP BIER Tunnel IPv6 SESSION Object . . . . . . . . 8 72 3.5. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . 8 73 3.5.1. P2MP BIER Tunnel IPv4 SENDER_TEMPLATE Object . . . . 9 74 3.5.2. P2MP BIER Tunnel IPv6 SENDER_TEMPLATE Object . . . . 9 75 3.6. S2L_BIER_SUB_LSP Object . . . . . . . . . . . . . . . . . 10 76 3.6.1. S2L_BIER_SUB_LSP IPv4 Object . . . . . . . . . . . . 10 77 3.6.2. S2L_BIER_SUB_LSP IPv6 Object . . . . . . . . . . . . 11 78 3.7. FILTER_SPEC Object . . . . . . . . . . . . . . . . . . . 11 79 3.7.1. P2MP BIER_IPv4 FILTER_SPEC Object . . . . . . . . . . 11 80 3.7.2. P2MP BIER_IPv6 FILTER_SPEC Object . . . . . . . . . . 11 81 4. Capability and Error Handling . . . . . . . . . . . . . . . . 11 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 8.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Bit Index Explicit Replication (BIER) is a new architecture that 93 provides optimal multicast forwarding without requiring intermediate 94 routers to maintain any per-flow state by using a multicast-specific 95 BIER header. [RFC4875] defines extensions to the RSVP-TE protocol 96 ([RFC3209] and [RFC3473] ) to support P2MP TE LSPs satisfying the set 97 of requirements described in [RFC4461] . 99 This document extends RSVP-TE to establish P2MP TE LSPs with BIER 100 information, which is called P2MP based BIER in 101 [I-D.xie-bier-mvpn-mpls-p2mp]. 103 2. Terminology 105 Readers of this document are assumed to be familiar with the 106 terminology and concepts of the documents listed as Normative 107 References. For convenience, some of the more frequently used terms 108 and new terms list below. 110 o LSP: Label Switch Path 112 o LSR: Label Switching Router 114 o BFR: BIER Forwarding Router 116 o BFR-ID: BIER Forwarding Router IDentify. 118 o P2MP: Point to Multi-point 120 o P2MP based BIER: BIER using P2MP as topology 122 3. RSVP Extensions 124 RSVP Extensions to setup a P2MP-based BIER is very similar to the 125 setup of a P2MP LSP described in [RFC4875]. Most of the structure 126 and description are borrowed from RFC4875, and a precursive example 127 is put in the beginning to give a whole picture of building the 128 forwarding state of P2MP based BIER. 130 3.1. Example of signaling the P2MP-BIER 132 Consider LSRs A - F, interconnected as follows: 134 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 135 (Root) \ \ 1 (0:0001) 136 \ \ 137 ( E ) ( F ) 138 3 (0:0100) 2 (0:0010) 140 Figure 1: P2MP-based BIER Topology 142 Say that the node D has a BFR-id 1, F has a BFR-id 2, and E has a 143 BFR-id 3, and we use a Bit String Length 4. 145 Consider an P2MP SESSION, for 146 which A is the Root, and say that D,E,F are all the Leafs of this 147 P2MP SESSION. 149 There are 3 Sub-LSPs: A-->B-->E, A-->B-->C-->D, A-->B-->C-->F. 151 PATH message: When PATH message walk through A-->B-->E, it include an 152 session attribute that identify ths session is to establish a P2MP- 153 based BIER LSP. The same to A-->B-->C-->D and A-->B-->C-->F. 155 RESV message: When RESV message work throuth A<--B<--E, it include an 156 Object that identify BFR-ID of E. The same to A<--B<--C<--D and 157 A<--B<--C<--F. 159 Procedure: B learns that it's downstream endpoint has a BFR-ID<3> 160 after a RSVP message passes through A<--B<--E. B also learns a BFR- 161 ID<1> after a RSVP message passes throuth A<--B<--C<--D, and a BFR- 162 ID<2> after a RSVP message passes through A<--B<--C<--D. 164 3.2. PATH Message 166 This section describes modifications made to the Path message format 167 as specified in [RFC4875]. The Path message is enhanced to signal 168 one or more S2L sub-LSPs with BIER information. This is done by 169 including the S2L BIER sub-LSP descriptor list in the Path message as 170 shown below. 172 ::= [ ] 173 [ [ | ] ...] 174 [ ] 175 176 177 [ ] 178 179 [ ] 180 [ ... ] 181 [ ] 182 [ ] 183 [ ] 184 [ ... ] 185 186 [] 187 ::= 188 [ ] 189 ::= 190 [ ] 192 Figure 2: PATH Message 194 3.3. RESV Message 196 The Resv message follows the [RFC4875] format: 198 ::= [ ] 199 [ [ | ] ... ] 200 [ ] 201 202 203 [ ] [ ] 204 [ ] 205 [ ] 206 [ ... ] 207