Internet DRAFT - draft-zhang-idr-nexthop-path-attr
draft-zhang-idr-nexthop-path-attr
Network Working Group Z. Li
Internet-Draft L. Zhang
Intended status: Standards Track Huawei Technologies
Expires: July 20, 2014 January 16, 2014
NEXTHOP_PATH ATTIBUTE for BGP
draft-zhang-idr-nexthop-path-attr-01
Abstract
As the BGP is deployed in a single Autonomous System for network
convergence such as Seamless MPLS, it is desirable for BGP to carry
more information to help select routing more intelligently. It can
reduce the cost proposed by complex policy control design on BGP
routes and adapt to network change easily. This document proposed a
new path attribute for BGP routes that can record the next hop path
for the route to help BGP route selection and network management.
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."
This Internet-Draft will expire on July 20, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li & Zhang Expires July 20, 2014 [Page 1]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Complexity of Route Selection . . . . . . . . . . . . . . 3
2.2. New Role of BGP in Seamless MPLS Network . . . . . . . . 4
3. Definition of NEXTHOP_PATH ATTRIBUTE . . . . . . . . . . . . 4
4. Process of NEXTHOP_PATH ATTRIBUTE . . . . . . . . . . . . . . 5
4.1. Creating and Modifying the NEXTHOP_PATH Attribute . . . . 5
4.2. Decision Process . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[I-D.ietf-mpls-seamless-mpls] describes an architecture which can be
used to extend MPLS networks to integrate access and aggregation
networks into a single MPLS domain ("Seamless MPLS"). As the mobile
backhaul service is deployed widely, the requirement of the
integration of mobile backhaul networks and core networks has been
proposed. For the reason of scalability , the Seamless MPLS network
tends to be divided into multiple IGP areas for access, aggregation,
and core networks and IBGPs runs among Area Border Routers (ABRs)
which should act as inline RRs to reflect the labeled BGP routes or
BGP VPN routes to remote BGP peers with next hop self (NHS).
As the BGP is used in a single Autonomous System for network
convergence, it is desirable for BGP to carry more information to
help select routing more intelligently. It can reduce the cost
proposed by complex policy control design on BGP routes and adapt to
network change easily.
Li & Zhang Expires July 20, 2014 [Page 2]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
This document proposes a new path attribute that can record the next
hop path of the route to help BGP route election and network
management.
2. Motivation
2.1. Complexity of Route Selection
In the Seamless MPLS network, Area Border Routers (ABRs) which run
IBGP should act as inline RRs to reflect the labeled BGP routes or
BGP VPN routes to remote BGP peers with next hop self (NHS). Each
ABR should process route selection which needs complex route policy
to control the BGP route distribution in the Seamless MPLS network ,
as shown below:
Inline RR Inline RR Inline RR
+------+ +------+ +------+
/ |ABR-a |---------|ABR-b |--------|ABR-c |
/ +------+ +------+ +------+\
/ | | | \
+-----+/ | | | \
|PE1 | IGP area1 | IGP area2 | IGP area3 | IGP area4 \+-----+
+-----+\ | | | | PE2|
\ | | | /+-----+
\ +------+ +------+ +---- -+ /
\|ABR-a'|---------|ABR-b'|--------|ABR-c'| /
+------+ +------+ +---- -+/
Inline RR Inline RR Inline RR
Figure 1 Seamless MPLS Network with Multiple IGP Areas
Just like Figure 1 shown, PE1 and PE2 are BGP VPN service end-point.
IBGP peers runs contiguously between ABRs in different IGP areas, and
each ABR works as inline RR. When labeled BGP routes or BGP VPN
routes originated from PE1 is distributed to the other service end-
point PE2, the route can be reflected by the ABRs one by one with
next hop self (NHS).
The inline RR will distribute the route to all of the IBGP peers
except the IBGP peer from which the route was received. As a result,
an ABR may receive routes of the same prefix from different IBGP
peers with different next hop. Traditionally the BGP RR should
select the best route to reflect to other IBGP peers. But in this
network the route selection process will be more complex which needs
to introduce complex route policy.
Li & Zhang Expires July 20, 2014 [Page 3]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
Here is an example for complex route policy. ABR-b may receive
routes of the same prefix originated from PE1 from different three
IBGP peers, ABR-a, ABR-a', ABR-c, and ABR-c'. The route policy
should guarantee that the route from ABR-a or ABR-a' is selected as
the best one. At the same time, routes of the same prefix originated
from PE2 may be received from ABR-a, ABR-a', ABR-c, and ABR-c'. The
route policy should guarantee that the route from ABR-c or ABR-c' is
selected as the best one. To satisfy the different best route
selection requirements, each IBGP speaker has to configure complex
route policy.
2.2. New Role of BGP in Seamless MPLS Network
When Seamless MPLS makes integration of mobile backhaul networks and
core networks, BGP in Seamless MPLS network act more like an
"Interior Gateway Protocol (IGP)". As the whole Seamless MPLS
network is in a single AS for uniform administration, the security
requirement proposed for traditional BGP can be reduced. At the same
time some path attributes for BGP route such as AS_PATH is no use in
this scenario. As the BGP is deployed from implementing network
convergence, it is desirable for BGP to carry more information to
help select route more intelligently. It can simplify policy control
design on BGP routes and adapt to network change easily. Moreover
the additional path information may facilitate the network operation
and maintenance. [I-D.ietf-idr-aigp] is the example which can help
BGP route selection by advertising IGP metric information with BGP
route. In this document, we propose a new method to record next hop
list for the BGP route, which can be used for automatic BGP route
selection and facilitating network operation and maintenance. The
new attribute, NEXTHOP_PATH ATTRIBUTE, is defined for the BGP route
to record the next hop path. It can work as AS_PATH ATTRIBUTE.
3. Definition of NEXTHOP_PATH ATTRIBUTE
The NEXTHOP_PATH ATTRIBUTE is an optional transitive BGP Path
Attribute. The NEXTHOP_PATH ATTRIBUTE type is defined as below
(refer to [RFC4271]):
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr. Flags |Attr. Type Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 NEXTHOP_PATH ATTRIBUTE Type definition
Attr. Flags
Li & Zhang Expires July 20, 2014 [Page 4]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
SHOULD be optional transitive
Attr. Type Code
SHOULD be allocated by IANA
NEXTHOP_PATH is composed of a sequence of next hop path segments.
Each next hop path segment is represented by a triple <path segment
type, path segment length, path segment value>. The format of the
next hop path segmen is shown in the figure 3.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 NH_SEQUENCE_V4 TLV
- Type: A single octet encoding the TLV Type. The Type of
"NH_SEQUENCE_V4" is defined in this document, which needs to be
allocated by IANA. The procedure for next hop path segement usage
for IPv6 or other extensions will be described in the future version.
- Length: Two octets encoding the length in octets of the TLV,
including the type and length fields. The length is encoded as an
unsigned binary integer.
- Reserved: A single octet that must be zero now.
- NextHop: four octets encoding for the route next hop address.
4. Process of NEXTHOP_PATH ATTRIBUTE
The NEXTHOP_PATH ATTRIBUTE defined here is an optional transitive BGP
Path Attribute, the process of this attribute MUSTaccord with the
procedures in [RFC4271].
4.1. Creating and Modifying the NEXTHOP_PATH Attribute
When a BGP speaker distributes a route to its BGP peer within UPDATE
message, the NEXTHOP_PATH ATTRIBUTE should be processed based on
different route states:
1. If the route is originated in this BGP peaker
Li & Zhang Expires July 20, 2014 [Page 5]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
* If the NEXTHOP_PATH ATTRIBUTE is supported, the NEXTHOP_PATH
ATTRIBUTE SHOULD be originated including the BGP speaker's own
next hop address in a next hop path segment. In this case,
the next hop address of the originating BGP speaker will be
the only entry of the next hop path segment, and this path
segment will be the only segment in NEXTHOP_PATH ATTRIBUTE.
* If the NEXTHOP_PATH ATTRIBUTE is not supported, the route will
be distributed without NEXTHOP_PATH ATTRIBUTE.
2. if the route is received from one BGP speaker's UPDATE message
* If the NEXTHOP_PATH ATTRIBUTE is NULL and the local BGP
speaker support NEXTHOP_PATH ATTRIBUTE, when the route is
propagated to another IBGP speaker with next hop self (NHS ),
the NEXTHOP_PATH ATTRIBUTE SHOULD be originated including the
BGP speaker's own next hop address in a next hop path segment.
In this case, the next hop address of this BGP speaker will be
the only entry to the next hop path segment, and this path
segment will be the only segment in NEXTHOP_PATH ATTRIBUTE
* If the NEXTHOP_PATH ATTRIBUTE is non-NULL and the local BGP
speaker support NEXTHOP_PATH ATTRIBUTE, when the route is
propagated to another IBGP speaker with next hop self (NHS ),
the BGP speaker MUST appends its own next hop address as the
last one of the next hop path segments.
* If the NEXTHOP_PATH ATTRIBUTE is NULL and the local BGP
speaker support NEXTHOP_PATH ATTRIBUTE, when the route is
propagated to another BGP speaker without changing the next
hop by the BGP speaker, the BGP speaker MUST NOT originate the
NEXTHOP_PATH ATTRIBUTE.
* If the NEXTHOP_PATH ATTRIBUTE is non-NULL and the local BGP
speaker support NEXTHOP_PATH ATTRIBUTE, when the route is
propagated to another BGP speaker without changing the next
hop by the BGP speaker, the BGP speaker MUST NOT change the
next hop path sequence.
* If the BGP speaker does not support NEXTHOP_PATH ATTRIBUTE, it
SHOULD keep the NEXTHOP_PATH ATTRIBUTE unchanged whether the
route is distribute with next hop self or not.
4.2. Decision Process
Support for the NEXTHOP_PATH ATTRIBUTE involves several modifications
to the tie breaking procedures of the "phase 2" decision of BGP route
selection, described in section 9.1.2.2 of [RFC4271].
Li & Zhang Expires July 20, 2014 [Page 6]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
If the NEXTHOP_PATH ATTRIBUTE of a BGP route contains a next hop path
loop, the BGP route MUST be excluded from the Phase 2 decision
function. The next hop path loop detection is done by scanning the
full next hop path (as specified in the NEXTHOP_PATH ATTRIBUTE), and
checking if the local BGP speaker appears in the next hop path.
The NEXTHOP_PATH ATTRIBUTE can be used for BGP route selection. The
priority of the NEXTHOP_PATH ATTRIBUTE for route selection is the
same as the AS_PATH attribute.
When a route is received from different IBGP speakers, if the best
route cannot acquired through the higher priority rules, the
NEXTHOP_PATH ATTRIBUTE SHOULD be used for route selection, and the
route with least nexthops will be selected. If the lengths of the
next hop lists are the same, the rest rules SHOULD be used for route
selection.
5. IANA Considerations
IANA need to assign the codepoint in the "BGP Path Attributes"
registry to the NEXTHOP_PATH ATTRIBUTE.
IANA shall create a registry for "next hop path segment". The type
field consists of a single octet, with possible values from 0 to 255.
The allocation policy for this field is to be "Standards Action with
Early Allocation". A new Type should be defined as "NH_SEQUENCE_V4".
6. Security Considerations
Note that, the NEXTHOP_PATH ATTRIBUTE is defined as a optional
transitive BGP Path attribute. Both the IBGP and EBGP speaker can
use this attribute. When an ASBR propagates the route receive from a
IBGP peer to an EBGP peer, the NEXTHOP_PATH ATTRIBUTE will be
distribute to the EBGP Speaker which may be controlled by other
Service Provider. If the EBGP speaker can support the NEXTHOP_PATH
ATTRIBUTE, it can parse the NEXTHOP_PATH ATTRIBUTE to get the inner
network architecture of the other network.
In order to prevent this possible security problem, the NEXTHOP_PATH
ATTRIBUTE capability should be disabled for specific BGP speaker,
such as EBGP. This can reduce the security risk.
7. References
Li & Zhang Expires July 20, 2014 [Page 7]
Internet-Draft NEXTHOP_PATH ATTIBUTE for BGP January 2014
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
7.2. Informative References
[I-D.ietf-idr-aigp]
Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", draft-
ietf-idr-aigp-14 (work in progress), December 2013.
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-04 (work in progress), July 2013.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li Zhang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: monica.zhangli@huawei.com
Li & Zhang Expires July 20, 2014 [Page 8]
