WDIFF

draft-vasseur-ccamp-ce-ce-te-00.txt --> draft-vasseur-ccamp-ce-ce-te-01.txt-19583.txt

Networking Working Group JP. Vasseur, Ed.
Internet-Draft Gargi. Nalawade
Expires: August 29, December 26, 2006 Cisco Systems, Inc
K. Kumaki
KDDI Corporation
February 25,
June 24, 2006

An MP-BGP protocol extension to advertize TE-related PE-CE link
information

draft-vasseur-ccamp-ce-ce-te-00
draft-vasseur-ccamp-ce-ce-te-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 29, December 26, 2006.

Abstract

This document proposes MP-BGP protocol extension so as to convey
Traffic Engineering Link characterictics of PE (Provider Edge) - CE
(Customer Edge) links in order to extend the visibility of the
Traffic Engineering Database to those links. This can then be used
to more efficiently compute CE-to-CE Traffic Engineering Label

Vasseur, et al. Expires August 29, December 26, 2006 [Page 1]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February draft-vasseur-ccamp-ce-ce-te-01 June 2006

Swtiched Path (TE LSP) when required to provide specific services
such as bandwidth guarantees and end to end fast protection. protection in a
Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)
environment.

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].

Table of Contents

1. Introduction Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
3. MP-BGP Protocol extensions . . . . . . . . . . . . . . . . . . 5 6
4. TED update . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Proposed Status and Discussion [To Be Removed
Upon Publication] . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10

Vasseur, et al. Expires August 29, December 26, 2006 [Page 2]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February draft-vasseur-ccamp-ce-ce-te-01 June 2006

1. Terminology

Terminology used in this document LSR: Label Switch Router.

BRPC: Backward Recursive Path Computation procedure.

CE: Customer Edge.

IGP Area: OSPF Area or IS-IS level.

Inter-domain TE LSP: A TE LSP whose path transits across at least two
different domains where a domain can either be an IGP area, an
Autonomous System or a sub-AS (BGP confederations).

NLRI: Network Layer Reachability Information.

PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.

PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.

PCEP: Path Computation Element Protocol.

PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the
PCE).

PE: Provider Edge.

RD: Route Distinguisher.

SAFI: Subsequence Address Family Identifier.

TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means.

TE LSP: Traffic Engineering Label Switched Path.

VSPT: Virtual Shortest Path Tree.

2. Introduction

