< draft-ietf-ospf-two-part-metric-01.txt   draft-ietf-ospf-two-part-metric-02.txt >
Open Shortest Path First Z. Zhang Open Shortest Path First Z. Zhang
Internet-Draft L. Wang Internet-Draft L. Wang
Updates: 2328, 5340 (if approved) Juniper Networks, Inc. Updates: 2328, 5340 (if approved) Juniper Networks, Inc.
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: January 26, 2016 Cisco Systems Expires: June 1, 2016 Cisco Systems
D. Dubois D. Dubois
General Dynamics C4S General Dynamics C4S
V. Julka V. Julka
T. McMillan T. McMillan
L3 Communications, Linkabit L3 Communications, Linkabit
July 25, 2015 November 29, 2015
OSPF Two-part Metric OSPF Two-part Metric
draft-ietf-ospf-two-part-metric-01.txt draft-ietf-ospf-two-part-metric-02.txt
Abstract Abstract
This document specifies an optional extension to the OSPF protocol, This document specifies an optional extension to the OSPF protocol,
to represent the metric on a multi-access network as two parts: the to represent the metric on a multi-access network as two parts: the
metric from a router to the network, and the metric from the network metric from a router to the network, and the metric from the network
to the router. The router to router metric would be the sum of the to the router. The router to router metric would be the sum of the
two. two.
Requirements Language Requirements Language
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 26, 2016. This Internet-Draft will expire on June 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3
3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4 3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4
3.2. Advertising Network-to-Router metric in OSPFv2 . . . . . 4 3.2. Advertising Network-to-Router metric in OSPFv2 . . . . . 4
3.3. Advertising Network-to-Router metric in OSPFv3 . . . . . 5 3.3. Advertising Network-to-Router metric in OSPFv3 . . . . . 5
3.4. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5 3.4. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
3.5. Backward Compatibility . . . . . . . . . . . . . . . . . 5 3.5. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
3.6. Backward Compatibility . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
For a broadcast network, a Network-LSA is advertised to list all For a broadcast network, a Network-LSA is advertised to list all
routers on the network, and each router on the network includes a routers on the network, and each router on the network includes a
link in its Router-LSA to describe its connection to the network. link in its Router-LSA to describe its connection to the network.
The link in the Router-LSA includes a metric but the listed routers The link in the Router-LSA includes a metric but the listed routers
in the Network LSA do not include a metric. This is based on the in the Network LSA do not include a metric. This is based on the
assumption that from a particular router, all others on the same assumption that from a particular router, all others on the same
network can be reached with the same metric. network can be reached with the same metric.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
need to be running any layer-3 protocol. Therefore for generality, need to be running any layer-3 protocol. Therefore for generality,
the metric is abstracted as to/from the "network" rather that the metric is abstracted as to/from the "network" rather that
specifically to/from the "satellite". specifically to/from the "satellite".
3. Speficications 3. Speficications
The following protocol specifications are added to or modified from The following protocol specifications are added to or modified from
the base OSPF protocol. If an area contains one or more two-part the base OSPF protocol. If an area contains one or more two-part
metric networks, then all routers in the area must support the metric networks, then all routers in the area must support the
extensions specified herein. This is ensured by procedures described extensions specified herein. This is ensured by procedures described
in Section 3.5. in Section 3.6.
3.1. Router Interface Parameters 3.1. Router Interface Parameters
The "Router interface parameters" have the following additions: The "Router interface parameters" have the following additions:
o Two-part metric: TRUE if the interface connects to a multi-access o Two-part metric: TRUE if the interface connects to a multi-access
network that uses two-part metric. All routers connected to the network that uses two-part metric. All routers connected to the
same network SHOULD have the same configuration for their same network SHOULD have the same configuration for their
corresponding interfaces. corresponding interfaces.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
used, though it is part of the Router-Link TLV of E-Router-LSA [ietf- used, though it is part of the Router-Link TLV of E-Router-LSA [ietf-
ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not
defined so the only valid value for the MT field is 0 and only one defined so the only valid value for the MT field is 0 and only one
such Sub-TLV SHOULD be included in the Router-Link TLV. Received such Sub-TLV SHOULD be included in the Router-Link TLV. Received
Sub-TLVs with non-zero MT field MUST be ignored. Sub-TLVs with non-zero MT field MUST be ignored.
Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link
Type 2 (connection to a transit network) and MUST be ignored if Type 2 (connection to a transit network) and MUST be ignored if
received for other link types. received for other link types.
3.4. SPF Calculation 3.4. OSPF Stub Router Behavior
When an OSPF router with interfaces including two-part metric is
advertising itself as a stub router [RFC6987], only the Router-to-
Network metric in the stub router's OSPF Router-LSA links is set to
the MaxLinkMetric. This is fully backward compatible and will result
in the same behavior as [RFC6987].
3.5. SPF Calculation
During the first stage of shortest-path tree calculation for an area, During the first stage of shortest-path tree calculation for an area,
when a vertex V corresponding to a Network-LSA is added to the when a vertex V corresponding to a Network-LSA is added to the
shortest-path tree and its adjacent vertex W (joined by a link in V's shortest-path tree and its adjacent vertex W (joined by a link in V's
corresponding Network LSA), the cost from V to W, which is W's corresponding Network LSA), the cost from V to W, which is W's
network-to-router cost, is determined as follows: network-to-router cost, is determined as follows:
o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque
LSA with an Extended Link TLV for the link from W to V, and the LSA with an Extended Link TLV for the link from W to V, and the
Extended Link TLV has a Network-to-Router Metric Sub-TLV for the Extended Link TLV has a Network-to-Router Metric Sub-TLV for the
corresponding topology, then the cost from V to W is the metric in corresponding topology, then the cost from V to W is the metric in
the Sub-TLV. Otherwise, the cost is 0. the Sub-TLV. Otherwise, the cost is 0.
o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a
Router-Link TLV for the link from W to V, and the Router-Link TLV Router-Link TLV for the link from W to V, and the Router-Link TLV
has a Network-to-Router Metric Sub-TLV, then the cost from V to W has a Network-to-Router Metric Sub-TLV, then the cost from V to W
is the metric in the Sub-TLV. If not, the cost is 0. is the metric in the Sub-TLV. If not, the cost is 0.
3.5. Backward Compatibility 3.6. Backward Compatibility
Due to the change of procedures in the SPF calculation, all routers Due to the change of procedures in the SPF calculation, all routers
in an area that includes one or more two-part metric networks must in an area that includes one or more two-part metric networks must
support the changes specified in this document. To ensure that, if support the changes specified in this document. To ensure that, if
an area is provisioned to support two-part metric networks, all an area is provisioned to support two-part metric networks, all
routers supporting this capability must advertise a Router routers supporting this capability must advertise a Router
Information (RI) LSA with a Router Functional Capabilities TLV [acee- Information (RI) LSA with a Router Functional Capabilities TLV [acee-
ospf-rfc4970bis] that includes the following Router Functional ospf-rfc4970bis] that includes the following Router Functional
Capability Bit: Capability Bit:
Bit Capabilities Bit Capabilities
0 OSPF Two-part Metric [TPM] 0 OSPF Two-part Metric [TPM]
Upon detecting the presence of a reachable Router-LSA without a Upon detecting the presence of a reachable Router-LSA without a
companion RI LSA that has the bit set, all routers MUST disable the companion RI LSA that has the bit set, all routers MUST recalculate
two-part metric functionalities and take the following actions: routes w/o considering any network-to-router costs.
o If this router currently advertises network-to-router costs,
remove the Network-to-Router Metric Sub-TLVs. This may lead to
removal of parent TLVs and even withdrawal of the parent LSAs.
o Recalculate routes w/o considering any network-to-router costs.
4. IANA Considerations 4. IANA Considerations
This document requests IANA to assigna a new bit in the Router This document requests IANA to assigna a new bit in the Router
Functional Capabilities TLV to indicate the capability of supporting Functional Capabilities TLV to indicate the capability of supporting
two-part metric, a new Sub-TLV in the OSPF Extended-Link TLV Sub-TLV two-part metric, a new Sub-TLV in the OSPF Extended-Link TLV Sub-TLV
Registry, and a new Sub-TLV in the The OSPFv3 Extend-LSA Sub-TLV Registry, and a new Sub-TLV in the The OSPFv3 Extend-LSA Sub-TLV
registry. registry.
5. Security Considerations 5. Security Considerations
skipping to change at page 7, line 13 skipping to change at page 7, line 13
in progress), July 2014. in progress), July 2014.
[I-D.ietf-ospf-lsa-extend] [I-D.ietf-ospf-lsa-extend]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem,
"OSPFv2 LSA Extendibility", draft-ietf-ospf-lsa-extend-00 "OSPFv2 LSA Extendibility", draft-ietf-ospf-lsa-extend-00
(work in progress), August 2014. (work in progress), August 2014.
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09
(work in progress), February 2015. (work in progress), November 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>. <http://www.rfc-editor.org/info/rfc5340>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, Yeung, "OSPF Link-Local Signaling", RFC 5613,
DOI 10.17487/RFC5613, August 2009, DOI 10.17487/RFC5613, August 2009,
<http://www.rfc-editor.org/info/rfc5613>. <http://www.rfc-editor.org/info/rfc5613>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987,
DOI 10.17487/RFC6987, September 2013,
<http://www.rfc-editor.org/info/rfc6987>.
7.2. Informative References 7.2. Informative References
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
and Point-to-Multipoint Interface Type", RFC 6845, and Point-to-Multipoint Interface Type", RFC 6845,
DOI 10.17487/RFC6845, January 2013, DOI 10.17487/RFC6845, January 2013,
<http://www.rfc-editor.org/info/rfc6845>. <http://www.rfc-editor.org/info/rfc6845>.
Authors' Addresses Authors' Addresses
Jeffrey Zhang
Zhaohui Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Lili Wang Lili Wang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
 End of changes. 13 change blocks. 
21 lines changed or deleted 30 lines changed or added

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