A Framework for BGP Feedback Message In Segment RoutingCisco Systems821 Alder DriveMilpitasCA95054USAkmajumda@cisco.comCisco Systems821 Alder DriveMilpitasCA95054USAkdeevi@cisco.com
Routing
SPRING Working Group BGPcommunitiesIn 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 .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 issuesThis 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. 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 MessageThe BGP Feedback Message Format: Length of Prefix in octetsPrefix associated with feedback message BGP Feedback message Type. It defines type of BGP application associated with the message.SR Label IndexSRv6 Migration Length: Length of the Feedback Message Data.Data: BGP Feedback Message DataThe below format defines the Prefix SID Message to be used part of Data field in the BGP Feedback Message. Impact Type: Collision or SRGB Outside Range
Segment Routing Label Index CollisionSegment Routing SRGB Outside Range Impact Value: Impacted or Resolved.
Collision or SRGB range ImpactedCollision 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.
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: The VPN Service Received at the Ingress PE from the Egress PE
L3 MPLS Segment Routing.IPv6 Segment Routing. Both L3 MPLS Segment Routing and IPv6 Segment Routing. Imposed VPN Service: The Imposed VPN Service in the Ingress PE
L3 MPLS Segment Routing.IPv6 Segment Routing.
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