idnits 2.17.1 draft-hsingh-ipv6-coin-ml-03.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 (December 9, 2019) is 1600 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) ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COIN H. Singh 3 Internet-Draft MNK Consulting 4 Intended status: Standards Track December 9, 2019 5 Expires: June 11, 2020 7 New IPv6 Multicast Addresses for Switch ML 8 draft-hsingh-ipv6-coin-ml-03 10 Abstract 12 Recently, in-network aggregation to scale distributed machine 13 learning (ML) has been presented. A network switch implementation 14 uses IPv4 broadcast messages from switch to the hosts to send updates 15 to all workers. IPv6 does not support broadcast addresses. This 16 document proposes, IPv6 implementations use the IPv6 link-local all- 17 nodes multicast address, until a new IPv6 link-local multicast 18 address is assigned by IANA for switch to hosts multicast 19 communications. 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 https://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 June 11, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Additional Information . . . . . . . . . . . . . . . . . . . 2 58 4. P4 Considerations . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 8.2. Informative References . . . . . . . . . . . . . . . . . 4 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1. Requirements Language 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 2. Introduction 75 New computing in the network for ML uses IPv4 broadcast 76 communications between switch to hosts. [Switch-ML]. With IPv6, 77 multicast communications would be used. This document proposes a new 78 well-known multicast address be defined for such communications. 79 Until a new address is defined, the IPv6 link-local all-nodes 80 multicast address may be used. By definition, a layer-2 switch 81 operates in the link-local subnet. Thus, the IPv6 link-local 82 multicast address defined by this document suffices for switch to 83 host multicast communications. 85 3. Additional Information 87 It is common when new networking protocols such as RPL [RFC6550] and 88 Babel [RFC6126] were developed, each protocol requested IANA for a 89 new IPv6 link-local multicast address for use. Switch ML does not 90 have a protocol defined by IETF just yet and may never define one. 91 However, experiments in switch ML are already using IP or layer-2 92 broadcast communications. For IPv6, switch ML experiments should use 93 IPv6 link-local multicast communications. A new IPv6 link-local 94 multicast address for switch ML facilitates efficient filtering by 95 hosts. 97 If a switch is configured in layer-3 mode and if switch ML 98 communicates with hosts to another IPv6 subnet, an IPv6 Site-Local 99 Scope Multicast address is recommended for communications. 101 4. P4 Considerations 103 P4 issues arise when implementing the paper. A P4 header stack 104 (array) is used to represent the vector. P4 has no for loops, so how 105 does one add elements of the vector? There is the one way. You can 106 have one action that adds 1 header, another that adds 2, another that 107 adds 3, etc., and choose between them at run time via a table lookup. 108 Even with a vector with 20-50 elements, writing such P4 code manually 109 is risky. One has to write a Python script to generate such code. 110 The paper did not think of it, but an alternative exists. With every 111 element in the vector, use a new 1-byte field. The field has values 112 0 or 1. 1 represents bos (bottom of stack) like what MPLS uses. The 113 last element has bos set to 1. Then, one has a termination condition 114 in the P4 parser to terminate recursive parsing of vector. As the 115 parser is recursing through the vector, add the vector elements and 116 save sum in metadata. One does not use a bit for bos because the p4c 117 bmv2 model accepts a header on byte boundary. 119 The same p4c bmv2 model, also, does not accept an index into array if 120 the index is a run-time value. The p4-16 specification allows run- 121 time index. Algorithm 1 in the paper uses "p.idx" which is a run- 122 time value. Again, one has to use P4 tables. Include the run-time 123 variable index as a table search key, which selects between several 124 different actions that are identical, except for the constant array 125 index values they use. This gets cumbersome with 128 or 512 indices 126 in the paper. Again, one would have to generate P4 code to avoid 127 mistakes cut-and-pasting code. For 128 indices with some bit 128 shifting, maybe we reduces indices to 32. If an asic allows run-time 129 index into array, then it is better to use the asic simulator rather 130 than bmv2 simulator. 132 5. Security Considerations 134 Use IPSec [RFC4301]. 136 6. IANA Considerations 138 This document requests IANA to assign a new IPv6 link-local multicast 139 address for use by network ML. This multicast address name is 140 Switch_ML_Host. An interface on the host MUST join this well-known 141 multicast address. 143 Additionally, IANA is requested to assign a new IPv6 Site-Local Scope 144 Multicast address for switch ML to host communication across IPv6 145 subnets. If configured to do so, an interface on the host MUST join 146 this well-known multicast address. 148 7. Acknowledgements 150 Thanks (in alphabetical order by first name) to Marco Canini for his 151 review. 153 8. References 155 8.1. Normative References 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, 159 DOI 10.17487/RFC2119, March 1997, 160 . 162 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 163 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 164 December 2005, . 166 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 167 DOI 10.17487/RFC6126, April 2011, 168 . 170 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 171 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 172 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 173 Low-Power and Lossy Networks", RFC 6550, 174 DOI 10.17487/RFC6550, March 2012, 175 . 177 8.2. Informative References 179 [Switch-ML] 180 Sapio, A., Canini, M., Ho, C., Nelson, J., Kalnis, P., 181 Kim, C., Krishnamurthy, A., Moshref, M., Ports, D. R., and 182 P. Richtarik, "SwitchML: Scaling Distributed Machine 183 Learning with In-Network Aggregation", February 2019, 184 . 186 Author's Address 187 Hemant Singh 188 MNK Consulting 189 7 Caldwell Drive 190 Westford, MA 01886 191 USA 193 Phone: +1 978 692 2340 194 Email: hemant@mnkcg.com 195 URI: http://mnkcg.com/