idnits 2.17.1 draft-bardhan-spring-poi-sr-oam-01.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 167 has weird spacing: '... and/or pop a...' -- The document date (December 22, 2016) is 2680 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 119, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 219, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-bfd-directed' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-anand-spring-poi-sr-01' is defined on line 231, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-04 == Outdated reference: A later version (-30) 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 (~~), 11 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: June 25, 2017 December 22, 2016 10 OAM for Packet-Optical Integration in Segment Routing 11 draft-bardhan-spring-poi-sr-oam-01 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Detailed Requirement List . . . . . . . . . . . . . . . . . . 4 59 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1 Normative References . . . . . . . . . . . . . . . . . . . 7 63 5.2 Informative References . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 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. 78 P5 79 P1 _ .-'-._ ,'P4 80 `._ .-' `-. ,' 81 `. _.-' `-._ ,' 82 `-. .-' `-. ,' 83 P2`.-'--------------------------`-.- P3 84 |\ /| 85 | \ / | Packet 86 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 87 | \ / | 88 | \ / | Transport 89 | \ / | 90 | ................../ | 91 | ,'O2 O3`. | 92 | ,' `. | 93 |,' `. | 94 O1\ | O4 95 \ ,' 96 \ ,' 97 .......................- 98 O6 O5 100 Figure 1: Representation of a packet-optical path 102 In Figure 1 above, the nodes represent a packet optical network. 103 P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical 104 network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that 105 communicate with other packet devices and also with the devices in the 106 optical transport domain. 108 This document is a place holder to identify and list the OAM 109 requirements for Segment Routing based network which can further be 110 extended to produce OAM tools for path liveliness and service validation 111 across the optical domain using Transport Segments. In the above figure, 112 these requirements would pertain to nodes P2 and P3. 114 1.1 Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 SR: Segment Routing 122 Initiator: Centralized OAM initiator 124 POG: Packet Optical Gateway that interworks between a packet and 125 optical network 127 2. Detailed Requirement List 129 This section list the OAM requirement for Transport Segments in a 130 Segment Routing based network. The below listed requirements MUST be 131 supported within an optical dataplane. 133 REQ#1: Transport Segment OAM SHOULD support Continuity Check 134 (liveliness of a path - BFD), Connectivity Verification (BFD, Ping), 135 Fault Verification - exercised on demand to validate the reported fault 136 (Ping). 138 REQ#2: Transport Segment OAM MUST support both On-demand and 139 Continuous OAM functionality. 141 REQ#3: Transport Segment OAM packet MUST follow exactly the same path 142 as the dataplane traffic. 144 REQ#4: The Transport Segment OAM packet MUST have the ability to 145 exercise any available paths as defined by the transport segment label. 147 REQ#5: Transport Segment OAM SHOULD have the ability to allow the 148 Initiator to add the Remote Transport Label and control the return path 149 from egress responder. draft-ietf-mpls-bfd-directed has provided the 150 semantics of a return path which would suit this need. 152 REQ#6: Transport Segment OAM MUST have the ability to be initialized 153 from an ingress POG node to perform connectivity verification and 154 continuity check to any remote POG within the same optical domain ID 155 based on the declared Transport Segment Label. 157 REQ#7: In case of any failure with continuity check, Transport Segment 158 OAM Layer SHOULD support rapid Connectivity Fault notification to the 159 Packet Control plane of the POG to withdraw the Transport Segment Label 160 associated with the affected path and/or take a local protection action. 162 REQ#8: Transport Segment OAM SHOULD also have the ability to be 163 initialized from a centralized controller. 165 REQ#9: When Transport Segment OAM is initialized from centralized 166 controller, the node on receiving the alert MAY take a local protection 167 action and/or pop an informational message. 169 REQ#10: When Transport Segment OAM is initialized, it SHOULD support 170 node redundancy based on network configuration. If primary Initiator 171 fails, secondary one MUST take over the responsibility without having 172 any impact on customer traffic. 174 REQ#11: Transport Segment OAM MUST have the ability to measure 175 bidirectional packet loss, throughput measurement, delay variation, as 176 well as unidirectional and dyadic measurements. 178 REQ#12: When a new path is instantiated, Transport Segment OAM SHOULD 179 allow path verification without noticeable delay. It may be desired to 180 check for liveliness of the optical path using Transport Segment OAM 181 before announcing the Transport Segment. 183 REQ#13: The above listed requirements SHOULD be supported without any 184 scalability limitation imposed and SHOULD be extensible to accommodate 185 any new SR functionality. 187 REQ#14: Transport Segment OAM SHOULD maintain per Transport label state 188 entry at the originating POG. 190 REQ#15: When traffic engineering is initiated by centralized controller 191 device, and when Transport Segment OAM is performed by POGs, there MUST 192 be a mechanism to communicate the failure to a centralized controller 193 device. 195 REQ#16: When a local repair in the optical network takes place, the 196 characteristics of the path between the POGS may have changed. If there 197 is significant change in the path characteristics based on thresholds, 198 the ingress POG SHALL trigger a re-advertisement of the transport 199 segment label at the global level. 201 REQ#17: The format of the Transport Segment OAM Ping packet SHALL follow 202 RFC 4379. 204 REQ#18: The format of the Transport Segment OAM BFD packet SHALL follow 205 RFC 5884. 207 3 Security Considerations 209 This document does not introduce any new security considerations. 211 4 IANA Considerations 213 TBD. 215 5 References 217 5.1 Normative References 219 [I-D.ietf-spring-segment-routing] Filsfils, C., 220 Previdi, S., Decraene, B., Litkowski, S., and r. 221 rjs@rob.sh, "Segment Routing Architecture", draft- 222 ietf-spring-segment-routing-04 (work in progress), July 223 2015. 225 [I-D.ietf-mpls-bfd-directed] Mirsky, G., Tantsura, 226 J., Varlashkin, I., and M. Chen, "Bidirectional 227 Forwarding Detection (BFD) Directed Return Path", 228 draft-ietf-mpls-bfd-directed-02 (work in progress), 229 March 2016. 231 [I-D.draft-anand-spring-poi-sr-01] Madhukar Anand, 232 Sanjoy Bardhan, Ramesh Subrahmaniam, Tantsura, J. 233 "Packet-Optical Integration in Segment Routing", draft- 234 anand-spring-poi-sr-01 (work in progress), July 235 2016. 237 5.2 Informative References 239 Authors' Addresses 241 Sanjoy Bardhan 242 Infinera Corporation 243 169 W Java Dr, Sunnyvale, CA 94089 245 Email: sbardhan@infinera.com 246 Madhukar Anand 247 Infinera Corporation 248 169 W Java Dr, Sunnyvale, CA 94089 250 Email: manand@infinera.com 252 Ramesh Subrahmaniam 253 Infinera Corporation 254 169 W Java Dr, Sunnyvale, CA 94089 256 Email: RSubrahmaniam@infinera.com 258 Jeff Tantsura 260 Email: jefftant.ietf@gmail.com 262 Acknowledgments 264 The authors would like to thank Krish Verma for his comments and 265 review of this document.