idnits 2.17.1 draft-zhang-pim-igp-ext-01.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2843 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) == Unused Reference: 'RFC7770' is defined on line 226, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pim-source-discovery-bsr-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-pim-source-discovery-bsr (ref. 'I-D.ietf-pim-source-discovery-bsr') ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Obsolete normative reference: RFC 7298 (Obsoleted by RFC 8967) ** Obsolete normative reference: RFC 7557 (Obsoleted by RFC 8966) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Stig. Venaas 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track Zheng. Zhang 5 Expires: January 8, 2017 ZTE Corporation 6 July 7, 2016 8 PIM IGP EXT 9 draft-zhang-pim-igp-ext-01 11 Abstract 13 This document introduces a method to advertise multicast source 14 information. The information will be flooded all over the network by 15 OSPF, ISIS and Babel extension. This allows PIM Sparse Mode routers 16 with connected receivers to build a Shortest Path Tree straight away, 17 with no need for a shared a tree. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 8, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Advertisement mechanism . . . . . . . . . . . . . . . . . . . 3 56 4. IGP extension . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. OSPF extension . . . . . . . . . . . . . . . . . . . . . 3 58 4.2. ISIS extension . . . . . . . . . . . . . . . . . . . . . 4 59 4.3. Babel extension . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Consideration . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Terminology 67 RP: Rendezvous Point. 69 RPF: Reverse Path Forwarding. 71 SPT: Shortest Path Tree. 73 FHR: First Hop Router, directly connected to the source. 75 LHR: Last Hop Router, directly connected to the receiver. 77 SG Mapping: Multicast source to group mapping. 79 MSGI: Multicast Source and group Information as abbreviation. 81 2. Introduction 83 [RFC4601] and [RFC7761] introduces that RP can be used to collect the 84 receiver and source information. Obviously, RP may be bottleneck in 85 some busy network. Though the RP-mapping mechanism [RFC6226] is used 86 to make different RP in charge of different groups, it makes the 87 network management more difficult and complex. 89 [I-D.ietf-pim-source-discovery-bsr] defines an effective way to 90 deliver multicast information by the way of PIM packet flooding. 91 This function is very useful in network with the routers that are all 92 credible and controllable. 94 Some routers may be attacked or forged in some networks. In these 95 networks, the source information announcement may be forged. There 96 is authentication method in IGP advertisement, such as OSPF, ISIS and 97 Babel. Authentication can prevent a router from injecting messages 98 with non-existing multicast sources. So the source information 99 announcement may be carried in OSPF, ISIS and Babel extension. 101 3. Advertisement mechanism 103 OSPF and ISIS are deployed widely in internet. And the two protocols 104 are the most popular and important routing protocol. The flooding 105 feature is an effective way to advertise the change of network 106 topology. In order to advertise the MSGI, the IGP flooding feature 107 is beneficial to spread the information to PIM routers that have, or 108 potentially may have, connected receivers. 110 Babel [RFC6126] is a loop-avoiding distance-vector routing protocol 111 that is robust and efficient both in ordinary wired networks and in 112 wireless mesh networks. And multicast service is useful in wired 113 networks and wireless networks. [RFC7298] defines the authentication 114 method of Babel. Babel extension can be used to delivery MSGI. 116 When a router starts receiving packets from a directly connected 117 source, it should advertise a MSGI for the source in the IGP, and 118 keep doing so as long as the source is active. Along with the IGP 119 flooding, the MSGI will quickly spread all over the network. 121 All routers receive the advertisement of the MSGI after flooding. A 122 router that is a LHR, joins the SPT towards the announced source 123 according to standard PIM Sparse Mode procedures, by sending a join 124 to the RPF neighbor towards the source. 126 Routers that do not have any connected receivers store the MSGI, such 127 that they can immediately join the SPT if they later should become a 128 LHR. 130 4. IGP extension 132 4.1. OSPF extension 134 A new type of the OSPF Opaque LSA is defined for OSPF MSGI 135 capability. And the same for OSPFv2 and OSPFv3. The format is: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type | Length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Group Address (Encoded-Group format) | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Src Address (Encoded-Unicast format) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 o Type : The value is TBD. 12 or later digit can be used. 149 o Length: The length of the value. 151 o Group Address: The group we are announcing sources for. The 152 format for this address is given in the Encoded-Group format in 153 [RFC7761]. 155 o Src Address: The source address for the corresponding group. The 156 format for these addresses is given in the Encoded-Unicast address 157 in [RFC7761]. 159 The TLV repeats for many groups and groups. In the case where a 160 source stops sending, the FHR simply stops announcing the TLVs. Then 161 the other routers delete the source information. 163 4.2. ISIS extension 165 A new ISIS TLV is defined for the MSGI advertisement. The format of 166 the TLV is same as OSPF. 168 4.3. Babel extension 170 A new Babel TLV is defined for MSGI advertisement according to 171 [RFC7557]. The format is same as OSPF. 173 5. Security Consideration 175 OSPF and ISIS protocol have the capability of authentication. The 176 security function can be used unchanged for the MSGI advertisement. 178 The authentication method defined in Babel [RFC7298] can be used 179 unchanged for MSGI advertisement. 181 6. IANA Considerations 183 A new OSPF Opaque LSA need to be added for carrying OSPF MSGI TLV. 185 A new MSGI TLV need to be added for ISIS MSGI advertisement. 187 A new Babel TLV is defined for MSGI advertisement according to 188 [RFC7557]. 190 7. Normative References 192 [I-D.ietf-pim-source-discovery-bsr] 193 Wijnands, I., Venaas, S., Brig, M., and A. Jonasson, "PIM 194 flooding mechanism and source discovery", draft-ietf-pim- 195 source-discovery-bsr-04 (work in progress), March 2016. 197 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 198 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 199 Protocol Specification (Revised)", RFC 4601, 200 DOI 10.17487/RFC4601, August 2006, 201 . 203 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 204 DOI 10.17487/RFC6126, April 2011, 205 . 207 [RFC6226] Joshi, B., Kessler, A., and D. McWalter, "PIM Group-to- 208 Rendezvous-Point Mapping", RFC 6226, DOI 10.17487/RFC6226, 209 May 2011, . 211 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 212 (HMAC) Cryptographic Authentication", RFC 7298, 213 DOI 10.17487/RFC7298, July 2014, 214 . 216 [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing 217 Protocol", RFC 7557, DOI 10.17487/RFC7557, May 2015, 218 . 220 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 221 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 222 Multicast - Sparse Mode (PIM-SM): Protocol Specification 223 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 224 2016, . 226 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 227 S. Shaffer, "Extensions to OSPF for Advertising Optional 228 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 229 February 2016, . 231 Authors' Addresses 233 Stig Venaas 234 Cisco Systems, Inc. 235 Tasman Drive 236 San Jose CA 95134 237 USA 239 Email: stig@cisco.com 241 Zheng(Sandy) Zhang 242 ZTE Corporation 243 No. 50 Software Ave, Yuhuatai Distinct 244 Nanjing 245 China 247 Email: zhang.zheng@zte.com.cn