draft-ietf-ospf-mt-ospfv3-01.txt   draft-ietf-ospf-mt-ospfv3-02.txt 
Network Working Group Sina Mirtorabi Network Working Group Sina Mirtorabi
Internet Draft Abhay Roy Internet Draft Force10 Networks
Expiration Date: September 2006 Cisco Systems Expiration Date: September 2007 Abhay Roy
File name: draft-ietf-ospf-mt-ospfv3-01.txt File name: draft-ietf-ospf-mt-ospfv3-02.txt Cisco Systems
Multi-topology routing in OSPFv3 (MT-OSPFv3) Multi-topology routing in OSPFv3 (MT-OSPFv3)
draft-ietf-ospf-mt-ospfv3-01.txt draft-ietf-ospf-mt-ospfv3-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2006. This Internet-Draft will expire on September 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes an extensible mechanism to support multiple This document describes an extensible mechanism to support multiple
topologies (MT) in OSPFv3. These topologies can be used within the topologies (MT) in OSPFv3. These topologies can be used within the
same address family in order to compute different paths for different same address family in order to compute different paths for different
classes of service, or belong to different address families allowing classes of service, or belong to different address families allowing
an integrated definition of address family with OSPFv3. The extension an integrated definition of address family with OSPFv3. The extension
described in this document can further facilitate any future described in this document can further facilitate any future
extensions of OSPFv3. extensions of OSPFv3.
1. Motivation 1. Introduction
Multi-topology routing as described in this document is similar in Multi-topology routing as described in this document is similar in
concept to M-ISIS [M-ISIS]. It is used to introduce an integrated concept to M-ISIS [M-ISIS]. It is used to introduce an integrated
definition of other address families in OSPFv3. Each address-family definition of other address families in OSPFv3. Each address-family
may also need to support multiple topologies, to compute different may also need to support multiple topologies, to compute different
paths for different classes of service or in-band management network. paths for different classes of service or in-band management network.
1.1. Requirements notation
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
[RFC-KEYWORDS].
2. Potential Solutions 2. Potential Solutions
In order to support multiple topologies at least two different In order to support multiple topologies at least two different
solutions are possible. We discuss them briefly below, and describe solutions are possible. We discuss them briefly below, and describe
issues with each of them. issues with each of them.
2.1 Using Different Instance IDs 2.1 Using Different Instance IDs
[INSTANCES] defines a range of Instance IDs for each address family. [INSTANCES] defines a range of Instance IDs for each address family.
It is therefore possible to define multiple topologies by using It is therefore possible to define multiple topologies by using
skipping to change at page 7, line 27 skipping to change at page 8, line 15
16. Forwarding in MT 16. Forwarding in MT
Forwarding must make sure that only routes belonging to the single Forwarding must make sure that only routes belonging to the single
topology are used to forward the packet along its way from source to topology are used to forward the packet along its way from source to
destination. Therefore user configuration MUST be consistently destination. Therefore user configuration MUST be consistently
applied throughout the network so that an incoming packet be applied throughout the network so that an incoming packet be
associated with the corresponding topology. It is outside of the associated with the corresponding topology. It is outside of the
scope of this document to consider different methods of associating scope of this document to consider different methods of associating
an incoming packet to the corresponding topology routes. an incoming packet to the corresponding topology routes.
17. MT reserved value 17. MT-ID reserved value
The following MT range are pre-assigned: The following MT-ID values are defined:
MT#0 - MT#7 IPv6 Unicast 0 - Reserved for IPv6 unicast topology
MT#8 - MT#15 IPv6 Multicast 1 - Reserved for IPv4 in-band management purposes
MT#16 - MT#23 IPv4 Unicast 2 - Reserved for IPv4 unicast topology
MT#24 - MT#31 IPv4 Multicast 3 - Reserved for IPv6 multicast topology
MT#33 - MT#255 Reserved 4 - Reserved for IPv4 multicast topology
5-31 - Reserved for IETF consensus.
32-255 - Reserved for development, experimental and
proprietary features [RFC3692].
18. IPv4 address family considerations 18. IPv4 address family considerations
OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses
for OSPFv3 control packets and next hop calculations. Although IPV6 for OSPFv3 control packets and next hop calculations. Although IPV6
link local addresses could be used as next hops for IPv4 address link local addresses could be used as next hops for IPv4 address
families, it is desirable to have IPv4 next hop addresses. For families, it is desirable to have IPv4 next hop addresses. For
example, in IPv4 multicast having the nexthop address the same as example, in IPv4 multicast having the nexthop address the same as
the PIM neighbor address (IPv4 address) makes it easier to know to the PIM neighbor address (IPv4 address) makes it easier to know to
which upstream neighbor to send a PIM join when doing a RPF lookup which upstream neighbor to send a PIM join when doing a RPF lookup
skipping to change at page 23, line 32 skipping to change at page 24, line 32
The technique described in this document does not introduce any new The technique described in this document does not introduce any new
security issues to the OSPFv3 protocol. security issues to the OSPFv3 protocol.
22. Acknowledgements 22. Acknowledgements
The authors would like to thank Alex Zinin, Acee Lindem, Tom The authors would like to thank Alex Zinin, Acee Lindem, Tom
Henderson, Jeff Ahrenholz and Paul Wells for their comments on the Henderson, Jeff Ahrenholz and Paul Wells for their comments on the
document. document.
23. References 23. IANA Considerations
IANA is requested to create a new registry, "OSPFv3 multi-topology ID
values" with the assignment listed in Section 17 of this document
and registration policies for future assignments.
24. References
Normative References Normative References
[OSPFv3] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", [OSPFv3] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999. RFC 2740, December 1999.
[RFC3692] Narten, T., "Assigning Experimental and Testing
Numbers Considered Useful", BCP 82, RFC 3692, January
2004.
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
Informative Reference Informative Reference
[INSTANCES] Mirtorabi, S. et al, "Support of address families in [INSTANCES] Mirtorabi, S. et al, "Support of address families in
OSPFv3", Internet Draft, work in progress OSPFv3", Internet Draft, work in progress
[M-ISIS] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology [M-ISIS] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology
(MT) Routing in IS-IS", Internet Draft, work in progress (MT) Routing in IS-IS", Internet Draft, work in progress
Appendix A. Global Parameter Appendix A. Global Parameter
RFC2740Compatibility RFC2740Compatibility
This parameter controls which LSAs are used for Default Topology. This parameter controls which LSAs are used for Default Topology.
When set to "enabled", the Default Topology is described using When set to "enabled", the Default Topology is described using
existing LSAs [OSPFv3]. When set to "disabled" the Default Topology existing LSAs [OSPFv3]. When set to "disabled" the Default Topology
is described using Extended LSAs as specified in this memo. This is described using Extended LSAs as specified in this memo. This
parameter is set to "enabled" by default. parameter is set to "enabled" by default.
Authors' Addresses Authors' Addresses
Sina Mirtorabi Abhay Roy Sina Mirtorabi Abhay Roy
Cisco Systems Cisco Systems Force10 Networks Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr. 350 Holger Way 170 W. Tasman Dr.
San Jose, CA 95134, USA San Jose, CA 95134, USA San Jose, CA 95134, USA San Jose, CA 95134, USA
E-mail: sina@cisco.com E-mail: akr@cisco.com
Intellectual Property Statement E-mail: sina@force10netwroks.com E-mail: akr@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 25, line 5 skipping to change at page 26, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
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 (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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 16 change blocks. 
35 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/