wdiff draft-dong-pce-discovery-proto-bgp-03.txt draft-dong-pce-discovery-proto-bgp-04.txt

Network Working Group J. Dong
Internet-Draft M. Chen
Intended status: Standards Track D. Dhody
Expires: March 4, September 10, 2016 Huawei Technologies
J. Tantsura
Ericsson
September 1, 2015
March 9, 2016

BGP Extensions for Path Computation Element (PCE) Discovery
draft-dong-pce-discovery-proto-bgp-03
draft-dong-pce-discovery-proto-bgp-04

Abstract

In networks where Path Computation Element (PCE) is used for
centralized path computation, it is desirable for the Path
Computation Clients (PCCs) to automatically discover a set of PCEs
and select the suitable ones to establish the PCEP session. RFC 5088
and RFC 5089 define the PCE discovery mechanisms based on Interior
Gateway Protocols (IGP). This document describes several scenarios
in which the IGP based PCE discovery mechanisms cannot be used
directly. This In such scenarios, BGP might be suitable, thus this
document specifies the BGP extensions for PCE discovery in these
scenarios. discovery. The BGP
based PCE discovery mechanism is complementary to the existing IGP
based mechanisms.

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 March 4, September 10, 2016.

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. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4
2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4
2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5
3. Operational Considerations . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 8

1. Introduction

In network scenarios where Path Computation Element (PCE) is used for
centralized path computation, it is desirable for the Path
Computation Clients (PCCs) to automatically discover a set of PCEs
and select the suitable ones to establish the PCEP session.
[RFC5088] and [RFC5089] define the PCE discovery mechanisms based on
Interior Gateway Protocols (IGP). Those

The IGP based mechanisms may not work in several
scenarios where discovery mechanism requires the PCEs do not PCE participate in the IGP, and it
IGP network, which usually requires that the PCE is
difficult for PCEs directly adjacent
to participate at least one of the IGP routers in multiple the network. In some scenarios
such requirement cannot be satisfied. For example, a PCE may need to
provide path computation service to some subsidiary networks of an
operator, which typically locate in different geographical region
(and not IGP domains where adjacent). Also when PCE function is implemented in a
central server running IGP on individual interfaces to each IGP area
can be cumbersome.

The requirement on PCE discovery, as described in [RFC4674], also
include the automatic discovery of the PCEs in other domains, as it
is needed.

In some scenarios, a desirable function in the case of inter-domain path computation.
The IGP based discovery mechanisms cannot meet such requirement.

For example, Backward Recursive Path Computation (BRPC) [RFC5441] can
be used by cooperating PCEs to compute inter-domain an inter-AS path, in which
case these cooperating PCEs should be known to each other in advance.
In this case of inter-AS networks where the PCEs belongs to different AS and do not participate
in a common IGP, the existing IGP based discovery mechanism
cannot be used to discover the PCEs in other domains.

In mechanisms are not
applicable.

Another example is the Hierarchical hierarchical PCE scenario [RFC6805], in which
the child PCEs need to know the address information of the parent PCEs. This
cannot be achieved through via IGP based discovery, as normally the child PCEs and the
parent PCE are under different administration and reside usually in different domains.

Besides, as

Since BGP could be used has been extended for north-bound distribution of routing
and Label Switched Path (LSP) information to PCE as described in
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-te-lsp-distribution] and
[I-D.ietf-idr-te-pm-bgp], PCEs can obtain the routing information
without participating in IGP. In this scenario, some other a new BGP based PCE
discovery mechanism is needed.

A detailed set of requirements for a PCE discovery mechanism are
provided in [RFC4674].

This document proposes to extend BGP for PCE discovery in the above
scenarios. In networks where BGP-LS is used for the north-bound
routing information distribution to PCE, the BGP based PCE discovery
can reuse make use of the existing BGP sessions and mechanisms to achieve
automatic PCE discovery. It should be noted that in each IGP domain, the Further IGP based
PCE discovery mechanism may be used in conjunction with the BGP based to redistribute
remote PCE discovery. information, the detailed mechanism is out of the scope of
this document. Thus the BGP based PCE discovery is complementary to
the existing IGP based mechanisms.

+-----------+
| PCE |
+-----------+
|
v
+-----------+
| BGP | +-----------+
| Speaker | | PCE |
+-----------+ +-----------+
| | | |
| | | |
+---------------+ | +-------------------+ |
v v v v
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
| & PCC | | & PCC | | & PCC |
+-----------+ +-----------+ +-----------+
|
| via
| IGP
v
+-----------+
| PCC |
+-----------+

Figure 1: BGP for PCE discovery

As shown in the network architecture in Figure 1, BGP is used for both
for routing information distribution and for PCE information
discovery. The routing information is collected from the network
elements and distributed to PCE, while the PCE discovery information
is advertised from PCE to PCCs, or between among different PCEs. The PCCs
maybe co-
located co-located with the BGP speakers as shown in Figure 1. The IGP based
PCE discovery mechanism may be used for the distribution of PCE
discovery information in IGP domain.

