Network Working Group Rahul Aggarwal Internet Draft Nischal Sheth Expiration Date: January 2005 Juniper Networks IS-IS TE Procedures for Learning Local Addresses draft-raggarwa-isis-te-node-addr-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or IPR claims of which I am aware have been disclosed, and any of which I 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 describes procedures that enable a router to populate its Traffic Engineering Database (TED), with local addresses of other routers, that are not advertised in IS-IS TE extensions. The only addresses belonging to a router that are advertised in IS-IS TE LSAs are the router's local addresses on links enabled for TE and the Router ID. The described procedures enable a router to compute traffic engineered MPLS LSPs to a given router's loopback and non-TE capable interface addresses. draft-raggarwa-isis-te-node-addr-01.txt [Page 1] Internet Draft draft-raggarwa-isis-te-node-addr-01.txt July 2004 1. Motivation In some cases it is desirable to setup, constrained shortest path first (CSPF) computed MPLS TE LSPs, to local addresses of a router that are not advertised in the TE LSAs i.e. loopback and non-TE interface addresses. For instance in a network carrying VPN and non-VPN traffic, its often desirable to use different MPLS TE LSPs for the VPN traffic and the non-VPN traffic. In this case one loopback address may be used as the BGP next-hop for VPN traffic while another may be used as the BGP next-hop for non-VPN traffic. Its also possible that different BGP sessions are used for VPN and non-VPN services. Hence two separate MPLS TE LSPs are desirable, one to each loopback address. However currently there is no defined procedure for a router to populate the TED with loopback or non-TE capable interface addresses of other routers. IS-IS TE extensions [IS-IS-TE] only advertise the router ID and the local addresses of TE enabled links, of a given router. Thus other routers in the network populate the TED only with these addresses. This document describes a procedure for populating the TED with loopback and non-TE interface addresses. 2. Proposed Solution The proposed solution is to use the local addresses learned from the IP Interface Address TLV [IS-IS] and the IPv6 Interface Address TLV [IS-IS-v6], to populate the TED. [IS-IS, IS-IS-v6] mandate including the IP(v6) Interface Address TLV in the IS-IS link state PDUs (LSP). This TLV contains a list of one or more IP(v6) addresses corresponding to one or more interfaces of the router which originates the LSP. Hence the local addresses that are not advertised in IS-IS TE extensions can be learned from the IP(v6) Interface Address TLV and used to populate the TED. Despite the mandatory requirement in [IS-IS] an existing implementation may not advertise the IP(v6) Interface Address TLV in its LSPs as the IP(v6) reachability information can be learned from the IP(v6) reachability TLVs defined in [IS-IS, IS-IS-v6]. Such an implementation will have to start advertising the IP(v6) Interface Address TLV in order to support the procedure described in this document. draft-raggarwa-isis-te-node-addr-01.txt [Page 2] Internet Draft draft-raggarwa-isis-te-node-addr-01.txt July 2004 3. Security Considerations This document does not introduce any further security issues other than those discussed in [IS-IS, IS-IS-v6, IS-IS-TE]. 4. Acknowledgments We would like to thank Kireeti Kompella for his contribution to this work. We would also like to thank Mike Shand and Robert Raszuk for their comments. 5. Normative References [IS-IS] "Intermediate System to Intermediate System Intra-Domain Routing exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589, 1992. [IS-IS-v6] C. E. Hopps, "Routing IPv6 with IS-IS", draft-ietf-isis-ipv6-05.txt. [IS-IS-TE] H. Smit, T. Li, "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-05.txt. [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Nischal Sheth Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: nsheth@juniper.net draft-raggarwa-isis-te-node-addr-01.txt [Page 3] Internet Draft draft-raggarwa-isis-te-node-addr-01.txt July 2004 7. 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. 8. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. draft-raggarwa-isis-te-node-addr-01.txt [Page 4] Internet Draft draft-raggarwa-isis-te-node-addr-01.txt July 2004 9. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-isis-te-node-addr-01.txt [Page 5]