[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05                                             
MPLS Working Group                                    S. Matsushima, Ed.
Internet-Draft                                          Softbank Telecom
Intended status: Standards Track                             T. Murakami
Expires: August 28, 2008                                   Cisco Systems
                                                               K. Nagami
                                                           INTEC Netcore
                                                       February 25, 2008


                      BGP Point to Multipoint LSP
                  draft-satoru-mpls-bgp-multipoint-05

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 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes motivations and use cases to P2MP extension
   of BGP.  This extension will allow to make both Inter-AS and Intra-AS
   P2MP LSP that fit to some use cases then also clarify required
   features.




Matsushima, et al.       Expires August 28, 2008                [Page 1]


Internet-Draft                BGP P2MP LSP                 February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Motivations  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Inter-AS P2MP  . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Intra-AS . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Use cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Inter-AS MVPN Option C . . . . . . . . . . . . . . . . . .  4
     3.2.  Carriers' Carrier P2MP routing . . . . . . . . . . . . . .  4
     3.3.  Over-layed Intra-AS P2MP-LSP . . . . . . . . . . . . . . .  5

   4.  BGP P2MP LSP . . . . . . . . . . . . . . . . . . . . . . . . .  6

   5.  Scalability Considerations . . . . . . . . . . . . . . . . . .  7

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7

   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . . 10
























Matsushima, et al.       Expires August 28, 2008                [Page 2]


Internet-Draft                BGP P2MP LSP                 February 2008


1.  Introduction

   For some reasons, BGP [1] is useful protocols to create Inter-AS and
   Intra-AS LSPs by extending to carry MPLS label informations[2] .  In
   the case of Point-to-Multipoint (P2MP) LSP, suitable motivations
   exist that using BGP to fit some use cases then we clarify required
   features for BGP P2MP.  In each use case, we assume that inter-AS
   link and network uses MPLS as P2MP transport as well as intra-AS
   networks.


2.  Motivations

   This section describes motivations of P2MP extension to BGP.

2.1.  Inter-AS P2MP

   Some applications that uses P2MP LSP has appeared.  Service provider
   is requesting the P2MP LSP connection among ASes.  Inter-AS Option C
   of RFC4364 [3] is used for a lot of service provider's Inter-AS
   connections.  In this case, it is also necessary to achieve Option C
   in the Inter-AS Multicast VPN [6] environment.  At this time, the
   P2MP LSP connection is needed between ASes.  Moreover, P2MP LSP
   connection between PE and CE is preferable in the case of Carriers'
   Carrier network of RFC4364 [3] as core network of VPN provider.

   The method of using PCE for the P2MP LSP connection with Inter-AS is
   examined.  PCE offers passing calculation information necessary to
   connect P2MP TE-LSP[7] in the Inter-AS environment but there is a
   case where TE-LSP cannot be connected by policy of Inter-AS.  In this
   case, neither P2MP-TE nor PCE are applicable.  On the other hand, BGP
   is generally used for Inter-AS in many cases then service provider
   may want to use BGP as P2MP connection as well.  However, P2MP LSP
   cannot be done by BGP.

2.2.  Intra-AS

   As for P2MP LSP that uses RSVP-TE or MLDP, signaling is done with
   hop-by-hop manner.  All LSRs are in Intra-AS that P2MP-LSP passes
   should support these signaling then makes efficient P2MP tree.
   Oppositely, there are a lot of demands of LSR that specializes P2MP
   function such as signaling and packet replication be isolated from
   unicast LSR to keep simple network even if it sacrifices efficiency.

   In this case, Service Provider may want to establish P2MP LSPs among
   P2MP LSRs as multi-hop, over-lay manner. they need to decide which
   LSR become appropriate branch LSR of P2MP LSP and which is backup in
   policy basis.  Hence they want to decide the branch LSR explicitly in



Matsushima, et al.       Expires August 28, 2008                [Page 3]


Internet-Draft                BGP P2MP LSP                 February 2008


   Intra-AS.


3.  Use cases

   This section describes some use case to find out required features to
   BGP support P2MP ability.

3.1.  Inter-AS MVPN Option C

   When a VPN traverse two or more AS composing of Inter-AS Option C,
   ASBRs should make LSP to PE that exists in adjacent other AS.  Here,
   advertising routes related to VPN customer between ASes must be done
   only between RRs.  This means that ASBR must be agnostic from VPN
   routes.  Also ASBR should maintain P-Tunnel to PE in Multicast VPN.


                             multihop EBGP
                  /---+RR1+----------------+RR2+---\
            IBGP /                                  \ IBGP
                /                                    \
               +                  EBGP                +
             PE1---P----P---ASBR1+---+ASBR2----P---P---PE2
                 (AS1 side)                  (AS2 side)


                          Figure 1: MVPN Option C

   RRs exchanges routes related to Multicast VPN on multihop EBGP peer
   in Figure 1 , and ASBR exchanges routes related to P-Tunnel.  This
   route must not cntain any VPN information.  Routes that ASBR
   exchanges should have MPLS label that identifies P-Tunnel that should
   be distinct in each ASes.  It is necessary to enhance BGP for EBGP
   between ASBR.  Note that in the case of ingress replication P-Tunnel
   type is excepted.  And whole of solution to achieve MVPN Option C is
   out of scope.

3.2.  Carriers' Carrier P2MP routing

   When a certain service provider is offering VPN MPLS backbone service
   by Carriers 'Carrier (CsC), service provider maintains only CE route
   in VPN.  Therefore, CsC PE does not need to know VPN service routes.
   This means that CsC network can scale well.








Matsushima, et al.       Expires August 28, 2008                [Page 4]


Internet-Draft                BGP P2MP LSP                 February 2008


                           /---RR---\
                          /          \
                         +    IBGP    +
           CsC  EBGP   CsC             CsC   EBGP  CsC
           CE1+-------+PE1------P------PE2+-------+CE2
              +                                   +
               \    multihop MVPN-EBGP/IBGP      /
                \-------------------------------/


                     Figure 2: P2MP Carriers' Carrier

   In CsC network shown in Figure 2, CsC-PEs should offer MPLS P2MP
   transport so that CsC CE may need MPLS P2MP connectivity with remote
   CE when CsC CE does Multicast service or Multicast VPN service.  If
   CsC CE1 does source CE and MVPN-BGP[8], CsC CE1 advertises Auto-
   discovery route to CsC CE2 on MVPN-IBGP.  At this time, it is
   necessary to deliver Tunnel identifier specified in PMSI Tunnel
   attribute to CsC-CE2 via CsC-PE1, RR, and CsC-PE2.

   Similarly, it is necessary to deliver Tunnel identifier advertised
   with Leaf auto-discovery route on MVPN-IBGP to CsC-CE1 via CsC-PE2,
   RR, and CsC-PE1 as for CsC-CE2.  CsC PEs should bind P2MP tree of
   internal with LSP between CsC PE to CsC CEs.  It is necessary to
   enhance BGP with these functions.  Note that the case where CsC-CE1
   and CsC-PE1 do ingress replication is excluded.

   When CsC-PEs aggregate two or more CsC-CEs into a P2MP transport to
   improve scalability, leaf CsC-PE2 will receive even a packet not
   necessary as a result.  De-multiplexer that takes out a necessary
   packet is needed from received packets.  CsC-PE2 can forward packet
   to CsC-CE2 when received packet have label that local assigned to
   bind CsC-CE2.  CsC-PE1 can forward packet when receive routes that
   include label to push onto shared P2MP transport.  And then that
   label is bind with CsC-CE1, CsC-PE1 can forward packet that received
   from CsC-CE1 to CsC-PE2.

3.3.  Over-layed Intra-AS P2MP-LSP

   It might be difficult for SP that wants to keep simple own network in
   some cases to give backbone multicast and/or P2MP ability in existing
   MPLS network.  As for such SP, the P2MP ability might be given to
   specific LSR, and may select way to separate service that needs
   packet replication from existing LSR though it somewhat sacrifices
   optimization of packet replication.






Matsushima, et al.       Expires August 28, 2008                [Page 5]


Internet-Draft                BGP P2MP LSP                 February 2008


                                      RR1
                                     /  \
                                    /    \
           CE1------PE1------P1----P3-----P5----P2------PE3------CE3
                     \      /      |      |      \      /
                      \ /--/      BLSR1   |       \ /--/
                       \----\      |    BLSR2      \---\
                      /      \     |      |       /     \
           CE2------PE2------P2----P4-----P6----P8------PE4------CE4
                                    \    /
                                     \  /
                                      RR2

                  Figure 3: Over-layed Intra-AS P2MP LSRs

   Network shown in Figure 3 starts offering CE1-CE4 Multicast VPN
   service by PE1-PE4, P1-P8, BLSR1, and 2 belonging and using P2MP LSP
   for same domain.  In this network, only BLSR1 and 2 have P2MP branch
   capability, and P1-P8 doesn't have the P2MP ability.  PE1-PE4 can
   become source and leaf of P2MP LSP.  When PE1 becomes source PE and
   P2MP LSP is configured to PE3 and PE4, LSP is as follows.

                           PE1---->BLSR1---->PE3
                                     |
                                     +------>PE4

   Unicast LSP overlays P2MP LSP between each PE and BLSR.  For
   instance, PE1--> BLSR1 exists on unicast LSP that passes
   PE1->P1->P3->BLSR1.  MPLS label that shows P2MP LSP becomes bottom
   stack label.  If unicast LSP is TE-LSP, becomes possible to
   protection by Fast Reroute and to do the traffic engineering.

   BGP may be used to establish P2MP LSP onto unicast LSP of each PE and
   BLSR in stack.  It is necessary to enhance BGP for P2MP LSP.  Because
   one unicast LSP can carry two or more P2MP LSP in stack, scalability
   of P router can be improved than hop-by-hop P2MP protocols.
   Moreover, it is possible to prepare for outage of P2MP node by policy
   based operation to which BLSR and/or source PE that becomes backup
   because it uses BGP are provided beforehand.  Detail of BGP
   extensions are described with following section.


4.  BGP P2MP LSP

   Concrete P2MP informations that is carry by BGP and procedures are
   further study.





Matsushima, et al.       Expires August 28, 2008                [Page 6]


Internet-Draft                BGP P2MP LSP                 February 2008


5.  Scalability Considerations

   The number of EBGP peering of ASBR and IBGP full mesh in AS give
   scalability impact even though BGP is originally excellent protocol
   in scalability.  In use case described in Section 3, Route reflector
   (RR) [4] be able to use instead of full mesh of IBGP.  At that time,
   necessary routes must not be summarize by RR.  Moreover, BGP
   maintains control plane only, and is not used for data plane.

   As for BGP P2MP routes, the number of BGP P2MP routes may be
   increased by increasing LSPs and LSRs.  To avoid or mitigate such
   increasing that may affect to scalability, RT Constraint [9] may
   appropriate for some cases.


6.  Security Considerations

   As well as RFC3107 [2] describes, P2MP LSP using BGP has the "label
   spoofing" problem.  For this, BGP LSR which also support P2MP LSP
   should not make the adjacencies of both trusted and untrusted system
   on the same interface.


7.  Acknowledgments

   Thanks to Miya Kohno and Paul Doolan for their support and helpful
   comments.


8.  References

8.1.  Normative References

   [1]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
        (BGP-4)", RFC 4271, January 2006.

   [2]  Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4",
        RFC 3107, May 2001.

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

   [4]  Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An
        Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456,
        April 2006.

   [5]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
        Communities Attribute", RFC 4360, February 2006.



Matsushima, et al.       Expires August 28, 2008                [Page 7]


Internet-Draft                BGP P2MP LSP                 February 2008


8.2.  Informative References

   [6]  Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen,
        E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP
        VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in progress),
        January 2008.

   [7]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to
        Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
        for Point-to-Multipoint TE Label Switched Paths (LSPs)",
        RFC 4875, May 2007.

   [8]  Aggarwal, R., "BGP Encodings and Procedures for Multicast in
        MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-04 (work
        in progress), November 2007.

   [9]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R.,
        Patel, K., and J. Guichard, "Constrained Route Distribution for
        Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
        Internet Protocol (IP) Virtual Private Networks (VPNs)",
        RFC 4684, November 2006.


Authors' Addresses

   Satoru Matsushima (editor)
   Softbank Telecom Corp.
   9-1, Higashi-Shinbashi 1-chome
   Minato-ku
   Tokyo  105-7316
   Japan

   Email: satoru@ft.solteria.net


   Tetsuya Murakami
   Cisco Systems
   2-1-1, Nishi-Shinjuku
   Shinjuku-ku
   Tokyo  163-0409
   Japan

   Email: tmurakam@cisco.com








Matsushima, et al.       Expires August 28, 2008                [Page 8]


Internet-Draft                BGP P2MP LSP                 February 2008


   Kenichi Nagami
   INTEC Netcore, Inc.
   1-3-3, Shin-suna
   Koto-ku
   Tokyo  135-0075
   Japan

   Email: nagami@inetcore.com











































Matsushima, et al.       Expires August 28, 2008                [Page 9]


Internet-Draft                BGP P2MP LSP                 February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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





Matsushima, et al.       Expires August 28, 2008               [Page 10]