idnits 2.17.00 (12 Aug 2021) /tmp/idnits3331/draft-bardhan-spring-poi-sr-oam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 137 has weird spacing: '... and/or pop a...' -- The document date (July 7, 2016) is 2144 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.filsfils-rtgwg-segment-routing' is mentioned on line 69, but not defined == Missing Reference: 'RFC2119' is mentioned on line 87, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 189, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-bfd-directed' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-anand-spring-poi-sr-01' is defined on line 201, but no explicit reference was found in the text == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == Outdated reference: A later version (-19) exists of draft-ietf-mpls-bfd-directed-02 == Outdated reference: A later version (-08) exists of draft-anand-spring-poi-sr-01 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Sanjoy Bardhan 3 Internet-Draft Madhukar Anand 4 Intended Status: Informational Ramesh Subrahmaniam 5 Infinera Corporation 6 Jeff Tantsura 7 Individual 8 Expires: January 7, 2017 July 7, 2016 10 OAM for Packet-Optical Integration in Segment Routing 11 draft-bardhan-spring-poi-sr-oam-00 13 Abstract 15 This document describes a list of functional requirements for 16 transport segment OAM in Segment Routing (SR) based networks. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Detailed Requirement List . . . . . . . . . . . . . . . . . . 3 59 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 63 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1 Introduction 69 [I-D.filsfils-rtgwg-segment-routing] introduces and explains Segment 70 Routing architecture that leverages source routing and tunneling 71 standards which can be applied directly to MPLS dataplane with no 72 changes on forwarding plane and on IPv6 dataplane with new Routing 73 Extension Header. In addition [I-D. draft-anand-spring-poi-sr] 74 introduces the concept of a Transport Segment at the edge of the 75 packet and optical network that represents the optical path taken for 76 a given flow. This document is a place holder to identify and list 77 the OAM requirements for Segment Routing based network which can 78 further be extended to produce OAM tools for path liveliness and 79 service validation across the optical domain using Transport 80 Segments. 82 1.1 Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 SR: Segment Routing 90 Initiator: Centralized OAM initiator 92 POG: Packet Optical Gateway that interworks between a packet and 93 optical network 95 2. Detailed Requirement List 97 This section list the OAM requirement for Transport Segments in a 98 Segment Routing based network. The below listed requirements MUST be 99 supported within an optical dataplane. 101 REQ#1: Transport Segment OAM SHOULD support Continuity Check 102 (liveliness of a path - BFD), Connectivity Verification (BFD, Ping), 103 Fault Verification - exercised on demand to validate the reported 104 fault (Ping). 106 REQ#2: Transport Segment OAM MUST support both On-demand and 107 Continuous OAM functionality. 109 REQ#3: Transport Segment OAM packet MUST follow exactly the same 110 path as the dataplane traffic. 112 REQ#4: The Transport Segment OAM packet MUST have the ability to 113 exercise any available paths as defined by the transport segment 114 label. 116 REQ#5: Transport Segment OAM SHOULD have the ability to allow the 117 Initiator to add the Remote Transport Label and control the return 118 path from egress responder. draft-ietf-mpls-bfd-directed has provided 119 the semantics of a return path which would suit this need. 121 REQ#6: Transport Segment OAM MUST have the ability to be 122 initialized from an ingress POG node to perform connectivity 123 verification and continuity check to any remote POG within the same 124 optical domain ID based on the declared Transport Segment Label. 126 REQ#7: In case of any failure with continuity check, Transport 127 Segment OAM Layer SHOULD support rapid Connectivity Fault 128 notification to the Packet Control plane of the POG to withdraw the 129 Transport Segment Label associated with the affected path and/or take 130 a local protection action. 132 REQ#8: Transport Segment OAM SHOULD also have the ability to be 133 initialized from a centralized controller. 135 REQ#9: When Transport Segment OAM is initialized from centralized 136 controller, the node on receiving the alert MAY take a local 137 protection action and/or pop an informational message. 139 REQ#10: When Transport Segment OAM is initialized, it SHOULD support 140 node redundancy based on network configuration. If primary Initiator 141 fails, secondary one MUST take over the responsibility without having 142 any impact on customer traffic. 144 REQ#11: Transport Segment OAM MUST have the ability to measure 145 bidirectional packet loss, throughput measurement, delay variation, 146 as well as unidirectional and dyadic measurements. 148 REQ#12: When a new path is instantiated, Transport Segment OAM 149 SHOULD allow path verification without noticeable delay. It may be 150 desired to check for liveliness of the optical path using Transport 151 Segment OAM before announcing the Transport Segment. 153 REQ#13: The above listed requirements SHOULD be supported without 154 any scalability limitation imposed and SHOULD be extensible to 155 accommodate any new SR functionality. 157 REQ#14: Transport Segment OAM SHOULD maintain per Transport label 158 state entry at the originating POG. 160 REQ#15: When traffic engineering is initiated by centralized 161 controller device, and when Transport Segment OAM is performed by 162 POGs, there MUST be a mechanism to communicate the failure to a 163 centralized controller device. 165 REQ#16: When a local repair in the optical network takes place, the 166 characteristics of the path between the POGS may have changed. If 167 there is significant change in the path characteristics based on 168 thresholds, the ingress POG SHALL trigger a re-advertisement of the 169 transport segment label at the global level. 171 REQ#17: The format of the Transport Segment OAM Ping packet SHALL 172 follow RFC 4379. 174 REQ#18: The format of the Transport Segment OAM BFD packet SHALL 175 follow RFC 5884. 177 3 Security Considerations 179 This document does not introduce any new security considerations. 181 4 IANA Considerations 183 TBD. 185 5 References 187 5.1 Normative References 189 [I-D.ietf-spring-segment-routing] Filsfils, C., 190 Previdi, S., Decraene, B., Litkowski, S., and r. 191 rjs@rob.sh, "Segment Routing Architecture", draft- 192 ietf-spring-segment-routing-04 (work in progress), July 193 2015. 195 [I-D.ietf-mpls-bfd-directed] Mirsky, G., Tantsura, 196 J., Varlashkin, I., and M. Chen, "Bidirectional 197 Forwarding Detection (BFD) Directed Return Path", 198 draft-ietf-mpls-bfd-directed-02 (work in progress), 199 March 2016. 201 [I-D.draft-anand-spring-poi-sr-01] Madhukar Anand, 202 Sanjoy Bardhan, Ramesh Subrahmaniam, Tantsura, J. 203 "Packet-Optical Integration in Segment Routing", draft- 204 anand-spring-poi-sr-01 (work in progress), July 205 2016. 207 5.2 Informative References 209 Authors' Addresses 211 Sanjoy Bardhan 212 Infinera Corporation 213 169 W Java Dr, Sunnyvale, CA 94089 215 Email: sbardhan@infinera.com 216 Madhukar Anand 217 Infinera Corporation 218 169 W Java Dr, Sunnyvale, CA 94089 220 Email: manand@infinera.com 222 Ramesh Subrahmaniam 223 Infinera Corporation 224 169 W Java Dr, Sunnyvale, CA 94089 226 Email: RSubrahmaniam@infinera.com 228 Jeff Tantsura 230 Email: jefftant.ietf@gmail.com 232 Acknowledgments 234 The authors would like to thank Krish Verma for his comments and 235 review of this document.