idnits 2.17.1 draft-ietf-trill-p2mp-bfd-09.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 abstract seems to indicate that this document updates RFC7177, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2018) is 2263 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL M. Zhang 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Pallagatti 5 Updates: 7175, 7177 6 V. Govindan 7 Cisco Systems 8 Expires: August 11, 2018 February 7, 2018 10 TRILL Support of Point to Multipoint BFD 11 draft-ietf-trill-p2mp-bfd-09 13 Abstract 15 Point to multipoint (P2MP) BFD is designed to verify multipoint 16 connectivity. This document specifies the support of P2MP BFD in 17 TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in 18 TRILL P2MP BFD are transmitted using RBridge Channel messages. This 19 document updates RFC 7175 and RFC 7177. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 2 55 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. A New RBridge Channel Message for P2MP BFD . . . . . . . . . . 3 59 5. Discriminators and Packet Demultiplexing . . . . . . . . . . . 4 60 6. Tracking Active Tails . . . . . . . . . . . . . . . . . . . . 4 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 10.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 TRILL supports multicast forwarding. Applications based on TRILL 72 multicast may need quick detection of multicast failures using P2MP 73 BFD [I-D.ietf-bfd-multipoint]. This document specifies TRILL support 74 of P2MP BFD. 76 To use P2MP BFD, the head end needs to periodically transmit BFD 77 Control packets to all tails using TRILL multicast. A new RBridge 78 Channel message is allocated for this purpose. 80 In order to execute the global protection of distribution used for 81 multicast forwarding [I-D.ietf-trill-resilient-trees], the head needs 82 to track the active status of tails 83 [I-D.ietf-bfd-multipoint-active-tail]. If the tail loses 84 connectivity as detected by not receiving the new RBridge Channel 85 message from the head, the tail should notify the head of the lack of 86 multipoint connectivity with unicast BFD Control packets. These 87 unicast BFD Control packets are transmitted using the existing 88 RBridge Channel message assigned to BFD Control [RFC7175]. 90 This document updates [RFC7177] as specified in Section 3 and updates 91 [RFC7175] as specified in Section 4 and Section 5. 93 2. Acronyms and Terminology 94 2.1. Acronyms 96 Data Label: VLAN or Fine Grained Label [RFC7172]. 98 BFD: Bidirectional Forwarding Detection 100 P2MP: Point to Multi-Point 102 TRILL: Transparent Interconnection of Lots of Links or Tunneled 103 Routing in the Link Layer 105 2.2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in 114 this document. 116 3. Bootstrapping 118 The TRILL adjacency mechanism bootstraps the establishment of one-hop 119 TRILL BFD sessions [RFC7177]. Multi-hop sessions are expected to be 120 configured by the network manager. A slight wording update to the 121 second sentence in Section 6 of [RFC7177] is required. 123 It currently read: 125 If an RBridge supports BFD [RFC7175], it will have learned whether 126 the other RBridge has BFD enabled by whether or not a BFD-Enabled 127 TLV [RFC6213] was included in its Hellos. 129 Now it should read: 131 If an RBridge supports BFD [RFC7175] [this document], it will have 132 learned whether the other RBridge has BFD enabled by whether or 133 not a BFD-Enabled TLV [RFC6213] was included in its Hellos. 135 4. A New RBridge Channel Message for P2MP BFD 137 RBridge Channel message protocol 0x002 is defined for TRILL point-to- 138 point BFD Control packets in [RFC7175]. That RFC provides that if 139 the M bit of the TRILL Header of the RBridge channel packet 140 containing a BFD Control packet is non-zero, the packet is generally 141 dropped. In P2MP BFD, the head is required to probe tails using 142 multicast. This means the M bit will be set to 1. For this reason, 143 a new RBridge Channel message, whose protocol code point is TBD, is 144 specified in this document. An RBridge that supports P2MP BFD MUST 145 support the new RBridge Channel message for P2MP BFD. The capability 146 to support the RBridge Channel message for P2MP BFD, and therefore 147 support performing P2MP BFD, is announced within the "RBridge Channel 148 Protocols Sub-TLV" in LSPs [RFC7176]. 150 As specified in [RFC7178], when the tail receives TRILL Data packets 151 sent as BFD RBridge channel messages, it will absorb the packets 152 itself rather than deliver these packets to its attached end- 153 stations. 155 5. Discriminators and Packet Demultiplexing 157 The processing in Section 3.2 of [RFC7175] generally applies except 158 that the test on the M bit in the TRILL Header is reversed. If the M 159 bit is zero, the packet MUST be discarded. If the M bit is one, it 160 is processed. 162 After the Section 3.2 of [RFC7175] processing, the tail demultiplexes 163 incoming BFD packets based on a combination of the source address and 164 My Discriminator as specified in [I-D.ietf-bfd-multipoint]. In 165 addition to this combination, TRILL P2MP BFD requires that the tail 166 use the Data Label, which is either the inner VLAN or the Fine 167 Grained Label [RFC7172], for demultiplexing. If the tail needs to 168 notify the head about the failure of a multipath, the tail is 169 required to send unicast BFD Control packets using the same Data 170 Label as used by the head. 172 6. Tracking Active Tails 174 According to [I-D.ietf-bfd-multipoint], the head has a session of 175 type MultipointHead that is bound to a multipoint path. Multipoint 176 BFD Control packets are sent by this session over the multipoint 177 path, and no BFD Control packets are received by it. Each tail 178 dynamically creates a MultipointTail per a multipoint path. 179 MultipointTail sessions receive BFD Control packets from the head 180 over multipoint paths. 182 An example use is when a multicast tree root needs to keep track of 183 all the receivers as in [I-D.ietf-trill-resilient-trees]; this can be 184 done by maintaining a session of type MultipointClient per receiver 185 that is of interest, as described in [I-D.ietf-bfd-multipoint-active- 186 tail]. See [I-D.ietf-bfd-multipoint-active-tail] for detail 187 operations of tracking active tails. 189 7. Security Considerations 190 Multipoint BFD provides its own authentication but does not provide 191 encryption (see Security Considerations in [I-D.ietf-bfd- 192 multipoint]). As specified in this document, the point-to-multipoint 193 BFD payloads are encapsulated in RBridge Channel messages which have 194 been extended by [RFC7978] to provide security. [RFC7978] provides 195 encryption only for point-to-point extended RBridge Channel messages 196 so its encryption facilities are not applicable to this draft. 197 However [RFC7978] provides stronger authentication than that 198 currently provided in BFD. Thus, there is little reason to use the 199 BFD security mechanisms if [RFC7978] authentication is in use. It is 200 expected that a future TRILL document will provide for group keying; 201 when that occurs, the use of [RFC7978] RBridge Channel security will 202 be able to provide both encryption and authentication. 204 For general multipoint BFD security considerations, see 205 [I-D.ietf-bfd-multipoint]. 207 For general RBridge Channel security considerations, see [RFC7178]. 209 8. IANA Considerations 211 IANA is required to allocate a number from the Standards Action range 212 of the RBridge Channel Protocols registry which is part of the 213 Transparent Interconnection of Lots of Links (TRILL) Parameters. The 214 number to be allocated is as follows: 216 Protocol Number 217 ---------------- ------ 218 P2MP BFD Control TBD 220 9. Acknowledgements 222 Authors would like to thank the comments and suggestions from Gayle 223 Noble and Donald Eastlake. 225 10. References 227 10.1. Normative References 229 [I-D.ietf-bfd-multipoint] 230 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 231 Networks", draft-ietf-bfd-multipoint (work in progress). 233 [I-D.ietf-bfd-multipoint-active-tail] 234 Katz, D., Ward, D., and J. Networks, "BFD Multipoint 235 Active Tails.", draft-ietf-bfd-multipoint-active-tail 236 (work in progress). 238 [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 239 Interconnection of Lots of Links (TRILL): RBridge Channel 240 Header Extension", RFC 7978, DOI 10.17487/RFC7978, 241 September 2016, . 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 247 Ghanwani, "Routing Bridges (RBridges): Base Protocol 248 Specification", RFC 6325, July 2011. 250 [RFC7172] Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D. 251 Dutt, "Transparent Interconnection of Lots of Links 252 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 254 [RFC7175] Manral, V., Eastlake, D., Ward, D., and A. Banerjee, 255 "Transparent Interconnection of Lots of Links (TRILL): 256 Bidirectional Forwarding Detection (BFD) Support", RFC 257 7175, May 2014. 259 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 260 and A. Banerjee, "Transparent Interconnection of Lots of 261 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 263 [RFC7177] Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V. 264 Manral, "Transparent Interconnection of Lots of Links 265 (TRILL): Adjacency", RFC 7177, May 2014. 267 [RFC7178] Eastlake, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, 268 "Transparent Interconnection of Lots of Links (TRILL): 269 RBridge Channel Support", RFC 7178, May 2014. 271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 273 May 2017, . 275 10.2. Informative References 277 [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 278 6213, April 2011. 280 [I-D.ietf-trill-resilient-trees] 281 Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A., 282 and A. Ghanwani, "TRILL Resilient Distribution Trees", 283 draft-ietf-trill-resilient-trees (work in progress). 285 Authors' Addresses 287 Mingui Zhang 288 Huawei Technologies 289 No.156 Beiqing Rd. Haidian District 290 Beijing 100095 291 P.R. China 293 Email: zhangmingui@huawei.com 295 Santosh Pallagatti 296 India 298 Email: santosh.pallagatti@gmail.com 300 Vengada Prasad Govindan 301 Cisco Systems 303 Email: venggovi@cisco.com