One document matched: draft-raggarwa-isis-te-node-addr-01.txt
Differences from draft-raggarwa-isis-te-node-addr-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-22 16:30:19 |