< draft-ietf-ospf-segment-routing-extensions-05.txt   draft-ietf-ospf-segment-routing-extensions-06.txt >
Open Shortest Path First IGP P. Psenak, Ed. Open Shortest Path First IGP P. Psenak, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi, Ed.
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: December 28, 2015 Cisco Systems, Inc. Expires: June 24, 2016 Cisco Systems, Inc.
H. Gredler H. Gredler
Juniper Networks, Inc. Individual
R. Shakir R. Shakir
British Telecom Jive Communications, Inc.
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
J. Tantsura J. Tantsura
Ericsson Ericsson
June 26, 2015 December 22, 2015
OSPF Extensions for Segment Routing OSPF Extensions for Segment Routing
draft-ietf-ospf-segment-routing-extensions-05 draft-ietf-ospf-segment-routing-extensions-06
Abstract Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF). advertised by the link-state routing protocols (IS-IS and OSPF).
This draft describes the OSPF extensions required for Segment This draft describes the OSPF extensions required for Segment
Routing. Routing.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 28, 2015. This Internet-Draft will expire on June 24, 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 7, line 29 skipping to change at page 7, line 29
index=0 means label 100 index=0 means label 100
... ...
index 99 means label 199 index 99 means label 199
index 100 means label 1000 index 100 means label 1000
index 199 means label 1099 index 199 means label 1099
... ...
index 200 means label 500 index 200 means label 500
... ...
The RI LSA can be advertised at any of the defined flooding scopes The RI LSA can be advertised at any of the defined flooding scopes
(link, area, or autonomous system (AS)). For the purposes of the SR- (link, area, or autonomous system (AS)). For the purposes of the
Capability TLV propagation, area scope flooding is required. SID/Label Range TLV propagation, area scope flooding is required.
4. OSPF Extended Prefix Range TLV 4. OSPF Extended Prefix Range TLV
In some cases it is useful to advertise attributes for the range of In some cases it is useful to advertise attributes for the range of
prefixes. Segment Routing Mapping Server, which is described in prefixes. Segment Routing Mapping Server, which is described in
[I-D.filsfils-spring-segment-routing-ldp-interop], is an example, [I-D.filsfils-spring-segment-routing-ldp-interop], is an example,
where we need a single advertisement to advertise SIDs for multiple where we need a single advertisement to advertise SIDs for multiple
prefixes from a contiguous address range. prefixes from a contiguous address range.
OSPF Extended Prefix Range TLV, which is a new top level TLV of the OSPF Extended Prefix Range TLV, which is a new top level TLV of the
skipping to change at page 11, line 46 skipping to change at page 11, line 46
domain border router (prefix propagation from one domain to domain border router (prefix propagation from one domain to
another). another).
If the E-flag is set then any upstream neighbor of the Prefix-SID If the E-flag is set then any upstream neighbor of the Prefix-SID
originator MUST replace the Prefix-SID with a Prefix-SID having an originator MUST replace the Prefix-SID with a Prefix-SID having an
Explicit-NULL value. This is useful, e.g., when the originator of Explicit-NULL value. This is useful, e.g., when the originator of
the Prefix-SID is the final destination for the related prefix and the Prefix-SID is the final destination for the related prefix and
the originator wishes to receive the packet with the original EXP the originator wishes to receive the packet with the original EXP
bits. bits.
When M-Flag is set, NP-flag MUST be set and E-bit MUST NOT be set. When M-Flag is set, NP-flag and E-flag MUST be ignored at reception.
As the Mapping Server does not specify the originator of a prefix As the Mapping Server does not specify the originator of a prefix
advertisement it is not possible to determine PHP behavior solely advertisement it is not possible to determine PHP behavior solely
based on the Mapping Server advertisement. However, PHP behavior may based on the Mapping Server advertisement. However, PHP behavior may
safely be done in following cases: safely be done in following cases:
Prefix is of intra-area type and the downstream neighbor is the Prefix is of intra-area type and the downstream neighbor is the
originator of the prefix. originator of the prefix.
Prefix is of inter-area type and downstream neighbor is an ABR, Prefix is of inter-area type and downstream neighbor is an ABR,
skipping to change at page 13, line 10 skipping to change at page 13, line 10
then the Prefix field in the Extended Prefix Range TLV would be set then the Prefix field in the Extended Prefix Range TLV would be set
to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7
and the Index value in the Prefix-SID Sub-TLV would be set to 51. and the Index value in the Prefix-SID Sub-TLV would be set to 51.
6. SID/Label Binding Sub-TLV 6. SID/Label Binding Sub-TLV
The SID/Label Binding Sub-TLV is used to advertise a SID/Label The SID/Label Binding Sub-TLV is used to advertise a SID/Label
mapping for a path to the prefix. mapping for a path to the prefix.
The SID/Label Binding TLV MAY be originated by any router in an OSPF The SID/Label Binding Sub-TLV MAY be originated by any router in an
domain. The router may advertise a SID/Label binding to a FEC along OSPF domain. The router may advertise a SID/Label binding to a FEC
with at least a single 'nexthop style' anchor. The protocol supports along with at least a single 'nexthop style' anchor. The protocol
more than one 'nexthop style' anchor to be attached to a SID/Label supports more than one 'nexthop style' anchor to be attached to a
binding, which results in a simple path description language. In SID/Label binding, which results in a simple path description
analogy to RSVP, the terminology for this is called an 'Explicit language. In analogy to RSVP, the terminology for this is called an
Route Object' (ERO). Since ERO style path notation allows anchoring 'Explicit Route Object' (ERO). Since ERO style path notation allows
SID/label bindings to both link and node IP addresses, any Label anchoring SID/label bindings to both link and node IP addresses, any
Switched Path (LSP) can be described. Additionally, SID/Label Label Switched Path (LSP) can be described. Additionally, SID/Label
Bindings from external protocols can be easily re-advertised. Bindings from external protocols can be easily re-advertised.
The SID/Label Binding TLV may be used for advertising SID/Label The SID/Label Binding Sub-TLV may be used for advertising SID/Label
Bindings and their associated Primary and Backup paths. In a single Bindings and their associated Primary and Backup paths. In a single
TLV, a primary ERO Path, backup ERO Path, or both can be advertised. TLV, a primary ERO Path, backup ERO Path, or both can be advertised.
If a router wants to advertise multiple parallel paths, then it can If a router wants to advertise multiple parallel paths, then it can
generate several TLVs for the same Prefix/FEC. Each occurrence of a generate several TLVs for the same Prefix/FEC. Each occurrence of a
Binding TLV for a given FEC Prefix will add a new path. Binding TLV for a given FEC Prefix will add a new path.
The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended
Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF Prefix TLV described in [I-D.ietf-ospf-prefix-link-attr] and the OSPF
Extended Prefix Range TLV described in Section 4. Multiple SID/Label Extended Prefix Range TLV described in Section 4. Multiple SID/Label
Binding TLVs can be present in their parent TLV. The SID/Label Binding TLVs can be present in their parent TLV. The SID/Label
skipping to change at page 14, line 21 skipping to change at page 14, line 21
M-bit - When the bit is set the binding represents the M-bit - When the bit is set the binding represents the
mirroring context as defined in mirroring context as defined in
[I-D.minto-rsvp-lsp-egress-fast-protection]. [I-D.minto-rsvp-lsp-egress-fast-protection].
MT-ID: Multi-Topology ID (as defined in [RFC4915]). MT-ID: Multi-Topology ID (as defined in [RFC4915]).
Weight: weight used for load-balancing purposes. The use of the Weight: weight used for load-balancing purposes. The use of the
weight is defined in [I-D.ietf-spring-segment-routing]. weight is defined in [I-D.ietf-spring-segment-routing].
The SID/Label Binding TLV supports the following Sub-TLVs: The SID/Label Binding Sub-TLV supports the following Sub-TLVs:
SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST
appear in the SID/Label Binding Sub-TLV and it MUST only appear appear in the SID/Label Binding Sub-TLV and it MUST only appear
once. once.
ERO Metric Sub-TLV as defined in Section 6.1. ERO Metric Sub-TLV as defined in Section 6.1.
ERO Sub-TLVs as defined in Section 6.2. ERO Sub-TLVs as defined in Section 6.2.
6.1. ERO Metric Sub-TLV 6.1. ERO Metric Sub-TLV
skipping to change at page 27, line 7 skipping to change at page 27, line 7
contribution on earlier incarnations of the "Binding / MPLS Label contribution on earlier incarnations of the "Binding / MPLS Label
TLV" in [I-D.gredler-ospf-label-advertisement]. TLV" in [I-D.gredler-ospf-label-advertisement].
Thanks to Acee Lindem for the detail review of the draft, Thanks to Acee Lindem for the detail review of the draft,
corrections, as well as discussion about details of the encoding. corrections, as well as discussion about details of the encoding.
13. References 13. References
13.1. Normative References 13.1. Normative References
[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, March 1997. 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, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<http://www.rfc-editor.org/info/rfc3477>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630,
2003. DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
4915, June 2007. RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007. Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
2007, <http://www.rfc-editor.org/info/rfc4970>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008. OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>.
13.2. Informative References 13.2. Informative References
[I-D.filsfils-spring-segment-routing-ldp-interop] [I-D.filsfils-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing interoperability with LDP", draft- "Segment Routing interoperability with LDP", draft-
filsfils-spring-segment-routing-ldp-interop-02 (work in filsfils-spring-segment-routing-ldp-interop-02 (work in
progress), September 2014. progress), September 2014.
skipping to change at page 28, line 11 skipping to change at page 28, line 27
Crabbe, "Segment Routing Use Cases", draft-filsfils- Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-01 (work in progress), spring-segment-routing-use-cases-01 (work in progress),
October 2014. October 2014.
[I-D.gredler-ospf-label-advertisement] [I-D.gredler-ospf-label-advertisement]
Gredler, H., Amante, S., Scholl, T., and L. Jalil, Gredler, H., Amante, S., Scholl, T., and L. Jalil,
"Advertising MPLS labels in OSPF", draft-gredler-ospf- "Advertising MPLS labels in OSPF", draft-gredler-ospf-
label-advertisement-03 (work in progress), May 2013. label-advertisement-03 (work in progress), May 2013.
[I-D.ietf-ospf-prefix-link-attr] [I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work
in progress), June 2015. in progress), August 2015.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing Architecture", draft-ietf- and E. Crabbe, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-00 (work in progress), December spring-segment-routing-00 (work in progress), December
2014. 2014.
[I-D.minto-rsvp-lsp-egress-fast-protection] [I-D.minto-rsvp-lsp-egress-fast-protection]
Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP
skipping to change at page 29, line 4 skipping to change at page 29, line 20
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Hannes Gredler Hannes Gredler
Juniper Networks, Inc. Individual
1194 N. Mathilda Ave. Austria
Sunnyvale, CA 94089
US
Email: hannes@juniper.net Email: hannes@gredler.at
Rob Shakir Rob Shakir
British Telecom Jive Communications, Inc.
London 1275 West 1600 North, Suite 100
UK Orem, UT 84057
US
Email: rob.shakir@bt.com
Email: rrjs@rob.sh
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
BE BE
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
 End of changes. 26 change blocks. 
45 lines changed or deleted 54 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/