< draft-ietf-ospf-te-link-attr-reuse-02.txt   draft-ietf-ospf-te-link-attr-reuse-03.txt >
Network Working Group P. Psenak Network Working Group P. Psenak, Ed.
Internet-Draft A. Lindem Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track L. Ginsberg Intended status: Standards Track A. Lindem
Expires: April 30, 2018 Cisco Systems Expires: August 3, 2018 L. Ginsberg
Cisco Systems
W. Henderickx W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Individual Nuage Networks
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Drake J. Drake
Juniper Networks Juniper Networks
October 27, 2017 January 30, 2018
OSPFv2 Link Traffic Engineering (TE) Attribute Reuse OSPFv2 Link Traffic Engineering (TE) Attribute Reuse
draft-ietf-ospf-te-link-attr-reuse-02.txt draft-ietf-ospf-te-link-attr-reuse-03.txt
Abstract Abstract
Various link attributes have been defined in OSPFv2 in the context of Various link attributes have been defined in OSPFv2 in the context of
the MPLS Traffic Engineering (TE) and GMPLS. Many of these link the MPLS Traffic Engineering (TE) and GMPLS. Many of these link
attributes can be used for purposes other than MPLS Traffic attributes can be used for purposes other than MPLS Traffic
Engineering or GMPLS. This documents defines how to distribute such Engineering or GMPLS. This documents defines how to distribute such
attributes in OSPFv2 for applications other than MPLS Traffic attributes in OSPFv2 for applications other than MPLS Traffic
Engineering or GMPLS purposes. Engineering or GMPLS purposes.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 30, 2018. This Internet-Draft will expire on August 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 2, line 36
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Link attributes examples . . . . . . . . . . . . . . . . . . 3 2. Link attributes examples . . . . . . . . . . . . . . . . . . 4
3. Advertising Link Attributes . . . . . . . . . . . . . . . . . 4 3. Advertising Link Attributes . . . . . . . . . . . . . . . . . 4
3.1. TE Opaque LSA . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TE Opaque LSA . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Extended Link Opaque LSA . . . . . . . . . . . . . . . . 5 3.2. Extended Link Opaque LSA . . . . . . . . . . . . . . . . 5
3.3. Selected Approach . . . . . . . . . . . . . . . . . . . . 5 3.3. Selected Approach . . . . . . . . . . . . . . . . . . . . 5
4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 6 4. Reused TE link attributes . . . . . . . . . . . . . . . . . . 6
4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 6 4.1. Shared Risk Link Group (SRLG) . . . . . . . . . . . . . . 6
4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 6 4.2. Extended Metrics . . . . . . . . . . . . . . . . . . . . 6
4.3. Administrative Group . . . . . . . . . . . . . . . . . . 7 4.3. Administrative Group . . . . . . . . . . . . . . . . . . 7
5. Advertisement of Application Specific Values . . . . . . . . 7 5. Advertisement of Application Specific Values . . . . . . . . 7
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 5.1. Special Considerations for Maximum Link Bandwidth . . . . 10
7. Attribute Advertisements and Enablement . . . . . . . . . . . 10 5.2. Special Considerations for Unreserved Bandwidth . . . . . 11
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Attribute Advertisements and Enablement . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Various link attributes have been defined in OSPFv2 [RFC2328] in the Various link attributes have been defined in OSPFv2 [RFC2328] in the
context of the MPLS traffic engineering and GMPLS. All these context of the MPLS traffic engineering and GMPLS. All these
attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV attributes are distributed by OSPFv2 as sub-TLVs of the Link-TLV
advertised in the OSPFv2 TE Opaque LSA [RFC3630]. advertised in the OSPFv2 TE Opaque LSA [RFC3630].
Many of these link attributes are useful outside of the traditional Many of these link attributes are useful outside of the traditional
MPLS Traffic Engineering or GMPLS. This brings its own set of MPLS Traffic Engineering or GMPLS. This brings its own set of
skipping to change at page 10, line 30 skipping to change at page 10, line 30
- Unidirectional Residual Bandwidth - Unidirectional Residual Bandwidth
- Unidirectional Available Bandwidth - Unidirectional Available Bandwidth
- Unidirectional Utilized Bandwidth - Unidirectional Utilized Bandwidth
- Administrative Group - Administrative Group
- Extended Administrative Group - Extended Administrative Group
5.1. Special Considerations for Maximum Link Bandwidth
Maximum link bandwidth is an application independent attribute of the
link. When advertised using the Application Specific Link Attributes
sub-TLV, multiple values for the same link MUST NOT be advertised.
This can be accomplished most efficiently by having a single
advertisement for a given link where both the Standard Application
Bit Mask and the User Defined Application Bit Mask are not present
(See Section Section 5).
Alternatively, similar can be achieved by having a single
advertisement for a given link where the Application Bit Mask
identifies all the applications which are making use of the value for
that link.
It is also possible to advertise the same value for a given link
multiple times with disjoint sets of applications specified in the
Application Bit Mask. This is less efficient but still valid.
If different values for Maximum Link Bandwidth for a given link are
advertised, all values MUST be ignored.
5.2. Special Considerations for Unreserved Bandwidth
Unreserved bandwidth is an attribute specific to RSVP. When
advertised using the Application Specific Link Attributes sub-TLV,
bits other than the RSVP-TE(R-bit) MUST NOT be set in the Application
Bit Mask. If an advertisement of Unreserved Bandwidth is received
with bits other than the RSVP-TE bit set, the advertisement MUST be
ignored.
6. Deployment Considerations 6. Deployment Considerations
If link attributes are advertised associated with zero length If link attributes are advertised associated with zero length
application bit masks for both standard applications and user defined application bit masks for both standard applications and user defined
applications, then that set of link attributes MAY be used by any applications, then that set of link attributes MAY be used by any
application. If support for a new application is introduced on any application. If support for a new application is introduced on any
node in a network in the presence of such advertisements, these node in a network in the presence of such advertisements, these
advertisements MAY be used by the new application. If this is not advertisements MAY be used by the new application. If this is not
what is intended, then existing advertisements MUST be readvertised what is intended, then existing advertisements MUST be readvertised
with an explicit set of applications specified before a new with an explicit set of applications specified before a new
skipping to change at page 11, line 31 skipping to change at page 12, line 14
Algorithm on that link. Rather the attributes are used to determine Algorithm on that link. Rather the attributes are used to determine
what links are included/excluded in the algorithm specific what links are included/excluded in the algorithm specific
constrained SPF. This is fully specified in constrained SPF. This is fully specified in
[I-D.hegdeppsenak-isis-sr-flex-algo]. [I-D.hegdeppsenak-isis-sr-flex-algo].
If, in the future, additional standard applications are defined to If, in the future, additional standard applications are defined to
use this mechanism, the specification defining this use MUST define use this mechanism, the specification defining this use MUST define
the relationship between application specific link attribute the relationship between application specific link attribute
advertisements and enablement for that application. advertisements and enablement for that application.
This document allows the advertisement of application specific link
attributes with no application identifiers i.e., both the Standard
Application Bit Mask and the User Defined Application Bit Mask are
not present (See Section Section 5). This supports the use of the
link attribute by any application. In the presence of an application
where the advertisement of link attribute advertisements is used to
infer the enablement of an application on that link (e.g., RSVP-TE),
the absence of the application identifier leaves ambiguous whether
that application is enabled on such a link. This needs to be
considered when making use of the "any application" encoding.
8. Backward Compatibility 8. Backward Compatibility
Link attributes may be concurrently advertised in both the TE Opaque Link attributes may be concurrently advertised in both the TE Opaque
LSA [RFC3630] and the Extended Link Opaque LSA [RFC7684]. LSA [RFC3630] and the Extended Link Opaque LSA [RFC7684].
In fact, there is at least one OSPF implementation that utilizes the In fact, there is at least one OSPF implementation that utilizes the
link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP link attributes advertised in TE Opaque LSAs [RFC3630] for Non-RSVP
TE applications. For example, this implementation of LFA and remote TE applications. For example, this implementation of LFA and remote
LFA utilizes links attributes such as Shared Risk Link Groups (SRLG) LFA utilizes links attributes such as Shared Risk Link Groups (SRLG)
[RFC4203] and Admin Group [[RFC3630]advertised in TE Opaque LSAs. [RFC4203] and Admin Group [[RFC3630]advertised in TE Opaque LSAs.
skipping to change at page 13, line 32 skipping to change at page 14, line 27
<https://www.rfc-editor.org/info/rfc7308>. <https://www.rfc-editor.org/info/rfc7308>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>. 2015, <https://www.rfc-editor.org/info/rfc7684>.
12.2. Informative References 12.2. Informative References
[I-D.hegdeppsenak-isis-sr-flex-algo] [I-D.hegdeppsenak-isis-sr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., and a. Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
arkadiy.gulko@thomsonreuters.com, "ISIS Segment Routing Segment Routing Flexible Algorithm", draft-hegdeppsenak-
Flexible Algorithm", draft-hegdeppsenak-isis-sr-flex- isis-sr-flex-algo-01 (work in progress), October 2017.
algo-01 (work in progress), October 2017.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015. (work in progress), October 2015.
[I-D.ietf-ospf-link-overload] [I-D.ietf-ospf-link-overload]
Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L. Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L.
Jalil, "OSPF Link Overload", draft-ietf-ospf-link- Jalil, "OSPF Graceful Link shutdown", draft-ietf-ospf-
overload-09 (work in progress), August 2017. link-overload-14 (work in progress), January 2018.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-21 (work in progress), October 2017. routing-extensions-24 (work in progress), December 2017.
[I-D.ietf-rtgwg-lfa-manageability] [I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and Litkowski, S., Decraene, B., Filsfils, C., Raza, K., and
M. Horneffer, "Operational management of Loop Free M. Horneffer, "Operational management of Loop Free
Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work Alternates", draft-ietf-rtgwg-lfa-manageability-11 (work
in progress), June 2015. in progress), June 2015.
[I-D.psarkar-rtgwg-rlfa-node-protection] [I-D.psarkar-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers, psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers,
C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node
skipping to change at page 15, line 4 skipping to change at page 15, line 42
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>. <https://www.rfc-editor.org/info/rfc7490>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>. 2016, <https://www.rfc-editor.org/info/rfc7855>.
Authors' Addresses Authors' Addresses
Peter Psenak
Cisco Systems Peter Psenak (editor)
Apollo Business Center Cisco Systems, Inc.
Mlynske nivy 43 Eurovea Centre, Central 3
Bratislava, 821 09 Pribinova Street 10
Bratislava 81109
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee@cisco.com Email: acee@cisco.com
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
skipping to change at page 15, line 38 skipping to change at page 16, line 29
Wim Henderickx Wim Henderickx
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerp, 2018 94089 Antwerp, 2018 94089
Belgium Belgium
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Jeff Tantsura Jeff Tantsura
Individual Nuage Networks
USA US
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 17 change blocks. 
35 lines changed or deleted 80 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/