| Network Working Group | N. Wu |
| Internet-Draft | Z. Zhuang |
| Intended status: Standards Track | Huawei |
| Expires: April 21, 2016 | October 19, 2015 |
BGP Extensions for Segment Allocation
draft-wu-idr-bgp-segment-allocation-ext-00
This document defines extensions to the BGP-LS to distribute/push the segment information to its administrative SR domain and describes some use cases.
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].
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 April 21, 2016.
Copyright (c) 2015 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.
In those networks with a central controller, it may be beneficial to allocate and manage SIDs for the network since the controller has the whole link-state database in mind. This document proposes BGP extensions to allocate SIDs in a centralized manner instead of distribution way.
It is possible that BGP may be the only routing protocol in some networks, such as the one described in [I-D.ietf-rtgwg-bgp-routing-large-dc]. If Segment Routing [I-D.ietf-spring-segment-routing] is going to be used for in the dataplane, it will be better to allocate SIDs in a centralized manner since no IGP flooding mechanism to advertise now.
In order to allocating SIDs, the centralized allocator SHOULD collect BGP network topology database ahead, which at least consists of BGP speakers, prefixes and adjacencies among them. No concrete technique for collecting this database has been specified in this document.
In the scenario SR & LDP interoperation described in [I-D.ietf-spring-segment-routing-ldp-interop], if mapping entries are allocated in a centralized manner, e.g. a controller, it is possible that Binding SIDs will be populated to a designated SRMS through a protocol instead of IGP, no matter whether the SRMS is a dedicated server or function module.
This section defines a new Protocol-ID called as BGP-Segment-Allocation (TBA) in the BGP-LS specification. The use of a new Protocol-ID allows separation and differentiation between the NLRIs carrying Segment Allocation information from the NLRIs carrying IGP link-state information as defined in [I-D.ietf-idr-ls-distribution].
This section describes the Node NLRI used for allocating the Node-SID. The Node NLRI Type uses descriptors and attributes already defined in [I-D.ietf-idr-ls-distribution]. The format of the Node NLRI Type is as follows:
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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This NLRI MAY contain BGP-LS-SR TLV 1033 (SID/Label Binding) as its attribute.
This section describes the Link NLRI used for allocating the Adj-SID. The format of the Link NLRI Type is as follows:
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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Link Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Following TLV will be used in Link Attribute:
This section describes the Prefix NLRI used for Allocating the Prefix-SID. The format of the Link NLRI Type is as follows:
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 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Prefix Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Following TLV will be used in Prefix Attribute:
As shown below, we assume:
Each node is its own AS (Node X has AS X). The loopback of Node X is 1.1.1.x/32.
Each node peers with its neighbors via BGP session.
Each node peers with Controller via BGP session.
Local BGP-LS Identifier in Node X is set to X0000.
/----------\
| |
| Controller |
| |
\----------/
|
+-----------------------+-------------------------------+
| | |
| +------+ | +------+ |
| | N7 |-+-| N8 | Tier-1 |
| +------+ +------+ |
| | | | | |
| +---------+ | | +----------+ |
| | +-------+--+-------+--+-------+ | |
| | | | | | | | | |
| +----+ +----+ +----+ +----+ |
| | N3 |-----| N4 | | N5 |-----| N6 | Tier-2 |
| +----+ +----+ +----+ +----+ |
| | | | | |
| | +-----+ | | +-----+ | |
| +-| N1 |-+ +-| N2 |-+ Tier-3 |
| +-----+ +-----+ |
| | | | | | | |
| <- Servers -> <- Servers -> |
+-------------------------------------------------------+
When the controller has collected the topology information of this BGP network, it can start segment allocation to the network.
A Node-SID represents a Node and has a global significance, something like a loopback of a router. Like an operator assigns a loopback's to their routers, it's expected that the Node-SID value will be assigned to every node. The assigned value can be an absolute or Index value and must be globally unique. In order to push a Node-SID for a router(e.g., N7), Controller advertise a Prefix NLRI to all the routers of the BGP-SR Network, where:
In order to push a Adj-SID for a router(e.g., N7 connects to N8), Controller advertise a Link NLRI to all the routers of the BGP-SR Network, where:
In the similar way, the controller can distribute Peer-Adj-SID and Peer-Set-SID.
In IGP networks deployed with SR, the method defined in [I-D.ietf-idr-ls-distribution] to populate the topology database and the SRGB to the controller.
A controller may use the extensions defined in this document to populate mapping entries to the SRMS. Then the SRMS will advertise this mapping to all the SR Nodes via IGP.
In the following figure, LSR1-10 and LSR20 are only running LDP and R21-to-R25 Routers are SR capable Routers. R21 and R22 will be running both SR and LDP as they are on the border between SR and LDP. The whole network is running single IGP let's say IS-IS.
/----------\
| |
| Controller |
| |
\----------/
/ \
/ \
+----------------------------+----------/-------\---------------+
| LDP Domain | /SR Domain\ |
| | / \ |
| ------ ------- / ------ \ --------- |
| |LSR1|\ | R21 |---+----| R23|\----\|Mapping| |
| ------ \ /-------\ / ------\ |Server | |
| 10.1.1.1\ / 20.1.1.1\ / 20.1.1.3\ --------+ |
| \ / | \ / \ 30.1.1.1 |
| ------ \ ------- / | \/ \ ------ |
| |LSR2|-----\|LSR20|/ | /\ \| R25| |
| ------ / -------\ | / \ /------ |
| 10.1.1.2 / 10.1.1.20\ | / \ / 20.1.1.5 |
| ... / \ | / \ / |
| ------ / \-------/ \------ / |
||LSR10|/ | R22 |----------|R24 |/ |
| ------ ------- ------ |
| 10.1.1.10 20.1.1.2 20.1.1.4 |
| | |
| | |
+----------------------------+----------------------------------+
The Node-SIDs and their corresponding label value mapping could be like this:
Prefix Index Value Range ------------------------------------ 10.1.1.1/32 1001 10 10.1.1.20/32 1020 1 20.1.1.1/32 2001 5
Mapping Server will convert BGP-LS-SR TLV-1033 to IS-IS TLV-149, and advertise this mapping to all the SR Nodes via IS-IS.
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 |0|0| | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 10 | /32 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .1 | .1 | .1 |Prefix-SID Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Length| Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |0|0| | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 1 | /32 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .1 | .1 | .20 |Prefix-SID Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Length| Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |0|0| | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range = 5 | /32 | 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .1 | .1 | .1 |Prefix-SID Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Length| Flags | Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[I-D.ietf-isis-segment-routing-extensions].
TBD.
TBD.
TBD.
| [I-D.ietf-idr-ls-distribution] | Gredler, H., Medved, J., Previdi, S., Farrel, A. and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Internet-Draft draft-ietf-idr-ls-distribution-13, October 2015. |
| [I-D.ietf-isis-segment-routing-extensions] | Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B. and J. Tantsura, "IS-IS Extensions for Segment Routing", Internet-Draft draft-ietf-isis-segment-routing-extensions-05, June 2015. |
| [I-D.ietf-rtgwg-bgp-routing-large-dc] | Lapukhov, P., Premji, A. and J. Mitchell, "Use of BGP for routing in large-scale data centers", Internet-Draft draft-ietf-rtgwg-bgp-routing-large-dc-07, August 2015. |
| [I-D.ietf-spring-segment-routing] | Filsfils, C., Previdi, S., Decraene, B., Litkowski, S. and r. rjs@rob.sh, "Segment Routing Architecture", Internet-Draft draft-ietf-spring-segment-routing-06, October 2015. |
| [I-D.ietf-spring-segment-routing-ldp-interop] | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B. and S. Litkowski, "Segment Routing interoperability with LDP", Internet-Draft draft-ietf-spring-segment-routing-ldp-interop-00, October 2015. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [I-D.gredler-idr-bgp-ls-segment-routing-extension] | Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M. and J. Tantsura, "BGP Link-State extensions for Segment Routing", Internet-Draft draft-gredler-idr-bgp-ls-segment-routing-extension-02, October 2014. |
| [I-D.ietf-idr-bgpls-segment-routing-epe] | Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J. and M. Chen, "Segment Routing Egress Peer Engineering BGP-LS Extensions", Internet-Draft draft-ietf-idr-bgpls-segment-routing-epe-00, June 2015. |