idnits 2.17.1 draft-lamparter-isis-p2mp-02.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '...icipating system MUST use a consistent...' RFC 2119 keyword, line 116: '... MAY support multiple SNPA addresses...' RFC 2119 keyword, line 120: '...cipant on a link MUST have an unique S...' RFC 2119 keyword, line 134: '...is specification MUST therefore suppor...' RFC 2119 keyword, line 148: '...S implementation SHOULD provide user c...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2016) is 2903 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) == Missing Reference: '-02' is mentioned on line 228, but not defined == Missing Reference: '-01' is mentioned on line 230, but not defined == Missing Reference: '-00' is mentioned on line 233, but not defined == Unused Reference: 'RFC7176' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 264, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Downref: Normative reference to an Informational RFC: RFC 5309 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Franke 3 Internet-Draft D. Lamparter 4 Intended status: Standards Track NetDEF 5 Expires: October 19, 2016 C. Hopps 6 Deutsche Telekom 7 April 17, 2016 9 IS-IS Point-to-Multipoint operation 10 draft-lamparter-isis-p2mp-02 12 Abstract 14 This document describes a new mode operation for IS-IS. In addition 15 to the existing LAN and point-to-point modes of operation, a point- 16 to-multipoint mode is defined. This mode is useful for operation 17 both on networks with more than two routers where multicast is 18 expensive in comparison to unicast, as well on networks where 19 creating a LAN pseudonode cannot adequately reflect metrics. 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 October 19, 2016. 38 Copyright Notice 40 Copyright (c) 2016 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. Point-To-Multipoint Pseudocircuits . . . . . . . . . . . . . 3 57 2.1. Pseudocircuit behaviour . . . . . . . . . . . . . . . . . 3 58 2.1.1. Representation in LSPs . . . . . . . . . . . . . . . 3 59 2.1.2. Forwarding . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Neighbor IS discovery . . . . . . . . . . . . . . . . . . 3 61 2.2.1. Manual configuration . . . . . . . . . . . . . . . . 4 62 2.2.2. Lower layer autodiscovery . . . . . . . . . . . . . . 4 63 2.2.3. Multicast autodiscovery . . . . . . . . . . . . . . . 4 64 2.3. Adjacency formation . . . . . . . . . . . . . . . . . . . 5 65 2.4. Pseudocircuit teardown . . . . . . . . . . . . . . . . . 5 66 3. Configuration model . . . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Appendix A. Misconfiguration With P2P over LAN . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 The core functionality of the protocol outlined in this document 80 consists of an additional Subnetwork dependent function per Section 8 81 of ISO/IEC 10589:2002 [IS-IS]. In that regard, the next section can 82 be understood as new section "8.5 Point-to-multipoint networks". 84 The outlined protocol is remotely similar to the derelict section 85 "8.3 ISO 8208 subnetworks" [X.25] in that multiple point-to-point 86 adjacencies are established on an interface. 88 Point-to-multipoint operation of IS-IS is thus not a new idea; in 89 fact section 6.2 already mentions "multipoint links." This document 90 re-enables the concept. 92 2. Point-To-Multipoint Pseudocircuits 94 In place of ISO 8473 call management [CLNS] establishing sessions, 95 this document establishes pairwise "pseudocircuits" between two IS on 96 a common medium. Multiple such pseudocircuits can normally exist on 97 one P2MP (Point-To-Multipoint) interface. 99 Each pseudocircuit operates, aside from subnetwork attachment 100 procedures, exactly as a P2P (Point-to-Point) link. 102 It should be noted that while the Multicast autodiscovery mechanism 103 requires broadcast capability, no other part of the protocol does. 104 The P2MP interface type can be used on non-transitive and/or non- 105 broadcast interfaces. 107 2.1. Pseudocircuit behaviour 109 An implementation maintains a set of pseudocircuits per P2MP 110 interface. Each pseudocircuit is uniquely identified by the local 111 interface and peer's SNPA address. 113 Each participating system MUST use a consistent SNPA address per 114 local interface. A change in SNPA address results in all neighbors 115 treating the interface as distinct from the previous one. A system 116 MAY support multiple SNPA addresses per interface by treating them as 117 distinct interfaces. 119 Unnumbered media are not supported by this protocol. Each 120 participant on a link MUST have an unique SNPA address on that link. 122 2.1.1. Representation in LSPs 124 Pseudocircuits are represented in LSPs as a regular P2P circuit would 125 be. As a result, their treatment in SPF calculations is also 126 identical to P2P circuits. 128 2.1.2. Forwarding 130 In scenarios where pseudocircuits do not form a full mesh of all 131 participants on a medium, the best path for a packet may be through 132 the same interface as the one it was received on. 134 Systems implementing this specification MUST therefore support 135 forwarding packets on the same interface that they were received on. 136 This applies only to interfaces configured for P2MP operation. 138 2.2. Neighbor IS discovery 139 The discovery machinery produces as output a "candidate neighbor 140 list," which is a list of possible neighbor's SNPAs and is maintained 141 per P2MP interface. Adding and removing entries to the candidate 142 neighbor list results in pseudocircuit creation and deletion. 144 A neighbors presence on the candidate list may be supported by 145 multiple sources. These sources are described in the following 146 sections 148 The IS-IS implementation SHOULD provide user configuration to disable 149 or filter individual sources. 151 2.2.1. Manual configuration 153 A list of neighbor IS MAY be configured by the user, providing 154 possible neighbor's SNPAs on an interface. 156 2.2.2. Lower layer autodiscovery 158 Lower protocol layers (VPLS, IEEE 802.11) may be able to provide a 159 list of attached neighbors. This list MAY be fed into the candidate 160 neighbor list. 162 2.2.3. Multicast autodiscovery 164 For broadcast capable networks, this document defines an 165 autodiscovery mechanism based on multicasting Hello packets. This 166 mechanism MAY be disabled by the user, but MUST be implemented for 167 all lower layer link types with (limited or full) broadcast 168 capability. 170 A multicast autodiscovery packet is defined as a P2P IIH which is 171 multicast over the LAN media as defined in [RFC5309]. Additionally 172 it must include a Three-Way Adjacency TLV as defined in [RFC5303] 173 indicating the circuit is in the DOWN state (i.e., 1 octet of value 174 indicating the DOWN state). Receiving such a Hello places the 175 sending IS on the candidate list for as long as the PDU's holdtime 176 indicates. 178 A system MAY implement a receive-only passive multicast autodiscovery 179 mode where it adds candidates (forms pseudocircuits) on receiving 180 autodiscovery PDU, but does not send such PDUs itself. 182 If either passive or full multicast autodiscovery is enabled, 183 receiving a unicast autodiscovery PDU also adds the neighbor to the 184 candidate list. 186 2.3. Adjacency formation 188 Since there may be no underlying protocol layer partitioning the link 189 into actual P2P circuits in this case, additional handling is 190 required on bringing up the individual pseudocircuit adjacencies. 192 To prevent different pseudocircuits from "bleeding" into each other, 193 implementations of this protocol MUST enable [RFC5303] on all P2MP 194 pseudocircuits, with changes as follows: 196 o Received IIH PDUs on P2MP pseudocircuits without the Point-to- 197 Point Three-Way Adjacency option MUST be discarded. 199 2.4. Pseudocircuit teardown 201 Pseudocircuits are destroyed when their P2P state machine has 202 transitioned into "Down" state and they are no longer supported as a 203 candidate by any discovery mechanism. 205 As long as a pseudocircuit is present, its P2P state machine will, as 206 expected for P2P circuits, trigger transmission of further Hello 207 PDUs, even when it is in Down state. 209 3. Configuration model 211 TODO: YANG model 213 4. Security Considerations 215 TODO. 217 5. Privacy Considerations 219 TODO. 221 6. Acknowledgements 223 Acknowledge Les Ginsberg for pointing out that P2P Hellos rather than 224 LAN hellos could and should be used. 226 7. Change Log 228 April 2016 [-02]: (no changes/keepalive) 230 October 2015 [-01]: Moved from new P2MP Hello PDU to using existing 231 P2P PDU. 233 July 2015 [-00]: Initial Version 235 8. References 237 8.1. Normative References 239 [IS-IS] ISO/IEC, "Intermediate System to Intermediate System 240 Intra-Domain Routing Exchange Protocol for use in 241 Conjunction with the Protocol for Providing the 242 Connectionless-mode Network Service (ISO 8473)", ISO/IEC 243 10589:2002, Second Edition, 2002. 245 [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way 246 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 247 October 2008. 249 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 250 over LAN in Link State Routing Protocols", RFC 5309, DOI 251 10.17487/RFC5309, October 2008, 252 . 254 8.2. Informative References 256 [CLNS] ISO/IEC, "Protocol for providing the connectionless-mode 257 network service: Protocol specification", ISO/IEC 258 8473-1:1998, 1998. 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 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 265 Scope Link State PDUs (LSPs)", RFC 7356, September 2014. 267 [X.25] ISO/IEC, "X.25 Packet Layer Protocol for Data Terminal 268 Equipment", ISO/IEC 8208:2000, 2000. 270 Appendix A. Misconfiguration With P2P over LAN 272 TODO. 274 Authors' Addresses 276 Christian Franke 277 NetDEF 278 Leipzig 279 DE 281 Email: chris@opensourcerouting.org 282 David Lamparter 283 NetDEF 284 Leipzig 04229 285 Germany 287 Email: david@opensourcerouting.org 289 Christian E. Hopps 290 Deutsche Telekom 292 Email: chopps@chopps.org