Network Working Group Satoru Matsushima Internet Draft Japan Telecom Expiration Date: August 2005 Tetsuya Murakami Furukawa Electric Kenichi Nagami INTEC Netcore February 2005 BGP Point to Multipoint LSP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 3 of RFC3667 [RFC3667]. 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 become aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document specify the way that is to make point to multipoint(p2mp) LSP using BGP. The BGP extended community is used to this purpose. The BGP speakers which exchenge a route and distribute a MPLS label can also use BGP to create a p2mp LSP. 1. Introduction The BGP speakers which are Label Switched Router(LSR) distribute label mapping information for a particular route in piggybacked in the BGP route. Suppose that the LSP in this manner is multipoint to point(mp2p) LSP. At the same time, the situation in which the label for point to multipoint LSP is also piggybacked in the BGP route which indicate p2mp route information is useful. Matsushima, et al. [Page 1] Internet Draft BGP Point to Multipoint LSP February 2005 For instance, when the p2mp LSP traverse BGP LSRs which are directly connected, making p2mp LSP is done by only BGP. This is useful case of if p2mp LSP traverse inter-domain MPLS environments. Other case is that if one exterior BGP LSR should transit p2mp LSP to other BGP LSR which does not directly connected, internal LSP among BGP LSRs can aggregate p2mp LSP. This case has advantage and scalable rather than internal p2mp LSP is mapped to external domain or area directly. The p2mp LSP information should be distributed in BGP update message. The BGP extended community and NLRI are used to distinguish particular p2mp LSP. This information should be propagated to BGP speakers which need to make p2mp LSP. The BGP p2mp LSR should have p2mp-instance that import p2mp routes as downstreams of particular LSP. When p2mp-instance receive packets from upstream LSR, it should replicate and send packets to its downstream entries. The BGP route-reflector[BGP-RR], which does not exist on forwarding path or egress LSR, these router may not have p2mp-instance. 2. BGP Point-to-Multipoint LSP Information The BGP p2mp LSP information is following: o P2MP_ID This attribute is used to identify the address or administrative number of P2MP-LSP. The ingress node and branch LSR shall advertise this attribute to the network. o P2MP_BRANCH_LIST This attribute is used to identify the sequence of the branch LSRs of P2MP-LSP. The branch LSR shall add its router-id or address this attribute to the route from its upstream branch LSR. If branch LSR receives routing information that doesn't have this attribute, the branch LSR shall create a new P2MP_BRANCH_LIST attribute and then advertise it to the network. o P2MP_IMPORTED_BRANCH This attribute is used to identify the upstream LSR at egress and/or branch LSR of P2MP-LSP. The egress node and the branch node shall advertise this attribute to the network, containing the Router-ID of its upstream LSR. o NLRI Matsushima, et al. [Page 2] Internet Draft BGP Point to Multipoint LSP February 2005 The NLRI in the p2mp route, it is used to identify the ingress router-id. Suppose that a situation in which an ingress router have several p2mp LSPs which has same id, then NLRI should be unique. For this reason, the NLRI may use vpnv4 address-family[2547bis] which has unique Route Distinguisher(RD), or may use other new address-family. 3. P2MP instance The BGP speaker which support p2mp branch capability should has p2mp-instance for each of p2mp LSP. The p2mp-instance should have one upstream entry and several downstream entries. When the BGP LSR has p2mp-instance, a MPLS label should be mapped to it to receive packets from its upstream. Then if the BGP LSR import particular p2mp routes, a p2mp-instance should have this route as downstream entries. The BGP LSR receives the packet which are imposed upstream label of particular p2mp-instance, a p2mp-instance should pop label, replicate it and push the label onto the packet's label stack to each of downstream entries. If downstream LSR is not connected directly, push the label which mapped interior LSP to BGP next hop onto the packet's label stack, and then send the packet to each downstream. 4. Operation 4.1 Making p2mp LSP tree The following actions complete making the tree of p2mp LSP in the network. In these step, the ingress LSR doesn't forward packets to any of branch and egress LSR even if the ingress LSR receives packets toward p2mp LSP. This step makes only the p2mp tree. This could be an advantage of operation because the operator can confirm and modify the tree before the packet traverse LSP. 1) Advertising of ingress and branch LSR First of all, the node that is becoming ingress LSR should advertise p2mp LSP routing information that including P2MP_ID community. The branch LSR that receives the routing information from the ingress LSR will update it with adding its router-id to P2MP_BRANCH_LIST and ORIGINATOR_ID. When branch LSR re-advertise p2mp LSP route, the NEXT_HOP attribute is branch LSR's address. 2) Tree of P2MP-LSP decision Each of branch LSR which receives these routes should select the best path in which branch LSR is its upstream based on its path selection rule or manual configuration. Then branch LSRs should Matsushima, et al. [Page 3] Internet Draft BGP Point to Multipoint LSP February 2005 re-advertise its p2mp route with P2MP_BRANCH_LIST where its route-id is added. It also includes upstream routers as P2MP_BRANCH_LIST. 3) Loop Prevention The p2mp route will be advertised repeatedly, and it will flow back to original branch LSR. In this case, each branch LSR should check whether the received route include its router-id as P2MP_BRANCH_LIST or not. If it includes itself, branch LSR should discard such routes to avoid routing loop. 4.2 Join to p2mp LSP When the egress LSR wants to receives packets from p2mp LSP, it selects the most appropriate upstream branch based on its path selection rule or manual configuration. And egress LSR should advertise the route with P2MP_ID and P2MP_IMPORTED_BRANCH attribute that indicate its upstream branch LSR. At this time, the next hop of advertise route indicates its address. When the branch LSR receives the route that include P2MP_IMPORTED_BRANCH, which indicate its local router-id, the branch LSR should import this route to local p2mp instance related to each p2mp LSP. The branch LSR imports routes from the egress node, it also advertises P2MP_IMPORTED_BRANCH which indicates its upstream of P2MP-LSP. This action is repeated to propagate upstream information. 4.3 Leave from p2mp LSP When the egress LSR and/or the branch LSR leave from p2mp LSP, they should stop importing of downstream routes and withdraw the route. It will include both P2MP_IMPORTED_BRANCH, and P2MP_BRANCH_LIST attribute if the node is branch LSR. This action causes the upstream LSR to discard the route from leaving downstream LSR, and then the LSR can leave from p2mp LSP. Moreover, the branch LSR can leave automatically if it doesn't have any route in local p2mp instance. 5. Security Considerations As well as [BGP-MPLS] describes, p2mp LSP using BGP has the "label spoofing" problem. For this reason, BGP LSR which also support p2mp LSP should not adjacent both of trusted and untrusted system on the same interface. 6. Acknowledgments Matsushima, et al. [Page 4] Internet Draft BGP Point to Multipoint LSP February 2005 Thanks to Miya Kohno for helpful comments. 7. References [BGP-MPLS] Rekhter, Y., Rosen, E., "Carrying Label Information in BGP-4", RFC3107 [BGP-RR] Bates, T. and R. Chandra, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 1966, June 1996. [2547bis] E. Rosen, Y. Rekhter "BGP/MPLS VPNs", draft-ietf-l3vpn- rfc2547bis-03 (work in progress), October 2004 8. Authors' Addresses Satoru Matsushima Japan Telecom Co.,LTD. Email: satoru@ft.solteria.net Tetsuya Murakami The Furukawa Electric Co.,LTD Email: murakami@inf.furukawa.co.jp Kenichi Nagami INTEC Netcore, Inc. Email: nagami@inetcore.com 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 (2005). 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. Matsushima, et al. [Page 5]