< draft-hegde-isis-advertising-te-protocols-02.txt   draft-hegde-isis-advertising-te-protocols-03.txt >
IS-IS WG S. Hegde IS-IS WG S. Hegde
Internet-Draft C. Bowers Internet-Draft C. Bowers
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: September 13, 2017 P. Mattes Expires: March 19, 2018 P. Mattes
M. Nanduri M. Nanduri
S. Giacalone S. Giacalone
Microsoft Microsoft
I. Mohammad I. Mohammad
Arista Networks Arista Networks
March 12, 2017 September 15, 2017
Advertising TE protocols in IS-IS Advertising TE protocols in IS-IS
draft-hegde-isis-advertising-te-protocols-02 draft-hegde-isis-advertising-te-protocols-03
Abstract Abstract
This document defines a mechanism to indicate which traffic This document defines a mechanism to indicate which traffic
engineering protocols are enabled on a link in IS-IS. It does so by engineering protocols are enabled on a link in IS-IS. It does so by
introducing a new traffic-engineering protocol sub-TLV for TLV-22. introducing a new traffic-engineering protocol sub-TLV for TLV-22.
This document also describes mechanisms to address backward This document also describes mechanisms to address backward
compatibility issues for implementations that have not yet been compatibility issues for implementations that have not yet been
upgraded to software that understands this new sub-TLV. upgraded to software that understands this new sub-TLV.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 September 13, 2017. This Internet-Draft will expire on March 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (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
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Explicit and unambiguous indication of TE protocol . . . 4 2.1. Explicit and unambiguous indication of TE protocol . . . 4
2.2. Limit increases in link state advertisements . . . . . . 5
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Traffic-engineering protocol sub-TLV . . . . . . . . . . 5 3.1. Traffic-engineering protocol sub-TLV . . . . . . . . . . 5
3.2. Segment Routing flag considerations . . . . . . . . . . . 6
4. Backward compatibility . . . . . . . . . . . . . . . . . . . 7 4. Backward compatibility . . . . . . . . . . . . . . . . . . . 7
4.1. Scenario with upgraded RSVP-TE transit router but RSVP- 4.1. Scenario with upgraded RSVP-TE transit router but RSVP-
TE ingress router not upgraded . . . . . . . . . . . . . 7 TE ingress router not upgraded . . . . . . . . . . . . . 7
4.2. Scenario with upgraded RSVP-TE ingress router but RSVP- 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP-
TE transit router not upgraded . . . . . . . . . . . . . 8 TE transit router not upgraded . . . . . . . . . . . . . 8
4.3. Need for a long term solution . . . . . . . . . . . . . . 8 4.3. Need for a long term solution . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 4, line 13 skipping to change at page 4, line 13
138) to infer that RSVP signalling is enabled on a link. It is 138) to infer that RSVP signalling is enabled on a link. It is
possible that other implementations may use other sub-TLVs to infer possible that other implementations may use other sub-TLVs to infer
that RSVP is enabled on a link. that RSVP is enabled on a link.
This document defines a standard way to indicate whether or not RSVP, This document defines a standard way to indicate whether or not RSVP,
segment routing, or another future protocol is enabled on a link. In segment routing, or another future protocol is enabled on a link. In
this way, implementations will not have to infer whether or not RSVP this way, implementations will not have to infer whether or not RSVP
is enabled based on the presence of different sub-TLVs, but can use is enabled based on the presence of different sub-TLVs, but can use
the explicit indication. When network operators want to use a non- the explicit indication. When network operators want to use a non-
RSVP traffic engineering application (such as IP/LDP FRR or segment RSVP traffic engineering application (such as IP/LDP FRR or segment
routing), they will be able to advertise traffic engineer sub-TLVs routing), they will be able to advertise traffic engineering sub-TLVs
and explicitly indicate what traffic engineering protocols are and explicitly indicate what traffic engineering protocols are
enabled on a link. enabled on a link.
2. Motivation 2. Goals
The motivation of this document is to provide a mechanism to
advertise TE attributes for current and future applications without
ambiguity. The following objectives help to accomplish this in a
range of deployment scenarios.
1. Advertise TE attributes for the link for variety of applications. 1. The solution should allow the TE protocol enabled on a link to be
communicated unambiguously.
2. Allow the solution to be backward compatible so that nodes that 2. The solution should decouple the advertisement of which TE
do not understand the new advertisement do not cause issues for protocols are enabled on a link from the advertisement of other
existing RSVP deployment. TE attributes.
3. Allow the solution to be extensible for any new applications that 3. The solution should be backward compatible so that nodes that do
need to look at TE attributes. not understand the new advertisement do not cause issues for
existing RSVP deployments.
4. Allow the TE protocol enabled on a link to be communicated 4. The solution should be extensible for new protocols.
unambiguously.
5. The solution should try to limit any increases to the quantity 5. The solution should try to limit any increases to the quantity
and size of link state advertisements. and size of link state advertisements.
2.1. Explicit and unambiguous indication of TE protocol 2.1. Explicit and unambiguous indication of TE protocol
Communicating unambiguously which TE protocol is enabled on a link is Communicating unambiguously which TE protocol is enabled on a link is
important to be able to share this information with other consumers important to be able to share this information with other consumers
through other protocols, aside from just the IGP. For example, for a through other protocols, aside from just the IGP. For example, for a
network running both RSVP-TE and SR, it will be useful to communicate network running both RSVP-TE and SR, it will be useful to communicate
which TE protocols are enabled on which links via BGP-LS [RFC7752] to which TE protocols are enabled on which links via BGP-LS [RFC7752] to
a central controller. Typically, BGP-LS relies on the IGP to a central controller. Typically, BGP-LS relies on the IGP to
distribute IGP topology and traffic engineering information so that distribute IGP topology and traffic engineering information so that
only a few BGP-LS sessions with the central controller are needed. only a few BGP-LS sessions with the central controller are needed.
In order for a router running a BGP-LS session to a central In order for a router running a BGP-LS session to a central
controller to correctly communicate what TE protocols are enabled on controller to correctly communicate what TE protocols are enabled on
the links in the IGP domain, that information first needs to be the links in the IGP domain, that information first needs to be
communicated unambiguously within the IGP itself. As Figure 1 communicated unambiguously within the IGP itself. As Figure 1
illustrates, that is currently not the case. illustrates, that is currently not the case.
2.2. Limit increases in link state advertisements
Over the years, the size of the networks running IS-IS has grown both
in terms of the total number of nodes as well as the number of links
interconnecting those nodes. IS-IS has proven to be quite scalable,
running in very large networks to simultaneously support routing of
IPv4 and IPv6 traffic, as well as the distribution of MPLS traffic
engineering information. With the advent of cloud scale computing,
we expect the demands placed on IS-IS by network operators to
continue to grow as networks become larger and more richly
interconnected. If we expect IS-IS to continue to scale to meet this
challenge, then as we evolve IS-IS, we should be careful to limit the
increases in both the quantity and size of link state advertisements
to the amount necessary to solve the problem at hand. The solution
described in this draft attempts to do that.
3. Solution 3. Solution
3.1. Traffic-engineering protocol sub-TLV 3.1. Traffic-engineering protocol sub-TLV
A new Traffic-engineering protocol sub-TLV is added in the TLV 22 A new Traffic-engineering protocol sub-TLV is added in the TLV 22
[RFC5305] or TLV 222 to indicate the protocols enabled on the link. [RFC5305] or TLV 222 to indicate the protocols enabled on the link.
The sub-TLV has flags in the value field to indicate the protocol The sub-TLV has flags in the value field to indicate the protocol
enabled on the link. The length field is variable to allow the flags enabled on the link. The length field is variable to allow the flags
field to grow for future requirements. field to grow for future requirements.
skipping to change at page 6, line 47 skipping to change at page 6, line 30
A router supporting the TE protocol sub-TLV which receives an A router supporting the TE protocol sub-TLV which receives an
advertisement for a link containing TLV 22 with the TE protocol sub- advertisement for a link containing TLV 22 with the TE protocol sub-
TLV present SHOULD respect the values of the flags in the TE protocol TLV present SHOULD respect the values of the flags in the TE protocol
sub-TLV. The receiving router SHOULD only consider links with a sub-TLV. The receiving router SHOULD only consider links with a
given TE protocol enabled for inclusion in a path using that TE given TE protocol enabled for inclusion in a path using that TE
protocol. Conversely, links for which the TE protocol sub-TLV is protocol. Conversely, links for which the TE protocol sub-TLV is
present, but for which the TE protocol flag is not set to one, SHOULD present, but for which the TE protocol flag is not set to one, SHOULD
NOT be included in any TE CSPF computations on the receiving router NOT be included in any TE CSPF computations on the receiving router
for the protocol in question. for the protocol in question.
However, if the SR protocol flag is set to zero on a link but the
adjacency-sids are advertised for that link, applications MAY use the
adjacency-sid for other purposes, for example OAM.
The ability for a receiving router to determine whether or not the The ability for a receiving router to determine whether or not the
sending router is capable of sending the TE protocol sub-TLV is also sending router is capable of sending the TE protocol sub-TLV is also
used for backward compatibility as described in Section 4. used for backward compatibility as described in Section 4.
An implementation that supports the TE protocol sub-TLV SHOULD be An implementation that supports the TE protocol sub-TLV SHOULD be
able to advertise TE sub-TLVs without enabling RSVP-TE signalling on able to advertise TE sub-TLVs without enabling RSVP-TE signalling on
the link. the link.
3.2. Segment Routing flag considerations
The Segment Routing (SR) architecture assumes that the SR topology is
congruent with the IGP topology. The path described by a prefix
segment is computed using the SPF algorithm applied to the IGP
topology, which is the same as the SR topology. Therefore, the
presence or absence of the Segment Routing flag MUST NOT be
interpreted as modifying the SR topology, which is always congruent
with the IGP topology.
It is however useful for a centralized application (or an ingress
router) to know whether or not it should expect to be able to forward
traffic over a given link using labels distributed via SR. If a link
is advertised with the TE protocol sub-TLV and the SR flag set to
zero, then a centralized application can assume that traffic sent
with a prefix segment whose path crosses that link is unlikely to be
forwarded across that link. With this information, a centralized
application can decide to use a different path for that traffic by
using a different label stack.
4. Backward compatibility 4. Backward compatibility
Routers running older software that do not understand the new Routers running older software that do not understand the new
Traffic-Engineering protocol sub-TLV will continue to interpret the Traffic-Engineering protocol sub-TLV will continue to interpret the
presence of some sub-TLVs in TLV 22 or the presence of TLV 138 as presence of some sub-TLVs in TLV 22 or the presence of TLV 138 as
meaning that RSVP is enabled a link. A network operator may not want meaning that RSVP is enabled a link. A network operator may not want
to or be able to upgrade all routers in the domain at the same time. to or be able to upgrade all routers in the domain at the same time.
There are two backward compatibility scenarios to consider depending There are two backward compatibility scenarios to consider depending
on whether the router that doesn't understand the new TE protocol on whether the router that doesn't understand the new TE protocol
sub-TLV is an RSVP-TE ingress router or an RSVP-TE transit router. sub-TLV is an RSVP-TE ingress router or an RSVP-TE transit router.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
6. IANA Considerations 6. IANA Considerations
This specification updates one IS-IS registry: This specification updates one IS-IS registry:
The extended IS reachability TLV Registry The extended IS reachability TLV Registry
i) Traffic-engineering Protocol sub-tlv = Suggested value 40 i) Traffic-engineering Protocol sub-tlv = Suggested value 40
7. Acknowledgements 7. Acknowledgements
The authors thank Alia Atlas and Les Ginsberg for helpful discissions The authors thank Alia Atlas, Les Ginsberg, and Peter Psenak for
on the topic of this draft. helpful discussions on the topic of this draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-09 (work in progress), July 2016. spring-segment-routing-09 (work in progress), July 2016.
[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>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016, RFC 7810, DOI 10.17487/RFC7810, May 2016,
<http://www.rfc-editor.org/info/rfc7810>. <https://www.rfc-editor.org/info/rfc7810>.
8.2. Informative References 8.2. Informative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <http://www.rfc-editor.org/info/rfc7916>. July 2016, <https://www.rfc-editor.org/info/rfc7916>.
Authors' Addresses Authors' Addresses
Shraddha Hegde Shraddha Hegde
Juniper Networks Juniper Networks
Embassy Business Park Embassy Business Park
Bangalore, KA 560093 Bangalore, KA 560093
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
 End of changes. 25 change blocks. 
51 lines changed or deleted 47 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/