idnits 2.17.1 draft-ietf-trill-p2mp-bfd-04.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 -- The document date (February 7, 2017) is 2628 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 (==), 1 comment (--). 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 Juniper Networks 6 V. Govindan 7 Cisco Systems 8 Expires: August 11, 2017 February 7, 2017 10 TRILL Support of Point to Multipoint BFD 11 draft-ietf-trill-p2mp-bfd-04 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 message. 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 This Internet-Draft will expire on December 11, 2015. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 2 57 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. A New RBridge Channel Message for P2MP BFD . . . . . . . . . . 3 61 5. Discriminators and Packet Demultiplexing . . . . . . . . . . . 4 62 6. Tracking Active Tails . . . . . . . . . . . . . . . . . . . . 4 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 10.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 TRILL supports multicast forwarding. Applications based on TRILL 74 multicast may need quick detection of multicast failures using P2MP 75 BFD. This document specifies TRILL support of P2MP BFD. 77 To use P2MP BFD, the head end needs to periodically transmit BFD 78 Control packets to all tails using TRILL multicast. A new RBridge 79 Channel message is allocated for this purpose. 81 In order to execute the global protection of distribution used for 82 multicast forwarding [I-D.ietf-trill-resilient-trees], the head needs 83 to track the active status of tails 84 [I-D.ietf-bfd-multipoint-active-tail]. If the tail loses 85 connectivity of the new RBridge Channel message from the head, the 86 tail should notify the head of the lack of multipoint connectivity 87 with unicast BFD Control packets. These unicast BFD Control packets 88 are transmitted using the existing RBridge Channel message assigned 89 to BFD Control [RFC7175]. 91 This document updates [RFC7177] as specified in Section 3 and updates 92 [RFC7175] as specified in Section 4. 94 2. Acronyms and Terminology 95 2.1. Acronyms 97 Data Label: VLAN or Fine Grained Label [RFC7172]. 99 BFD: Bidirectional Forwarding Detection 101 P2MP: Point to Multi-Point 103 TRILL: Transparent Interconnection of Lots of Links or Tunneled 104 Routing in the Link Layer 106 2.2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in 113 this document. 115 3. Bootstrapping 117 The TRILL adjacency mechanism bootstraps the establishment of the BFD 118 session [RFC7177]. A slight wording update to the second sentence in 119 Section 6 of [RFC7177] is required. 121 It currently read: 123 If an RBridge supports BFD [RFC7175], it will have learned whether 124 the other RBridge has BFD enabled by whether or not a BFD-Enabled 125 TLV [RFC6213] was included in its Hellos. 127 Now it should read: 129 If an RBridge supports BFD [RFC7175] [this document], it will have 130 learned whether the other RBridge has BFD enabled by whether or 131 not a BFD-Enabled TLV [RFC6213] was included in its Hellos. 133 4. A New RBridge Channel Message for P2MP BFD 135 RBridge Channel message protocol 0x002 is defined for TRILL point-to- 136 point BFD Control packets in [RFC7175]. If the M bit of the TRILL 137 Header of the RBridge channel packet containing a BFD Control packet 138 is non-zero, the packet MUST be dropped [RFC7175]. In P2MP BFD, the 139 head is required to probe tails using multicast. This means the M 140 bit will be set to 1. For this reason, a new RBridge Channel 141 message, whose protocol code point is TBD, is specified in this 142 document. An RBridge that supports P2MP BFD MUST support the new 143 RBridge Channel message for P2MP BFD. The capability to support the 144 RBridge Channel message for P2MP BFD, and therefore support 145 performing P2MP BFD, is announced within the "RBridge Channel 146 Protocols Sub-TLV" in LSPs [RFC7176]. 148 As specified in [RFC7178], when the tail receives TRILL Data packets 149 sent as BFD RBridge channel messages, it will absorb the packets 150 itself rather than deliver these packets to its attached end- 151 stations. 153 5. Discriminators and Packet Demultiplexing 155 The processing in Section 3.2 of [RFC7175] applies except that the 156 test on the M bit in the TRILL Header is reversed. If the M bit is 157 zero, the packet is discarded. If the M bit is one, it is processed. 159 After the Section 3.2 of [RFC7175] processing, the tail demultiplexes 160 incoming BFD packets based on a combination of the source address and 161 My Discriminator as specified in [I-D.ietf-bfd-multipoint]. In 162 addition to this combination, TRILL P2MP BFD that requires the tail 163 use the Data Label, which is either the inner VLAN or the Fine 164 Grained Label [RFC7172], for demultiplexing. If the tail needs to 165 notify the head about the failure of a multipath, the tail is 166 required to send unicast BFD Control packets using the same Data 167 Label as used by the head. 169 6. Tracking Active Tails 171 According to[I-D.ietf-bfd-multipoint], the head has a session of type 172 MultipointHead that is bound to a multipoint path. Multipoint BFD 173 Control packets are sent by this session over the multipoint path, 174 and no BFD Control packets are received by it. Each tail dynamically 175 creates a MultipointTail per a multipoint path. MultipointTail 176 sessions receive BFD Control packets from the head over multipoint 177 paths. 179 If the head is keeping track of some or all of the tails 180 [I-D.ietf-trill-resilient-trees], it has a session of type 181 MultipointClient per tail that it cares about 182 [I-D.ietf-bfd-multipoint-active-tail]. See 183 [I-D.ietf-bfd-multipoint-active-tail] for detail operations of 184 tacking active tails. 186 7. Security Considerations 188 P2MP BFD control packets can be encapsulated as the payload of the 189 RBridge Channel Tunnel [RFC7978]. In that case, the security option 190 of RBridge Channel Tunnel can secure the transmission of BFD control 191 packets. 193 The demultiplexing of TRILL P2MP BFD at the tail is Data Label aware. 194 This enhances the security of the dynamic creation of MultipointTail 195 sessions at tails. In order to forge BFD Control packets, the 196 attacker has to acquire the right Data Label that the head uses for 197 P2MP BFD. 199 For general multipoint BFD security considerations, see 200 [I-D.ietf-bfd-multipoint]. 202 For general RBridge Channel security considerations, see [RFC7178]. 204 8. IANA Considerations 206 IANA is required to allocate one RBridge Channel protocol number from 207 the Standards Action range, as follows: 209 Protocol Number 210 ---------------- ------ 211 P2MP BFD Control TBD 213 9. Acknowledgements 215 Authors would like to thank the comments and suggestions from Gayle 216 Noble and Donald Eastlake. 218 10. References 220 10.1. Normative References 222 [I-D.ietf-bfd-multipoint] 223 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 224 Networks", draft-ietf-bfd-multipoint (work in progress). 226 [I-D.ietf-bfd-multipoint-active-tail] 227 Katz, D., Ward, D., and J. Networks, "BFD Multipoint 228 Active Tails.", draft-ietf-bfd-multipoint-active-tail 229 (work in progress). 231 [I-D.ietf-trill-resilient-trees] 232 Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A., 233 and A. Ghanwani, "TRILL Resilient Distribution Trees", 234 draft-ietf-trill-resilient-trees (work in progress). 236 [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 237 Interconnection of Lots of Links (TRILL): RBridge Channel 238 Header Extension", RFC 7978, DOI 10.17487/RFC7978, 239 September 2016, . 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, March 1997. 244 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 245 Ghanwani, "Routing Bridges (RBridges): Base Protocol 246 Specification", RFC 6325, July 2011. 248 [RFC7172] Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D. 249 Dutt, "Transparent Interconnection of Lots of Links 250 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 252 [RFC7175] Manral, V., Eastlake, D., Ward, D., and A. Banerjee, 253 "Transparent Interconnection of Lots of Links (TRILL): 254 Bidirectional Forwarding Detection (BFD) Support", RFC 255 7175, May 2014. 257 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 258 and A. Banerjee, "Transparent Interconnection of Lots of 259 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 261 [RFC7177] Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V. 262 Manral, "Transparent Interconnection of Lots of Links 263 (TRILL): Adjacency", RFC 7177, May 2014. 265 [RFC7178] Eastlake, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, 266 "Transparent Interconnection of Lots of Links (TRILL): 267 RBridge Channel Support", RFC 7178, May 2014. 269 10.2. Informative References 271 [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 272 6213, April 2011. 274 Authors' Addresses 276 Mingui Zhang 277 Huawei Technologies 278 No.156 Beiqing Rd. Haidian District 279 Beijing 100095 280 P.R. China 282 Email: zhangmingui@huawei.com 284 Santosh Pallagatti 285 Juniper Networks 286 Embassy Business Park 287 Bangalore KA 560093 288 India 290 Email: santoshpk@juniper.net 292 Vengada Prasad Govindan 293 Cisco Systems 295 Email: venggovi@cisco.com