SFC WG T. Ao
Internet-Draft Individual contributor
Intended status: Standards Track G. Mirsky
Expires: June 3, 2020 ZTE Corp.
Z. Chen
China Telecom
December 1, 2019
Controlled Return Path for Service Function Chain (SFC) OAM
draft-ao-sfc-oam-return-path-specified-05
Abstract
This document defines an extension to the Service Function Chain
(SFC) Operation, Administration and Maintenance (OAM) that enables
control of the Echo Reply return path directing it over a Reverse
Service Function Path. Enforcing the specific return path can be
used to verify the bidirectional connectivity of SFC and increase the
robustness of SFC OAM.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 3, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Ao, et al. Expires June 3, 2020 [Page 1]
Internet-Draft Controlled Return Path for SFC OAM December 2019
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SFC Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 4
5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Bi-directional SFC Case . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7.1. SFC Return Path Type . . . . . . . . . . . . . . . . . . 6
7.2. New Return Codes . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
While Service Function Chain (SFC) Echo Request, defined in
[I-D.ietf-sfc-multi-layer-oam], always traverses the SFC it directed
to, the corresponding Echo Reply is sent over IP network
[I-D.ietf-sfc-multi-layer-oam]. There are scenarios when it is
beneficial to direct the responder to use a path other than the IP
network. This document extends Service Function Chain (SFC)
Operation, Administration and Maintenance (OAM) by enabling control
of the Echo Reply return path to be directed over a Reply Service
Function Path (SFP). This document defines a new Type-Length-Value
(TLV), Reply Service Function Path TLV, for Reply via Specified Path
mode of SFC Echo Reply (Section 4).
The Reply Service Function Path TLV can provide an efficient
mechanism to test SFCs, such as bidirectional and hybrid SFC, as
defined in Section 2.2 [RFC7665]. For example, it allows an operator
to test both directions of the bidirectional or hybrid SFP with a
single SFC Echo Request/Echo Reply operation.
Ao, et al. Expires June 3, 2020 [Page 2]
Internet-Draft Controlled Return Path for SFC OAM December 2019
2. Conventions used in this document
2.1. Terminology
SF - Service Function
SFF - Service Function Forwarder
SFC - Service Function Chain, an ordered set of some abstract SFs.
SFP - Service Function Path
SPI - Service Path Index
OAM - Operation, Administration, and Maintenance
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Extension
Following reply modes had been defined in
[I-D.ietf-sfc-multi-layer-oam]:
o Do Not Reply
o Reply via an IPv4/IPv6 UDP Packet
o Reply via Application Level Control Channel
o Reply via Specified Path
The Reply via Specified Path mode is intended to enforce the use of
the particular return path specified in the included TLV. This mode
may help to verify bidirectional continuity or increase the
robustness of the monitoring of the SFC by selecting a more stable
path. In the case of SFC, the sender of Echo Request instructs the
destination SFF to send Echo Reply message along the SFP specified in
the SFC Reply Path TLV as described in Section 4.
Ao, et al. Expires June 3, 2020 [Page 3]
Internet-Draft Controlled Return Path for SFC OAM December 2019
4. SFC Reply Path TLV
The SFC Reply Path TLV carries the information that sufficiently
identifies the return SFP that the SFC Echo Reply message is expected
to follow. The format of SFC Reply Path TLV is shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Reply Path Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Service Function Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SFC Reply TLV Format
where:
o Reply Path TLV Type: is two octets long, indicates the TLV that
contains information about the SFC Reply path.
o Length: is two octets long, MUST be equal to 4
o Reply Service Function Path is used to describe the return path
that an SFC Echo Reply is requested to follow.
The format of the Reply Service Function Path field displayed in
Figure 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Service Function Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Reply Service Function Path Field Format
where:
o Reply Service Function Path Identifier: SFP identifier for the
path that the SFC Echo Reply message is requested to be sent over.
o Service Index: the value for the Service Index field.in the NSH of
the SFC Echo Reply message.
Ao, et al. Expires June 3, 2020 [Page 4]
Internet-Draft Controlled Return Path for SFC OAM December 2019
5. Theory of Operation
[RFC7110] defined mechanism to control return path for MPLS LSP Echo
Reply. In case of SFC, the return path is an SFP along which SFC
Echo Reply message MUST be transmitted. Hence, the SFC Reply Path
TLV included in the SFC Echo Request message MUST sufficiently
identify the SFP that the sender of the Echo Request message expects
the receiver to use for the corresponding SFC Echo Reply.
When sending an Echo Request, the sender MUST set the value of Reply
Mode field to "Reply via Specified Path", defined in
[I-D.ietf-sfc-multi-layer-oam], and if the specified path is SFC
path, the Request MUST include SFC Reply Path TLV. The SFC Reply
Path TLV includes the identifier of the reverse SFP and an
appropriate Service Index.
Echo Reply is expected to be sent by the destination SFF of the SFP
being tested or by the SFF at which SFC TTL expires as defined
[RFC8300]. The processing described below equally applies to both
cases and referred to as responding SFF.
If the Echo Request message with SFC Reply Path TLV, received by the
responding SFF, has Reply Mode value of "Reply via Specified Path"
but no SFC Reply Path TLV is present, then the responding SFF MUST
send Echo Reply with Return Code set to "Reply Path TLV is missing"
value (TBA2). If the responding SFF cannot find requested SFP it
MUST send Echo Reply with Return Code set to "Reply SFP was not
found" and include the SFC Reply Path TLV from the Echo Request
message.
5.1. Bi-directional SFC Case
The ability to specify the return path for an Echo Reply might be
used in case of bi-directional SFC. The egress SFF of the forward
SFP may be not co-located with a classifier of the reverse SFP, and
thus the egress SFF has no infrmation about the reverse path of an
SFC. Because of that, even for bi-directional SFC, a reverse SFP
needs to be indicated in a Reply Path TLV in the Echo Request
message.
6. Security Considerations
Security considerations discussed in [RFC8300] apply to this
document.
The SFC Return Path extension, defined in this document, can be used
for potential "proxying" attacks. For example, an initiator of the
Echo Request may specify a return path that has a destination
Ao, et al. Expires June 3, 2020 [Page 5]
Internet-Draft Controlled Return Path for SFC OAM December 2019
different from that of the initiator. But usually, such attacks will
not happen in an SFC domain where the initiators and receivers belong
to the same domain, as specified in [RFC7665]. Even if the attack
occurs, in order to prevent using the SFC Return Path extension for
proxying any possible attacks, the return path SFP SHOULD have a path
to reach the sender of the Echo Request, identified in SFC Source TLV
[I-D.ietf-sfc-multi-layer-oam]. The receiver MAY drop the Echo
Request when it cannot determine whether the return path SFP has the
route to the initiator. That means, when sending Echo Request, the
sender SHOULD choose a proper source address according to specified
return path SFP to help the receiver to make the decision.
7. IANA Considerations
7.1. SFC Return Path Type
IANA is requested to assign from its SFC Echo Request/Echo Reply TLV
registry new type as follows:
+-------+----------------------+---------------+
| Value | Description | Reference |
+-------+----------------------+---------------+
| TBA1 | SFC Reply Path Type | This document |
+-------+----------------------+---------------+
Table 1: SFC Return Path Type
7.2. New Return Codes
IANA is requested to assign new return codes from the SFC Echo
Request/Echo Reply Return Codes registry as following:
+-------+----------------------------+---------------+
| Value | Description | Reference |
+-------+----------------------------+---------------+
| TBA2 | Reply Path TLV is missing | This document |
| TBA3 | Reply SFP was not found | This document |
+-------+----------------------------+---------------+
Table 2: SFC Echo Reply Return Codes
8. References
8.1. Normative References
Ao, et al. Expires June 3, 2020 [Page 6]
Internet-Draft Controlled Return Path for SFC OAM December 2019
[I-D.ietf-sfc-multi-layer-oam]
Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active
OAM for Service Function Chains in Networks", draft-ietf-
sfc-multi-layer-oam-04 (work in progress), November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
8.2. Informative References
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Ting Ao
Individual contributor
No.889, BiBo Road
Shanghai 201203
China
Phone: +86 17721209283
Email: 18555817@qq.com
Ao, et al. Expires June 3, 2020 [Page 7]
Internet-Draft Controlled Return Path for SFC OAM December 2019
Greg Mirsky
ZTE Corp.
1900 McCarthy Blvd. #205
Milpitas, CA 95035
USA
Email: gregimirsky@gmail.com
Zhonghua Chen
China Telecom
No.1835, South PuDong Road
Shanghai 201203
China
Phone: +86 18918588897
Email: 18918588897@189.cn
Ao, et al. Expires June 3, 2020 [Page 8]