idnits 2.17.1 draft-deevimajumdar-spring-bgp-feedback-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 2 instances 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 21, 2017) is 2560 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) -- Looks like a reference, but probably isn't: '30000' on line 187 -- Looks like a reference, but probably isn't: '40000' on line 187 -- Looks like a reference, but probably isn't: '60000' on line 187 -- Looks like a reference, but probably isn't: '70000' on line 187 == Missing Reference: 'BGP-CAP' is mentioned on line 419, but not defined == Unused Reference: 'I-D.filsfils-spring-segment-routing-policy' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC7606' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-prefix-sid' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-conflict-resolution' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC5549' is defined on line 529, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-00 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-27) exists of draft-ietf-idr-bgp-prefix-sid-05 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 2 errors (**), 0 flaws (~~), 23 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group K. Majumdar 3 Internet-Draft K. Deevi 4 Intended status: Standards Track Cisco Systems 5 Expires: October 23, 2017 April 21, 2017 7 A Framework for BGP Feedback Message In Segment Routing 8 draft-deevimajumdar-spring-bgp-feedback-00 10 Abstract 12 In support of Segment Routing(SR), routing protocols advertise a 13 variety of identifiers used to define the segments that direct packet 14 forwarding. 16 In cases where the information advertised by a given protocol 17 instance is either internally inconsistent or conflicts with 18 advertisements from another protocol instance a means of notifying 19 the originator about the inconsistency is required. This document 20 defines a generic mechanism to notify the BGP originator about the 21 inconsistency in the network. 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 http://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 October 23, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Segment Routing Prefix SID Issues . . . . . . . . . . . . . . 3 65 3. Prefix SID Label Index Collision Traffic flow . . . . . . . . 4 66 4. Segment Routing SRv6-VPN Migration Issues . . . . . . . . . . 5 67 5. BGP Feedback Mechanism . . . . . . . . . . . . . . . . . . . 5 68 6. BGP Feedback Capability . . . . . . . . . . . . . . . . . . . 6 69 7. BGP Feedback Message Format . . . . . . . . . . . . . . . . . 6 70 8. BGP Feedback Message Prefix SID Data . . . . . . . . . . . . 7 71 9. Prefix SID Index Feedback Mechanism Summary . . . . . . . . . 7 72 10. The Migration from L3 MPLS to SRv6 SR . . . . . . . . . . . . 8 73 11. BGP Feedback Message SR Migration Handling Data . . . . . . . 9 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 14.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The BGP Prefix SID ietf draft describes the BGP extension to signal 84 the BGP Prefix SID but it doesn't describe the cases where Prefix Sid 85 conflicts with an other node. In case of misconfiguration there is a 86 possibility of Prefix SID collision in the network and if the Prefix 87 SID collision happens there needs a way to notify the BGP originator 88 about the Prefix SID collision information. In case BGP nodes are 89 locally configured with SR Global Block (SRGB) range then there could 90 be possibility that SRGB range is fully used up when BGP originator 91 is trying to use the SRGB to allocate SR label on a certain prefix 92 SID. 94 The draft BGP Signaling of IPv6 SR VPN Networks describes the 95 migration scenarios from MPLS based dataplane to SRv6 based 96 dataplane. But again this draft doesn't describe the scenario if the 97 different migration scenarios are supported in the ingress PE. 98 Considering all the cases there is a need to support BGP notification 99 mechanism to inform the BGP originator about the downstream behavior 100 on what is supported or advertised Prefix SID can be used without any 101 issues 103 This requires BGP to send informational feedback message back to 104 originator of the BGP update message and let the originator act on 105 it. The existing notification message (bgp message type 3) defined 106 for notifying the error conditions back to originator requires the 107 BGP session to be closed. So this doesn't suit well in cases where 108 there is only a need to send some information messages to originator 109 but not close/withdraw the prefixes received from originator. 111 The SR Prefix SID Collision and Out of range Notification mechanisms 112 are some of the use cases where BGP Feedback message could be used. 113 On receipt of this notification, the originator can take appropriate 114 action like correcting the configuration in the network causing the 115 collision. 117 The Migration case from L3 MPLS based Segment Routing to SRv6 Segment 118 Routing is another use case of the Feedback message. When migrating 119 the exiting MPLS VPN network into SRv6 VPN network it is possible 120 that not all the nodes in the network are SRv6 capable. Its possible 121 that the egress router sends SRv6 SID but ingress node not support 122 it. In this case the Ingress node might have to send an information 123 message to originator to send MPLS VPN label instead of SRv6 SID. 125 To achieve this a new BGP message type called BGP "Feedback Message" 126 is defined in this draft. The Feedback message type is to provide 127 the feedback to the BGP peers. It would be processed hop by hop like 128 update message. Upon receiving BGP Feedback message, BGP node can 129 decide if they want to take any action on it. The BGP session would 130 not be impacted by the Feedback message. The BGP Feedback message 131 would be a generic purpose message and could be used for any cases 132 within BGP by defining the required new TLVs under this message. The 133 BGP nodes will exchange their capability to support this BGP Feedback 134 Message type and the BGP feedback message is only sent to the node 135 which support it. 137 2. Segment Routing Prefix SID Issues 139 The BGP Prefix SID is described in [draft-ietf-idr-bgp-prefix-sid]. 140 The downstream BGP router might detect collision in the label index. 141 When it finds the collision for the same Prefix SID label index, it 142 would fallback to dynamic label. This collision most likely will 143 continue in other downstream BGP routers and based on the current 144 mechanism, all of them would be using dynamic label. This is not a 145 desired behavior. The same behavior could happen for out of SRGB 146 range SID label index. 148 This draft proposes a mechanism to notify the BGP originator if the 149 advertised prefix SID label index is in collision with another prefix 150 SID label index or if the advertised prefix SID label index is no 151 longer able to produce local SR index as the local SRGB range is 152 fully used. The current Prefix SID Label Index collision or out of 153 SRGB range notification to the originator can be handled with the 154 newly introduced BGP feedback mechanism. 156 As soon as the downstream BGP router detects the collision on the 157 label index or finds that the label index is outside the SRGB range, 158 it can inform the originating BGP router that Label Index collision 159 detected. The BGP originator once received the Label Index collision 160 or out of range feedback message it would process and notify user 161 through some log messages. The originator BGP router can optionally 162 resolve the collision by allocating a new Label Index and advertise 163 the new label index TLV to its downstream BGP peers. 165 3. Prefix SID Label Index Collision Traffic flow 167 +---+ +---+ 168 Lo0=1.1.1.1/32, Lo0=2.2.2.2/32, 169 Label Index = 100 | A | | B | Label Index = 100 171 +---+ +---+ 172 1.1.1.1/32->A \ / 2.2.2.2/32->B 173 Label Index = 100 \ / Label Index = 100 174 +---+ 175 | C | SRGB Config: [30000, 40000] 176 +---+ SR Index=30100 (In Collision) 177 | 178 | 179 +---+ 180 | D | SRGB Config: [60000, 70000] 181 +---+ SR Index=60100 (In Collision) 183 In the above SR flow, note that A and B are the two BGP originator 184 for the prefixes 1.1.1.1/32 and 2.2.2.2/32 respectively. C is the 185 first BGP downstream router connected to both A and B and receives 186 update from both A and B. C and D have local SRGB range configured 187 [30000, 40000] and [60000, 70000] respectively. 189 In this use case C applies certain route map policy which prevents 190 the prefix update from A to go to B and vice-versa. The other case 191 is A applies certain route-map policy which prevents A to receive BGP 192 prefix update from B and vice-versa. 194 In this flow C would be the first downstream router that would detect 195 the SR label index collision. C would assign SR Index 30100 as it 196 receives the prefix advertisement from either A or B with label index 197 100 for the first time. The next time prefix advertise comes with 198 the same label index it would collide with the originally allocated 199 SR Index and would allocate dynamic label. The same behavior would 200 continue on D as well. 202 4. Segment Routing SRv6-VPN Migration Issues 204 The draft [BGP Signaling of IPv6-SR VPN Networks] describes the BGP 205 signaling of SRv6-VPN SID for the VPN route; it doesn't describe the 206 scenario when ingress PE can only support L3 MPLS based data plane or 207 the local BGP policy prevent ingress PE to use SRv6-VPN Service. 208 These can be referred as SRv6 VPN Service Migration. The BGP 209 Feedback message described below handle the SRv6-VPN Service 210 migration scenarios. 212 5. BGP Feedback Mechanism 214 This draft defines a new BGP Message type called BGP Feedback Message 215 which will carry the informational message back to the originator. 216 It should carry the associated prefix and informational data. 218 Currently defined Notification message (BGP Message type 3) doesn't 219 suit for these cases as the Notification message BGP has to close the 220 session. 222 The idea behind the Feedback message type is to provide the feedback 223 to the BGP peers without having to close the BGP session. It would 224 be processed hop by hop like update message. Upon receiving BGP 225 Feedback message BGP node can decide if they want to take any action 226 on it. But the Feedback message doesn't impose a mandate on a BGP 227 node to take certain action. It is treated more of a passing 228 information to the BGP peers. The BGP Feedback message would be a 229 generic purpose message and could be used by for different use cases 230 within BGP. 232 The SR Prefix SID Collision and Out of range Notification mechanisms 233 are some of the use cases where BGP Feedback message could be used. 235 The Migration case from L3 MPLS based Segment Routing to SRv6 Segment 236 Routing is another use case of the Feedback message. 238 6. BGP Feedback Capability 240 To advertise the BGP Feedback Capability to a peer, a BGP speaker 241 uses BGP Capabilities Advertisement [BGP-CAP]. This capability is 242 advertised using the Capability code 74 and Capability length 0. 244 By advertising the BGP Feedback Capability to a peer, a BGP speaker 245 conveys to the peer that the speaker is capable of receiving and 246 properly handling the BGP Feedback message (as defined in Section 7) 247 from the peer. 249 7. BGP Feedback Message Format 251 The BGP Feedback message is a new BGP message type defined as 252 follows: 254 Type: 6 - BGP Feedback Message 256 The BGP Feedback Message Format: 258 +----------------------------------------- + 259 | Prefix Length (1 octet) 260 +----------------------------------------- + 261 | Prefix (Variable) 262 +----------------------------------------- + 263 | Type (1 octet) 264 +----------------------------------------- + 265 | Length (1 octet) 266 +----------------------------------------- + 267 | Data (Variable) 268 +----------------------------------------- + 270 Prefix Length: Length of Prefix in octets 272 Prefix: Prefix associated with feedback message 274 Type: BGP Feedback message Type. It defines type of BGP application 275 associated with the message. 277 Type 1: SR Label Index 279 Type 2: SRv6 Migration 281 Length: Length of the Feedback Message Data. 283 Data: BGP Feedback Message Data 285 8. BGP Feedback Message Prefix SID Data 287 The below format defines the Prefix SID Message to be used part of 288 Data field in the BGP Feedback Message. 290 +----------------------------------------- + 291 | Impact Type (1 octet) 292 +----------------------------------------- + 293 | Impact Value (1 octet) 294 +----------------------------------------- + 295 | Number of Labels (1 octet) 296 +----------------------------------------- + 297 | Label Index (variable) 298 +----------------------------------------- + 300 Impact Type: Collision or SRGB Outside Range 302 Impact Type 1: Segment Routing Label Index Collision 304 Impact Type 2: Segment Routing SRGB Outside Range 306 Impact Value: Impacted or Resolved. 308 Impact Value 1: Collision or SRGB range Impacted 310 Impact Value 2: Collision or SRGB range Impact Resolved 312 Number of Labels: The number of labels associated with the Prefix 313 that got impacted. It would be 1 in the current case. But in future 314 if more labels get advertised with the route this option will address 315 it. 317 Label Index: Actual Indexes which are all impacted or impact 318 resolved. 320 9. Prefix SID Index Feedback Mechanism Summary 322 This new Feedback mechanism is defined to notify the BGP originator 323 if the BGP advertised prefix with the SID label index is in collision 324 with already used index in the network or if the assigned label index 325 from the BGP originator is outside the SRGB range. 327 Once BGP originator gets the BGP feedback message it might provide 328 collision or out of range SID index info in the log message or part 329 of BGP show command. It could optionally assign a new label index 330 with the prefix came under collision or out of range. 332 This specification doesn't mandate action on the BGP originator. The 333 BGP originator would decide on the action. This draft is defined 334 only to define the mechanism on how to notify the BGP originator. 336 The BGP originator would be notified if the impacted SID index is no 337 longer impacted as well. This scenario could happen through the 338 route withdraw or SRGB range modification. 340 10. The Migration from L3 MPLS to SRv6 SR 342 At Egress-PE: 344 If BGP offers a SRv6-VPN service Then BGP allocates an SRv6-VPN SID 345 for the VPN service and adds the BGP SRv6-VPN SID TLV while 346 advertising VPN prefixes. 348 If BGP offers an MPLS VPN service Then BGP allocates an MPLS Label 349 for the VPN service and use it in NLRI as normal for MPLS L3 VPNs. 351 If BGP offers both SRv6-VPN and MPLS VPN service then BGP would 352 advertise SRv6-VPN SID TLV and the NLRI with MPLS label for VPN 353 service. 355 At Ingress-PE: 357 Selection of which encapsulation below (SRv6-VPN or MPLS-VPN) is 358 defined by local BGP policy 360 If BGP supports SRv6-VPN service, and receives a BGP SRv6-VPN SID 361 Attribute from the Egress PE with a SRv6 SID then BGP programs RIB to 362 use SRv6 for the VPN prefix. 364 If BGP supports MPLS VPN service, and the MPLS Label is not Implicit- 365 Null in the BGP update received from the Egress PE then BGP programs 366 RIB to use the MPLS label is used as a VPN label for the VPN prefix. 368 Based on what is advertised from the Egress PE to the Ingress PE and 369 what is actually supported in the Ingress PE the below two scenarios 370 could occur: 372 - If Egress PE offers only SRv6-VPN SID TLV and Ingress PE only 373 supports MPLS VPN service or local BGP policy imposes Ingress PE to 374 use only MPLS VPN Service then Ingress PE needs to send the BGP 375 Feedback Message to the Egress PE. 377 - If Egress PE offers only MPLS VPN Service and Ingress PE only 378 supports SRv6-VPN service or local BGP policy imposes Ingress PE to 379 use only SRv6-VPN VPN Service then Ingress PE needs to send the BGP 380 Feedback Message to the Egress PE. 382 11. BGP Feedback Message SR Migration Handling Data 384 The below format defines the Segment Routing Migration Handling 385 Message to be used part of Data field in the BGP Feedback Message. 387 +----------------------------------------- + 388 | Received VPN Service (1 octet) 389 +----------------------------------------- + 390 | Imposed VPN Service (1 octet) 391 +----------------------------------------- + 393 Received VPN Service: The VPN Service Received at the Ingress PE from 394 the Egress PE 396 Type 1: L3 MPLS Segment Routing. 398 Type 2: IPv6 Segment Routing. 400 Type 3: Both L3 MPLS Segment Routing and IPv6 Segment Routing. 402 Imposed VPN Service: The Imposed VPN Service in the Ingress PE 404 Type 1: L3 MPLS Segment Routing. 406 Type 2: IPv6 Segment Routing. 408 12. Security Considerations 410 This document introduces no new security considerations above and 411 beyond those already specified in [RFC4271] and [RFC3107]. 413 13. IANA Considerations 415 This document defines a new BGP Message Type known as the BGP 416 Feedback Message and a new BGP Capability Code [BGP-CAP]. This 417 document requests IANA to assign a new message type (suggested value: 418 6) for BGP the Feedback and a new BGP Capability Code (suggested 419 value: 74) [BGP-CAP] for Feedback Message Handling capability from 420 the BGP Message Type and Capability Code registry. 422 This document defines 2 new TLVs for BGP Feedback Message type. 423 These TLVs needs to be registered with IANA. We request IANA to 424 create a new registry for BGP Feedback TLVs as follows: 426 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 427 Feedback TLV Types" (Reference: this document) should follow the 428 below Registration Procedure(s): Values 1-254 First Come, First 429 Served, Value 0 and 255 reserved 431 Value Type Reference 432 0 Reserved this document 433 1 SR Label Index Message this document 434 2 SRv6 Migration Message this document 435 3-254 Unassigned 436 255 Reserved this document 438 14. References 440 14.1. Normative References 442 [I-D.filsfils-spring-segment-routing-policy] 443 Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin, 444 S., bogdanov@google.com, b., Horneffer, M., Clad, F., 445 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 446 Routing Policy for Traffic Engineering", draft-filsfils- 447 spring-segment-routing-policy-00 (work in progress), 448 February 2017. 450 [I-D.filsfils-spring-srv6-network-programming] 451 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 452 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 453 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 454 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 455 Sharif, M., Ayyangar, A., Mynam, S., Bashandy, A., Raza, 456 K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network 457 Programming", draft-filsfils-spring-srv6-network- 458 programming-00 (work in progress), March 2017. 460 [I-D.ietf-6man-segment-routing-header] 461 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 462 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 463 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 464 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 465 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 466 segment-routing-header-06 (work in progress), March 2017. 468 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 469 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 470 December 1998, . 472 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 473 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 474 . 476 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 477 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 478 2006, . 480 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 481 Reflection: An Alternative to Full Mesh Internal BGP 482 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 483 . 485 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 486 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 487 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 488 2015, . 490 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 491 Patel, "Revised Error Handling for BGP UPDATE Messages", 492 RFC 7606, DOI 10.17487/RFC7606, August 2015, 493 . 495 14.2. Informative References 497 [I-D.ietf-idr-bgp-prefix-sid] 498 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 499 and H. Gredler, "Segment Routing Prefix SID extensions for 500 BGP", draft-ietf-idr-bgp-prefix-sid-05 (work in progress), 501 April 2017. 503 [I-D.ietf-spring-conflict-resolution] 504 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 505 "Segment Routing Conflict Resolution", draft-ietf-spring- 506 conflict-resolution-02 (work in progress), October 2016. 508 [I-D.ietf-spring-segment-routing] 509 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 510 and R. Shakir, "Segment Routing Architecture", draft-ietf- 511 spring-segment-routing-11 (work in progress), February 512 2017. 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, 516 DOI 10.17487/RFC2119, March 1997, 517 . 519 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 520 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 521 DOI 10.17487/RFC4271, January 2006, 522 . 524 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 525 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 526 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 527 . 529 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 530 Layer Reachability Information with an IPv6 Next Hop", 531 RFC 5549, DOI 10.17487/RFC5549, May 2009, 532 . 534 Authors' Addresses 536 Kausik Majumdar 537 Cisco Systems 538 821 Alder Drive 539 Milpitas, CA 95054 540 USA 542 Email: kmajumda@cisco.com 544 Krishna Deevi 545 Cisco Systems 546 821 Alder Drive 547 Milpitas, CA 95054 548 USA 550 Email: kdeevi@cisco.com