One document matched: draft-vasseur-ccamp-ce-ce-te-02.txt

Differences from draft-vasseur-ccamp-ce-ce-te-01.txt

Networking Working Group                                JP. Vasseur, Ed.
Internet-Draft                                           Gargi. Nalawade
Intended status: Standards Track                      Cisco Systems, Inc
Expires: December 15, 2007                                     K. Kumaki
                                                        KDDI Corporation
                                                           June 13, 2007


    An MP-BGP protocol extension to advertize TE-related PE-CE link
                              information
                    draft-vasseur-ccamp-ce-ce-te-02

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 December 15, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 December 15, 2007               [Page 1]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


   Swtiched Path (TE LSP) when required to provide specific services
   such as bandwidth guarantees and end to end fast 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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  MP-BGP Protocol extensions . . . . . . . . . . . . . . . . . .  6
   4.  TED update . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  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 December 15, 2007               [Page 2]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


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 advertise Traffic Engineering link
   characteristics across an IGP area, which can then be used to compute



Vasseur, et al.         Expires December 15, 2007               [Page 3]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


   MPLS Traffic Engineering Label Switched Path (TE LSP).

   In 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 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 where Customer Edge (CE) routers could be
   interconnected via TE LSPs so as to offer CE-to-CE 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-pce-brpc]].

   That said, the per-domain path computation technique may be
   suboptimal.  Consider the following network:

















Vasseur, et al.         Expires December 15, 2007               [Page 4]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


   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 each path segment is being computed (on
   a per domain basis) during TE LSP 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 and
   finally that last egress PE would compute the last path segment up to
   the destination CE.  Altough such path computation allows for the
   computation of CE-to-CE TE LSP it cannot guarantee that the computed
   path is optimal (shortest constrained inter-domain TE 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 path computation.
   A Multi-PCE path computation technique has been described in
   [[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) 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, which in turn relays the
   PCReq message to the egress PE (also acting as a PCE).  The shortest
   constrained CE-to-CE TE LSP would then be computed using the backward
   recursive scheme specifed in .  [I-D.vasseur-pce-brpc].  In the
   particular context of CE-to-CE TE LSP, 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.




Vasseur, et al.         Expires December 15, 2007               [Page 5]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


   MP-BGP protocol extensions are proposed in this document to extend
   the TED visibility to some PE-CE 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]].  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.


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 use a threshold-based
   mechanisms to rate limit the frequency at which BGP updates will be
   sent (similarly to the IGP 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 exemplary
   network depicted in Figure 1.

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




Vasseur, et al.         Expires December 15, 2007               [Page 6]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


   Step 2: Upon receiving the PCReq message from CE1, PE1 (acting as a
   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.


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-05 (work in
              progress), April 2007.

   [I-D.ietf-ccamp-inter-domain-rsvp-te]
              Ayyangar, A., "Inter domain Multiprotocol Label Switching
              (MPLS) and Generalized MPLS  (GMPLS) Traffic Engineering -



Vasseur, et al.         Expires December 15, 2007               [Page 7]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


              RSVP-TE extensions",
              draft-ietf-ccamp-inter-domain-rsvp-te-06 (work in
              progress), April 2007.

   [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-03 (work in
              progress), February 2007.

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

   [I-D.ietf-pce-pcep]
              Roux, J. and J. Vasseur, "Path Computation Element (PCE)
              communication Protocol (PCEP)", draft-ietf-pce-pcep-07
              (work in progress), March 2007.

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

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (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 December 15, 2007               [Page 8]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


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 December 15, 2007               [Page 9]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-02           June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Vasseur, et al.         Expires December 15, 2007              [Page 10]