idnits 2.17.1 draft-ietf-trill-p2mp-bfd-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 : ---------------------------------------------------------------------------- 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 (June 09, 2015) is 3238 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 (-19) exists of draft-ietf-bfd-multipoint-06 == Outdated reference: A later version (-10) exists of draft-ietf-bfd-multipoint-active-tail-00 == Outdated reference: A later version (-11) exists of draft-ietf-trill-channel-tunnel-05 == Outdated reference: A later version (-09) exists of draft-ietf-trill-resilient-trees-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 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 Expires: December 11, 2015 Juniper Networks 6 V. Govindan 7 Cisco Systems 8 June 09, 2015 10 TRILL Support of Point to Multipoint BFD 11 draft-ietf-trill-p2mp-bfd-00 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 an RBridge Channel. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 11, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 2 56 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. A New RBridge Channel for P2MP BFD . . . . . . . . . . . . . 3 60 5. Discriminators and Packet Demultiplexing . . . . . . . . . . 4 61 6. Tracking Active Tails . . . . . . . . . . . . . . . . . . . . 4 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 10.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 TRILL supports multicast forwarding. Applications based on TRILL 73 multicast may need quick detection of multicast failures using P2MP 74 BFD. This document specifies TRILL support 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 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]. When the tail loses 84 connectivity from the head, the tail should notify the head of the 85 lack of multipoint connectivity with unicast BFD Control packets. 86 These packets are transmitted using the existing RBridge Channel 87 assigned to BFD Control [RFC7175]. 89 2. Acronyms and Terminology 91 2.1. Acronyms 93 Data Label: VLAN or Fine Grained Label [RFC7172]. 95 BFD: Bidirectional Forwarding Detection 96 P2MP: Point to Multi-Point 98 TRILL: Transparent Interconnection of Lots of Links or Tunneled 99 Routing in the Link Layer 101 2.2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 Familiarity with [RFC6325][RFC7175][RFC7178] is assumed in this 108 document. 110 3. Bootstrapping 112 The TRILL adjacency mechanism bootstraps the establishment of the BFD 113 session [RFC7177]. A slight wording update to the second sentence in 114 Section 6 of [RFC7177] is required. 116 It currently read: 118 If an RBridge supports BFD [RFC7175], it will have learned whether 119 the other RBridge has BFD enabled by whether or not a BFD-Enabled 120 TLV [RFC6213] was included in its Hellos. 122 Now it should read: 124 If an RBridge supports BFD [RFC7175] [this document], it will have 125 learned whether the other RBridge has BFD enabled by whether or 126 not a BFD-Enabled TLV [RFC6213] was included in its Hellos. 128 4. A New RBridge Channel for P2MP BFD 130 RBridge Channel 0x002 is defined for TRILL point-to-point BFD Control 131 packets in [RFC7175]. If the M bit of the TRILL Header of the 132 channeled packet containing the BFD Control packet is non-zero, the 133 packet MUST be dropped [RFC7175]. While for P2MP BFD, the head is 134 required to probe tails using multicast. This means the M bit will 135 be set to 1. For this reason, a new RBridge Channel, whose code 136 point is TBD, is specified in this document. An RBridge that 137 supports P2MP BFD MUST support the new RBridge Channel for P2MP BFD. 138 The capability to support the RBridge Channel for P2MP BFD, and 139 therefore support performing P2MP BFD, is announced within the 140 "RBridge Channel Protocols Sub-TLV" in LSPs [RFC7176]. 142 As specified in [RFC7178], when the tail receives TRILL Data packets 143 sent on the channel, it will absorb the packets itself rather than 144 deliver these packets to its attached end-stations. 146 5. Discriminators and Packet Demultiplexing 148 The processing in Section 3.2 of [RFC7175] applies except that the 149 test on the M bit in the TRILL Header is reversed. If the M bit is 150 zero, the packet is discarded. If the M bit is one, it is processed. 152 After the Section 3.2 of [RFC7175] processing, the tail demultiplexes 153 incoming BFD packets based on a combination of the source address and 154 My Discriminator as specified in [I-D.ietf-bfd-multipoint]. In 155 addition to this combination, TRILL P2MP BFD requires the tail to use 156 the Data Label, which is either the inner VLAN or the Fine Grained 157 Label [RFC7172], for demultiplexing. If the tail need to notify the 158 head about the failure of a multipath, the tail is required to send 159 unicast BFD Control packets using the same Data Label as used by the 160 head. 162 6. Tracking Active Tails 164 According to[I-D.ietf-bfd-multipoint], the head has a session of type 165 MultipointHead that is bound to a multipoint path. Multipoint BFD 166 Control packets are sent by this session over the multipoint path, 167 and no BFD Control packets are received by it. Each tail dynamically 168 creates a MultipointTail per a multipoint path. MultipointTail 169 sessions receive BFD Control packets from the head over multipoint 170 paths. 172 If the head is keeping track of some or all of the tails 173 [I-D.ietf-trill-resilient-trees], it has a session of type 174 MultipointClient per tail that it cares about 175 [I-D.ietf-bfd-multipoint-active-tail]. See 176 [I-D.ietf-bfd-multipoint-active-tail] for detail operations of 177 tacking active tails. 179 7. Security Considerations 181 P2MP BFD control packets can be encapsulated as the payload of the 182 RBridge Channel Tunnel [I-D.ietf-trill-channel-tunnel]. In that 183 case, the security option of RBridge Channel Tunnel can secure the 184 transmission of BFD control packets. 186 The demultiplexing of TRILL P2MP BFD at the tail is Data Label aware. 187 This enhances the security of the dynamic creation of MultipointTail 188 sessions at tails. In order to forge BFD Control packets, the 189 attacker has to acquire the right Data Label that the head uses for 190 P2MP BFD. 192 For general multipoint BFD security considerations, see 193 [I-D.ietf-bfd-multipoint]. 195 For general RBridge Channel security considerations, see [RFC7178]. 197 8. IANA Considerations 199 IANA is required to allocate one RBridge Channel protocol number from 200 the Standards Action range, as follows: 202 Protocol Number 203 ---------------- ------ 204 P2MP BFD Control TBD 206 9. Acknowledgements 208 Authors would like to thank the comments and suggestions from Donald 209 Eastlake. 211 10. References 213 10.1. Normative References 215 [I-D.ietf-bfd-multipoint] 216 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 217 Networks", draft-ietf-bfd-multipoint-06 (work in 218 progress), May 2015. 220 [I-D.ietf-bfd-multipoint-active-tail] 221 Katz, D., Ward, D., and J. Networks, "BFD Multipoint 222 Active Tails.", draft-ietf-bfd-multipoint-active-tail-00 223 (work in progress), May 2015. 225 [I-D.ietf-trill-channel-tunnel] 226 Eastlake, D., Umair, M., and L. Yizhou, "TRILL: RBridge 227 Channel Tunnel Protocol", draft-ietf-trill-channel- 228 tunnel-05 (work in progress), April 2015. 230 [I-D.ietf-trill-resilient-trees] 231 Zhang, M., Senevirathne, T., Pathangi, J., Banerjee, A., 232 and A. Ghanwani, "TRILL Resilient Distribution Trees", 233 draft-ietf-trill-resilient-trees-02 (work in progress), 234 December 2014. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 240 Ghanwani, "Routing Bridges (RBridges): Base Protocol 241 Specification", RFC 6325, July 2011. 243 [RFC7172] Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D. 244 Dutt, "Transparent Interconnection of Lots of Links 245 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 247 [RFC7175] Manral, V., Eastlake, D., Ward, D., and A. Banerjee, 248 "Transparent Interconnection of Lots of Links (TRILL): 249 Bidirectional Forwarding Detection (BFD) Support", RFC 250 7175, May 2014. 252 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 253 and A. Banerjee, "Transparent Interconnection of Lots of 254 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 256 [RFC7177] Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V. 257 Manral, "Transparent Interconnection of Lots of Links 258 (TRILL): Adjacency", RFC 7177, May 2014. 260 [RFC7178] Eastlake, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, 261 "Transparent Interconnection of Lots of Links (TRILL): 262 RBridge Channel Support", RFC 7178, May 2014. 264 10.2. Informative References 266 [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 267 6213, April 2011. 269 Authors' Addresses 271 Mingui Zhang 272 Huawei Technologies 273 No.156 Beiqing Rd. Haidian District 274 Beijing 100095 275 P.R. China 277 Email: zhangmingui@huawei.com 278 Santosh Pallagatti 279 Juniper Networks 280 Embassy Business Park 281 Bangalore KA 560093 282 India 284 Email: santoshpk@juniper.net 286 Vengada Prasad Govindan 287 Cisco Systems 289 Email: venggovi@cisco.com