idnits 2.17.1 draft-ietf-trill-p2mp-bfd-05.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 (May 8, 2017) is 2516 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: November 9, 2017 May 8, 2017 10 TRILL Support of Point to Multipoint BFD 11 draft-ietf-trill-p2mp-bfd-05 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 as detected by not receiving the new RBridge Channel 86 message from the head, the tail should notify the head of the lack of 87 multipoint connectivity with unicast BFD Control packets. These 88 unicast BFD Control packets are transmitted using the existing 89 RBridge Channel message assigned 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 one-hop 118 TRILL BFD sessions [RFC7177]. Multi-hop sessions are expected to be 119 configured by the network manager. A slight wording update to the 120 second sentence in Section 6 of [RFC7177] is required. 122 It currently read: 124 If an RBridge supports BFD [RFC7175], it will have learned whether 125 the other RBridge has BFD enabled by whether or not a BFD-Enabled 126 TLV [RFC6213] was included in its Hellos. 128 Now it should read: 130 If an RBridge supports BFD [RFC7175] [this document], it will have 131 learned whether the other RBridge has BFD enabled by whether or 132 not a BFD-Enabled TLV [RFC6213] was included in its Hellos. 134 4. A New RBridge Channel Message for P2MP BFD 136 RBridge Channel message protocol 0x002 is defined for TRILL point-to- 137 point BFD Control packets in [RFC7175]. If the M bit of the TRILL 138 Header of the RBridge channel packet containing a BFD Control packet 139 is non-zero, the packet MUST be dropped [RFC7175]. In P2MP BFD, the 140 head is required to probe tails using multicast. This means the M 141 bit will be set to 1. For this reason, a new RBridge Channel 142 message, whose protocol code point is TBD, is specified in this 143 document. An RBridge that supports P2MP BFD MUST support the new 144 RBridge Channel message for P2MP BFD. The capability to support the 145 RBridge Channel message for P2MP BFD, and therefore support 146 performing P2MP BFD, is announced within the "RBridge Channel 147 Protocols Sub-TLV" in LSPs [RFC7176]. 149 As specified in [RFC7178], when the tail receives TRILL Data packets 150 sent as BFD RBridge channel messages, it will absorb the packets 151 itself rather than deliver these packets to its attached end- 152 stations. 154 5. Discriminators and Packet Demultiplexing 156 The processing in Section 3.2 of [RFC7175] applies except that the 157 test on the M bit in the TRILL Header is reversed. If the M bit is 158 zero, the packet is discarded. If the M bit is one, it is processed. 160 After the Section 3.2 of [RFC7175] processing, the tail demultiplexes 161 incoming BFD packets based on a combination of the source address and 162 My Discriminator as specified in [I-D.ietf-bfd-multipoint]. In 163 addition to this combination, TRILL P2MP BFD requires that the tail 164 use the Data Label, which is either the inner VLAN or the Fine 165 Grained Label [RFC7172], for demultiplexing. If the tail needs to 166 notify the head about the failure of a multipath, the tail is 167 required to send unicast BFD Control packets using the same Data 168 Label as used by the head. 170 6. Tracking Active Tails 172 According to[I-D.ietf-bfd-multipoint], the head has a session of type 173 MultipointHead that is bound to a multipoint path. Multipoint BFD 174 Control packets are sent by this session over the multipoint path, 175 and no BFD Control packets are received by it. Each tail dynamically 176 creates a MultipointTail per a multipoint path. MultipointTail 177 sessions receive BFD Control packets from the head over multipoint 178 paths. 180 If the head is keeping track of some or all of the tails 181 [I-D.ietf-trill-resilient-trees], it has a session of type 182 MultipointClient per tail that it cares about 183 [I-D.ietf-bfd-multipoint-active-tail]. See 184 [I-D.ietf-bfd-multipoint-active-tail] for detail operations of 185 tacking active tails. 187 7. Security Considerations 189 Multipoint BFD provides its own authentication but does not provide 190 encryption (see Security Considerations in [I-D.ietf-bfd- 191 multipoint]). As specified in this document, the point-to-multipoint 192 BFD payloads are encapsulated in RBridge Channel messages which have 193 been extended by [RFC7978] to provide security. However, [RFC7978], 194 while it provides both authentication and encryption for point-to- 195 point extended RBridge Channel messages, provides only authentication 196 for multipoint RBridge Channel messages. Thus, there is little reason 197 to use the [RFC7978] security mechanisms at this time. However, it is 198 expected that a future document will provide for group keying; when 199 that occurs, the use of RBridge Channel security will also be able to 200 provide encryption and may be desirable. 202 For general multipoint BFD security considerations, see 203 [I-D.ietf-bfd-multipoint]. 205 For general RBridge Channel security considerations, see [RFC7178]. 207 8. IANA Considerations 209 IANA is required to allocate one RBridge Channel protocol number from 210 the Standards Action range, as follows: 212 Protocol Number 213 ---------------- ------ 214 P2MP BFD Control TBD 216 9. Acknowledgements 218 Authors would like to thank the comments and suggestions from Gayle 219 Noble and Donald Eastlake. 221 10. References 223 10.1. Normative References 225 [I-D.ietf-bfd-multipoint] 226 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 227 Networks", draft-ietf-bfd-multipoint (work in progress). 229 [I-D.ietf-bfd-multipoint-active-tail] 230 Katz, D., Ward, D., and J. Networks, "BFD Multipoint 231 Active Tails.", draft-ietf-bfd-multipoint-active-tail 232 (work in progress). 234 [I-D.ietf-trill-resilient-trees] 235 Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A., 236 and A. Ghanwani, "TRILL Resilient Distribution Trees", 237 draft-ietf-trill-resilient-trees (work in progress). 239 [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 240 Interconnection of Lots of Links (TRILL): RBridge Channel 241 Header Extension", RFC 7978, DOI 10.17487/RFC7978, 242 September 2016, . 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 248 Ghanwani, "Routing Bridges (RBridges): Base Protocol 249 Specification", RFC 6325, July 2011. 251 [RFC7172] Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D. 252 Dutt, "Transparent Interconnection of Lots of Links 253 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 255 [RFC7175] Manral, V., Eastlake, D., Ward, D., and A. Banerjee, 256 "Transparent Interconnection of Lots of Links (TRILL): 257 Bidirectional Forwarding Detection (BFD) Support", RFC 258 7175, May 2014. 260 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 261 and A. Banerjee, "Transparent Interconnection of Lots of 262 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 264 [RFC7177] Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V. 265 Manral, "Transparent Interconnection of Lots of Links 266 (TRILL): Adjacency", RFC 7177, May 2014. 268 [RFC7178] Eastlake, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, 269 "Transparent Interconnection of Lots of Links (TRILL): 270 RBridge Channel Support", RFC 7178, May 2014. 272 10.2. Informative References 274 [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 275 6213, April 2011. 277 Authors' Addresses 279 Mingui Zhang 280 Huawei Technologies 281 No.156 Beiqing Rd. Haidian District 282 Beijing 100095 283 P.R. China 285 Email: zhangmingui@huawei.com 287 Santosh Pallagatti 288 India 290 Email: santosh.pallagatti@gmail.com 292 Vengada Prasad Govindan 293 Cisco Systems 295 Email: venggovi@cisco.com