Internet DRAFT - draft-deevimajumdar-spring-bgp-feedback
draft-deevimajumdar-spring-bgp-feedback
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
Abstract
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.
Requirements Language
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].
Status of This Memo
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.
Majumdar & Deevi Expires October 23, 2017 [Page 1]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Segment Routing Prefix SID Issues . . . . . . . . . . . . . . 3
3. Prefix SID Label Index Collision Traffic flow . . . . . . . . 4
4. Segment Routing SRv6-VPN Migration Issues . . . . . . . . . . 5
5. BGP Feedback Mechanism . . . . . . . . . . . . . . . . . . . 5
6. BGP Feedback Capability . . . . . . . . . . . . . . . . . . . 6
7. BGP Feedback Message Format . . . . . . . . . . . . . . . . . 6
8. BGP Feedback Message Prefix SID Data . . . . . . . . . . . . 7
9. Prefix SID Index Feedback Mechanism Summary . . . . . . . . . 7
10. The Migration from L3 MPLS to SRv6 SR . . . . . . . . . . . . 8
11. BGP Feedback Message SR Migration Handling Data . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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.
Majumdar & Deevi Expires October 23, 2017 [Page 2]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
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.
2. Segment Routing Prefix SID Issues
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
Majumdar & Deevi Expires October 23, 2017 [Page 3]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
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.
3. Prefix SID Label Index Collision Traffic flow
+---+ +---+
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.
Majumdar & Deevi Expires October 23, 2017 [Page 4]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
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.
4. Segment Routing SRv6-VPN Migration Issues
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.
5. BGP Feedback Mechanism
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.
Majumdar & Deevi Expires October 23, 2017 [Page 5]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
6. BGP Feedback Capability
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.
7. BGP Feedback Message Format
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)
+----------------------------------------- +
Prefix Length: Length of Prefix in octets
Prefix: Prefix associated with feedback message
Type: BGP Feedback message Type. It defines type of BGP application
associated with the message.
Type 1: SR Label Index
Type 2: SRv6 Migration
Length: Length of the Feedback Message Data.
Data: BGP Feedback Message Data
Majumdar & Deevi Expires October 23, 2017 [Page 6]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
8. BGP Feedback Message Prefix SID 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 Type 1: Segment Routing Label Index Collision
Impact Type 2: Segment Routing SRGB Outside Range
Impact Value: Impacted or Resolved.
Impact Value 1: Collision or SRGB range Impacted
Impact Value 2: Collision or SRGB range Impact 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.
9. Prefix SID Index Feedback Mechanism Summary
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.
Majumdar & Deevi Expires October 23, 2017 [Page 7]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
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.
10. The Migration from L3 MPLS to SRv6 SR
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
Majumdar & Deevi Expires October 23, 2017 [Page 8]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
use only SRv6-VPN VPN Service then Ingress PE needs to send the BGP
Feedback Message to the Egress PE.
11. BGP Feedback Message SR Migration Handling Data
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
Type 1: L3 MPLS Segment Routing.
Type 2: IPv6 Segment Routing.
Type 3: Both L3 MPLS Segment Routing and IPv6 Segment Routing.
Imposed VPN Service: The Imposed VPN Service in the Ingress PE
Type 1: L3 MPLS Segment Routing.
Type 2: IPv6 Segment Routing.
12. Security Considerations
This document introduces no new security considerations above and
beyond those already specified in [RFC4271] and [RFC3107].
13. IANA Considerations
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:
Majumdar & Deevi Expires October 23, 2017 [Page 9]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
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
14. References
14.1. Normative References
[I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Yoyer, D., Nanduri, M., Lin,
S., bogdanov@google.com, b., Horneffer, M., Clad, F.,
Steinberg, D., Decraene, B., and S. Litkowski, "Segment
Routing Policy for Traffic Engineering", draft-filsfils-
spring-segment-routing-policy-00 (work in progress),
February 2017.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
Sharif, M., Ayyangar, A., Mynam, S., Bashandy, A., Raza,
K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network
Programming", draft-filsfils-spring-srv6-network-
programming-00 (work in progress), March 2017.
[I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-06 (work in progress), March 2017.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
Majumdar & Deevi Expires October 23, 2017 [Page 10]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>.
14.2. Informative References
[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", draft-ietf-idr-bgp-prefix-sid-05 (work in progress),
April 2017.
[I-D.ietf-spring-conflict-resolution]
Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
"Segment Routing Conflict Resolution", draft-ietf-spring-
conflict-resolution-02 (work in progress), October 2016.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-11 (work in progress), 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,
<http://www.rfc-editor.org/info/rfc2119>.
Majumdar & Deevi Expires October 23, 2017 [Page 11]
Internet-Draft BGP Feedback Message In Segment Routing April 2017
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[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,
<http://www.rfc-editor.org/info/rfc4659>.
[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,
<http://www.rfc-editor.org/info/rfc5549>.
Authors' Addresses
Kausik Majumdar
Cisco Systems
821 Alder Drive
Milpitas, CA 95054
USA
Email: kmajumda@cisco.com
Krishna Deevi
Cisco Systems
821 Alder Drive
Milpitas, CA 95054
USA
Email: kdeevi@cisco.com
Majumdar & Deevi Expires October 23, 2017 [Page 12]
