draft-ietf-ospf-te-node-addr-01.txt   draft-ietf-ospf-te-node-addr-02.txt 
Network Working Group Rahul Aggarwal Network Working Group Rahul Aggarwal
Internet Draft Kireeti Kompella Internet Draft Kireeti Kompella
Expiration Date: January 2005 Juniper Networks Expiration Date: September 2005 Juniper Networks
Advertising a Router's Local Addresses in OSPF TE Extensions Advertising a Router's Local Addresses in OSPF TE Extensions
draft-ietf-ospf-te-node-addr-01.txt draft-ietf-ospf-te-node-addr-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or IPR claims of which I am aware have been disclosed, and any patent or IPR claims of which we are aware have been disclosed, and
of which I become aware will be disclosed, in accordance with RFC any of which we become aware will be disclosed, in accordance with
3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Abstract Abstract
This document describes procedures that enhance OSPF Traffic This document describes procedures that enhance OSPF Traffic
Engineering (TE) extensions for advertising a router's local Engineering (TE) extensions for advertising a router's local
addresses. This is needed to enable other routers in a network to addresses. This is needed to enable other routers in a network to
compute traffic engineered MPLS LSPs to a given router's local compute traffic engineered MPLS LSPs to a given router's local
addresses. Currently, the only addresses belonging to a router that addresses. Currently, the only addresses belonging to a router that
are advertised in TE LSAs are the local addresses corresponding to TE are advertised in TE LSAs are the local addresses corresponding to TE
enabled links and the local address corresponding to the Router ID. enabled links and the local address corresponding to the Router ID.
Conventions used in this document
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 [KEYWORDS].
1. Motivation 1. Motivation
In some cases it is desirable to setup constrained shortest path In some cases it is desirable to setup constrained shortest path
first (CSPF) computed MPLS TE LSPs to local addresses of a router, first (CSPF) computed MPLS TE LSPs to local addresses of a router,
that are not currently advertised in the TE LSAs i.e. loopback and that are not currently advertised in the TE LSAs i.e. loopback and
non-TE interface addresses. non-TE interface addresses.
For instance, in a network carrying VPN and non-VPN traffic, it is For instance, in a network carrying VPN and non-VPN traffic, it is
often desirable to use different MPLS TE LSPs for the VPN traffic and 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 non-VPN traffic. In this case one loopback address may be used as
skipping to change at page 6, line 35 skipping to change at page 6, line 38
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUNG BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Acknowledgement 11. Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/