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

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


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

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

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, 2006.

Copyright Notice

   Copyright (C) The Internet Society (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, 2006                [Page 1]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-00       February 2006


   Swtiched Path (TE LSP) when required to provide specific services
   such as bandwidth guarantees and end to end fast protection.

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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  MP-BGP Protocol extensions . . . . . . . . . . . . . . . . . .  5
   4.  TED update . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   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, 2006                [Page 2]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-00       February 2006


1.  Introduction

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

   In 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
   local protection techniques 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 Customer Edge (CE) routers could be
   interconnected via TE LSPs.  This can be seen as a paritcular
   instanciation of inter-domain MPLS Traffic Engineering whereby a TE
   LSP must be computed across multiple routing domain.  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]].

   That said, such 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.  Consider the following network:

   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 path is being computed on a per
   domain basis, as the TE LSP signaling process progresses.  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 and 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


   that would finally compute the last path segment up to the
   destination CE.  Altough such path computation allows for the
   computation of inter-domain TE LSP it cannot guarantee that the
   computed path is optimal (shortest constrained inter-domain TE LSP).
   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-ccamp-
   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 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 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
   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 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.


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



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
   threshold-based mechanisms to rate limit the frequency at which BGP
   update 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 examplary
   network depicted in Figure 1.

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

   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.




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 (work in
              progress), October 2005.

   [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 (work in
              progress), October 2005.

   [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 (work in
              progress), January 2006.

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

   [I-D.vasseur-ccamp-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 (work in progress),
              February 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, 2006                [Page 8]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-00       February 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, 2006                [Page 9]

Internet-Draft       draft-vasseur-ccamp-ce-ce-te-00       February 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 Statement

   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, 2006               [Page 10]