OSPF Two-part Metric
draft-ietf-ospf-two-part-metric-09
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (ospf WG) | |
|---|---|---|---|
| Authors | Zhaohui (Jeffrey) Zhang , Lili Wang , Acee Lindem | ||
| Last updated | 2016-10-13 (Latest revision 2016-08-29) | ||
| Replaces | draft-zzhang-ospf-two-part-metric | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
GENART Telechat review
Ready
OPSDIR Last Call review
(of
-05)
Has Nits
GENART Last Call review
(of
-05)
Almost Ready
|
||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Yingzhen Qu | ||
| Shepherd write-up | Show Last changed 2016-04-29 | ||
| IESG | IESG state | Approved-announcement to be sent::Revised I-D Needed | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Alia Atlas | ||
| Send notices to | "Yingzhen Qu" <yiqu@cisco.com> | ||
| IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-ospf-two-part-metric-09
Network Working Group Z. Zhang
Internet-Draft L. Wang
Updates: 2328, 5340 (if approved) Juniper Networks, Inc.
Intended status: Standards Track A. Lindem
Expires: March 2, 2017 Cisco Systems
August 29, 2016
OSPF Two-part Metric
draft-ietf-ospf-two-part-metric-09.txt
Abstract
This document specifies an optional extension to the OSPF protocol,
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
to the router. The router to router metric would be the sum of the
two. This document updates RFC 2328.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 2, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Zhang, et al. Expires March 2, 2017 [Page 1]
Internet-Draft ospf-two-part-metric August 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3
3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4
3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4
3.3. Advertising Network-to-Router TE Metric . . . . . . . . . 5
3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5
3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Appendix B. Contributors' Addreses . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
With Open Shortest Path First (OSPF, [RFC2328], [RFC5340]) protocol,
for a broadcast network, a Network-LSA is advertised to list all
routers on the network, and each router on the network includes a
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
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
network can be reached with the same metric.
With some broadcast networks, different routers can be reached with
different metrics. [RFC6845] extends the OSPF protocol with a hybrid
interface type for that kind of broadcast network, where no Network
LSA is advertised and Router-LSAs simply include p2p links to all
routers on the same network with individual metrics. Broadcast
capability is still utilized to optimize database synchronization and
adjacency maintenance.
That works well for broadcast networks where the metric between
different pair of routers are really independent. For example, VPLS
networks.
Zhang, et al. Expires March 2, 2017 [Page 2]
Internet-Draft ospf-two-part-metric August 2016
With certain types of broadcast networks, further optimization can be
made to reduce the size of the Router-LSAs and number of updates.
Consider a satellite radio network with fixed and mobile ground
terminals. All communication goes through the satellite. When the
mobile terminals move about, their communication capability may
change. When OSPF runs over the radio network (routers being or in
tandem with the terminals), [RFC6845] hybrid interface can be used,
but with the following drawbacks.
Consider that one terminal/router moves into an area where its
communication capability degrades significantly. Through the radio
control protocol, all other routers determine that the metric to this
particular router changed and they all need to update their Router-
LSAs accordingly. The router in question also determines that its
metric to reach all others also changed and it also needs to update
its Router-LSA. Consider that there could be many terminals and many
of them can be moving fast and frequently, the number/frequency of
updates of those large Router-LSAs could inhibit network scaling.
1.1. Requirements Language
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 [RFC2119].
2. Proposed Enhancement
Notice that in the above scenario, when one terminal's communication
capability changes, its metric to all other terminals and the metric
from all other terminals to it will all change in a similar fashion.
Given this, the above problem can be easily addressed by breaking the
metric into two parts: the metric to the satellite and the metric
from the satellite. The metric from terminal R1 to R2 would be the
sum of the metric from R1 to the satellite and the metric from the
satellite to R2.
Now instead of using the [RFC6845] hybrid interface type, the network
is just treated as a regular broadcast network. A router on the
network no longer lists individual metrics to each neighbor in its
Router-LSA. Instead, each router advertises the metric from the
network to itself in addition to the normal metric for the network.
With the normal Router-to-Network and additional Network-to-Router
metrics advertised for each router, individual router-to-router
metric can be calculated.
Zhang, et al. Expires March 2, 2017 [Page 3]
Internet-Draft ospf-two-part-metric August 2016
With the proposed enhancement, the size of Router-LSA will be
significantly reduced. In addition, when a router's communication
capability changes, only that router needs to update its Router-LSA.
Note that while the example uses the satellite as the relay point at
the radio level (layer-2), at layer-3, the satellite does not
participate in packet forwarding. In fact, the satellite does not
need to be running any layer-3 protocol. Therefore for generality,
the metric is abstracted as to/from the "network" rather that
specifically to/from the "satellite".
3. Speficications
The following protocol specifications are added to or modified from
the base OSPF protocol. If an area contains one or more two-part
metric networks, then all routers in the area MUST support the
extensions specified herein. This is ensured by procedures described
in Section 3.7.
3.1. Router Interface Parameters
The "Router interface parameters" have the following additions:
o Two-part metric: TRUE if the interface connects to a multi-access
network that uses two-part metric. All routers connected to the
same network SHOULD have the same configuration for their
corresponding interfaces.
o Interface input cost: Link state metric from the two-part-metric
network to this router. Defaulted to "Interface output cost" but
not valid for normal networks using a single metric. May be
configured or dynamically adjusted to a value different from the
"Interface output cost".
3.2. Advertising Network-to-Router Metric in OSPFv2
For OSPFv2, the Network-to-Router metric is encoded in an OSPF
Extended Link TLV Sub-TLV [RFC7684], defined in this document as the
Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD2.
The length of the Sub-TLV is 4 (for the value part only). The value
part of the Sub-TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT | 0 | MT metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang, et al. Expires March 2, 2017 [Page 4]
Internet-Draft ospf-two-part-metric August 2016
Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV,
one for each topology [RFC4915]. The OSPF Extended Link TLV
identifies the transit link to the network, and is part of an OSPFv2
Extended-Link Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-
Link TLVs for Link Type 2 (link to transit network), and MUST be
ignored if received for other link types.
3.3. Advertising Network-to-Router TE Metric
A Traffic Engineering Network-to-Router Metric Sub-TLV is defined,
similar to the Traffic Engineering Metric Sub-TLV defined in
Section 2.5.5 of [RFC3630]. The only difference is the TLV type,
which is TBD3. The Sub-TLV MUST only appear in type 2 Link TLVs
(Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs
(OSPFv3) [RFC5329], and MUST appear at most once in one such Link
TLV.
3.4. Advertising Network-to-Router Metric in OSPFv3
Network-to-Router metric advertisement in OSPFv3 Extended-Router-LSA
[I-D.ietf-ospf-ospfv3-lsa-extend] will be described in a separate
document.
3.5. 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.6. SPF Calculation
The first stage of the shortest-path tree calculation is described in
section 16.1 of [RFC2328]. With two-part metric, when a vertex V
corresponding to a Network-LSA has just been added to the Shortest
Path Tree (SPT) and an adjacent vertex W (joined by a link in V's
corresponding Network-LSA) is being added to the candidate list, the
cost from V to W (W's network-to-router cost) is determined as
follows:
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
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
the Sub-TLV. Otherwise, the cost is 0.
Zhang, et al. Expires March 2, 2017 [Page 5]
Internet-Draft ospf-two-part-metric August 2016
o OSPFv3 [RFC5340] SPF changes will be described in a separate
document.
3.7. Backward Compatibility
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
support the changes specified in this document. To ensure that, if
an area is provisioned to support two-part metric networks, all
routers supporting this capability must advertise a Router
Information (RI) LSA with a Router Functional Capabilities TLV
[RFC7770] that includes the following Router Functional Capability
Bit:
Bit Capabilities
TBD1 OSPF Two-part Metric (TPM)
Upon detecting the presence of a reachable Router-LSA without a
companion RI LSA that has the bit set, all routers MUST recalculate
routes without considering any network-to-router costs.
4. IANA Considerations
This document requests the following IANA assignments:
o A new bit (TBD1) in Registry for OSPF Router Informational
Capability Bits, to indicate the capability of supporting two-part
metric.
o A new Sub-TLV type (TBD2) in OSPF Extended Link TLV Sub-TLV
registry, for the Network-to-Router Metric Sub-TLV.
o A new Sub-TLV type (TBD3) in Types for sub-TLVs of TE Link TLV
(Value 2) registry, for the Network-to-Router TE Metric Sub-TLV.
5. Security Considerations
This document does not introduce new security risks. Existing
security considerations in OSPFv2 and OSPFv3 apply.
6. References
6.1. Normative References
Zhang, et al. Expires March 2, 2017 [Page 6]
Internet-Draft ospf-two-part-metric August 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008,
<http://www.rfc-editor.org/info/rfc5329>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <http://www.rfc-editor.org/info/rfc7684>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>.
6.2. Informative References
[I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10
(work in progress), May 2016.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
Zhang, et al. Expires March 2, 2017 [Page 7]
Internet-Draft ospf-two-part-metric August 2016
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
and Point-to-Multipoint Interface Type", RFC 6845,
DOI 10.17487/RFC6845, January 2013,
<http://www.rfc-editor.org/info/rfc6845>.
[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>.
Appendix A. Acknowledgements
The authors would like to thank Abhay Roy, Hannes Gredler, Peter
Psenak and Eric Wu for their comments and suggestions.
The RFC text was produced using Marshall Rose's xml2rfc tool.
Zhang, et al. Expires March 2, 2017 [Page 8]
Internet-Draft ospf-two-part-metric August 2016
Appendix B. Contributors' Addreses
David Dubois
General Dynamics C4S
400 John Quincy Adams Road
Taunton, MA 02780
EMail: dave.dubois@gd-ms.com
Vibhor Julka
Individual
EMail: vjulka1@yahoo.com
Tom McMillan
L3 Communications, Linkabit
9890 Towne Centre Drive
San Diego, CA 92121
EMail: tom.mcmillan@l-3com.com
Authors' Addresses
Zhaohui Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
Email: zzhang@juniper.net
Lili Wang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
Email: liliw@juniper.net
Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC 27513
Email: acee@cisco.com
Zhang, et al. Expires March 2, 2017 [Page 9]