draft-ietf-ospf-segment-routing-msd-12.txt   draft-ietf-ospf-segment-routing-msd-13.txt 
OSPF Working Group J. Tantsura OSPF Working Group J. Tantsura
Internet-Draft Nuage Networks Internet-Draft Nuage Networks
Intended status: Standards Track U. Chunduri Intended status: Standards Track U. Chunduri
Expires: November 10, 2018 Huawei Technologies Expires: November 18, 2018 Huawei Technologies
S. Aldrin S. Aldrin
Google, Inc Google, Inc
P. Psenak P. Psenak
Cisco Systems Cisco Systems
May 09, 2018 May 17, 2018
Signaling MSD (Maximum SID Depth) using OSPF Signaling MSD (Maximum SID Depth) using OSPF
draft-ietf-ospf-segment-routing-msd-12 draft-ietf-ospf-segment-routing-msd-13
Abstract Abstract
This document defines a way for an OSPF Router to advertise multiple This document defines a way for an OSPF Router to advertise multiple
types of supported Maximum SID Depths (MSDs) at node and/or link types of supported Maximum SID Depths (MSDs) at node and/or link
granularity. Such advertisements allow entities (e.g., centralized granularity. Such advertisements allow entities (e.g., centralized
controllers) to determine whether a particular SID stack can be controllers) to determine whether a particular SID stack can be
supported in a given network. This document defines only one type of supported in a given network. This document defines only one type of
MSD, but defines an encoding that can support other MSD types. Here MSD, but defines an encoding that can support other MSD types. Here
the term OSPF means both OSPFv2 and OSPFv3. the term OSPF means both OSPFv2 and OSPFv3.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 10, 2018. This Internet-Draft will expire on November 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4
3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5
4. Using Node and Link MSD Advertisements . . . . . . . . . . . 6 4. Using Node and Link MSD Advertisements . . . . . . . . . . . 6
5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
When Segment Routing(SR) paths are computed by a centralized When Segment Routing(SR) paths are computed by a centralized
controller, it is critical that the controller learns the Maximum SID controller, it is critical that the controller learns the Maximum SID
Depth(MSD) that can be imposed at each node/link on a given SR path Depth(MSD) that can be imposed at each node/link on a given SR path
to insure that the SID stack depth of a computed path doesn't exceed to insure that the SID stack depth of a computed path doesn't exceed
the number of SIDs the node is capable of imposing. the number of SIDs the node is capable of imposing.
The PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals The PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals
MSD in SR PCE Capability TLV and METRIC Object. However, if PCEP is MSD in SR PCE Capability TLV and METRIC Object. However, if PCEP is
not supported/configured on the head-end of an SR tunnel or a not supported/configured on the head-end of an SR tunnel or a
Binding-SID anchor node and controller does not participate in IGP Binding-SID anchor node and controller do not participate in IGP
routing, it has no way to learn the MSD of nodes and links. BGP-LS routing, it has no way to learn the MSD of nodes and links. BGP-LS
[RFC7752] defines a way to expose topology and associated attributes [RFC7752] defines a way to expose topology and associated attributes
and capabilities of the nodes in that topology to a centralized and capabilities of the nodes in that topology to a centralized
controller. MSD signaling by BGP-LS has been defined in controller. MSD signaling by BGP-LS has been defined in
[I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, BGP-LS is [I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, BGP-LS is
configured on a small number of nodes that do not necessarily act as configured on a small number of nodes that do not necessarily act as
head-ends. In order for BGP-LS to signal MSD for all the nodes and head-ends. In order for BGP-LS to signal MSD for all the nodes and
links in the network MSD is relevant, MSD capabilites should be links in the network MSD is relevant, MSD capabilites should be
advertised by every OSPF router in the network. advertised by every OSPF router in the network.
Other types of MSD are known to be useful. For example, Other types of MSD are known to be useful. For example,
[I-D.ietf-ospf-mpls-elc] defines Readable Label Depth Capability [I-D.ietf-ospf-mpls-elc] defines Readable Label Depth Capability
(RLDC) that is used by a head-end to insert an Entropy Label (EL) at (RLDC) that is used by a head-end to insert an Entropy Label (EL) at
a depth that can be read by transit nodes. a depth that can be read by transit nodes.
This document defines an extension to OSPF used to advertise one or This document defines an extension to OSPF used to advertise one or
more types of MSD at node and/or link granularity. It also creates more types of MSD at node and/or link granularity. It also defines
an IANA registry for assigning MSD type identifiers. It also defines
the Base MPLS Imposition MSD type. In the future it is expected, the Base MPLS Imposition MSD type. In the future it is expected,
that new MSD types will be defined to signal additional capabilities that new MSD types will be defined to signal additional capabilities
e.g., entropy labels, SIDs that can be imposed through recirculation, e.g., entropy labels, SIDs that can be imposed through recirculation,
or SIDs associated with another dataplane e.g., IPv6. Although MSD or SIDs associated with another dataplane e.g., IPv6. Although MSD
advertisements are associated with Segment Routing, the advertisements are associated with Segment Routing, the
advertisements MAY be present even if Segment Routing itself is not advertisements MAY be present even if Segment Routing itself is not
enabled. enabled.
1.1. Conventions used in this document 1.1. Conventions used in this document
skipping to change at page 3, line 50 skipping to change at page 3, line 49
PCE: Path Computation Element PCE: Path Computation Element
PCEP: Path Computation Element Protocol PCEP: Path Computation Element Protocol
SR: Segment Routing SR: Segment Routing
SID: Segment Identifier SID: Segment Identifier
LSA: Link state advertisement LSA: Link state advertisement
RI: Router Information LSA RI: OSPF Router Information LSA
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119], [RFC8174] when, and only when they appear in all BCP14 [RFC2119], [RFC8174] when, and only when they appear in all
capitals, as shown here . capitals, as shown here .
2. Node MSD Advertisement 2. Node MSD Advertisement
skipping to change at page 4, line 37 skipping to change at page 4, line 37
| MSD Type and Value ... | MSD Type and Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 1: Node MSD TLV Figure 1: Node MSD TLV
The Type: TBD1 The Type: TBD1
Length: variable (minimum of 2, multiple of 2 octets) and represents Length: variable (minimum of 2, multiple of 2 octets) and represents
the total length of value field. the total length of value field.
Value: consists of one or more pairs of a 1 octet type (IANA Value: consists of one or more pairs of a 1 octet MSD-type and 1
Registry) and 1 octet value. octet MSD-Value.
MSD Type 1 (IANA Section), MSD and the Value field contains the MSD MSD-Type: one of the values defined in the MSD Types registry defined
of the originating router. Node MSD is a number in the range of in [I-D.ietf-isis-segment-routing-msd].
0-255. 0 represents lack of the ability to impose MSD stack of any
depth; any other value represents that of the node. This value
SHOULD represent the minimum value supported by a node.
Other MSD Types are reserved for future extensions. MSD-Value: a number in the range of 0-255. For all MSD-Types, 0
represents lack of the ability to impose MSD stack of any depth; any
other value represents that of the node. This value MUST represent
the lowest value supported by any link configured for use by the
advertising OSPF instance.
This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is
optional. The scope of the advertisement is specific to the optional. The scope of the advertisement is specific to the
deployment. deployment.
When multiple Node MSD TLVs are received from a given router, the When multiple Node MSD TLVs are received from a given router, the
receiver MUST use the first occurrence of the TLV in the Router receiver MUST use the first occurrence of the TLV in the Router
Information LSA. If the Node MSD TLV appears in multiple Router Information LSA. If the Node MSD TLV appears in multiple Router
Information LSAs that have different flooding scopes, the Node MSD Information LSAs that have different flooding scopes, the Node MSD
TLV in the Router Information LSA with the area-scoped flooding scope TLV in the Router Information LSA with the area-scoped flooding scope
skipping to change at page 5, line 48 skipping to change at page 5, line 48
For OSPFv2, the Link level MSD value is advertised as an optional For OSPFv2, the Link level MSD value is advertised as an optional
Sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684], and Sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684], and
has value of TBD2. has value of TBD2.
For OSPFv3, the Link level MSD value is advertised as an optional For OSPFv3, the Link level MSD value is advertised as an optional
Sub-TLV of the E-Router-LSA TLV as defined in [RFC8362], and has Sub-TLV of the E-Router-LSA TLV as defined in [RFC8362], and has
value of TBD3. value of TBD3.
Length: variable and similar to that, defined in Section 2. Length: variable and similar to that, defined in Section 2.
Value: consists of one or more pairs of a 1 octet MSD Type (IANA Value: consists of one or more pairs of a 1 octet MSD-type and 1
Registry) and 1 octet value. octet MSD-Value.
MSD Type 1 (IANA Section), MSD and the Value field contains Link MSD MSD-Type: one of the values defined in the MSD Types registry defined
of the router originating the corresponding LSA as specified for in [I-D.ietf-isis-segment-routing-msd].
OSPFv2 and OSPFv3. Link MSD is a number in the range of 0-255. 0
represents lack of the ability to impose MSD stack of any depth; any MSD-Value field contains Link MSD of the router originating the
other value represents that of the particular link MSD value. corresponding LSA as specified for OSPFv2 and OSPFv3. Link MSD is a
number in the range of 0-255. For all MSD-Types, 0 represents lack
of the ability to impose MSD stack of any depth; any other value
represents that of the particular link when used as an outgoing
interface.
Other MSD Types are reserved for future extensions. Other MSD Types are reserved for future extensions.
If this TLV is advertised multiple times in the same OSPFv2 Extended If this TLV is advertised multiple times in the same OSPFv2 Extended
Link Opaque LSA, only the first instance of the TLV is used by Link Opaque LSA, only the first instance of the TLV is used by
receiving OSPFv2 routers. This situation SHOULD be logged as an receiving OSPFv2 routers. This situation SHOULD be logged as an
error. error.
If this TLV is advertised multiple times for the same link in If this TLV is advertised multiple times for the same link in
different OSPFv2 Extended Link Opaque LSAs originated by the same different OSPFv2 Extended Link Opaque LSAs originated by the same
skipping to change at page 7, line 4 skipping to change at page 7, line 7
specified when an MSD type is defined. specified when an MSD type is defined.
5. Base MPLS Imposition MSD 5. Base MPLS Imposition MSD
The Base MPLS Imposition MSD (BMI-MSD) signals the total number of The Base MPLS Imposition MSD (BMI-MSD) signals the total number of
MPLS labels a node is capable of imposing, including all MPLS labels a node is capable of imposing, including all
service/transport/special labels. service/transport/special labels.
Absence of BMI-MSD advertisements indicates solely that the Absence of BMI-MSD advertisements indicates solely that the
advertising node does not support advertisement of this capability. advertising node does not support advertisement of this capability.
Assignment of MSD-Type for BMI-MSD is defined in
[I-D.ietf-isis-segment-routing-msd].
6. IANA Considerations 6. IANA Considerations
This document requests IANA to allocate TLV type (TBD1) from the OSPF This document requests IANA to allocate TLV type (TBD1) from the OSPF
Router Information (RI) TLVs Registry as defined by [RFC4970]. IANA Router Information (RI) TLVs Registry as defined by [RFC4970]. IANA
has allocated the value 12 through the early assignment process. has allocated the value 12 through the early assignment process.
Also, this document requests IANA to allocate a sub-TLV type (TBD2) Also, this document requests IANA to allocate a sub-TLV type (TBD2)
from the OSPFv2 Extended Link TLV Sub-TLVs registry. IANA has from the OSPFv2 Extended Link TLV Sub-TLVs registry. IANA has
allocated the the value 6 through the early assignment process. allocated the the value 6 through the early assignment process.
Finally, this document requests IANA to allocate a sub-TLV type Finally, this document requests IANA to allocate a sub-TLV type
(TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry. (TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry.
This document requests creation of an IANA managed registry under a
new category of "Interior Gateway Protocol (IGP) Parameters" IANA
registries to identify MSD types as proposed in Section 2, Section 3.
The registration procedure is "Expert Review" as defined in
[RFC8126]. The suggested registry name is "MSD types". Types are an
unsigned 8 bit number. The following values are defined by this
document.
Value Name Reference
----- --------------------- -------------
0 Reserved This document
1 Base MPLS Imposition MSD This document
2-250 Unassigned This document
251-254 Experimental This document
255 Reserved This document
Figure 3: MSD Types Codepoints Registry
7. Security Considerations 7. Security Considerations
Security concerns for OSPF are addressed in [RFC7474]. Further Security concerns for OSPF are addressed in [RFC7474]. Further
security analysis for OSPF protocol is done in [RFC6863] including security analysis for OSPF protocol is done in [RFC6863] including
analysis of both the above documents. Security considerations, as analysis of both the above documents. Security considerations, as
specified by [RFC7770], [RFC7684] and [RFC8362] are applicable to specified by [RFC7770], [RFC7684] and [RFC8362] are applicable to
this document. this document.
Advertisement of an incorrect MSD value may result: in a path Advertisement of an incorrect MSD value may result: in a path
computation failing and the service unavailable or instantiation of a computation failing and the service unavailable or instantiation of a
skipping to change at page 8, line 4 skipping to change at page 7, line 39
Advertisement of an incorrect MSD value may result: in a path Advertisement of an incorrect MSD value may result: in a path
computation failing and the service unavailable or instantiation of a computation failing and the service unavailable or instantiation of a
path that can't be supported by the head-end (the node performing the path that can't be supported by the head-end (the node performing the
imposition). imposition).
8. Contributors 8. Contributors
The following people contributed to this document: The following people contributed to this document:
Les Ginsberg Les Ginsberg
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Acee Lindem, Ketan Talaulikar, The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal
Stephane Litkowski and Bruno Decraene for their reviews and valuable Mizrahi, Stephane Litkowski and Bruno Decraene for their reviews and
comments. valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-isis-segment-routing-msd]
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling MSD (Maximum SID Depth) using IS-IS", draft-
ietf-isis-segment-routing-msd-12 (work in progress), May
2018.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
2007, <https://www.rfc-editor.org/info/rfc4970>. 2007, <https://www.rfc-editor.org/info/rfc4970>.
 End of changes. 20 change blocks. 
48 lines changed or deleted 42 lines changed or added

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