draft-ietf-ospf-mt-07.txt   draft-ietf-ospf-mt-08.txt 
Network Working Group P. Psenak Network Working Group P. Psenak
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track S. Mirtorabi Intended status: Standards Track S. Mirtorabi
Expires: May 31, 2007 Force10 Networks Expires: July 24, 2007 Force10 Networks
A. Roy A. Roy
L. Nguyen L. Nguyen
P. Pillay-Esnault P. Pillay-Esnault
Cisco Systems Cisco Systems
November 27, 2006 January 20, 2007
Multi-Topology (MT) Routing in OSPF Multi-Topology (MT) Routing in OSPF
draft-ietf-ospf-mt-07.txt draft-ietf-ospf-mt-08.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 39 skipping to change at page 1, line 39
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 May 31, 2007. This Internet-Draft will expire on July 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This draft describes an extension to Open Shortest Path First (OSPF) This draft describes an extension to Open Shortest Path First (OSPF)
in order to define independent IP topologies called Multi-Topologies in order to define independent IP topologies called Multi-Topologies
(MTs). The Multi-Topologies extension can be used for computing (MTs). The Multi-Topologies extension can be used for computing
different paths for unicast traffic, multicast traffic, different different paths for unicast traffic, multicast traffic, different
classes of service based on flexible criteria, or an in-band network classes of service based on flexible criteria, or an in-band network
management topology. management topology.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
4.1. Exclusion of Links in the Default Topology . . . . . . . . 9 4.1. Exclusion of Links in the Default Topology . . . . . . . . 9
4.2. New Area Data Structure Parameter . . . . . . . . . . . . 9 4.2. New Area Data Structure Parameter . . . . . . . . . . . . 9
4.3. Adjacency Formation with Link Exclusion Capability . . . . 10 4.3. Adjacency Formation with Link Exclusion Capability . . . . 10
4.4. OSPF Control Packets Transmission Over Excluded Links . . 11 4.4. OSPF Control Packets Transmission Over Excluded Links . . 11
4.5. OSPF LSA Advertisement and SPF Computation for 4.5. OSPF LSA Advertisement and SPF Computation for
Excluded Links . . . . . . . . . . . . . . . . . . . . . . 11 Excluded Links . . . . . . . . . . . . . . . . . . . . . . 11
5. Interoperability between MT Capable and Non-MT Capable 5. Interoperability between MT Capable and Non-MT Capable
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Demand Circuit Compatibility Considerations . . . . . . . 12 5.1. Demand Circuit Compatibility Considerations . . . . . . . 12
6. Migration from non-MT-Area to MT-area . . . . . . . . . . . . 13 6. Migration from non-MT-Area to MT-area . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. MT Network Management Considerations . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. Create dedicated management topology to include all
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 the nodes . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.2. Extend the default topology to all the nodes . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. OSPF data formats . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. OSPF data formats . . . . . . . . . . . . . . . . . . 19
B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 22 B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 24 B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20
B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 21
B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
OSPF uses a fixed packet format, therefore it is not easy to OSPF uses a fixed packet format, therefore it is not easy to
introduce any backward compatible extensions. However, the OSPF introduce any backward compatible extensions. However, the OSPF
specification [OSPF] introduced Type of Service (TOS) metric in an specification [OSPF] introduced Type of Service (TOS) metric in an
earlier specification [TOS-OSPF] in order to announce a different earlier specification [TOS-OSPF] in order to announce a different
link cost based on TOS. TOS based routing as described in [TOS-OSPF] link cost based on TOS. TOS based routing as described in [TOS-OSPF]
was never deployed and was subsequently deprecated. [M-ISIS] was never deployed and was subsequently deprecated. [M-ISIS]
describes a similar mechanism for ISIS. describes a similar mechanism for ISIS.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
3.7. MT-ID Values 3.7. MT-ID Values
Since AS-External-LSAs use the high order bit in the MT-ID field (E Since AS-External-LSAs use the high order bit in the MT-ID field (E
bit) for the external metric-type, only MT-IDs in the 0 to 127 range bit) for the external metric-type, only MT-IDs in the 0 to 127 range
are valid. The following MT-ID values are reserved: are valid. The following MT-ID values are reserved:
0 - Reserved for advertising the metric associated 0 - Reserved for advertising the metric associated
with the default topology (see Section 4.2) with the default topology (see Section 4.2)
1 - Reserved for advertising the metric associated 1 - Reserved for advertising the metric associated
with the default multicast topology with the default multicast topology
2-127 - Reserved for definition as per local policy and 2 - Reserved for IPv4 in-band management purposes.
configuration 3-31 - Reserved for IETF consensus.
32-127 - Reserved for development, experimental and
proprietary features [RFC3692].
128-255 - Invalid and SHOULD be ignored. 128-255 - Invalid and SHOULD be ignored.
3.8. Forwarding in MT 3.8. Forwarding in MT
It is outside of the scope of this document to specify how the It is outside of the scope of this document to specify how the
information in various topology specific forwarding structures are information in various topology specific forwarding structures are
used during packet forwarding or how incoming packets are associated used during packet forwarding or how incoming packets are associated
with the corresponding topology. For correct operation, both with the corresponding topology. For correct operation, both
forwarding behavior and methods of associating incoming packets to a forwarding behavior and methods of associating incoming packets to a
corresponding topology must be consistently applied in the network. corresponding topology must be consistently applied in the network.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
capable so that inter-area routing is assured for MT destinations capable so that inter-area routing is assured for MT destinations
in different areas. in different areas.
4. Gradually the whole network can be made MT capable. 4. Gradually the whole network can be made MT capable.
Note that inter-area routing for the MT-area still depends on the Note that inter-area routing for the MT-area still depends on the
backbone area. Therefore, if different areas configured for a given backbone area. Therefore, if different areas configured for a given
topology need to communicate, the backbone area also needs to be topology need to communicate, the backbone area also needs to be
configured for this topology. configured for this topology.
7. Security Considerations 7. MT Network Management Considerations
When multiple OSPF topologies exist within a domain, some of the
routers can be configured to participate in a subset of the MTs in
the network. This section discusses some of the options we have to
enable operations or the network management stations to access those
routers.
7.1. Create dedicated management topology to include all the nodes
This approach is to setup a dedicated management topology or 'in-
band' management topology. This 'mgmt' topology will include all the
routers need to be managed. The computed routes in the topology will
be installed into the 'mgmt' RIB. In the condition of the 'mgmt'
topology uses a set of non-overlapping address space with the default
topology, those 'mgmt' routes can also be optionally installed into
the default RIB. The advantages of duplicate 'mgmt' routes in both
RIBs include: the network management utilities on the system does not
have to be modified to use specific RIB other than the default RIB;
the 'mgmt' topology can share the same link with the default topology
if so designed.
7.2. Extend the default topology to all the nodes
Even in the case default topology is not used on some of the nodes in
the IP forwarding, we may want to extend the default topology to
those nodes for the purpose of network management. Operators SHOULD
set high cost on the links which belong to the extended portion of
the default topology. This way the IP data traffic will not be
forwarded through those nodes during network topology changes.
8. Security Considerations
This document does not raise any security issues that are not already This document does not raise any security issues that are not already
covered in [OSPF]. covered in [OSPF].
8. IANA Considerations 9. IANA Considerations
The T-bit as defined in [TOS-OSPF] for a router's TOS capability is The T-bit as defined in [TOS-OSPF] for a router's TOS capability is
redefined as the MT-bit in this document. No IANA action is required redefined as the MT-bit in this document. No IANA action is required
for the MT-bit. for the MT-bit.
Similarly, the TOS field for Router-LSAs, Summary-LSAs, Type-5 and Similarly, the TOS field for Router-LSAs, Summary-LSAs, Type-5 and
Type-7 AS-external LSAs as defined in [OSPF] is redefined as MT-ID in Type-7 AS-external LSAs as defined in [OSPF] is redefined as MT-ID in
Section 3.7. Section 3.7.
MT-ID space is one byte and the entire range is defined by this IANA is requested to create a new registry, "OSPF multi-topology ID
document. No IANA action is required to manage the MT-ID space. values" with the assignment listed in Section 3.7 of this document
and registration policies for future assignments.
9. References 10. References
9.1. Normative References 10.1. Normative References
[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits",
RFC 1793, April 1995. RFC 1793, April 1995.
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC-KEYWORDS] [RFC-KEYWORDS]
Bradner, S., "Key words for use in RFC's to Indicate Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", RFC 3692, January 2004.
[TOS-OSPF] [TOS-OSPF]
Moy, J., "OSPF Version 2", RFC 1583, March 1994. Moy, J., "OSPF Version 2", RFC 1583, March 1994.
9.2. Informative References 10.2. Informative References
[M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in IS-IS", Topology (MT) Routing in IS-IS",
draft-ietf-isis-wg-multi-topology-07.txt (work in draft-ietf-isis-wg-multi-topology-11.txt (work in
progress). progress).
[STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137, McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001. June 2001.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Scott Sturgess, Alvaro Retana, David The authors would like to thank Scott Sturgess, Alvaro Retana, David
Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their
skipping to change at page 24, line 7 skipping to change at page 25, line 7
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: ppe@cisco.com Email: ppe@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 17 change blocks. 
34 lines changed or deleted 75 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/