idnits 2.17.1 draft-raza-mpls-ldp-olf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 1, 2012) is 4370 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) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kamran Raza 2 Internet Draft Sami Boutros 3 Intended status: Standards Track Pradosh Mohapatra 4 Expires: October 30, 2012 5 Cisco Systems, Inc. 7 May 1, 2012 9 LDP Outbound Label Bindings Filtering 11 draft-raza-mpls-ldp-olf-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on October 30, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 The Label Distribution Protocol (LDP) allows one Label Switching 54 Router (LSR) to advertise to another a set of "bindings" between 55 MPLS labels and "Forwarding Equivalence Classes" (FECs). Suppose 56 LSR2 is advertising a set of label bindings to LSR1. Frequently, 57 LSR1 does not need to know all of LSR2's label bindings, and LSR1 58 may be configured to disregard bindings in which it has no interest. 59 This document defines an "Outbound Label Bindings Filtering" (OLF) 60 mechanism that allows LSR1 to inform LSR2 dynamically of the set of 61 FECs for which it needs to receive label bindings. LSR2 then 62 applies this filter before sending its label bindings to LSR1. In 63 addition to the generic aspects of this mechanism, this document 64 also specifies the format for the outbound label binding filter for 65 the "Address Prefix FEC" type. 67 Table of Contents 69 1. Introduction 3 70 2. Conventions used in this document 3 71 3. FEC Label Bindings 4 72 4. Outbound Label Filter 4 73 4.1. Constructs 4 74 4.1.1. FEC-Type 4 75 4.1.2. OLF Policy 5 76 4.2. OLF Signaling 6 77 4.2.1. OLF Policy Status TLV 6 78 4.2.2. OLF Element Format 7 79 4.2.3. OLF Entry Format 8 80 Rules for OLF Element and OLF Entry 9 81 4.2.4. 9 82 4.3. OLF Capability negotiation 10 83 4.4. OLF Procedures 12 84 4.4.1. OLF Capability Negotiation At Session Estab. Time 13 85 4.4.2. OLF Capability Dynamic Changes 14 86 4.4.3. OLF Policy Updates 15 87 5. OLF Specification for "Address Prefix FEC" 16 88 5.1. Matching Address Prefixes to OLF Entries 18 89 6. Operational Examples 19 90 6.1. Label Filtering at Area Border Router 19 91 6.2. LSR with limited LIB size 19 92 6.3. Label Filtering an Address Family in an IP Dual-Stack LSR 19 93 7. Security Considerations 20 94 8. IANA Considerations 20 95 9. References 20 96 9.1. Normative References 20 97 9.2. Informative References 21 98 10. Acknowledgments 21 100 1. Introduction 102 The Label Distribution Protocol (LDP) allows one Label Switching 103 Router (LSR) to advertise to another a set of "bindings" between MPLS 104 labels and "Forwarding Equivalence Classes" (FECs). When 105 "Downstream Unsolicited" mode [RFC5036] is in use for a LDP session, 106 an LSR may receive unsolicited label bindings for FECs in which it 107 has no interest. The receiving LSR typically filters out these 108 unwanted label bindings based on its local policy. Since the 109 advertisement of label binding updates by the sender, as well as the 110 processing of these updates by the receiver, consume network 111 bandwidth and LSR resources, it may be beneficial if the 112 advertisement of such label bindings can be avoided at the source 113 itself under the control of the receiver. 115 This document defines a label filtering mechanism that allows an LDP 116 speaker to send to its LDP peer a set of FEC-based Outbound Label 117 Filters (OLFs). The peer would apply these filters, in addition to 118 any local outbound filtering policy, to constrain/filter its outbound 119 label binding updates to the speaker. 121 This document also defines the Outbound Label Bindings Filter, named 122 "Address Prefix FEC Outbound Label Filter", for "Address Prefix" FEC 123 type. This filter, thus, can be used to perform outbound label 124 filtering for IP Prefix label bindings. 126 This specification is modeled on [RFC5291] and [RFC5292]. 128 2. Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC-2119 [RFC2119]. 134 The term "FEC-Type" is used to refer to a tuple consisting of . 137 3. FEC Label Bindings 139 LDP [RFC5036] associates a FEC with each Label Switched Path (LSP) 140 it creates. This means that a label is assigned for one or more 141 FEC(s) and label bindings advertised to peers are bound to FEC(s). 142 To define an LDP OLF, filters need to be defined for label bindings. 143 These filter definitions need to include both FEC Element type, as 144 well as Address Family, if/as applicable, for a given FEC type. 146 Following is a list of most commonly used LDP FEC elements (at the 147 time of writing of this document): 149 LDP FEC Element Type Address Family Specification 150 -------------------- ------------- ------------- 151 Wildcard N/A [RFC5036] 152 Address Prefix IPv4, IPv6 [RFC5036] 153 Typed Wildcard AF of Sub-FEC [RFC5918] 154 P2MP IPv4, IPv6 [RFC6388] 155 MP2MP-Upstream IPv4, IPv6 [RFC6388] 156 MP2MP-Downstream IPv4, IPv6 [RFC6388] 157 PWid N/A [RFC4447] 158 Generalized PWid N/A [RFC4447] 159 P2MP PW Upstream N/A [P2MP-PW] 160 P2P PW Downstream N/A [P2MP-PW] 162 Table 1: LDP FEC Types 164 This document defines a framework for label filtering that applies 165 to all of the FEC types listed under Table 1, except "Wildcard" and 166 "Typed Wildcard" FEC types. The framework is also easily extensible 167 for new FEC types that may get defined in the future. 169 4. Outbound Label Filter 171 4.1. Constructs 173 4.1.1. FEC-Type 175 In the context of this document, we define "FEC-Type" as a construct 176 that uniquely identifies (or maps to) a FEC. This is defined as a 177 tuple of the following form: 179 181 As shown in Table 1, not all FEC elements are qualified with an 182 Address Family. For those types, the address family is not specified 183 (set to a reserved value). 185 Following are some example of FEC-Types: 187
189
191 193 4.1.2. OLF Policy 195 We define an OLF Policy as a set of one or more OLF Elements, each 196 corresponding to a given FEC-Type. Where, an OLF Element itself 197 comprises one or more OLF Entries. 199 4.1.2.1. OLF Element 201 An OLF Element is identified by a FEC-Type and consists of one or 202 more OLF entries that have a common FEC-Type. The FEC-Type component 203 uniquely identifies a FEC and is used to provide a coarse 204 granularity control by limiting an OLF to only those FECs that match 205 the FEC-Type component. 207 To define an OLF Element for a given FEC-Type, precise conditions and 208 rules need to be specified under which the given FEC is considered to 209 match a particular OLF entry. 211 4.1.2.2. OLF Entry 213 An OLF entry is a tuple of the form: 215 217 The "Action" component specifies how the OLF filter is to be handled 218 by the receiving LSR. The specified values for "Action" include 219 "PERMIT", "DENY", and "PERMIT-ALL". PERMIT action indicates to 220 receiving LSR to allow advertisement of label bindings for the set 221 of FECs that match the OLF entry, DENY is opposite of PERMIT and 222 disallows (i.e. filters) the advertisement of label bindings for the 223 set of FECs that match the OLF entry. PERMIT-ALL is the wildcard 224 equivalent of PERMIT, and hence apply to all FECs associated with 225 the FEC-Type of the OLF Element corresponding to OLF entry. 227 The "OLF-value" component is FEC-specific and provides the 228 specification of FEC for matching. This component is not mandatory 229 and is not present when Action component is PERMIT-ALL. The format 230 of the OLF-value for a given FEC element type is to be defined by 231 the designer of the FEC element. This document defines the format of 232 OLF-value for FEC-Types corresponding to "Address Prefix" FEC 233 Element type [RFC5036]. 235 4.2. OLF Signaling 237 4.2.1. OLF Policy Status TLV 239 An OLF is signaled to a peer through an LDP Notification message. A 240 new status TLV, named "OLF Policy Status", is introduced to carry 241 the OLF specifications. This TLV is carried in the optional 242 parameter section of the LDP Notification message. Moreover, a new 243 LDP Status Code, "OLF Status", is defined for use in LDP Status TLV 244 to indicate the presence of "OLF Policy Status" TLV in a given 245 Notification message. 247 A single OLF Policy Status TLV may contain one or more OLF Element 248 sub-TLVs, where each OLF Element TLV represents a single FEC-Type 249 and consists of one or more "OLF Entry" sub-TLVs. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |U|F| OLF Policy Status(IANA) | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |M| Reserved | | 257 +-+-+-+-+-+-+-+-+ | 258 | | 259 ~ OLF Element(s) ~ 260 ~ ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ 263 Figure 1: OLF Policy Status TLV 264 Where: 266 U/F bits: U-bit/F-bit MUST be set to 1/0 respectively so that a 267 receiver MUST silently ignore this TLV if unknown to it, and 268 continue processing the rest of the message. 270 Length: Total length (in octets) of "OLF Policy Status" TLV 271 following the "Length" field. There is no padding requirement at 272 the end of this TLV in case TLV does not end at Word boundary. 274 OLF Element(s): One or more OLF Element sub-TLVs. In a given OLF 275 Policy Status TLV, only one OLF Element for a given FEC-Type is 276 allowed. If more than one OLF Element is present for a given 277 FEC-Type, then receiving LSR MUST pick the first occurrence of 278 such an element and ignore the other occurrences corresponding 279 to the given FEC-Type. 281 M-bit: "More" bit specifying if there are more/further OLF Policy 282 Status to follow for the given update set. The bit is set to 1 283 if there are further portion of policy that will follow in 284 subsequent message(s), and set to 0 if the TLV alone constitutes 285 the policy, or is the last update for the given update set. 287 Reserved bits: Reserved for future use. MUST be set to zero on 288 transmit and ignored on receipt. 290 An LSR MAY update its OLF with a peer by sending OLF Policy Status' 291 TLVs in an LDP Notification message. The receipt of an OLF Policy 292 update from a peer for a given FEC-Type is meant to replace 293 (overwrite) the previously installed FEC-Type OLF policy 294 corresponding to the peer, if any, at the receiving LSR. 296 A complete OLF policy can be splitted across more than one OLF 297 policy updates -- e.g. if the given OLF policy is big enough to fit 298 in a single Notification message (due to LDP PDU size limitation 299 [RFC5036]). In such cases, the sender LSR MAY send more than one LDP 300 Notification message(s) with "OLF Policy Status" TLV, splitting the 301 policy on OLF Element boundaries (i.e. an OLF Element MUST NOT span 302 across more than one message). Using M-bit, the sender also 303 indicates if more than single Policy message will be sent for the 304 given OLF update, as well as indicates the last message in the given 305 update set. Upon receiving OLF updates that span across more than 306 one message, the receiver LSR stores the received policy update(s) 307 in the order of receipt and processes them once complete policy set 308 has been received. If an LSR receives an incomplete/partial update 309 set, and does not receive an end of update (i.e. last message in the 310 given set with M bit be set to 0), it keeps these partial updates in 311 its temporary buffer until one of the following events occur: 313 1. End of [policy] update received (OLF Policy Status TLV with M=0) 314 2. Session terminates 315 3. OLF capability changes 317 4.2.2. OLF Element Format 319 As shown in Figure 2, an OLF Element comprises one or more OLF 320 entries grouped by FEC-Type : 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | FEC-Elem-Type | Address-Family | Length ... | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | ... | | 328 +-+-+-+-+-+-+-+-+ | 329 | | 330 ~ OLF Entries ~ 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ 333 Figure 2: OLF Element format 335 Where: 337 FEC-Elem-Type/Address-Family: These fields jointly represent a 338 FEC-Type. For the FEC element types listed in Table 1 which are 339 not qualified with an Address Family, Address-Family field MUST 340 be set to zero on transmit and MUST be ignored on receipt. 342 Length: Length (in octets) of the OLF Element sub-TLV following 343 the "Length" field; i.e. total length of OLF entries that follow 344 in the given OLF Element sub-TLV. There is no padding 345 requirement at the end of this TLV in case TLV does not end at 346 Word boundary. 348 4.2.3. OLF Entry Format 350 Each OLF Entry is encoded as follows: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Common part | | 356 +-+-+-+-+-+-+-+-+ | 357 ~ Type-specific part ~ 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ 360 Figure 3: OLF Entry format 362 Where: 364 Common part: Common definition that is applicable to all types of 365 OLF entries. 366 Type-specific part: FEC-Type specific (variable) definition; This 367 field corresponds to the "OLF-value" under section 4.1.2.2. 369 The "Common part" is one-octet field defined as following: 371 0 1 2 3 4 5 6 7 372 +-+-+-+-+-+-+-+-+ 373 |Action | Rsvd | 374 +-+-+-+-+-+-+-+-+ 376 Where: 378 Action: Indicates the desired action (operation) to be performed 379 by receiving LSR on received OLF entry, if enclosed value (i.e. 380 FEC) matches. The possible values for Action are 382 0: PERMIT 383 1: DENY 384 2: PERMIT-ALL 385 4-15: Reserved (for future use). 387 Rsvd: Reserved for future use. MUST be set to 0 on transmit and 388 MUST be ignored on the receipt. 390 4.2.4. Rules for OLF Elements and Entries 392 Following rules apply to an OLF Element and OLF Entry: 394 o When the Action component of an OLF entry specifies a wildcard 395 operation (PERMIT-ALL), then the OLF entry MUST consist of only 396 the Common part. 398 o When an OLF Element contains more than one OLF entry, then 399 receiving LSR MUST process the OLF entries in the same order as 400 they are specified inside the OLF element. 402 o When processing a received OLF policy for a given FEC-Type, the 403 receiving LSR MUST assume an implicit "DENY" as the last 404 rule/entry. This assumption means that LSR denies all those FECs 405 [of given FEC-Type] that have not already been matched in any of 406 the specified OLF entries. This also means that the sender LSR 407 needs to construct an OLF Element while keeping in mind an 408 implicit DENY-ALL as the last rule. 410 4.3. OLF Capability negotiation 412 When a session has been negotiated to operate in Downstream 413 Unsolicited mode, LDP speakers exchange all of their label bindings. 414 If it is desired/required to exchange only selected label bindings 415 between peers, the "Outbound Label Filtering Capability" (OLF) is 416 negotiated at session establishment time or at a later time. 418 An LDP speaker advertises the OLF Capability to announce to its peer 419 its capability [and desire] to either send, or receive, or both send 420 and receive the OLF filters. The OLF feature will, however, work 421 only when at least one LSR is able to compute and send the policy, 422 and other is able to receive and process the OLF filters. The OLF 423 Capability can be sent either in an Initialization message 424 (Capability TLV's S-bit MUST be set to 1) or in a Capability message 425 (Capability TLV's S-bit set to 1 or 0 to advertise or withdraw this 426 capability respectively). 428 "Outbound Label Filtering Capability" TLV is a new LDP capability, 429 defined in accordance with LDP Capability definition guidelines 430 [RFC5561]. An LDP speaker that advertises OLF capability MUST 431 support "OLF Policy Status" TLV and "OLF Status" Status Code. 433 The format of "Outbound Label Filtering Capability" TLV is as 434 follows: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |U|F| OLF Capability(IANA) | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |S| Reserved | | 442 +-+-+-+-+-+-+-+-+ | 443 | | 444 ~ OLF Capability Element(s) ~ 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ 448 Figure 5: OLF Capability TLV 450 Where: 452 U/F-bits: The U-bit/F-bit for the TLV MUST be set to 1/0 453 respectively so that a receiver MUST silently ignore this TLV if 454 unknown to it, and continue processing the rest of the message. 456 Length: The length (in octets) of TLV following the "Length" 457 field. The value of this field is variable because it depends on 458 Capability-specific data [RFC5561] that follows in the TLV. 459 There is no padding requirement at the end of this TLV in case 460 TLV does not end at Word boundary. 462 S-bit: The value of S-bit is set to 1 or 0 to advertise or 463 withdraw the capability respectively as specified in [RFC5561]. 465 OLF Capability Element(s): This is the Capability-specific data 466 [RFC5561] that is defined for OLF Capability, and consists of 467 one or more "OLF Capability Element" types (defined below). 469 The format of an "OLF Capability Element" sub-TLV is specified as 470 follows: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | FEC Elem Type | Address Family |T|R| Reserved | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 6: OLF Capability Element 480 Where: 482 FEC Elem Type / Address Family: These fields jointly represent a 483 FEC-Type. For the FEC element types listed in Table 1 which are 484 not qualified with an Address Family, Address-Family field MUST 485 be set to zero on transmit and MUST be ignored on receipt. 487 T-bit: Transmit/Send capability; set to 1 by an LDP speaker that is 488 able/willing to push/send its OLF policy/filters to its peer; 489 set to zero otherwise. 491 R-bit: Receive capability; set to 1 by an LDP speaker that is 492 able/willing to receive OLF policy/filters from its peer; set to 493 zero otherwise. 495 Reserved: Reserved for future use. MUST be set to zero on transmit 496 and MUST be ignored on receipt. 498 An LDP speaker SHOULD NOT send an "OLF Capability Element" with both 499 T/R bits set to zero when advertising the capability. If an LSR 500 receives an OLF Capability Element with both T/R bits set to zero in 501 an Initialization message or in a Capability message (with S-bit set 502 to 1), then the receiving LSR SHOULD ignore the corresponding OLF 503 Capability Element and continue processing the rest of the TLV. The 504 semantics and usage of T/R-bits is elaborated more in the following 505 sections. 507 There MUST be one and only one OLF Capability Element specified for a 508 given FEC-Type in an OLF Capability TLV. Upon receiving more than one 509 OLF Capability Element for a given FEC-Type in the same "OLF 510 Capability TLV", the receiving LSR MUST send an LDP Notification 511 message towards the sender with "Malformed TLV" status code, and 512 abort the processing of entire message. 514 An LSR MAY update/withdraw its OLF capability for a given FEC-Type 515 towards a peer by sending an OLF Capability TLV in a LDP Capability 516 message if both the LSR and peer support "Dynamic Capability 517 Announcement" capability. To update its OLF capability, the S-bit of 518 OLF Capability is set to 1 and OLF Capability Element is encoded 519 accordingly and sent to the peer. The receipt of a new OLF Capability 520 Element corresponding to a FEC-Type MUST be treated as overwrite of 521 any previously advertised capability. To withdraw its OLF capability, 522 the S-bit of OLF Capability is set to 0 and OLF Capability Element is 523 encoded with both T/R bits set to 0. The receipt of a withdrawal of a 524 OLF Capability Element corresponding to a FEC-Type removes any filter 525 installed by the sender on the receiver LSR. 527 4.4. OLF Procedures 529 To describe the OLF procedures in the following subsections, let us 530 consider LDP speaker LSR1 that is capable of sending OLF policy 531 filters (for one or more FEC types), and LSR2 that is capable of 532 receiving (and processing) them. Let us assume that the supported 533 FEC-Types for OLF are IPv4/IPv6 "Address Prefix" OLF types. 534 Henceforth, both LSRs are configured respectively to send/receive 535 OLF filters for "IPv4/IPv6 Address Prefix" OLF types to/from its 536 peer. Let us also assume that the LSR1 is configured with an OLF 537 filtering policy for "IPv4/IPv6 Address Prefix" FEC-Types that needs 538 to be pushed to LSR2. 540 Moreover, assume that both LSR1 and LSR2 support "Dynamic Capability 541 Announcement" capability TLV [RFC5561] and hence are capable of 542 handling dynamic capability changes. 544 4.4.1. OLF Capability Negotiation At Session Establishment Time 546 At the session initialization time, LSR1 constructs an "OLF 547 Capability TLV" with S-bit set to 1. The TLV also contains two OLF 548 Capability Elements corresponding to FEC-Types "IPv4 Address Prefix" 549 (FEC Elem Type=2, Address Family=1) and "IPv6 Address Prefix" (FEC 550 Elem Type=2, Address Family=2). The LSR also sets T-bit/R-bit of 551 these OLF Capability Elements to 1/0 respectively. 553 LSR1 then includes this "OLF Capability" TLV in the LDP 554 Initialization message towards LSR2. 556 LSR2, on the other hand, constructs/sends the "OLF Capability" TLV 557 in the same manner as done by LSR1; the only difference being that 558 LSR2 sets T-bit/R-bit of its OLF Capability Elements to 0/1 559 respectively. 561 Having exchanged/negotiated the "OLF Capability" TLVs successfully 562 at session establishment time, LSR2 treats this as an implicit DENY 563 for all label bindings for given FEC-Types (IPv4/IPv6 Prefix) and 564 blocks any label binding advertisements towards LSR1 corresponding 565 to these FEC-Types. LSR2 now waits for subsequent OLF filters/policy 566 (via LDP Notification messages) from LSR1. LSR1 also understands 567 that LSR2 is capable of receiving the OLF filters and hence it 568 constructs OLF filters using its configured OLF policy for LSR2, and 569 sends these filters to LSR2 via "OLF Policy Status" TLV in an LDP 570 Notification message (Status code set to "OLF Status"). Upon the 571 receipt of such an OLF policy, LSR2 reacts and applies the received 572 outbound policy in addition to any locally configured outbound 573 policy, and advertises towards LSR1 only those label bindings that 574 are "permitted" by the installed OLF policy. 576 Since LSR2 is operating only in "R" (Receive) mode for given OLF 577 with LSR1, LSR1 does not block the advertisements and advertises all 578 its label bindings for given IP Prefix FECs (in accordance with its 579 locally configured outbound policy) towards LSR2. 581 4.4.1.1. Peer Incapable of "Receive" OLF 583 Consider a case where LSR2 is not capable as OLF receiver for given 584 FEC-Types. This means that LSR2 either does not send any "OLF 585 Capability" TLV corresponding to given FEC-Type, or "OLF Capability" 586 TLV for given FEC-Type does not have R-bit set. Having negotiated 587 the "OLF Capability" for given FEC-Types, LSR1 realizes that LSR2 is 588 not capable of receiving OLF filters for given FEC-Type(s), and 589 hence LSR1 does not send any OLF filters (via LDP Notification 590 message). In this case, LSR2 sends label bindings corresponding to 591 given FEC-Type(s) towards LSR1 in unsolicited manner after session 592 establishment, at which point, LSR1 may chose to discard them by 593 applying the filtering policy in inbound direction. 595 4.4.2. OLF Capability Dynamic Changes 597 It is possible that OLF capability is enabled on an LSR after 598 session has already been established with the peer. To signal and 599 negotiate OLF Capability dynamically, both peers MUST support 600 "Dynamic Capability Announcement" TLV [RFC5561]. 602 4.4.2.1. "Send" OLF capability changes 604 Let us consider a case when LSR2 is initially configured to be able 605 to receive the OLF filters for IPv4/IPv6 Prefix FEC-Types, but LSR1 606 is not configured to be able to "send" the same. Now, a user enables 607 and configures LSR1 to send OLF filters for given FECs towards LSR2. 608 This triggers LSR1 to construct an "OLF Capability" TLV in the same 609 manner as described in section 4.4.1. The constructed "OLF 610 Capability" is sent in a Capability message (with S-bit set to 1) 611 towards LSR2. Upon receipt of this Capability message, LSR2 612 withdraws all label bindings from LSR1 corresponding to given FEC- 613 Type(s). Later on, LSR1 sends its OLF filters via "OLF Policy 614 Status" and duly applied by LSR2. 616 Assuming both LSR1 and LSR2 are already engaged in OLF filtering in 617 sender and receiver roles respectively for given FEC-Types. Now 618 consider that LSR1 configuration is changed to remove "send" 619 capability for one FEC type (say IPv4 Prefix) towards LSR2. This 620 triggers LSR1 to construct an "OLF Capability" TLV that includes 621 only one OLF Capability Element corresponding to "IPv4 Prefix" FEC 622 type. The constructed "OLF Capability" is sent in a Capability 623 message (with S-bit set to 0) towards LSR2. Upon receipt of this 624 Capability [withdrawal] message, LSR2 removes any existing OLF 625 filters towards LSR1 corresponding to given FEC-Type "IPv4 Prefix", 626 and re-advertises to LSR1 its entire label bindings database for 627 given FEC-Type. 629 4.4.2.2. "Receive" OLF capability changes 631 Let us consider a case when LSR1 is initially configured to be able 632 to send OLF filters for IPv4/IPv6 Prefix FEC-Types, but LSR2 is not 633 configured to be able to "receive" the same. Now, a user enables and 634 configures LSR2 to be able to receive OLF filters for IPv4/IPv6 635 Prefix FECs from LSR1. This triggers LSR2 to construct an "OLF 636 Capability" TLV in the same manner as described in section 4.4.1. 637 The constructed "OLF Capability" is sent in a Capability message 638 (with S-bit set to 1) towards LSR1. Upon receipt of this Capability 639 message, LSR1 realizes that LSR2 is now capable to receive OLF 640 filters for IPv4/IPv6 Prefix FEC types. As described in earlier 641 section, LSR1 now proceeds by constructing "OLF Policy Status" using 642 its configured filters for LSR2, and sends them in an LDP 643 Notification message towards LSR2. Upon receipt of this message, 644 LSR2 applies the received OLF policy and withdraws any label 645 bindings corresponding to matching FEC (prefixes) that are no more 646 permitted for advertisement. Later on, LSR1 can also update its OLF 647 filters by pushing updates to LSR2 as/when any change in LSR1's OLF 648 policy occurs. 650 Assuming both LSR1 and LSR2 are already engaged in OLF filtering in 651 sender and receiver roles respectively for given FEC-Types. Now 652 consider that LSR2 configuration is changed to remove the "receive" 653 capability for one FEC-Type (say IPv4 Prefix) from LSR1. This 654 triggers LSR2 to construct an "OLF Capability" TLV that includes 655 only one OLF Capability Element corresponding to "IPv4 Prefix" FEC 656 type. The constructed "OLF Capability" is sent in a Capability 657 message (with S-bit set to 0) towards LSR1. Upon receipt of this 658 Capability [withdrawal] message, LSR1 marks LSR2 as IPv4 Prefix FEC 659 OLF "receive" incapable peer and makes sure that no more OLF filter 660 updates (via LDP Notification messages) are sent to LSR2. LSR2, 661 after sending the Capability [withdrawal] message, now deletes any 662 installed OLF filter corresponding to LSR1 for "IPv4 Prefix" FEC, 663 and re advertises its entire label bindings database for "IPv4 664 Prefix" FEC to LSR1. Upon receipt of unwanted label bindings, LSR1 665 may chose to discard them by applying the filtering policy in 666 inbound direction. 668 4.4.3. OLF Policy Updates 670 After successful negotiation of "OLF Capability" for a FEC-Type with 671 the peer as the receiver and self as the sender, an LSR SHOULD now 672 send its OLF policy to its peer via "OLF Policy Status" TLV in an 673 LDP Notification message. The LSR MAY also update its OLF policy 674 towards its peer by sending further updates, if/when its locally 675 configuration/policy changes. 677 Consider LSR1 as sender and LSR2 as receiver of OLF filters for 678 IPv4/IPv6 Prefix FEC types. After successful negotiation of OLF 679 capabilities, LSR1 proceeds by sending its OLF filters towards LSR2 680 via LDP Notification message. LSR1 first constructs Status TLV and 681 sets its status code to "OLF Status", and adds the "OLF Policy 682 Status" TLV in the optional parameter section of the Notification 683 message. The contents of "OLF Policy Status" TLV are constructed as 684 set of OLF filters as defined by local configuration and policy for 685 one or more OLF types. The sender MUST only include those OLF types 686 in this TLV for which it has successfully negotiated the OLF 687 capability with the peer. In our example, LSR1 constructs two OLF 688 Elements for IPv4 and IPv6 Prefix FEC types. Each OLF Element is 689 constructed with one ore more OLF Entries, as defined by or mapped 690 to locally configured OLF policy corresponding to LSR2. LSR1 then 691 sends the constructed "OLF Policy Status" TLV, alongwith Status TLV 692 (with status set to "OLF Status") in a LDP Notification message to 693 LSR2. 695 The receiver LDP speaker LSR2 MUST honor the receipt of this TLV in 696 a Notification message because it had successfully negotiated the 697 capability as the receiver for one or more OLF types. If an LDP 698 speaker receives a "OLF Policy Status" TLV in a Notification message 699 without prior OLF Capability(ies) exchange and negotiation, or if 700 negotiated OLF Capability as sender-only role, it MUST ignore the 701 received "OLF Policy Status" TLV, send a "Unknown TLV" Notification 702 back to the peer, and continue processing rest of the message. 703 Similarly, LSR2 behaves the same way on receipt of this TLV in a 704 Notification message with status code other than "OLF Status", and 705 respond back with "Malformed TLV" Notification. 707 If the receiver LSR2 does not understand or does not support the 708 FEC-Type (FEC Element type and/or Address Family) specified in an 709 "OLF Element", it MUST respond with a LDP Notification with status 710 code set to "Unknown FEC" or "Unsupported Address Family" as 711 applicable, and abort processing of the entire message. 713 If LSR1's configured OLF policy changes, LSR1 sends further updates 714 using "OLF Policy Status" in a LDP Notification message. Upon 715 receipt of such an update for given FEC-Type, LSR2 treats this as an 716 overwrite of the previously installed OLF filters corresponding to 717 LSR1, and re-applies the policy. As the result of policy re- 718 application, LSR2 advertises any new [matching] prefix being 719 permitted now, and withdraws any previously advertised prefixes 720 which are no longer permitted as per matching rules. 722 5. OLF Specification for "Address Prefix FEC" 724 Using the earlier OLF framework defined in this document, this 725 section defines the OLF type for the "Address Prefix" FEC Element 726 type. The OLF types for other FEC Element types are beyond the scope 727 of this document. 729 The "Address Prefix FEC" OLF type allows a user to express OLFs in 730 terms of address prefixes. That is, it provides filtering based on 731 address prefixes, including prefix length or range based matching. 733 To define an OLF for "Address Prefix FEC" type of given address 734 family, the FEC-Elem-Type and Address-Family fields of an OLF 735 Element are defined as follows: 737 FEC-Elem-Type: 2 ("Address Prefix") 738 Address-Family: 1 (IPv4) or 2 (IPv6) 740 Conceptually, an "Address Prefix FEC" OLF entry for a given Address 741 Family consists of the fields , and hence the "Address Prefix FEC" OLF entry within 743 an "Address Prefix FEC" OLF element is encoded as follows: 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 |Action | Rsvd | Minlen | Maxlen | Prefix Len | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 ~ Prefix ~ 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-++-+-+-+-+-+-+-+ 755 Figure 7: Format of OLF Entry for Address Prefix FEC 757 With reference to Fig 3, the first octet of the above OLF Entry 758 belongs to the "Common part" and the rest of the fields belong to 759 the "Type-specific part" (as defined for Address Prefix FEC Element 760 type). 762 As per OLF Entry rules defined earlier, if the Action component of 763 the entry specifies wildcard operation ("PERMIT-ALL"), then Address 764 Prefix FEC OLF Entry does not specify any type-specific data (i.e. 765 OLF entry size is 1 octet only). 767 The "Minlen" and "Maxlen" fields indicate respectively the minimum 768 and the maximum prefix length in bits that is used for "matching". 769 Either the Minlen or Maxlen field or both may have the value 0 to 770 indicate that the value of the field is "unspecified". The "Maxlen" 771 value must not be more than the maximum length (in bits) of a host 772 address for the given address family. 774 The "Prefix Len" field indicates the length in bits of the address 775 prefix. This field MUST NOT be specified as zero. 777 The "Prefix" field contains an address prefix encoded according to 778 the given address family. 780 This document imposes that values of these fields MUST satisfy the 781 following rule, assuming Minlen and Maxlen are specified: 783 0 < Prefix Len <= Minlen <= Maxlen 785 5.1. Matching Address Prefixes to OLF Entries 787 Consider an Address Prefix FEC OLF entry, and an IP route maintained 788 by an LDP speaker in the form of . Following 789 are the matching rules defined for Address Prefix OLF specific 790 matching. 792 o The IP route is considered as "no match" to the OLF entry if the 793 route prefix is neither more specific than, nor equal to, the 794 fields of the OLF entry. 796 o When the IP route is either more specific than, or equal to, the 797 fields of the OLF entry, the route is 798 considered as a match to the OLF entry only if the match conditions 799 as listed in Table 2 are satisfied (where un-spec refers to a value 800 of zero). 802 OLF Entry Route Prefix 803 Minlen Maxlen Match Condition 804 +-----------+------------+------------------------------------+ 805 | un-spec. | un-spec. | Route.Prefix Len == OLF.Prefix Len | 806 | specified | un-spec. | Route.Prefix Len >= OLF.Minlen | 807 | un-spec. | specified | Route.Prefix Len <= OLF.Maxlen | 808 | specified | specified | Route.Prefix Len >= OLF.Minlen AND | 809 | | | Route.Prefix Len <= OLF.Maxlen | 810 +-----------+------------+------------------------------------+ 811 Table 2: Matching Rules for an Address Prefix OLF Entry 813 o When more than one Address Prefix OLF entry matches the route, the 814 "first-match" rule applies. That is, the OLF entry that is specified 815 (and processed) first in a given OLF update (among all the matching 816 OLF entries) is considered as the sole match, and it would determine 817 whether the route should be permitted or denied. 819 6. Operational Examples 821 6.1. Label Filtering at Area Border Router 823 A typical service provider core network is designed with two or more 824 levels of IGP hierarchy. In OSPF parlance, a backbone area is 825 connected to multiple islands of non-zero areas. Similarly, in an 826 IS-IS network, core L2 areas are connected to L1 areas. When LDP is 827 enabled in such a network, an ABR (or a L2 router) that connects 828 multiple non-zero areas to the backbone will advertise LDP label 829 bindings for all prefixes (non-zero area as well as backbone area). 830 However, depending on the MPLS hierarchy, each ABR may want label 831 bindings for only the backbone area prefixes. The OLF scheme 832 specified in this document provides a mechanism to do so 833 efficiently. 835 6.2. LSR with limited LIB size 837 Assume an LSR (LSR1) is not capable of storing all IPv4 label 838 bindings from its peer (LSR2) in its IPv4 Label Information Base 839 (LIB), and it is desirable to receive and store only handful of 840 remote label bindings from its peer. One approach of solving this 841 issue is to use Downstream on Demand mode of label distribution so 842 that LSR2 does not send its entire label database unsolicitedly 843 towards LSR1. Instead, LSR1 uses Label Request mechanics to request 844 labels for [handful of] interested FECs from its peer LSR2. This 845 approach has few drawbacks: 847 a. This forces Downstream On Demand label distribution mode on both 848 LSRs (LSR1 and LSR2) engaged in the session, although this mode is 849 really required by LSR1 due to its limitation. 851 b. The control plane signaling convergence for Downstream On Demand 852 label distribution mode is slower than Downstream Unsolicited. 854 An alternate approach to meet LSR1 requirement is to use OLF 855 mechanics while using Downstream Unsolicited distribution mode. In 856 this approach, LSR1 and LSR2 will negotiate OLF Capability as 857 sender/receiver respectively, and LSR1 will install OLF filters to 858 limit the IPv4 label bindings sent by LSR2 to the only IPv4 prefixes 859 in which LSR1 is interested in. 861 6.3. Label Filtering an Address Family in an IP Dual-Stack LSR 863 The OLF mechanism specified in this document can be useful in cases 864 when an operator wants to filter entire address family to/from peer 865 in (IP) dual-stack environment. Consider that LSR2 is locally 866 enabled for label switching for both IPv4 and IPv6 address families, 867 whereas LSR1 is enabled for label switching for IPv4 address family 868 only. Without any filtering mechanics, LSR2 may advertise all its 869 label bindings for both IPv4 and IPv6 address families towards LSR1 870 although LSR1 is an IPv4-only LDP peer with whom hello adjacencies 871 and transport connection is formed using IPv4 only. In this case, 872 the advertisement of IPv6 addresses and labels to the peer is 873 unnecessary, as well as wasteful from LSR memory/CPU and network 874 resource consumption point of view. 876 To avoid this unnecessary label advertisement (for IPv6 address 877 family, in this example), OLF mechanics could be useful -- i.e. If 878 LSR1 and LSR2 supported "send" and receive OLF capability for ("IP 879 Prefix" FEC, IPv6 Address Family), the OLF capability could be 880 exchanged at the session establishment time, blocking any IPv6 label 881 bindings to be advertised to LSR1 until any further OLF policy 882 changes/updates are received and installed at LSR2. In this case, 883 LSR1 will not send any OLF Policy to LSR2 for IPv6 Prefix FEC type, 884 leaving the IPv6 label advertisement blocked/filtered (due to 885 implicit DENY ALL) for entire IPV6 LIB on LSR2 side. 887 7. Security Considerations 889 The proposal introduced in this document does not introduce any new 890 security considerations beyond that already apply to the base LDP 891 specification [RFC5036] and [RFC5920]. 893 8. IANA Considerations 895 The document introduces following new protocol elements that require 896 code point assignment by IANA: 898 o "OLF Capability" TLV (requested code point: 0x50E) 900 o "OLF Policy Status" TLV (requested code point: 0x50F) 902 o "OLF Status" status code (requested code point: 0x00000050) 904 9. References 906 9.1. Normative References 908 [RFC5036] L. Andersson, I. Mine, and B. Thomas, "LDP Specification", 909 RFC 5036, September 2007. 911 [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le 912 Roux, "LDP Capabilities", RFC 5561, July 2009. 914 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 915 Requirement Levels", BCP 14, RFC2119, March 1997. 917 9.2. Informative References 919 [RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS 920 Networks", RFC 5920, July 2010. 922 [RFC5291] E. Chen, Y. Rekhter, "Outbound Route Filtering Capability 923 for BGP-4", RFC 5291, August 2008. 925 [RFC5292] E. Chen, S. Sangli, "Address-Prefix-Based Outbound Route 926 Filter for BGP-4", RFC 5292, August 2008. 928 [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution 929 Protocol Typed Wildcard FEC", RFC 5918, August 2010. 931 [RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron, 932 "Pseudowire Setup and Maintenance using the Label 933 Distribution Protocol", RFC 4447, April 2006. 935 [RFC6388] I. Minei, I. Wijnand, K. Kompella, and B. Thomas, "LDP 936 Extensions for P2MP and MP2MP LSPs", RFC 6388, November 937 2011. 939 [P2MP-PW] L. Martini, et. al, "Signaling Root-Initiated Point-to- 940 Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp- 941 pw-04.txt, Work in Progress, March 2012. 943 10. Acknowledgments 945 The authors would like to thank Eric Rosen for his valuable input 946 and comments. 948 This document was prepared using 2-Word-v2.0.template.dot. 950 Authors' Addresses 952 Kamran Raza 953 Cisco Systems, Inc., 954 2000 Innovation Drive, 955 Ottawa, ON K2K-3E8, Canada. 956 E-mail: skraza@cisco.com 957 Sami Boutros 958 Cisco Systems, Inc. 959 3750 Cisco Way, 960 San Jose, CA 95134, USA. 961 E-mail: sboutros@cisco.com 963 Pradosh Mohapatra 964 Cisco Systems, Inc. 965 3750 Cisco Way, 966 San Jose, CA 95134, USA. 967 E-mail: pmohapat@cisco.com