| SPRING Working Group | K. Majumdar |
| Internet-Draft | K. Deevi |
| Intended status: Standards Track | Cisco Systems |
| Expires: October 23, 2017 | April 21, 2017 |
A Framework for BGP Feedback Message In Segment Routing
draft-deevimajumdar-spring-bgp-feedback-00
In support of Segment Routing(SR), routing protocols advertise a variety of identifiers used to define the segments that direct packet forwarding.
In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of notifying the originator about the inconsistency is required. This document defines a generic mechanism to notify the BGP originator about the inconsistency in the network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 23, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The BGP Prefix SID ietf draft describes the BGP extension to signal the BGP Prefix SID but it doesn't describe the cases where Prefix Sid conflicts with an other node. In case of misconfiguration there is a possibility of Prefix SID collision in the network and if the Prefix SID collision happens there needs a way to notify the BGP originator about the Prefix SID collision information. In case BGP nodes are locally configured with SR Global Block (SRGB) range then there could be possibility that SRGB range is fully used up when BGP originator is trying to use the SRGB to allocate SR label on a certain prefix SID.
The draft BGP Signaling of IPv6 SR VPN Networks describes the migration scenarios from MPLS based dataplane to SRv6 based dataplane. But again this draft doesn't describe the scenario if the different migration scenarios are supported in the ingress PE. Considering all the cases there is a need to support BGP notification mechanism to inform the BGP originator about the downstream behavior on what is supported or advertised Prefix SID can be used without any issues
This requires BGP to send informational feedback message back to originator of the BGP update message and let the originator act on it. The existing notification message (bgp message type 3) defined for notifying the error conditions back to originator requires the BGP session to be closed. So this doesn’t suit well in cases where there is only a need to send some information messages to originator but not close/withdraw the prefixes received from originator.
The SR Prefix SID Collision and Out of range Notification mechanisms are some of the use cases where BGP Feedback message could be used. On receipt of this notification, the originator can take appropriate action like correcting the configuration in the network causing the collision.
The Migration case from L3 MPLS based Segment Routing to SRv6 Segment Routing is another use case of the Feedback message. When migrating the exiting MPLS VPN network into SRv6 VPN network it is possible that not all the nodes in the network are SRv6 capable. Its possible that the egress router sends SRv6 SID but ingress node not support it. In this case the Ingress node might have to send an information message to originator to send MPLS VPN label instead of SRv6 SID.
To achieve this a new BGP message type called BGP “Feedback Message” is defined in this draft. The Feedback message type is to provide the feedback to the BGP peers. It would be processed hop by hop like update message. Upon receiving BGP Feedback message, BGP node can decide if they want to take any action on it. The BGP session would not be impacted by the Feedback message. The BGP Feedback message would be a generic purpose message and could be used for any cases within BGP by defining the required new TLVs under this message. The BGP nodes will exchange their capability to support this BGP Feedback Message type and the BGP feedback message is only sent to the node which support it.
The BGP Prefix SID is described in [draft-ietf-idr-bgp-prefix-sid]. The downstream BGP router might detect collision in the label index. When it finds the collision for the same Prefix SID label index, it would fallback to dynamic label. This collision most likely will continue in other downstream BGP routers and based on the current mechanism, all of them would be using dynamic label. This is not a desired behavior. The same behavior could happen for out of SRGB range SID label index.
This draft proposes a mechanism to notify the BGP originator if the advertised prefix SID label index is in collision with another prefix SID label index or if the advertised prefix SID label index is no longer able to produce local SR index as the local SRGB range is fully used. The current Prefix SID Label Index collision or out of SRGB range notification to the originator can be handled with the newly introduced BGP feedback mechanism.
As soon as the downstream BGP router detects the collision on the label index or finds that the label index is outside the SRGB range, it can inform the originating BGP router that Label Index collision detected. The BGP originator once received the Label Index collision or out of range feedback message it would process and notify user through some log messages. The originator BGP router can optionally resolve the collision by allocating a new Label Index and advertise the new label index TLV to its downstream BGP peers.
+---+ +---+
Lo0=1.1.1.1/32, Lo0=2.2.2.2/32,
Label Index = 100 | A | | B | Label Index = 100
+---+ +---+
1.1.1.1/32->A \ / 2.2.2.2/32->B
Label Index = 100 \ / Label Index = 100
+---+
| C | SRGB Config: [30000, 40000]
+---+ SR Index=30100 (In Collision)
|
|
+---+
| D | SRGB Config: [60000, 70000]
+---+ SR Index=60100 (In Collision)
In the above SR flow, note that A and B are the two BGP originator for the prefixes 1.1.1.1/32 and 2.2.2.2/32 respectively. C is the first BGP downstream router connected to both A and B and receives update from both A and B. C and D have local SRGB range configured [30000, 40000] and [60000, 70000] respectively.
In this use case C applies certain route map policy which prevents the prefix update from A to go to B and vice-versa. The other case is A applies certain route-map policy which prevents A to receive BGP prefix update from B and vice-versa.
In this flow C would be the first downstream router that would detect the SR label index collision. C would assign SR Index 30100 as it receives the prefix advertisement from either A or B with label index 100 for the first time. The next time prefix advertise comes with the same label index it would collide with the originally allocated SR Index and would allocate dynamic label. The same behavior would continue on D as well.
The draft [BGP Signaling of IPv6-SR VPN Networks] describes the BGP signaling of SRv6-VPN SID for the VPN route; it doesn’t describe the scenario when ingress PE can only support L3 MPLS based data plane or the local BGP policy prevent ingress PE to use SRv6-VPN Service. These can be referred as SRv6 VPN Service Migration. The BGP Feedback message described below handle the SRv6-VPN Service migration scenarios.
This draft defines a new BGP Message type called BGP Feedback Message which will carry the informational message back to the originator. It should carry the associated prefix and informational data.
Currently defined Notification message (BGP Message type 3) doesn’t suit for these cases as the Notification message BGP has to close the session.
The idea behind the Feedback message type is to provide the feedback to the BGP peers without having to close the BGP session. It would be processed hop by hop like update message. Upon receiving BGP Feedback message BGP node can decide if they want to take any action on it. But the Feedback message doesn't impose a mandate on a BGP node to take certain action. It is treated more of a passing information to the BGP peers. The BGP Feedback message would be a generic purpose message and could be used by for different use cases within BGP.
The SR Prefix SID Collision and Out of range Notification mechanisms are some of the use cases where BGP Feedback message could be used.
The Migration case from L3 MPLS based Segment Routing to SRv6 Segment Routing is another use case of the Feedback message.
To advertise the BGP Feedback Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement [BGP-CAP]. This capability is advertised using the Capability code 74 and Capability length 0.
By advertising the BGP Feedback Capability to a peer, a BGP speaker conveys to the peer that the speaker is capable of receiving and properly handling the BGP Feedback message (as defined in Section 7) from the peer.
The BGP Feedback message is a new BGP message type defined as follows:
Type: 6 - BGP Feedback Message
The BGP Feedback Message Format:
+----------------------------------------- + | Prefix Length (1 octet) +----------------------------------------- + | Prefix (Variable) +----------------------------------------- + | Type (1 octet) +----------------------------------------- + | Length (1 octet) +----------------------------------------- + | Data (Variable) +----------------------------------------- +
Length: Length of the Feedback Message Data.
Data: BGP Feedback Message Data
The below format defines the Prefix SID Message to be used part of Data field in the BGP Feedback Message.
+----------------------------------------- + | Impact Type (1 octet) +----------------------------------------- + | Impact Value (1 octet) +----------------------------------------- + | Number of Labels (1 octet) +----------------------------------------- + | Label Index (variable) +----------------------------------------- +
Impact Type: Collision or SRGB Outside Range
Impact Value: Impacted or Resolved.
Number of Labels: The number of labels associated with the Prefix that got impacted. It would be 1 in the current case. But in future if more labels get advertised with the route this option will address it.
Label Index: Actual Indexes which are all impacted or impact resolved.
This new Feedback mechanism is defined to notify the BGP originator if the BGP advertised prefix with the SID label index is in collision with already used index in the network or if the assigned label index from the BGP originator is outside the SRGB range.
Once BGP originator gets the BGP feedback message it might provide collision or out of range SID index info in the log message or part of BGP show command. It could optionally assign a new label index with the prefix came under collision or out of range.
This specification doesn’t mandate action on the BGP originator. The BGP originator would decide on the action. This draft is defined only to define the mechanism on how to notify the BGP originator.
The BGP originator would be notified if the impacted SID index is no longer impacted as well. This scenario could happen through the route withdraw or SRGB range modification.
At Egress-PE:
If BGP offers a SRv6-VPN service Then BGP allocates an SRv6-VPN SID for the VPN service and adds the BGP SRv6-VPN SID TLV while advertising VPN prefixes.
If BGP offers an MPLS VPN service Then BGP allocates an MPLS Label for the VPN service and use it in NLRI as normal for MPLS L3 VPNs.
If BGP offers both SRv6-VPN and MPLS VPN service then BGP would advertise SRv6-VPN SID TLV and the NLRI with MPLS label for VPN service.
At Ingress-PE:
Selection of which encapsulation below (SRv6-VPN or MPLS-VPN) is defined by local BGP policy
If BGP supports SRv6-VPN service, and receives a BGP SRv6-VPN SID Attribute from the Egress PE with a SRv6 SID then BGP programs RIB to use SRv6 for the VPN prefix.
If BGP supports MPLS VPN service, and the MPLS Label is not Implicit-Null in the BGP update received from the Egress PE then BGP programs RIB to use the MPLS label is used as a VPN label for the VPN prefix.
Based on what is advertised from the Egress PE to the Ingress PE and what is actually supported in the Ingress PE the below two scenarios could occur:
- If Egress PE offers only SRv6-VPN SID TLV and Ingress PE only supports MPLS VPN service or local BGP policy imposes Ingress PE to use only MPLS VPN Service then Ingress PE needs to send the BGP Feedback Message to the Egress PE.
- If Egress PE offers only MPLS VPN Service and Ingress PE only supports SRv6-VPN service or local BGP policy imposes Ingress PE to use only SRv6-VPN VPN Service then Ingress PE needs to send the BGP Feedback Message to the Egress PE.
The below format defines the Segment Routing Migration Handling Message to be used part of Data field in the BGP Feedback Message.
+----------------------------------------- + | Received VPN Service (1 octet) +----------------------------------------- + | Imposed VPN Service (1 octet) +----------------------------------------- +
Received VPN Service: The VPN Service Received at the Ingress PE from the Egress PE
Imposed VPN Service: The Imposed VPN Service in the Ingress PE
This document introduces no new security considerations above and beyond those already specified in [RFC4271] and [RFC3107].
This document defines a new BGP Message Type known as the BGP Feedback Message and a new BGP Capability Code [BGP-CAP]. This document requests IANA to assign a new message type (suggested value: 6) for BGP the Feedback and a new BGP Capability Code (suggested value: 74) [BGP-CAP] for Feedback Message Handling capability from the BGP Message Type and Capability Code registry.
This document defines 2 new TLVs for BGP Feedback Message type. These TLVs needs to be registered with IANA. We request IANA to create a new registry for BGP Feedback TLVs as follows:
Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP Feedback TLV Types" (Reference: this document) should follow the below Registration Procedure(s): Values 1-254 First Come, First Served, Value 0 and 255 reserved
Value Type Reference
0 Reserved this document
1 SR Label Index Message this document
2 SRv6 Migration Message this document
3-254 Unassigned
255 Reserved this document
| [I-D.ietf-idr-bgp-prefix-sid] | Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A. and H. Gredler, "Segment Routing Prefix SID extensions for BGP", Internet-Draft draft-ietf-idr-bgp-prefix-sid-05, April 2017. |
| [I-D.ietf-spring-conflict-resolution] | Ginsberg, L., Psenak, P., Previdi, S. and M. Pilka, "Segment Routing Conflict Resolution", Internet-Draft draft-ietf-spring-conflict-resolution-02, October 2016. |
| [I-D.ietf-spring-segment-routing] | Filsfils, C., Previdi, S., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", Internet-Draft draft-ietf-spring-segment-routing-11, February 2017. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4271] | Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006. |
| [RFC4659] | De Clercq, J., Ooms, D., Carugi, M. and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006. |
| [RFC5549] | Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, DOI 10.17487/RFC5549, May 2009. |