Skip to main content

Segment Routing Prefix SID extensions for BGP
draft-keyupate-idr-bgp-prefix-sid-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Keyur Patel , Saikat Ray , Stefano Previdi , Clarence Filsfils
Last updated 2014-10-25
Replaced by draft-ietf-idr-bgp-prefix-sid, RFC 8669
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-keyupate-idr-bgp-prefix-sid-00
IDR                                                             K. Patel
Internet-Draft                                                    S. Ray
Intended status: Standards Track                              S. Previdi
Expires: April 28, 2015                                      C. Filsfils
                                                           Cisco Systems
                                                        October 25, 2014

             Segment Routing Prefix SID extensions for BGP
                  draft-keyupate-idr-bgp-prefix-sid-00

Abstract

   Segment Routing (SR) architecture allows a node to steer a packet
   flow through any topological path and service chain by leveraging
   source routing.  The ingress node prepends a SR header to a packet
   containing a set of "segments".  Each segment represents a
   topological or a service-based instruction.  Per-flow state is
   maintained only at the ingress node of the SR domain.

   The Segment Routing architecture can be implemented using MPLS with
   no changes to the forwarding plane.  It requires minor extensions to
   the existing routing protocols.

   This document describes the BGP extension for announcing BGP Prefix
   Segment Identifier (BGP Prefix SID) information.

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 RFC 2119 [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."

Patel, et al.            Expires April 28, 2015                 [Page 1]
Internet-Draft                                              October 2014

   This Internet-Draft will expire on April 28, 2015.

Copyright Notice

   Copyright (c) 2014 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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Segment Routing Documents . . . . . . . . . . . . . . . . . .   3
   4.  BGP-Prefix-SID  . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  BGP-Prefix-SID Label Index Attribute  . . . . . . . . . . . .   4
   6.  Receiving BGP-Prefix-SID Label Index Attribute  . . . . . . .   5
   7.  Announcing BGP-Prefix-SID Label Index Attribute . . . . . . .   5
   8.  Error Handling of BGP-Prefix-SID Label Index Attribute  . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   12. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     13.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     13.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Segment Routing (SR) architecture leverages the source routing
   paradigm.  A group of inter-connected nodes that use SR forms a SR
   domain.  The ingress node of the SR domain prepends a SR header
   containing "segments" to an incoming packet.  Each segment represents
   a topological instruction (such as "go to prefix P following shortest
   path") or a service instruction ("pass through deep packet
   inspection").  By inserting the desired sequence of instructions, the
   ingress node is able to steer a packet via any topological path and/
   or service chain; per-flow state is maintained only at the ingress
   node of the SR domain.

Patel, et al.            Expires April 28, 2015                 [Page 2]
Internet-Draft                                              October 2014

   Each segment is identified by a Segment Identifier (SID).  By using
   MPLS labels as SIDs, the SR architecture can be implemented using the
   existing MPLS dataplane.

   A BGP-Prefix Segment (aka BGP-Prefix-SID), is a BGP segment attached
   to a BGP prefix.  A BGP-Prefix-SID is always global within the SR/BGP
   domain and identifies an instruction to forward the packet over the
   ECMP-aware best-path computed by BGP to the related prefix.  The BGP-
   Prefix-SID is the identifier of the BGP prefix segment.

   This document describes the BGP extension to signal the BGP-Prefix-
   SID.  Specifically, this document defines a new BGP attribute known
   as BGP Label index attribute (carrying the BGP Prefix SID) and
   specifies the rules to originate, receive and handle error conditions
   of the new attribute.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
   be interpreted as described in [RFC2119] only when they appear in all
   upper case.  They may also appear in lower or mixed case as English
   words, without any normative meaning.

3.  Segment Routing Documents

   The main reference for this document is the SR architecture defined
   in [I-D.filsfils-spring-segment-routing].

   The Segment Routing Egress Peer Engineering architecture is described
   in [I-D.filsfils-spring-segment-routing-central-epe].

   The Segment Routing Egress Peer Engineering BGPLS extensions are
   described in [I-D.previdi-idr-bgpls-segment-routing-epe].

   A practical use case of the BGP Prefix SID is illustrated in
   [I-D.filsfils-spring-segment-routing-msdc].

4.  BGP-Prefix-SID

   The BGP-Prefix-SID attached to a BGP prefix P represents the
   instruction "go to Prefix P" along its BGP bestpath (potentially
   ECMP-enabled).  This Segment is realized on a MPLS dataplane in the
   following way:

      According to [I-D.filsfils-spring-segment-routing], each BGP
      speaker is configured with a label block called Segment Routing

Patel, et al.            Expires April 28, 2015                 [Page 3]
Internet-Draft                                              October 2014

      Global Block (SRGB).  The SRGB could be different on different
      speakers.

      The operator assigns a globally unique "index", L_I, to a locally
      sourced prefix of a BGP speaker N which is advertised to all other
      BGP speakers in the SR domain.

      The index L_I is a 32 bit offset in the SRGB.  Each BGP speaker
      derives its local MPLS label, L, by adding L_I to the start value
      of its own SRGB, and programs L in its MPLS dataplane as its
      incoming/local label for the prefix.

      If the BGP speakers are configured with the same SRGB start value,
      they will all program the same MPLS label value for a given prefix
      P.  This has the effect of having a single label value for prefix
      P across all BGP speakers despite the MPLS paradigm of "local
      label" is preserved.

   In order to advertise the SRGB label index of a given prefix P, a new
   extension to BGP is needed.  This extension is described in
   subsequent sections.

5.  BGP-Prefix-SID Label Index Attribute

   BGP Prefix Label Index is a new optional, transitive BGP path
   attribute.  The attribute type code for BGP Label Index attribute is
   to be assigned by IANA.  The value field of the Label Index attribute
   has following format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           RESERVED            |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Label Index                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   o  RESERVED: 16 bit field.  SHOULD be unset on transmission and MUST
      be ignored on reception.

   o  Flags: 16 bits of flags.  None are defined in this document.
      Flags SHOULD be unset on transmission an MUST be ignored at
      reception.

   o  Label Index: 32 bit value representing the index value in the SRGB
      space.

Patel, et al.            Expires April 28, 2015                 [Page 4]
Internet-Draft                                              October 2014

   Using the BGP protocol Label index as an offset, a label value for a
   given prefix is computed from a BGP SRGB.  The BGP SRGB protocol
   label block is configured explicitly on each BGP Speaker enabled with
   BGP-Prefix-SID extensions.

6.  Receiving BGP-Prefix-SID Label Index Attribute

   It is assumed that a BGP speaker is configured with an SRGB=[GB_S,
   GB_E].  Given a label index L_I, we call L = L_I + GB_S as the
   derived label.  A BGP Label Index attribute is called "unacceptable"
   for a speaker M if the derived label value L lies outside the SRGB
   configured on M.  Otherwise the Label Index attribute is called
   "acceptable" to speaker M.

   When a BGP speaker receives a path from a neighbor with an acceptable
   BGP Label Index attribute, it SHOULD program the derived label as the
   local label for the prefix in its MPLS dataplane.  In case of any
   error, a BGP speaker MUST resort to the error handling rules
   specified in the later section of the document.  A BGP speaker MAY
   log an error for further analysis.

   When a BGP speaker receives a path from a neighbor with an
   unacceptable BGP Label Index attribute, for the purpose of label
   allocation, it SHOULD treat the path as if it came without a Label
   Index attribute.  A BGP speaker MAY choose to assign a local (also
   called dynamic) label (non-SRGB) for such a prefix.  A BGP speaker
   MAY log an error for further analysis.

   A BGP speaker receiving a BGP Label index attribute from its EBGP
   neighbor SHOULD discard the attribute unless it is configured to
   accept the attribute from the EBGP neighbor.  A BGP speaker MAY log
   an error when discarding an attribute for further analysis.

   A BGP speaker receiving a prefix with a Label index attribute and a
   label NLRI field of implicit-null from a neighbor MUST adhere to
   standard behavior and program its MPLS dataplane to pop the top label
   when forwarding traffic to the prefix.The label NLRI defines the
   outbound label that MUST be used by the receiving node.  The Label
   Index gives a hint to the receiving node on which local/incoming
   label he SHOULD use.

7.  Announcing BGP-Prefix-SID Label Index Attribute

   A BGP speaker that originates a prefix attaches the Label Index
   attribute when it advertises the prefix to its neighbors.  The value
   of the Label Index is determined by configuration.

Patel, et al.            Expires April 28, 2015                 [Page 5]
Internet-Draft                                              October 2014

   A BGP speaker that advertises a path received from one of its
   neighbors SHOULD advertise the Label Index received with the path
   without modification regardless of whether the Label Index was
   acceptable.  If the path did not come with a Label Index attribute,
   the speaker MAY attach a Label Index to the path if configured to do
   so.  The value of the Label Index is determined by the configuration.

   In all cases, the label field of the NLRI ([RFC3107], [RFC4364]) MUST
   be set to the label programmed in the MPLS dataplane for the given
   prefix.  If the prefix is that of a local interface of the speaker,
   this label is the usual MPLS label (such as implicit or explicit NULL
   label).

   The BGP Label Index attribute SHOULD only be announced with BGP
   Prefixes carried in a labeled address-family (SAFI value 4 or SAFI
   value 128).  Since the BGP Label index value must be unique within an
   SR domain, by default an implementation SHOULD NOT advertise the BGP
   Label Index attribute outside an Autonomous System unless it is
   explicitly configured to do so.  To contain distribution of the BGP
   Label Index attribute beyond its intended scope of applicability,
   attribute filtering MAY be deployed.

8.  Error Handling of BGP-Prefix-SID Label Index Attribute

   When a BGP Speaker receives a BGP Update message containing more than
   one, or a malformed BGP Label Index attribute, it MUST ignore the
   received BGP Label Index attributes and not pass it to other BGP
   peers.  (see [I-D.ietf-idr-error-handling], Section 7).  This is
   equivalent to the -attribute discard- action specified in
   [[I-D.ietf-idr-error-handling].  A BGP speaker MAY log an error when
   discarding an attribute for further analysis.

   When a BGP Speaker receives a BGP Label Index attribute that is
   attached to prefixes belonging to SAFI value other than 4 or 128, it
   MUST quietly ignore the received attribute and not pass it to other
   BGP peers.  A BGP speaker MAY log an error for further analysis.

   When a BGP speaker receives an unacceptable Label Index attribute, it
   MAY log an error for further analysis.

9.  IANA Considerations

   This document defines a new BGP attribute known as BGP Label Index
   attribute.  This document requests IANA to assign a new attribute
   code type for BGP Label Index attribute from the BGP Path Attributes
   registry.

Patel, et al.            Expires April 28, 2015                 [Page 6]
Internet-Draft                                              October 2014

10.  Security Considerations

   This document introduces no new security considerations above and
   beyond those already specified in [RFC4271] and [RFC3107].

11.  Acknowledgements

   TBD

12.  Change Log

   Initial Version:  Sep 21 2014

13.  References

13.1.  Normative References

   [I-D.ietf-idr-error-handling]
              Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
              "Revised Error Handling for BGP UPDATE Messages", draft-
              ietf-idr-error-handling-14 (work in progress), September
              2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

13.2.  Informative References

   [I-D.filsfils-spring-segment-routing]
              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
              Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
              Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
              "Segment Routing Architecture", draft-filsfils-spring-
              segment-routing-04 (work in progress), July 2014.

Patel, et al.            Expires April 28, 2015                 [Page 7]
Internet-Draft                                              October 2014

   [I-D.filsfils-spring-segment-routing-central-epe]
              Filsfils, C., Previdi, S., Patel, K., Aries, E.,
              shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment
              Routing Centralized Egress Peer Engineering", draft-
              filsfils-spring-segment-routing-central-epe-02 (work in
              progress), July 2014.

   [I-D.filsfils-spring-segment-routing-msdc]
              Filsfils, C., "BGP-Prefix Segment in large-scale data
              centers", 2014.

   [I-D.previdi-idr-bgpls-segment-routing-epe]
              Previdi, S., Filsfils, C., Ray, S., and K. Patel, "Segment
              Routing Egress Peer Engineering BGPLS Extensions", draft-
              previdi-idr-bgpls-segment-routing-epe-00 (work in
              progress), May 2014.

Authors' Addresses

   Keyur Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95124  95134
   USA

   Email: keyupate@cisco.com

   Saikat Ray
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95124  95134
   USA

   Email: sairay@cisco.com

   Stefano Previdi
   Cisco Systems
   Via Del Serafico, 200
   Rome  00142
   Italy

   Email: sprevidi@cisco.com

Patel, et al.            Expires April 28, 2015                 [Page 8]
Internet-Draft                                              October 2014

   Clarence Filsfils
   Cisco Systems
   Brussels
   Belgium

   Email: cfilsfils@cisco.com

Patel, et al.            Expires April 28, 2015                 [Page 9]