idnits 2.17.1 draft-lp-spring-sr-policy-reverse-path-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '... As introduced in [I-D.ietf-spring-bfd], the sender MAY use a Binding...' RFC 2119 keyword, line 69: '...to that particular node and a BSID MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2021) is 1184 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-10) exists of draft-ietf-spring-bfd-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-spring-bfd (ref. 'I-D.ietf-spring-bfd') == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING WG Y. Liu 3 Internet-Draft S. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: July 31, 2021 January 27, 2021 7 SR Policy for Reverse Path 8 draft-lp-spring-sr-policy-reverse-path-00 10 Abstract 12 This document introduces a method of dynamically configuring the 13 return path for an SR path. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 31, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. SR Policy for Bidirectional Path . . . . . . . . . . . . . . 2 51 2.1. BGP Extensions for Advertising Segment List . . . . . . . 3 52 2.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 4 53 2.3. Difference from Path Segment . . . . . . . . . . . . . . 5 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 59 1. Introduction 61 Echo-BFD [RFC5880] can be used to monitor an SR Policy between the 62 local and the remote BFD peers. As defined in [RFC5880], the remote 63 BFD system does not process the payload of an Echo BFD. 65 A BSID can be used to specify the return path of an Echo BFD packet. 67 As introduced in [I-D.ietf-spring-bfd], the sender MAY use a Binding 68 SID (BSID) [RFC8402] that has been bound with the SR Policy that 69 ensures the return of a packet to that particular node and a BSID MAY 70 be associated with the SR Policy that is the reverse to the SR Policy 71 programmed onto the BFD Echo packet by the sender. 73 One way to implement this is through static configuration, e.g, 74 configure the BSID corresponding to the return path for each segment 75 list when enable BFD for an SR policy or an segment list. 77 This document introduces a method of dynamically configuring the 78 return path for an SR path, which can be used to specify the return 79 path in Echo BFD for SR, ICMPv6 for SRv6, etc. 81 2. SR Policy for Bidirectional Path 83 In order to specify the return path for an segment list when 84 delivering the SR Policy, and the tail node can return the packet 85 according to the specified return path, this document proposes 86 extensions of SR Policy. It allows the segment list to have its own 87 BSID. 89 When delivering SR policy, the BSID of the segment list and the 90 corresponding BSID of the return segment list can be carried 91 together. 93 2.1. BGP Extensions for Advertising Segment List 95 Segment List sub-TLV is introduced in 96 [I-D.ietf-idr-segment-routing-te-policy] and it includes the elements 97 of the paths (i.e., segments). 99 This document introduces two optional sub-sub-tlvs of Segment List 100 sub-TLV, Binding SID Sub-TLV and Reverse Binding SID Sub-TLV. 102 The Binding SID sub-TLV has the following format: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Type | Length | Flags | RESERVED | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Binding SID (variable, optional) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1: Binding SID Sub-TLV 114 where: 116 Type: TBD. 118 Length: specifies the length of the value field not including Type 119 and Length fields. 121 Binding SID: the BSID of the segment list. 123 The Reverse Binding SID sub-TLV has the following format: 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Type | Length | Flags | RESERVED | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Reverse Binding SID (variable, optional) | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 2: Reverse Binding SID Sub-TLV 135 where: 137 Type: TBD 139 Length: specifies the length of the value field not including Type 140 and Length fields. 142 Reverse Binding SID: the BSID of the reverse SR path. If it is 143 encapsulated in the packet, the Reverse Binding SID must the last 144 segment to be processed. 146 The extended SR Policy Encoding structure is as follows: 148 SR Policy SAFI NLRI: 149 Attributes: 150 Tunnel Encaps Attribute (23) 151 Tunnel Type: SR Policy 152 Binding SID 153 SRv6 Binding SID 154 Preference 155 Priority 156 Policy Name 157 Policy Candidate Path Name 158 Explicit NULL Label Policy (ENLP) 159 Segment List 160 Binding SID 161 Reverse Binding SID 162 Weight 163 Segment 164 Segment 165 ... 167 Whether to carry RBSID in the packet can be configured according to 168 service requirements. For example, when echo BFD packets are 169 encapsulated, RBSID is carried in segment list, while packets of 170 other services do not carry RBSID by default. Thus BFD packets and 171 common service packets can share the same SR Policy. 173 2.2. Illustration 175 +-+ +-+ +-+ +-+ 176 |A|------|B|------|C|------|D| 177 +-+ +-+ +-+ +-+ 179 Figure 3: Reference Topology 181 The content of Segment List1 in SR Policy1 received by A is: 183 Segment List1 184 Reverse Binding SID D1 185 Segment B 186 Segment C 187 Segment D 189 The content of Segment List2 in SR Policy2 received by D is: 191 Segment List2 192 Binding SID D1 193 Segment C 194 Segment B 195 Segment A 197 The SID-List of the BFD ECHO sent by A is < B, C, D, D1 >. 199 After the packet arrives at node D, D1 is Segment List2 BSID. BFD 200 packets are returned from node D according to segment list < C, B, A 201 >. 203 2.3. Difference from Path Segment 205 TBD 207 3. Security Considerations 209 Procedures and protocol extensions defined in this document do not 210 affect the security considerations discussed in 211 [I-D.ietf-idr-segment-routing-te-policy] and 212 [I-D.ietf-spring-segment-routing-policy]. 214 4. IANA Considerations 216 TBD 218 5. Normative References 220 [I-D.ietf-idr-segment-routing-te-policy] 221 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 222 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 223 Routing Policies in BGP", draft-ietf-idr-segment-routing- 224 te-policy-11 (work in progress), November 2020. 226 [I-D.ietf-spring-bfd] 227 Mirsky, G., Tantsura, J., Varlashkin, I., Chen, M., and J. 228 Wenying, "Bidirectional Forwarding Detection (BFD) in 229 Segment Routing Networks Using MPLS Dataplane", draft- 230 ietf-spring-bfd-00 (work in progress), September 2020. 232 [I-D.ietf-spring-segment-routing-policy] 233 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 234 P. Mattes, "Segment Routing Policy Architecture", draft- 235 ietf-spring-segment-routing-policy-09 (work in progress), 236 November 2020. 238 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 239 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 240 . 242 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 243 Decraene, B., Litkowski, S., and R. Shakir, "Segment 244 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 245 July 2018, . 247 Authors' Addresses 249 Liu Yao 250 ZTE Corporation 251 Nanjing 252 China 254 Email: liu.yao71@zte.com.cn 256 Peng Shaofu 257 ZTE Corporation 258 Nanjing 259 China 261 Email: peng.shaofu@zte.com.cn