Network Working Group Z. Li
Internet-Draft Li
Intended status: Standards Track Huawei
Expires: January 9, 2020 July 08, 2019
BGP Request for Advertising Candidate Path of Segment Routing TE
Policies
draft-li-ldr-bgp-request-cp-sr-te-policy-00
Abstract
An SR Policy is a set of candidate paths. The headend of an SR
Policy may learn multiple candidate paths for an SR Policy via a
number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.
BGP distribute candidate paths has been defined in
[I-D.ietf-idr-segment-routing-te-policy]. This document defines an
extension of BGP to request BGP speaker(controller) advertise the
candidate paths. The goal is to unify the protocol when the
candidate path of SR Policy provision is via BGP to reduce the
network complexity and potential bugs cause by different protocol
interactions.
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 https://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 January 9, 2020.
Li & Li Expires January 9, 2020 [Page 1]
Internet-Draft BGP Trigger SR TE Policies July 2019
Copyright Notice
Copyright (c) 2019 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
(https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of BGP UPDATE Message for Request SR TE policy
candidate path advertising . . . . . . . . . . . . . . . . . 3
4. BGP request UPDATE Message Encoding . . . . . . . . . . . . . 4
4.1. Extention of SR Policy NLRI . . . . . . . . . . . . . . . 4
4.2. New SR Policy and Tunnel Encapsulation Attribute . . . . 5
4.3. New SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . 5
4.3.1. LSPA Sub-TLV . . . . . . . . . . . . . . . . . . . . 5
4.3.2. SVEC Sub-TLV . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 8
4.3.4. Include Route Sub-TLV . . . . . . . . . . . . . . . . 9
4.3.5. Load-Balancing Sub-TLV . . . . . . . . . . . . . . . 10
5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
An SR Policy defined in [I-D.ietf-spring-segment-routing-policy] is a
set of candidate paths. The headend of an SR Policy may be informed
by various means including: Configuration, PCEP[RFC8281] or
BGP[I-D.ietf-idr-segment-routing-te-policy] . All these mechanisms
are PCE/Controller initiated, but in some situations headend maybe
want pull one or a set of candidate paths from PCE/Controller rather
than get all information passively. Actually PCEP can use request
and reply messages defined in [RFC5440]to match this requirement but
the mechanism is not clear when controller advertise candidate path
via BGP protocol.
Li & Li Expires January 9, 2020 [Page 2]
Internet-Draft BGP Trigger SR TE Policies July 2019
This document wants to define a way to request controller(BGP
speaker) advertise candidate path via BGP update message to let BGP
protocol can also get the similar mechanism with request and reply
like PCEP.
2. Terminology
RP: Request Parameters
LSPA: LSP Attributes
SVEC: Synchronization VECtor
IRO: Include Route Object
ERO: Explicit Route Object
MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491]
NAI: Node or Adjacency Identifier
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: Path Computation Element Communication Protocol
SID: Segment Identifier
SR: Segment Routing
SR-TE: Segment Routing Traffic Engineering
3. Overview of BGP UPDATE Message for Request SR TE policy candidate
path advertising
[I-D.ietf-idr-segment-routing-te-policy] defined the headend get
candidate paths by BGP from controller(BGP speaker). In some
situations headend just want get these candidate paths when some
special event occur (e.g receive a customer route (VPN route) with
special color or special BGP attribute). This document define the
mechanism when this special situation occurred how the headend
request controller to advertise the matched SR policy with the
candidate paths.
Step1. The headend decide to get a new candidate path from
controller based on some trigger event. This trigger mechanism is
out of scope of this document.
Li & Li Expires January 9, 2020 [Page 3]
Internet-Draft BGP Trigger SR TE Policies July 2019
Step2. The headend create a new BGP request UPDATE message (defined
in this document) with constrains of TE, such as affinity, metric,
SRLG, and so on. This special request UPDATE message SHOULD NOT be
used for BGP best path selection.
Step3. The controller will calculate one or a set of segment list
based on the payload of BGP request message from headend. How to
calculate the path is out of scope of this document.
Step4. The controller advertise SR Policy with candidate path to
headend. How to advertise the policy is out of scope of this
document and defined in [I-D.ietf-idr-segment-routing-te-policy]
4. BGP request UPDATE Message Encoding
4.1. Extention of SR Policy NLRI
defined the SR Policy NLRI as follows:
+------------------+
| NLRI Length | 1 octet
+------------------+
| Distinguisher | 4 octets
+------------------+
| Policy Color | 4 octets
+------------------+
| Endpoint | 4 or 16 octets
+------------------+
where:
o NLRI Length: 1 octet of length expressed in bits as defined in
[RFC4760].
o Distinguisher: 4-octet value uniquely identifying the policy in
the context of <color, endpoint> tuple. The distinguisher has no
semantic value and is solely used by the SR Policy originator to
make unique (from an NLRI perspective) multiple occurrences of the
same SR Policy.
o Policy Color: 4-octet value identifying (with the endpoint) the
policy. The color is used to match the color of the destination
prefixes to steer traffic into the SR Policy
[I-D.ietf-spring-segment-routing-policy]
o Endpoint: identifies the endpoint of a policy. The Endpoint may
represent a single node or a set of nodes (e.g., an anycast
Li & Li Expires January 9, 2020 [Page 4]
Internet-Draft BGP Trigger SR TE Policies July 2019
address). The Endpoint is an IPv4 (4-octet) address or an IPv6
(16-octet) address according to the AFI of the NLRI.
NLRI Length, Policy Color, Endpoint field remains unchanged, while
the Distinguisher field will be set to FF:FF:FF:FF to signal the
request to controller.
4.2. New SR Policy and Tunnel Encapsulation Attribute
The content of the SR Policy is encoded in the Tunnel Encapsulation
Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a
new Tunnel-Type TLV (codepoint is 15, assigned by IANA. The SR
Policy Encoding structure is as follows:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy
<Sub-TLVs>
Preference, Binding SID, Priority, Policy Name, ENLP, Segment- List,
Weight and Segment sub-TLVs are all defined in
[I-D.ietf-idr-segment-routing-te-policy] for SR Policy advertise to
headend.
Additional 6 new Sub-TLVs are defined in this document section 3.3
for request mechanism.
1. LSPA Sub-TLV
2. SVEC Sub-TLV
3. Metric Sub-TLV
4. Include Route Sub-TLV
5. Load-Balancing
4.3. New SR Policy Sub-TLVs
4.3.1. LSPA Sub-TLV
The LSPA(LSP Attributes) Sub-TLV carries the same content as LSPA
Object defined in [RFC5440] and [RFC3209].
The LSPA Sub-TLV is optional and specifies various TE LSP attributes
to be taken for path computation. Most of the fields of the LSPA
Sub-TLV are identical to the fields of the SESSION-ATTRIBUTE object
Li & Li Expires January 9, 2020 [Page 5]
Internet-Draft BGP Trigger SR TE Policies July 2019
(C-Type = 7) defined in [RFC3209] . See Section 4.7.4 of [RFC3209]
for a detailed description of the use of resource affinities.
The LSPA sub-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Type: TBD1
o Length: specifies the length of the value field not including Type
and Length fields.
o Flags (8 bits)
* L flag: Corresponds to the "Local Protection Desired" bit
[RFC3209] of the SESSION-ATTRIBUTE Object. When set, this
means that the computed path must include links protected with
Fast Reroute as defined in [RFC4090].
* Reserved (8 bits): This field MUST be set to zero on
transmission and MUST be ignored on receipt.
* Unassigned flags MUST be set to zero on transmission and MUST
be ignored on receipt.
o Optional TLVs may be defined in the future to carry additional TE
LSP attributes such as those defined in [RFC5420]
o Exclude-any, Include-any, Include-all sub-TLV's format is the same
as subobjects defined in[RFC3209]
Li & Li Expires January 9, 2020 [Page 6]
Internet-Draft BGP Trigger SR TE Policies July 2019
4.3.2. SVEC Sub-TLV
The SVEC (Synchronization VECtor) Sub-TLV carries the same content as
SVEC Object defined in [RFC5440].
The SVEC Sub-TLV allows headend to request the synchronization of a
set of dependent or independent segment list computation requests.
It's optional be carried.
The SVEC sub-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Type: TBD2
o Length: the total length (not including the Type and Length
fields) of the sub-TLVs encoded
o Flags (24 bits): Defines the potential dependency between a set of
segment lists in one candidate path.
o
* L (Link diverse) bit: when set, this indicates that the
computed segment lists of the same candidate path MUST NOT have
any link in common.
* N (Node diverse) bit: when set, this indicates that the
computed segment lists of the same candidate path MUST NOT have
any node in common.
* S (SRLG diverse) bit: when set, this indicates that the
computed segment lists of the same candidate path MUST NOT
share any SRLG (Shared Risk Link Group).
In case of a set of segment lists synchronized independent path
computation, the bits L, N, and S are cleared.
Unassigned flags MUST be set to zero on transmission and MUST be
ignored on receipt.
Li & Li Expires January 9, 2020 [Page 7]
Internet-Draft BGP Trigger SR TE Policies July 2019
4.3.3. Metric Sub-TLV
The Metric Sub-TLV carries the same content as Metric Object defined
in[RFC5440] and [I-D.ietf-pce-segment-routing]. The Metric sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TBD3
o Length: specifies the length of the value field not including Type
and Length fields.
o Flags (8 bits): Two flags are currently defined:
* B (Bound - 1 bit): When set in a BGP UPDATE message, the
metric- value indicates a bound (a maximum) for the path metric
that must not be exceeded for the headend to consider the
computed path as acceptable. The path metric must be less than
or equal to the value specified in the metric-value field.
When the B flag is cleared, the metric-value field is not used
to reflect a bound constraint.
* C (Computed Metric - 1 bit): When set in a BGP UPDATE message,
this indicates that the controller MUST provide the computed
path metric value (should a path satisfying the constraints be
found) in the advertise message for the corresponding metric.
* Unassigned flags MUST be set to zero on transmission and MUST
be ignored on receipt.
o T (Type - 8 bits): Specifies the metric type
* Four values are currently defined:
* T=1: IGP metric
* T=2: TE metric
* T=3: Hop Counts
* T=11: Maximum SID Depth of the requested path
Li & Li Expires January 9, 2020 [Page 8]
Internet-Draft BGP Trigger SR TE Policies July 2019
o Metric-value (32 bits): metric value encoded in 32 bits in IEEE
floating point format (see [IEEE.754.1985]).
4.3.4. Include Route Sub-TLV
TheThe Include Route Sub-TLV is optional and can be used to specify
that the computed candidate path MUST traverse a set of specified
network elements. The Include Route Sub-TLV carries the same content
as IRO Object defined in[RFC5440], [RFC3209] and SR-ERO defiend in
[I-D.ietf-pce-segment-routing]
The Include Route Sub-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | NT | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SID (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ NAI (variable, optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: TBD4
o Length: specifies the length of the value field not including Type
and Length fields.
o NAI Type (NT): Indicates the type and format of the NAI contained
in the Sub-TLV body, if any is present then the NT field has no
meaning and MUST be ignored by the receiver. This document
describes the following NT values:
* NT=0 The NAI is absent.
* NT=1 The NAI is an IPv4 node ID.
* NT=2 The NAI is an IPv6 node ID.
* NT=3 The NAI is an IPv4 adjacency.
* NT=4 The NAI is an IPv6 adjacency with global IPv6 addresses.
* NT=5 The NAI is an unnumbered adjacency with IPv4 node IDs.
Li & Li Expires January 9, 2020 [Page 9]
Internet-Draft BGP Trigger SR TE Policies July 2019
* NT=6 The NAI is an IPv6 adjacency with link-local IPv6
addresses.
o SID and NAI are the same as SR-ERO defined in
[I-D.ietf-pce-segment-routing]
4.3.5. Load-Balancing Sub-TLV
The Load-Balancing Sub-TLV defined how many segment list should be
included in one candidate path. The Load-Balancing sub-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flag | Max-Slist |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Option TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: TBD5
o Length: specifies the length of the value field not including Type
and Length fields.
o Flags (8 bits):No flag is currently defined. The Flags field MUST
be set to zero on transmission and MUST be ignored on receipt.
o Max-Slist (8 bits): maximum number of S-Lists in the candidate
path.
o Option TLV: No Option TLV currently defined. If bandwidth can be
reserved in SR-Policy candidate path or different load-balancing
principle between segment lists for diferent weight here can
define additional TLVs.
5. IANA
This document defines new Sub-TLVs in following existing registries:
Li & Li Expires January 9, 2020 [Page 10]
Internet-Draft BGP Trigger SR TE Policies July 2019
+------------+-----------------------+---------------------------+
| Type Value | Sub-TLV | Description |
+----------------------------------------------------------------+
| TBD1 | LSA-Sub-TLV | This document |
+----------------------------------------------------------------+
| TBD2 | SVEC Sub-TLV | This document |
+----------------------------------------------------------------+
| TBD3 | Metric Sub-TLV | This document |
+----------------------------------------------------------------+
| TBD4 | Include Route Sub-TLV | This document |
+----------------------------------------------------------------+
| TBD5 | Load-Balancing | This document |
+------------+-----------------------+---------------------------+
6. Contributors
TBD
7. Acknowledgments
TBD
8. References
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain,
D., and S. Lin, "Advertising Segment Routing Policies in
BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in
progress), July 2019.
[I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The
BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
tunnel-encaps-12 (work in progress), May 2019.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-16 (work in progress),
March 2019.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019.
Li & Li Expires January 9, 2020 [Page 11]
Internet-Draft BGP Trigger SR TE Policies July 2019
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <https://www.rfc-editor.org/info/rfc5420>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
Authors' Addresses
Zhenbin Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: lizhenbin@huawei.com
Li & Li Expires January 9, 2020 [Page 12]
Internet-Draft BGP Trigger SR TE Policies July 2019
Lei Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: lily.lilei@huawei.com
Li & Li Expires January 9, 2020 [Page 13]