idnits 2.17.1 draft-omar-alsp-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 82 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 117: '... MUST configure the ASN so it can b...' RFC 2119 keyword, line 126: '... - The engineer MUST redistribute BGP...' RFC 2119 keyword, line 143: '... BGP and MUST configure the ASN of ...' RFC 2119 keyword, line 145: '...GP, the engineer MUST redistribute the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (April 16, 2020) is 1469 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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-omar-alsp-00 Khaled Omar 2 Internet-Draft The Road 3 Intended status: Standard Track 4 Expires: October 16, 2020 April 16, 2020 6 ASN Label Switching Protocol (ALSP) 7 Specification 8 draft-omar-alsp-00 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the provisions 13 of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF). Note that other groups may also distribute working documents 17 as Internet-Drafts. The list of current Internet-Drafts is at 18 http://datatracker.ietf.org/drafts/current/. 20 Internet-Drafts are draft documents valid for a maximum of six months and 21 may be updated, replaced, or obsoleted by other documents at any time. 22 It is inappropriate to use Internet-Drafts as reference material or to cite 23 them other than as "work in progress." 25 This Internet-Draft will expire on October 16, 2020. 27 Copyright Notice 29 Copyright (c) 2020 IETF Trust and the persons identified as the document 30 authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 33 Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect 34 on the date of publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect to this 36 document. Code Components extracted from this document must include 37 Simplified BSD License text as described in Section 4.e of the Trust Legal 38 Provisions and are provided without warranty as described in the Simplified 39 BSD License. 41 Abstract 43 This document specifies ASN Label Switching Protocol (ALSP). 45 Table of Contents 47 1. Introduction..................................................1 48 2. ALSP Header...................................................1 49 3. ASN Label Switching Protocol (ALSP)...........................1 50 4. Security Considerations.......................................3 51 5. Acknowledgments...............................................3 52 6. Author Address................................................3 53 7. References....................................................3 54 8. Full Copyright Statement......................................3 56 RFC ASN Label Switching Protocol (ALSP) April 16, 2020 58 1. Introduction 60 - ASN Label Switching Protocol (ALSP) is a wide-area network (WAN) 61 protocol that is used to connect an Enterprise's local-area networks 62 (LANs) through Service Provider's network. 63 - ALSP can be used to connect different Enterpises' networks as well 64 that uses overlapped private IPv4 addresses. 65 - ALSP depends on the unique ASN assigned to each organization. 66 - ALSP is similar to the MPLS concept but much more simpler. 68 2. ALSP Header 70 - ALSP adds the following header to the IP packet: 72 +-+-+-+-+-+-+ 73 | ASN | 74 +-+-+-+-+-+-+ 75 32-bits 77 - ASN is the Autonomous System Number. 79 3. ASN Label Switching Protocol (ALSP) 81 - Consider the following two enterprise sites that are connected 82 through an ALSP Cloud of routers: 84 Customer-A SP-1 Customer-A 85 Site-1 ALSP Colud Site-2 86 ASN-100 ASN-300 ASN-100 88 ************* **************** ************* 89 *10.1.1.0/24* * * * * 90 * *CE1 PE1* *PE2 CE2* * 91 * IGP-1 * x *o----o* x * IGP-2 * x *o----o* x * IGP-3 * 92 * * eBGP * * eBGP * * 93 * * * * * * 94 ************* **************** ************* 96 Sample Network for Connecting an Enterprise with Two Sites 98 Where: 100 - CE: Customer Edge. 101 - PE: Provider Edge. 102 - ASN: Autonomous System Number. 103 - IGP: Interior Gateway Protocol. 104 - eBGP: External Boarder Gateway Protocol. 106 - CE1 has ALSP enabled on the interface connected to PE1. 107 - Similarly, CE2 has ALSP enabled on the interface connected 108 to PE2. 109 - Also, all the ALSP cloud routers have ALSP enabled globally. 110 - ALSP enabled interface means that the IGP or EGP advertisements 111 through this interface can have the ALSP header which is the ASN 112 configured on the IGP or EGP. 113 - Consider that Customer-A's Site-1 has a subnet 10.1.1.0/24 that 114 needs to be advertised to Site-2. 115 - The 10.1.1.0/24 subnet is learned by CE1 through IGP-1. 116 - The engineer first should advertise this subnet through BGP and 117 MUST configure the ASN so it can be added to the advertised update 118 messages. 119 - When PE1 receives the BGP update with ASN 100, if it doesn't have 120 a VRF table for ASN-100, AUTOMATICALLY it will create a VRF instance 121 with a naming convention VRF-ASN, so in this case it will be VRF-100. 123 RFC ASN Label Switching Protocol (ALSP) April 16, 2020 125 - Now, PE1 has a VRF-100 table with 10.1.1.0/24 learned by BGP. 126 - The engineer MUST redistribute BGP into IGP-2 and adds the ASN 127 of Customer-A to the configuration. 128 - Through IGP-2, all routers within ASN-300 will learn about the 129 subnet 10.1.1.0/24. 130 - Each router within the ALSP cloud receives the update takes 131 one of the following actions: 133 a) If there is no VRF table for that ASN, it will create one 134 and add the learned subnet to that VRF table. 135 b) If there is already created VRF table for that ASN, it will 136 only add the learned subnet to that VRF table. 138 - Now, consider that PE2 received the update through IGP-2 and it 139 has not any VRF for that ASN that is associated with the update 140 message, it will create a new VRF table called VRF-100 and add 141 10.1.1.0/24 to that table. 142 - Now, the engineer should advertise 10.1.1.0/24 subnet to CE2 using 143 BGP and MUST configure the ASN of that VRF. 144 - When CE2 receives 10.1.1.0/24 subnet with ASN-100 in the header 145 via BGP, the engineer MUST redistribute the BGP learned subnet 146 into IGP-3 normally. 148 RFC ASN Label Switching Protocol (ALSP) April 16, 2020 149 Expires: 16-10-2020 151 Security Considerations 153 Acknowledgments 155 Author Address 157 Khaled Omar Ibrahim Omar 158 The Road 159 6th of October City, Giza 160 Egypt 162 Phone: +2 01003620284 163 E-mail: eng.khaled.omar@hotmail.com 164 National ID No.: 28611262102992 166 References 168 Full Copyright Statement 170 Copyright (C) IETF (2020). All Rights Reserved. 172 This document and translations of it may be copied and furnished to 173 others, and derivative works that comment on or otherwise explain it 174 or assist in its implementation may be prepared, copied, published 175 and distributed, in whole or in part, without restriction of any 176 kind, provided that the above copyright notice and this paragraph are 177 included on all such copies and derivative works. However, this 178 document itself may not be modified in any way, such as by removing 179 the copyright notice or references, except as needed for the purpose of 180 developing Internet standards in which case the procedures for 181 copyrights defined in the Internet Standards process must be 182 followed, or as required to translate it into languages other than 183 English. 185 The limited permissions granted above are perpetual and will not be 186 revoked. 188 This document and the information contained herein is provided on 189 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 190 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 191 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 192 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 193 PURPOSE.