draft-ietf-6man-segment-routing-header-02.txt   draft-ietf-6man-segment-routing-header-03.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: March 24, 2017 B. Field Expires: July 17, 2017 B. Field
Comcast Comcast
I. Leung I. Leung
Rogers Communications Rogers Communications
J. Linkova J. Linkova
Google Google
E. Aries E. Aries
Facebook Facebook
T. Kosugi T. Kosugi
NTT NTT
E. Vyncke E. Vyncke
Cisco Systems, Inc. Cisco Systems, Inc.
D. Lebrun D. Lebrun
Universite Catholique de Louvain Universite Catholique de Louvain
September 20, 2016 January 13, 2017
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-02 draft-ietf-6man-segment-routing-header-03
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet through a Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction, header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain. maintaining per-flow state only at the ingress node to the SR domain.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 March 24, 2017. This Internet-Draft will expire on July 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (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
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 5, line 15 skipping to change at page 5, line 15
o A set of nodes connected as an overlay over one or more transit o A set of nodes connected as an overlay over one or more transit
providers. The overlay nodes exchange SR-enabled traffic with providers. The overlay nodes exchange SR-enabled traffic with
segments belonging solely to the overlay routers (the SR domain). segments belonging solely to the overlay routers (the SR domain).
None of the segments in the SR-enabled packets exchanged by the None of the segments in the SR-enabled packets exchanged by the
overlay belong to the transit networks overlay belong to the transit networks
The source based routing model through its instantiation of the The source based routing model through its instantiation of the
Segment Routing Header (SRH) defined in this document equally applies Segment Routing Header (SRH) defined in this document equally applies
to all the above examples. to all the above examples.
While the source routing model defined in [RFC2460] doesn't mandate It is assumed in this document that the SRH is added to the packet by
which node is allowed to insert (or modify) the SRH, it is assumed in its source, consistently with the source routing model defined in
this document that the SRH is inserted in the packet by its source. [RFC2460]. For example:
For example:
o At the node originating the packet (host, server). o At the node originating the packet (host, server).
o At the ingress node of an SR domain where the ingress node o At the ingress node of an SR domain where the ingress node
receives an IPv6 packet and encapsulates it into an outer IPv6 receives an IPv6 packet and encapsulates it into an outer IPv6
header followed by a Segment Routing header. header followed by a Segment Routing header.
2.2.1. SR Domain in a Service Provider Network 2.2.1. SR Domain in a Service Provider Network
The following figure illustrates an SR domain consisting of an The following figure illustrates an SR domain consisting of an
skipping to change at page 9, line 8 skipping to change at page 9, line 8
o First Segment: contains the index, in the Segment List, of the o First Segment: contains the index, in the Segment List, of the
first segment of the path which is in fact the last element of the first segment of the path which is in fact the last element of the
Segment List. Segment List.
o Flags: 16 bits of flags. Following flags are defined: o Flags: 16 bits of flags. Following flags are defined:
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|P|O|A|H| Unused | |U|P|O|A|H| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-flag: Clean-up flag. Set when the SRH has to be removed from "U" and Unused: Reserved and for future use. SHOULD be unset
the packet when the packet reaches the last segment. on transmission and MUST be ignored on receipt.
P-flag: Protected flag. Set when the packet has been rerouted P-flag: Protected flag. Set when the packet has been rerouted
through FRR mechanism by an SR endpoint node. through FRR mechanism by an SR endpoint node.
O-flag: OAM flag. When set, it indicates that this packet is O-flag: OAM flag. When set, it indicates that this packet is
an operations and management (OAM) packet. an operations and management (OAM) packet.
A-flag: Alert flag. If present, it means important Type Length A-flag: Alert flag. If present, it means important Type Length
Value (TLV) objects are present. See Section 3.1 for details Value (TLV) objects are present. See Section 3.1 for details
on TLVs objects. on TLVs objects.
H-flag: HMAC flag. If set, the HMAC TLV is present and is H-flag: HMAC flag. If set, the HMAC TLV is present and is
encoded as the last TLV of the SRH. In other words, the last encoded as the last TLV of the SRH. In other words, the last
36 octets of the SRH represent the HMAC information. See 36 octets of the SRH represent the HMAC information. See
Section 3.1.5 for details on the HMAC TLV. Section 3.1.5 for details on the HMAC TLV.
Unused: Reserved and for future use. SHOULD be unset on
transmission and MUST be ignored on receipt.
o RESERVED: SHOULD be unset on transmission and MUST be ignored on o RESERVED: SHOULD be unset on transmission and MUST be ignored on
receipt. receipt.
o Segment List[n]: 128 bit IPv6 addresses representing the nth o Segment List[n]: 128 bit IPv6 addresses representing the nth
segment in the Segment List. The Segment List is encoded starting segment in the Segment List. The Segment List is encoded starting
from the last segment of the path. I.e., the first element of the from the last segment of the path. I.e., the first element of the
segment list (Segment List [0]) contains the last segment of the segment list (Segment List [0]) contains the last segment of the
path while the last segment of the Segment List (Segment List[n]) path while the last segment of the Segment List (Segment List[n])
contains the first segment of the path. The index contained in contains the first segment of the path. The index contained in
"Segments Left" identifies the current active segment. "Segments Left" identifies the current active segment.
skipping to change at page 25, line 47 skipping to change at page 25, line 47
<http://www.rfc-editor.org/info/rfc5095>. <http://www.rfc-editor.org/info/rfc5095>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407, of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <http://www.rfc-editor.org/info/rfc6407>. October 2011, <http://www.rfc-editor.org/info/rfc6407>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
Extensions for Segment Routing", draft-ietf-isis-segment- "IS-IS Extensions for Segment Routing", draft-ietf-isis-
routing-extensions-07 (work in progress), June 2016. segment-routing-extensions-09 (work in progress), October
2016.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-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, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-06 (work in progress), July segment-routing-extensions-07 (work in progress), October
2016. 2016.
[I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and
R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring- R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring-
ipv6-use-cases-07 (work in progress), July 2016. ipv6-use-cases-07 (work in progress), July 2016.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Filsfils, C., Previdi, S., Francois, P., Decraene, B., and Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
R. Shakir, "Use-cases for Resiliency in SPRING", draft- "Resiliency use cases in SPRING networks", draft-ietf-
ietf-spring-resiliency-use-cases-05 (work in progress), spring-resiliency-use-cases-08 (work in progress), October
September 2016. 2016.
[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-10 (work in progress), November
2016.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing- with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-05 (work in progress), July 2016. mpls-06 (work in progress), January 2017.
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940, Forwarding Specification (Version 1)", RFC 1940,
DOI 10.17487/RFC1940, May 1996, DOI 10.17487/RFC1940, May 1996,
<http://www.rfc-editor.org/info/rfc1940>. <http://www.rfc-editor.org/info/rfc1940>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
 End of changes. 14 change blocks. 
25 lines changed or deleted 23 lines changed or added

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