< draft-ao-sfc-oam-return-path-specified-02.txt   draft-ao-sfc-oam-return-path-specified-03.txt >
SFC WG T. Ao SFC WG T. Ao
Internet-Draft ZTE Corporation Internet-Draft ZTE Corporation
Intended status: Standards Track G. Mirsky Intended status: Standards Track G. Mirsky
Expires: April 19, 2019 ZTE Corp. Expires: September 11, 2019 ZTE Corp.
Z. Chen Z. Chen
China Telecom China Telecom
October 16, 2018 March 10, 2019
Controlled Return Path for Service Function Chain (SFC) OAM Controlled Return Path for Service Function Chain (SFC) OAM
draft-ao-sfc-oam-return-path-specified-02 draft-ao-sfc-oam-return-path-specified-03
Abstract Abstract
This document defines extensions to the Service Function Chain (SFC) This document defines extensions to the Service Function Chain (SFC)
Operation, Administration and Maintenance (OAM) that enable control Operation, Administration and Maintenance (OAM) that enable control
of the Echo Reply return path by specifying it as Reverse Service of the Echo Reply return path by specifying it as Reverse Service
Function Path. Enforcing the specific return path can be used to Function Path. Enforcing the specific return path can be used to
verify bidirectional connectivity of SFC and increase the robustness verify bidirectional connectivity of SFC and increase the robustness
of SFC OAM. of SFC OAM.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 19, 2019. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
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 2, line 31 skipping to change at page 2, line 31
7.1. SFC Return Path Type . . . . . . . . . . . . . . . . . . 6 7.1. SFC Return Path Type . . . . . . . . . . . . . . . . . . 6
7.2. New Return Codes . . . . . . . . . . . . . . . . . . . . 6 7.2. New Return Codes . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
While Service Function Chain (SFC) Echo Request, defined in While Service Function Chain (SFC) Echo Request, defined in
[I-D.wang-sfc-multi-layer-oam], always traverses the SFC it directed [I-D.ietf-sfc-multi-layer-oam], always traverses the SFC it directed
to, the corresponding Echo Reply is sent over IP network to, the corresponding Echo Reply is sent over IP network
[I-D.wang-sfc-multi-layer-oam]. There are scenarios when it is [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 beneficial to direct the responder to use a path other than the IP
network. This document defines extensions to the Service Function network. This document defines extensions to the Service Function
Chain (SFC) Operation, Administration and Maintenance (OAM) that Chain (SFC) Operation, Administration and Maintenance (OAM) that
enable control of the Echo Reply return path by specifying it as enable control of the Echo Reply return path by specifying it as
Reply Service Function Path. This document defines a new Type- Reply Service Function Path. This document defines a new Type-
Length-Value (TLV), Reply Service Function Path TLV, for Reply via Length-Value (TLV), Reply Service Function Path TLV, for Reply via
Specified Path mode of SFC Echo Reply (Section 4). Specified Path mode of SFC Echo Reply (Section 4).
The Reply Service Function Path TLV can provide an efficient The Reply Service Function Path TLV can provide an efficient
mechanism to test SFCs,such as bidirectional and hybrid SFC, as these mechanism to test SFCs,such as bidirectional and hybrid SFC, as these
were defined in Section 2.2 [RFC7665], For example, it allows an were defined in Section 2.2 [RFC7665]. For example, it allows an
operator to test both directions of the bidirectional or hybrid SFP operator to test both directions of the bidirectional or hybrid SFP
with a single SFC Echo Request/Echo Reply operation. with a single SFC Echo Request/Echo Reply operation.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
SF - Service Function SF - Service Function
SFF - Service Function Forwarder SFF - Service Function Forwarder
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Extension 3. Extension
Following reply modes had been defined in Following reply modes had been defined in
[I-D.wang-sfc-multi-layer-oam]: [I-D.ietf-sfc-multi-layer-oam]:
o Do Not Reply o Do Not Reply
o Reply via an IPv4/IPv6 UDP Packet o Reply via an IPv4/IPv6 UDP Packet
o Reply via Application Level Control Channel o Reply via Application Level Control Channel
o Reply via Specified Path o Reply via Specified Path
The Reply via Specified Path mode is intended to enforce the use of The Reply via Specified Path mode is intended to enforce the use of
the particular return path specified in the included TLV. This mode the particular return path specified in the included TLV. This mode
may help to verify bidirectional continuity or increase the may help to verify bidirectional continuity or increase the
robustness of the monitoring of the SFC by selecting a more stable 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 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 destination SFF to send Echo Reply message along the SFP specified in
the SFC Reply Path TLV Section 4. the SFC Reply Path TLV as described in Section 4.
4. SFC Reply Path TLV 4. SFC Reply Path TLV
The SFC Reply Path TLV carries the information that sufficiently The SFC Reply Path TLV carries the information that sufficiently
identifies the return SFP that the SFC Echo Reply message is expected 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. to follow. The format of SFC Reply Path TLV is shown in Figure 1.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 16 skipping to change at page 5, line 16
[RFC7110] defined mechanism to control return path for MPLS LSP Echo [RFC7110] defined mechanism to control return path for MPLS LSP Echo
Reply. In case of SFC, the return path is a SFP along which SFC Echo Reply. In case of SFC, the return path is a SFP along which SFC Echo
Reply message MUST be transmitted. Hence, the SFC Reply Path TLV Reply message MUST be transmitted. Hence, the SFC Reply Path TLV
included in the SFC Echo Request message MUST sufficiently identify included in the SFC Echo Request message MUST sufficiently identify
the SFP that the sender of the Echo Request message expects the the SFP that the sender of the Echo Request message expects the
receiver to use for the corresponding SFC Echo Reply. receiver to use for the corresponding SFC Echo Reply.
When sending an Echo Request, the sender MUST set the value of Reply When sending an Echo Request, the sender MUST set the value of Reply
Mode field to "Reply via Specified Path", defined in Mode field to "Reply via Specified Path", defined in
[I-D.wang-sfc-multi-layer-oam], and if the specified path is SFC [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, the Request MUST include SFC Reply Path TLV. The SFC Reply
Path TLV includes identifier of the reverse SFP and an appropriate Path TLV includes identifier of the reverse SFP and an appropriate
Service Index. Service Index.
Echo Reply is expected to be sent by the destination SFF of the SFP 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 being tested or by the SFF at which SFC TTL expires as defined
[I-D.ietf-sfc-nsh]. The processing described below equally applies [RFC8300]. The processing described below equally applies in both
in both cases and referred to as responding SFF. cases and referred to as responding SFF.
If the Echo Request message with SFC Reply Path TLV, received by the If the Echo Request message with SFC Reply Path TLV, received by the
responding SFF, has Reply Mode value of "Reply via Specified Path" responding SFF, has Reply Mode value of "Reply via Specified Path"
but no SFC Reply Path TLV is present, then the responding SFF MUST 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" send Echo Reply with Return Code set to "Reply Path TLV is missing"
value (TBA2). If the responding SFF cannot find requested SFP it value (TBA2). If the responding SFF cannot find requested SFP it
MUST send Echo Reply with Return Code set to "Reply SFP was not 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 found" and include the SFC Reply Path TLV from the Echo Request
message. message.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
Ability to specify the return path to be used for Echo Reply is handy Ability to specify the return path to be used for Echo Reply is handy
in bi-directional SFC. For bi-directional SFC, since the last SFF of in bi-directional SFC. For bi-directional SFC, since the last SFF of
the forward SFP may not co-locate with a classifier of the reverse the forward SFP may not co-locate with a classifier of the reverse
SFP,it is assumed that the last SFF doesn't know the reply path of a SFP,it is assumed that the last SFF doesn't know the reply path of a
SFC. So even for bi-directional SFC, a reverse SFP also need to be SFC. So even for bi-directional SFC, a reverse SFP also need to be
indicated in reply path TLV in echo request message. indicated in reply path TLV in echo request message.
6. Security Considerations 6. Security Considerations
Security considerations discussed in [I-D.ietf-sfc-nsh] apply to this Security considerations discussed in [RFC8300] apply to this
document. document.
In addition, the SFC Return Path extension, defined in this document, In addition, the SFC Return Path extension, defined in this document,
can be used for potential "proxying" attacks. For example, an echo can be used for potential "proxying" attacks. For example, an echo
request initiator may specify a return path that has a destination request initiator may specify a return path that has a destination
different from that of the initiator. But usually, such attacks will different from that of the initiator. But usually, such attacks will
not happen in an SFC domain where the initiators and receivers belong not happen in an SFC domain where the initiators and receivers belong
to the same domain, as specified in [RFC7665]. Even if the attack to the same domain, as specified in [RFC7665]. Even if the attack
occurs, in order to prevent using the SFC Return Path extension for occurs, in order to prevent using the SFC Return Path extension for
proxying any possible attacks, the return path SFP SHOULD have a path 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 to reach the sender of the echo request, identified in SFC Source TLV
[I-D.wang-sfc-multi-layer-oam]. The receiver MAY drop the echo [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 request when it cannot determine whether the return path SFP has the
route to the initiator. That means, when sending echo request, the route to the initiator. That means, when sending echo request, the
sender SHOULD choose a proper source address according to specified sender SHOULD choose a proper source address according to specified
return path SFP to help the receiver to make the decision. return path SFP to help the receiver to make the decision.
7. IANA Considerations 7. IANA Considerations
7.1. SFC Return Path Type 7.1. SFC Return Path Type
IANA is requested to assign from its SFC Echo Request/Echo Reply TLV IANA is requested to assign from its SFC Echo Request/Echo Reply TLV
skipping to change at page 6, line 48 skipping to change at page 6, line 48
| TBA2 | Reply Path TLV is missing | This document | | TBA2 | Reply Path TLV is missing | This document |
| TBA3 | Reply SFP was not found | This document | | TBA3 | Reply SFP was not found | This document |
+-------+----------------------------+---------------+ +-------+----------------------------+---------------+
Table 2: SFC Echo Reply Return Codes Table 2: SFC Echo Reply Return Codes
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-multi-layer-oam]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
November 2017.
[I-D.wang-sfc-multi-layer-oam]
Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active
OAM for Service Function Chains in Networks", draft-wang- OAM for Service Function Chains in Networks", draft-ietf-
sfc-multi-layer-oam-12 (work in progress), October 2018. sfc-multi-layer-oam-02 (work in progress), March 2019.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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 8.2. Informative References
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping", "Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014, RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>. <https://www.rfc-editor.org/info/rfc7110>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
 End of changes. 17 change blocks. 
23 lines changed or deleted 23 lines changed or added

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