idnits 2.17.1 draft-kaliraj-idr-multinexthop-attribute-00.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 22, 2017) is 2494 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 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 K. Vairavakkalai 3 Internet-Draft M. Jeyananth 4 Intended status: Experimental Juniper Networks, Inc. 5 Expires: December 24, 2017 June 22, 2017 7 BGP MultiNexthop attribute 8 draft-kaliraj-idr-multinexthop-attribute-00 10 Abstract 12 Today, a BGP speaker can advertise one nexthop for a set of NLRIs in 13 an Update. This nexthop can be encoded in either the BGP-Nexthop 14 attribute (code 3), or inside the MP_REACH attribute (code 14). 16 For cases where multiple nexthops need to be advertised, BGP-Addpath 17 is used. Though Addpath allows basic ability to advertise multiple- 18 nexthops, it does not allow the sender to specify desired 19 relationship between the multiple nexthops being advertised e.g., 20 relative-preference, type of load-balancing. These are local 21 decisions at the receiving speaker based on path-selection between 22 the various additional-paths, which may tie-break on some arbitrary 23 step like Router-Id. 25 Some scenarios with a BGP-free core may benefit from having a 26 mechanism, where egress-node can signal multiple-nexthops along with 27 their relationship to ingress nodes. This document defines a new BGP 28 attribute "MultiNexthop" that can be used for this purpose. 30 This attribute can be used for both labeled and unlabled BGP 31 families. For labeled-families, it is used for a different purpose 32 in "downstream allocation" case than "upstream allocation" scenarios. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 24, 2017. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Use-cases examples . . . . . . . . . . . . . . . . . . . . . 3 76 2.1. Optimal forwarding exit-points signaling to ingress-node 3 77 2.2. Choosing a received label based on it's forwarding- 78 semantic at advertising node . . . . . . . . . . . . . . 4 79 2.3. Signaling desired forwarding behavior when installing 80 MPLS Upstream labels at receiving node . . . . . . . . . 4 81 3. The "MultiNexthop" BGP attribute encoding . . . . . . . . . . 4 82 3.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 5 83 3.1.1. Interaction with Nexthop (in attr-code 3, 14) . . . . 5 84 3.1.2. Interaction with Addpath . . . . . . . . . . . . . . 6 85 3.1.3. Path-selection considerations . . . . . . . . . . . . 6 86 3.1.4. NH-Flags U bit, denoting upstream/downstream 87 semantics . . . . . . . . . . . . . . . . . . . . . . 6 88 3.2. Nexthop Forwarding Semantics TLV . . . . . . . . . . . . 7 89 3.3. Nexthop-Leg Descriptor TLV . . . . . . . . . . . . . . . 8 90 3.4. Nexthop Attributes Sub-TLV . . . . . . . . . . . . . . . 9 91 3.4.1. IP Address . . . . . . . . . . . . . . . . . . . . . 9 92 3.4.2. Labeled IP nexthop . . . . . . . . . . . . . . . . . 9 93 3.4.3. Available Bandwidth . . . . . . . . . . . . . . . . . 9 94 3.4.4. Load balance factor . . . . . . . . . . . . . . . . . 10 95 3.4.5. Forwarding-context name . . . . . . . . . . . . . . . 10 96 3.4.6. Forwarding-context Route-Distinguisher . . . . . . . 11 97 4. Error handling procedures . . . . . . . . . . . . . . . . . . 11 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 103 8.2. References . . . . . . . . . . . . . . . . . . . . . . . 12 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 106 1. Introduction 108 Today, a BGP speaker can advertise one nexthop for a set of NLRIs in 109 an Update. This nexthop can be encoded in either the top-level BGP- 110 Nexthop attribute (code 3), or inside the MP_REACH attribute (code 111 14). 113 For cases where multiple nexthops need to be advertised, BGP-Addpath 114 is used. Though Addpath allows basic ability to advertise multiple- 115 nexthops, it does not allow the sender to specify desired 116 relationship between the multiple nexthops being advertised e.g., 117 relative-ordering, type of load-balancing, fast-reroute. These are 118 local decision at the upstream node based on path-selection between 119 the various additional-paths, which may tie-break on some arbitrary 120 step like Router-Id. 122 Some scenarios with a BGP-free core may benefit from having a 123 mechanism, where egress-node can signal multiple-nexthops along with 124 their relationship to ingress nodes. This document defines a new BGP 125 attribute "MultiNexthop" that can be used for this purpose. 127 2. Use-cases examples 129 2.1. Optimal forwarding exit-points signaling to ingress-node 131 In a BGP free core, one can dynamically signal to the ingress-node, 132 how traffic should be load-balanced towards a set of exit-nodes, in 133 one BGP-route containing this attribute. 135 Example, for prefix1, perform equal cost load-balancing towards exit- 136 nodes A, B; where-as for prefix2, perform unequal-cost load-balancing 137 (40%, 30%, 30%) towards exit-nodes A, B, C. 139 Example, for prefix1, use PE1 as primary-nexthop and use PE2 as a 140 backup-nexthop. 142 2.2. Choosing a received label based on it's forwarding-semantic at 143 advertising node 145 In Downstream label allocation case, receiving speaker can benefit 146 from this information as in the following examples: 148 - For a Prefix, a label with FRR enabled nexthop-set can be preferred 149 to another label with a nexthop-set that doesn't provide FRR. 151 - For a Prefix, a label pointing to 10g nexthop can be preferred to 152 another label pointing to a 1g nexthop 154 - Set of labels advertised can be aggregated, if they have same 155 forwarding semantics (e.g. VPN per-prefix-label case) 157 2.3. Signaling desired forwarding behavior when installing MPLS 158 Upstream labels at receiving node 160 In Upstream label allocation case, the receiving speaker's 161 forwarding-state can be controlled by the advertising speaker, thus 162 enabling a standardized API to program desired MPLS forwarding-state 163 at the receiving node. This is described in the draft 164 [BGP_PRIVATE_LABELS] 166 3. The "MultiNexthop" BGP attribute encoding 168 "MultiNexthop" is a new BGP optional-transitive attribute code TBD, 169 that can be used to convey multiple-nexthops to a BGP-speaker. This 170 attribute describes forwarding semantics using one or more Nexthop- 171 Forwarding-Semantics TLV. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |1 1 0 1(Flags) |Attr. Type Code| Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | NH-Flags | PNH-Len | ..Advertising| 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | PNH Address /32 or /128.. | Num-Nexthops | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | ...one or more "Nexthop-Forwarding-Semantics TLV"... | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Fig 1: MultiNexthop - BGP Attribute 186 Flags BGP Path-attribute flags. 1101 to indicate 187 Optional Transitive, Extended-length field 189 Length Two bytes field stating length of attribute 190 value in bytes 192 NH-Flags 16 bit flag (UR..R) Only one bit MSB is 193 defined currently, others are reserved. 195 R: Reserved 196 U: 1 means the Upstream-allocation, 197 attribute describes forwarding state 198 desired at receiving speaker 199 U: 0 means the Downstream-allocation, 200 attribute describes forwarding state 201 present at advertising-speaker 203 PNH-Len NH-Length in bits (= 32 or 128) 205 Advertising PNH IPv4 or IPv6 PNH-address (Len = 32 or 128) 206 advertised in NEXT_HOP or MP_REACH_NLRI attr. 207 Used to sanity-check this attribute 209 Num-Nexthops >1 if ECMP or Alternate-paths 211 Sec 3.2 describes the Nexthop-Forwarding-Semantics TLV. 213 3.1. Operations 215 3.1.1. Interaction with Nexthop (in attr-code 3, 14) 217 When adding a MultiNexthop attribute to an advertised BGP route, the 218 speaker MUST put the same next-hop address in the Advertising PNH 219 field as it put in the Nexthop field inside NEXT_HOP attribute or 220 MP_REACH_NLRI attribute. Any speaker that recognizes this attribute 221 and changes the PNH while re-advertising the route MUST remove the 222 MultiNexthop-Attribute in the re-advertisement. The speaker MAY 223 however add a new MultiNexthop-Attribute to the re-advertisement; 224 while doing so the speaker MUST record in the "Advertising-PNH" field 225 the same next-hop address as used in NEXT_HOP field or MP_REACH_NLRI 226 attribute. 228 A speaker receiving a MultiNexthop-attribute SHOULD ignore the 229 attribute if the next-hop address contained in Advertising-PNH field 230 is not the same as the next-hop address contained in NEXT_HOP field 231 or MP_REACH_NLRI field. 233 3.1.2. Interaction with Addpath 235 A RR advertising ADD_PATHs should use the MultiNexthop attribute when 236 comparing with next-hop of other contributing paths and arriving on 237 set of paths to advertise to Addpath receivers. 239 3.1.3. Path-selection considerations 241 While tie breaking in the path-selection as described in RFC-4271, 242 9.1.2.2. step (e) viz. the "IGP cost to nexthop", consider the 243 highest cost among the nexthop-legs present in this attribute. 245 3.1.4. NH-Flags U bit, denoting upstream/downstream semantics 247 U-bit being Set indicates that this attribute describes what the 248 forwarding semantics of an Upstream-allocated label at the receiving- 249 speaker should be. All other bits in NH-Flags are currently 250 reserved, MUST be set to 0 by sender and MUST be ignored by receiver. 252 This attribute can be used for both labeled and unlabled BGP 253 families. 255 A MultiNexthop attribute with U=0 is called "Label-Nexthop- 256 Descriptor" role. A BGP speaker advertising a downstream-allocated 257 label-route MAY add this attribute to the BGP route Update, to 258 "describe" to the receiving speaker what the label's forwarding 259 semantics at the sending speaker is. 261 Today semantics of a downstream-allocated label is known only to the 262 egress-node advertising the label. The speaker receiving the label- 263 binding doesn't know what the label's forwarding-semantic at the 264 advertiser is. In some environments, it may be useful to convey this 265 information to the receiving speaker. Like, this may help in better 266 debugging and manageability, or enable the label-receiving-speaker, 267 which could also be some centralized controller, make better 268 decisions about which label to use, based on the label's forwarding- 269 semantic. 271 While doing upstream-label allocation, today there is no way to 272 signal to the receiving-speaker what the forwarding-semantic for the 273 label should be. This attribute can be used to convey the 274 forwarding-semantics at the receiving node should be. Details of the 275 BGP protocol extensions required for signaling upstream-label 276 allocation are out of scope of this document, and are described in 277 [BGP_PRIVATE_LABELS]. 279 In rest of this document, the use of term "label" will mean 280 downstream allocated label, unless specified otherwise as upstream- 281 allocated label. 283 3.2. Nexthop Forwarding Semantics TLV 285 Each Forwarding-Semantics TLV expresses a nexthop leg's forwarding 286 action. i.e. a "FwdAction" with an associated Nexthop. The type of 287 actions defined by this TLV are given below. The "Nexthop-Leg" field 288 takes appropriate values based on the FwdAction. 290 (preamble) 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | FwdAction | Len | ...Nexthop-Leg | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Descriptor-TLV... | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Fig 2: Nexthop Forwarding Semantics TLV 302 FwdAction Meaning 304 1 Forward 305 2 Pop-And-Forward 306 3 Swap 307 4 Push 308 5 Pop-And-Lookup 310 Meaning of most of the above FwdAction semantics is well understood. 311 FwdAction 1 is applicable for both IP and MPLS routes. FwdActions 312 2-5 are applicable for MPLS routes only. 314 The "Forward" action means forward the IP/MPLS packet with the 315 destination prefix (IP-dest-addr/MPLS-label) value unchanged. For IP 316 routes, this is the forwarding-action given for next-hop addresses 317 contained in BGP path-attributes: Nexthop (code 3) or MP_REACH_NLRI 318 (code 14). For MPLS routes, usage of this action is explained in 319 [BGP_PRIVATE_LABELS] when Upstream-label-allocation is in use. 321 The "Pop-And-Lookup" action may result in a MPLS-lookup or an upper- 322 layer (like IPv4, IPv6) lookup, depending on whether the label that 323 was popped was the bottom of stack label. 325 If an incompatible FwdAction is received for a prefix-type, or an 326 unsupported FwdAction is received, it is considered a semantic-error 327 and MUST be dealt with as explained in section 5. 329 3.3. Nexthop-Leg Descriptor TLV 331 The Nexthop-Leg Descriptor TLV describes various attributes of the 332 Nexthop-legs that the FwdAction is associated with. 334 (preamble) 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | NhopDescrType | Len | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Flags | Relative-Preference | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | ..nhop attributes SubTLV.. | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | ..nhop attributes SubTLV.. | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Fig 3: Nexthop Descriptor TLV 350 NhopDescrType Meaning 351 1 IPv4-nexthop 352 2 IPv6-nexthop 353 3 Labeled-IP-Nexthop 354 4 Forwarding-Context-Nexthop 356 Len Length of Nexthop-Descriptor-TLV 357 including Flags, Relative-Weight 358 and all SubTLVs 360 Flags Must send zero. Must ignore on 361 receive. 363 Relative-Preference Unsigned integer specifying relative 364 order or preference, to use in FIB. 366 Use in FIB all usable legs with 367 lowest relative-weight. If multiple 368 legs exist with that weight, 369 form ECMP. 371 3.4. Nexthop Attributes Sub-TLV 373 SubTLV type Meaning 374 1 IP-Address 375 2 Labeled-Nexthop 376 3 Bandwidth 377 4 Load-Balance-Factor 378 5 Forwarding-context Name 379 6 Fprwarding-context Route-Distinguisher 381 3.4.1. IP Address 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Attr SubTLV Type = 1 |Len (32, 128)| ..IPv4 or | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | ..IPv6 Address.. | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 IP-Address attribute sub-TLV 393 This sub-TLV would be valid with Nexthop-Forwarding-Semantics TLV 394 with FwdAction of Pop-And-Forward or Forward. 396 3.4.2. Labeled IP nexthop 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Attr SubTLV Type = 2 | ... 3107bis Label ... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Len | IPv4 or IPv6 Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 "Labeled nexthop" attribute sub-TLV 408 This sub-TLV would be valid with Nexthop-Forwarding-Semantics TLV 409 with FwdAction of Swap or Push. 411 3.4.3. Available Bandwidth 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Attr SubTLV Type = 3 | 4octet bandwidth | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | value in bytes | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 3.3.6. "Bandwidth" attribute sub-TLV 422 This sub-TLV would be valid with Nexthop-Forwarding-Semantics TLV 423 with FwdAction of Forward, Swap or Push. 425 The bandwidth of the link is expressed as 4 octets in IEEE floating 426 point format, units being bytes (not bits!) per second 428 This sub-TLV would be valid in a Label-Descriptor-attribute whose 429 U-bit is reset. 431 3.4.4. Load balance factor 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Attr SubTLV Type = 4 | Balance Percentage | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 "Load-Balance-Factor" attribute sub-TLV 441 This sub-TLV would be valid with Nexthop-Forwarding-Semantics TLV 442 with FwdAction of Forward, Swap or Push. 444 This is the explicit "balance percentage" requested by the sender, 445 for unequal load-balancing over these Nexthop-Descriptor-TLV legs. 446 This balance percentage would override the implicit balance- 447 percentage calculated using "Bandwidth" attribute sub-TLV 449 3.4.5. Forwarding-context name 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Attr SubTLV Type = 5 | Len | ..Forwarding- | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Context-name... (unicode) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Forwarding-Context name attribute sub-TLV 460 This sub-TLV would be valid with Nexthop-Forwarding-Semantics TLV 461 with FwdAction of Pop-And-Lookup. Ref: usecase 2.3. The Fowarding- 462 context-name identfies the forwarding-context (for e.g. the VRF- 463 name) where the lookup should happen after pop label. 465 3.4.6. Forwarding-context Route-Distinguisher 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Attr SubTLV Type = 6 | Type | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | (..Route-Distinguisher identifying the context..) | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 "Route-Target identifying the Forwarding-Context" attribute sub-TLV 477 This sub-TLV would be valid with Nexthop-Forwarding-Semantics TLV 478 with FwdAction of Pop-And-Lookup. Ref: usecase 2.3. The RD uniquely 479 identfies the forwarding-context (for e.g. VRF) where the lookup 480 should happen after pop label. 482 If any of these sub-TLVs or FwdAction combinations are unrecognized 483 or unsupported by a receiving speaker, it is considered a semantic 484 error for that speaker, and in such case error-handling procedures 485 described in section 4 should be followed. 487 4. Error handling procedures 489 When U-bit is Reset, this attribute is used to describe the label 490 advertised by the BGP-peer. If the value in the attribute is 491 syntactically parse-able, but not semantically valid, the receiving 492 speaker should deal with the error gracefully and MUST NOT tear down 493 the BGP session. In such cases the rest of the BGP-update can be 494 consumed if possibe. 496 When U-bit is Set, this attribute is used to specify the forwarding 497 action at the receiving BGP-peer. If the value in the attribute is 498 syntactically parse-able, but not semantically valid, the receiving 499 speaker SHOULD deal with the error gracefully by keeping the route 500 hidden and not act on it, and MUST NOT tear down the BGP session. 502 5. IANA Considerations 504 This document makes request to IANA to allocate the following codes. 506 1. Multi-Nexthop-Descriptor BGP-attribute: A new BGP attribute code 507 TBD. 509 2. "FwdAction" type as defined in 3.1. 511 3. Nexthop-Leg Descriptor TLV:"NhopDescrType" as defined in 3.2. 513 4. "Nexthop Attributes Sub-TLV type" as defined in 3.3. 515 Note to RFC Editor: this section may be removed on publication as an 516 RFC. 518 6. Security Considerations 520 Like any other optional transitive BGP attribute, it is possible that 521 this attribute gets propagated thru speakers that don't understand 522 this attribute and an error detected by a speaker multiple hops away. 523 This is mitigated by requiring the receiving speaker to remove this 524 attribute when doing nexthop-self. And following the error handling 525 procedures described above. 527 7. Acknowledgements 529 8. References 531 8.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 8.2. References 540 [BGP_PRIVATE_LABELS] 541 "BGP Signalled Private MPLS Labels (draft-kaliraj-bess- 542 bgp-signaled-private-mpls-labels-00)". 544 Authors' Addresses 546 Kaliraj Vairavakkalai 547 Juniper Networks, Inc. 548 1194 N. Mathilda Ave. 549 Sunnyvale, CA 94089 550 US 552 Email: kaliraj@juniper.net 554 Minto Jeyananth 555 Juniper Networks, Inc. 556 1194 N. Mathilda Ave. 557 Sunnyvale, CA 94089 558 US 560 Email: minto@juniper.net