IGP extensions have been defined for OSPF (see [[RFC3630]) and for
IS-IS (see [[RFC3784]) so as flood advertise Traffic Engineering link
characteristic
characteristics across an IGP area, which can then be used to compute
constrained

Vasseur, et al. Expires December 26, 2006 [Page 3]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006

MPLS Traffic Engineering Label Switched Path (TE LSP).

In MPLS VPN Multiprotocol Label Switching Virtual Private Network (MPLS VPN)
enabled networks ([[RFC4364]), IP connectivity is provided to
customers sites by means VPNs enabled across an MPLS VPN network.
Service Providers have been using constrained based routing using
MPLS Traffic Engineering in their MPLS core between Provider Edge
(PE) Label Switch Router (LSR) to carry the traffic between the PEs
more optimaly and also to provide fast traffic restoration using a
local protection techniques technique such as Fast Reroute ([[RFC4090]]).

In addition to IP connectivity services, Service Providers expressed
the requirements to also be able to provide other services to VPN
network based whereby where Customer Edge (CE) routers could be
interconnected via TE LSPs. This can be seen LSPs so as a paritcular
instanciation of inter-domain MPLS Traffic Engineering whereby a TE
LSP must be computed across multiple routing domain. Thus, to offer CE-to-CE
TE LSP bandwidth
guarantees, CE-to-CE protection (using a local protection recovery
mechanism such as Fast Reroute [[RFC4090]]), and CE-to-CE path
diversity. It must be noted that CE-to-CE path diversity may be
required in order to load balance the flows while avoiding to affect
all the traffic between the CEs upon the occurence of a single
failure or when a global protection mechanism is used, in which case
the second TE LSP is used as a backup should the primary TE LSP be
affected by a failure.

The provisioning of a CE-to-CE TE LSP can be seen as a particular
instanciation of inter-domain MPLS Traffic Engineering whereby a TE
LSP is computed across multiple routing domains. Thus, CE-to-CE TE
LSP can be computed using either the per-domain path computation
approach (described in [[I-D.ietf-ccamp-inter-domain-pd-path-comp]])
or a PCE-based path computation technique such as [[I-D.vasseur-
ccamp-brpc]]. [[I-D.vasseur-pce-
brpc]].

That said, such the per-domain path computation technique may be suboptimal and may lead
to call admission failure increase due to the lack of TE data for the
remote PE-CE link.
suboptimal. Consider the following network:

Vasseur, et al. Expires December 26, 2006 [Page 4]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006

CE1---PE1----P1----P2-----PE3----CE3
| | | | /
PE2----P3----P4-----PE4--/

CE1, CE2 and CE3 belong to the same VPNx
PE1, ..., PE4 are PEs routers
P1, ..., P4 are P routers

Objective is to compute a TE LSP T1 from CE1 to CE2

Figure 1 - An example of CE to CE TE LSP

[I-D.ietf-ccamp-inter-domain-pd-path-comp] specifies a path
computation technique whereby the each path segment is being computed on (on
a per domain basis, as the basis) during TE LSP signaling process progresses. signaling. In case of the example
provided in figure 1, CE1 would compute the TE LSP up to PE1 (if PE1
is chosen as its prefered next-hop), then PE1 would select its best
next hop PE and would compute the path segment up to that node

Vasseur, et al. Expires August 29, 2006 [Page 3]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February 2006 and
finally that last egress PE would finally compute the last path segment up to
the destination CE. Altough such path computation allows for the
computation of inter-domain CE-to-CE TE LSP it cannot guarantee that the computed
path is optimal (shortest constrained inter-domain TE LSP). LSP) and may
lead to call admission failure due to the lack of TE information from
the ingress to CE about the core network and from the ingress PE
about the remote PE-CE link.

Furthermore, the computation of a set of N diverse inter-domain paths
is quite challenging.

In contrast, PCE-based path computation techniques (see [[I-D.ietf-
pce-architecture]]) have been defined that allows for the computation
of shortest constrained inter-domain TE LSP, an particular
instantiation of which is the CE to CE CE-to-CE path computation. A Multi-PCE
path computation technique has been described in [[I-D.vasseur-ccamp- [[I-D.vasseur-pce-
brpc]] that can be used for the computation of such shortest
constrained CE-to-CE TE LSP. Applying the BRPC procedure, a CE
acting as a PCC (Path Computation Client) would send sends a path computation
request of one of its attached PE acting as a PCE (in the form of a
PCEP [[I-D.ietf-pce-pcep]] PCReq message), message, which would in turn relay the PCReq message to the egress PE. The shortest
constrained CE-to-CE TE LSP would then be computed using the backward
recursive scheme specifed in . [I-D.vasseur-ccamp-brpc]. In the
particular context of CE to CE path, the BRPC procedure can be
optimized by extending the TED visibility to some PE-CE links.
Indeed, the knowledge of TE PE-CE link characteristics would allow
the ingress PE (e.g. PE1) to compute in one pass the optimal
(shortest) CE-to-CE TE LSP.

MP-BGP protocol extensions are proposed in this document to extend relays the TED visibility to some PE-CE links.

2. Terminology

Terminology used in this document LSR: Label Switch Router.

BRPC: Backward Recursive Path Computation procedure.

CE: Customer Edge.

IGP Area: OSPF Area or IS-IS level.

Inter-domain TE LSP: A TE LSP whose path transits across at least two
different domains where a domain can either be an IGP area, an
Autonomous System or a sub-AS (BGP confederations).

NLRI: Network Layer Reachability Information.

PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.

Vasseur, et al. Expires August 29, 2006 [Page 4]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February 2006

PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.

PCEP: Path Computation Element Protocol.

PCEP Peer: an element involved in a PCEP session (i.e. a PCC or
PCReq message to the egress PE (also acting as a PCE).

PE: Provider Edge.

RD: Route Distinguisher.

SAFI: Subsequence Address Family Identifier.

TED: Traffic Engineering Database which contains The shortest
constrained CE-to-CE TE LSP would then be computed using the topology and
resource information backward
recursive scheme specifed in . [I-D.vasseur-pce-brpc]. In the
particular context of CE-to-CE TE LSP, the domain. The TED may BRPC procedure can be fed by IGP
extensions or potentially
optimized by other means.

TE LSP: Traffic Engineering Label Switched Path.

VSPT: Virtual Shortest Path Tree.

3. MP-BGP Protocol extensions

A set extending the TED visibility to some PE-CE links.
Indeed, the knowledge of Traffic Engineering TLVs have been defined in [RFC3784] and
[RFC3630] for ISIS and OSPF respectively. Furthermore other TE PE-CE link
attributes may be advertised using characteristics would allow
the TLV specified ingress PE (e.g. PE1) to compute in [[I-D.ietf-
isis-link-attr]]. No new one pass the optimal
(shortest) CE-to-CE TE TLVs LSP.

Vasseur, et al. Expires December 26, 2006 [Page 5]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006

MP-BGP protocol extensions are specified proposed in this document and
the existing TE TLVs will be re-used for to extend
the TED visibility to some PE-CE link without any
change. links.

3. MP-BGP Protocol extensions

A set of Traffic Engineering TLVs have been defined in [RFC3784] and
[RFC3630] for ISIS and OSPF respectively. Furthermore other TE link
attributes may be advertised using the TLV specified in
[I-D.ietf-isis-link-attr]. [[I-D.ietf-
isis-link-attr]]. No new TE TLVs are specified in this document and
the existing TE TLVs will be re-used for the PE-CE link without any
change.

This document introduces a new SAFI called TE-Link SAFI [to be
defined in a further revision of this document]. The NLRI of this
SAFI is of the form RD:IP-address, where the RD is the RD of the VRF
as described in [RFC4364] and the IP-address is the address of the CE
router. The MP-BGP update for this SAFI will also be accompanied by
extended community attribute carrying Export Route-targets as defined
in [RFC4364]. This document also defines a new attribute called the
TE attribute which carries the set of sub-TLVs defined in [RFC3784].
The format of the BGP TE attribute will be defined in a further
revision of this document.

Vasseur, et al. Expires August 29, 2006 [Page 5]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February 2006

4. TED update

The mode of operation described in this document requires to extend
the TED so as to make it VPN-aware. That said, this does not require
any protocol extensions per-say and will not be discussed in this
document.

The receipt of an MP-BGP update comprising a new BGP TE attribute
will simply trigger a TED update should a TE-related information for
a PE-CE link be changed. An implementation MAY implementation use a threshold-based
mechanisms to rate limit the frequency at which BGP
update updates will be
sent similarly (similarly to the IGP case. case).

5. Example

An example is provided in this section that shows how the MP-BGP
extensions defined in this document optimizes the BRPC path
computation in the context of CE-to-CE TE LSP. Back to the examplary exemplary
network depicted in Figure 1.

Step 1: The ingress CE (e.g. CE1) selects a PCE (say PE1).

Vasseur, et al. Expires December 26, 2006 [Page 6]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006

Step 2: Upon receiving the PCReq message from CE1, PE1 acting (acting as a
PCE,
PCE) determines the set S of PEs with a PE-CE link to the destination
CE (e.g. CE2). The following VSPT is then computed:

VSPT computed by the ingress PE acting as a PCE

CE2
/ \
PE1 PE2

Step 3: The shortest constrained path is then returned to CE1 in the
form of a PCRep message (with loose hop).

6. IANA Considerations

The SAFI code for the TE SAFI will be assigned by IANA.

The BGP TE attribute code will also be assigned by the IANA.

7. Security Considerations

This document raises no new security issues for BGP.

Vasseur, et al. Expires August 29, 2006 [Page 6]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February 2006

8. Acknowledgements

9. References

9.1. Normative References

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

9.2. Informative References

[I-D.ietf-ccamp-inter-domain-pd-path-comp]
Vasseur, J., "A Per-domain path computation method for
establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-01
draft-ietf-ccamp-inter-domain-pd-path-comp-02 (work in
progress), October 2005. February 2006.

[I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-02

Vasseur, et al. Expires December 26, 2006 [Page 7]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-01 June 2006

draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in
progress), October 2005. March 2006.

[I-D.ietf-isis-link-attr]
Vasseur, J. and S. Previdi, "Definition of an IS-IS Link
Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in
progress), May 2005.

[I-D.ietf-pce-architecture]
Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-04 draft-ietf-pce-architecture-05 (work in
progress), January April 2006.

[I-D.ietf-pce-pcep]
Vasseur, J., "Path Computation Element (PCE) communication
Protocol (PCEP) - Version 1 -", draft-ietf-pce-pcep-00 1", draft-ietf-pce-pcep-02 (work
in progress), November 2005.

[I-D.vasseur-ccamp-brpc] June 2006.

[I-D.vasseur-pce-brpc]
Vasseur, J., "A Backward Recursive PCE-based Computation
(BRPC) procedure to compute shortest inter-domain Traffic
Engineering Label Switched Path",
draft-vasseur-ccamp-brpc-00 Paths",
draft-vasseur-pce-brpc-01 (work in progress),
February June 2006.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering

Vasseur, et al. Expires August 29, 2006 [Page 7]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February 2006
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.

[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.

[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.

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

Appendix A. Proposed Status and Discussion [To Be Removed Upon
Publication]

This Internet-Draft is being submitted for eventual publication as an
RFC with a proposed status of Standard. Discussion of this proposal
should take place on the following mailing list: ccamp@ietf.org.

Vasseur, et al. Expires August 29, December 26, 2006 [Page 8]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February draft-vasseur-ccamp-ce-ce-te-01 June 2006

Authors' Addresses

JP Vasseur (editor)
Cisco Systems, Inc
1414 Massachusetts Avenue
Boxborough, MA 01719
USA

Email: jpv@cisco.com

Gargi Nalawade
Cisco Systems, Inc
510 McCarthy Blvd
Milpitas, MA 95035
USA

Email: gargi@cisco.com

Kenji Kumaki
KDDI Corporation
Garden Air Tower Iidabashi, Chiyoda-ku,
Tokyo, 102-8460
JAPAN

Email: ke-kumaki@kddi.com

Vasseur, et al. Expires August 29, December 26, 2006 [Page 9]

Internet-Draft draft-vasseur-ccamp-ce-ce-te-00 February draft-vasseur-ccamp-ce-ce-te-01 June 2006

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Vasseur, et al. Expires August 29, December 26, 2006 [Page 10]

----