2. Carrying PCE Discovery Information in BGP

2.1. PCE Address Information

The PCE discovery information is advertised in BGP UPDATE messages
using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re-
used, and a new NLRI Type is defined for PCE discovery information as
below:

o Type = TBD: PCE Discovery NLRI

The format of PCE Discovery NLRI is shown in the following figure:

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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PCE-Address (4 or 16 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. PCE Discovery NLRI

The 'Protocol-ID' field SHOULD be set to a new the appropriate value which
indicates the information source protocol of the PCE discovery information. If BGP
speaker and PCE are co-located, the Protocol-ID SHOULD be set to
"Direct". In other cases, it is PCE.

+-------------+----------------------------------+
| RECOMMENDED that the Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+
| TBD | PCE |
+-------------+----------------------------------+
value be set to "Static configuration".

As defined in [I-D.ietf-idr-ls-distribution], the 64-Bit 'Identifier'
field is used to identify the "routing universe" where the PCE
belongs.

2.2. PCE Discovery TLVs

The detailed PCE discovery information is carried in the BGP-LS
attribute [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery
TLV", which contains a set of sub-TLVs for specific PCE discovery
information. The PCE Discovery TLV and sub-TLVs SHOULD only be used
with the PCE Discovery NLRI.

The format of the PCE Discovery TLV is shown as below:

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PCE Discovery Sub-TLVs (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. PCE Discovery TLV

The PCE Discovery sub-TLVs are listed as below. The format of the
PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs as
defined in [RFC5088] and [RFC5089]. The PATH-SCOPE sub-TLV MUST
always be carried in the PCE Discovery TLV. Other PCE Discovery sub-
TLVs are optional and may facilitate the PCE selection process on the
PCCs.

More PCE Discovery sub-TLVs may be defined in future and the future. The format and
semantic of new PCE Discovery sub-TLVs SHOULD be consistent in line with the new sub-TLVs defined for BGP
and IGP based PCE discovery.

3. Operational Considerations

Existing BGP operational procedures apply to the advertisement of PCE
discovery information. This information is treated as pure
application level data which has no immediate impact on forwarding
states. Normal BGP path selection can be applied to PCE Discovery
NLRI only for the information propagation in the network, while on
PCCs the PCE selection on the PCCs would be is based on the information carried in the PCE
Discovery TLV. The PCE discovery information SHOULD be advertised
only to the domains where such information is allowed to be used.
This can be achieved by policy control on the ASBRs.

The PCE discovery information is considered relatively stable and
does not change frequently, thus this information will not bring
significant impact on the amount of BGP updates in the network.

4. IANA Considerations

IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from
the "BGP-LS NLRI-Types" registry.

IANA needs to assign a new Protocol-ID for "PCE" from the "BGP-LS
Protocol-IDs" registry.

IANA needs to assign a new TLV code point for 'PCE Discovery TLV'
from the "node anchor, link descriptor and link attribute TLVs"
registry.

IANA needs to create a new registry for "PCE Discovery Sub-TLVs".
The registry will be initialized as shown in section 2.2 of this
document.

5. Security Considerations

Procedures and protocol extensions defined in this document do not
affect the BGP security model. See the 'Security Considerations'
section of [RFC4271] for a discussion of BGP security. Also refer to
[RFC4272] and [RFC6952] for analysis of security issues for BGP.

6. Acknowledgements

The authors would like to thank Zhenbin Li and Li, Hannes Gredler Gredler, Jan
Medved, Adrian Farrel and Julien Meuric for
their the valuable discussion
and comments.

7. References

7.1. Normative References

[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", draft-ietf-idr-ls-distribution-11 draft-ietf-idr-ls-distribution-13
(work in progress), June 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,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>.

[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
January 2008, <http://www.rfc-editor.org/info/rfc5088>.

[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
January 2008, <http://www.rfc-editor.org/info/rfc5089>.

7.2. Informative References

[I-D.ietf-idr-te-lsp-distribution]
Dong, J., Chen, M., Gredler, H., Previdi, S., and J.
Tantsura, "Distribution of MPLS Traffic Engineering (TE)
LSP State using BGP", draft-ietf-idr-te-lsp-
distribution-03
distribution-04 (work in progress), May December 2015.

[I-D.ietf-idr-te-pm-bgp]
Wu, Q., Previdi, S., Gredler, H., Ray, S., and J.
Tantsura, "BGP attribute for North-Bound Distribution of
Traffic Engineering (TE) performance Metrics", draft-ietf-
idr-te-pm-bgp-02 (work in progress), January 2015.

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>.

[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,
October 2006, <http://www.rfc-editor.org/info/rfc4674>.

[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.

[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.

[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<http://www.rfc-editor.org/info/rfc6952>.

Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China

Email: jie.dong@huawei.com

Mach(Guoyi) Chen
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China

Email: mach.chen@huawei.com

Dhruv Dhody
Huawei Technologies
Leela Palace
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560008 560066
India

Email: dhruv.ietf@gmail.com

Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
US

Email: jeff.tantsura@ericsson.com