idnits 2.17.1 draft-shyam-rt-inside-vlsm-tree-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 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2018) is 2125 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 1771 (ref. '1') (Obsoleted by RFC 4271) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Bandyopadhyay 3 draft-shyam-rt-inside-vlsm-tree-01.txt July 1, 2018 4 Intended status: Proposed Standard 5 Expires: January 1, 2019 7 Setting Default Route Inside VLSM Tree 8 draft-shyam-rt-inside-vlsm-tree-01.txt 10 Abstract 12 This document shows how to set default route inside VLSM tree. With 13 this approach routing information of the external world need not be 14 passed down to the VLSM tree. It shows how RSVP-TE is extended to 15 support IP-VPN with MPLS to support default route inside VLSM tree. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 1, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 1. Introduction 48 Inside a VLSM tree of provider assigned address space, traditionally 49 BGP [1] is used to provide routing and to support VPN services [2]. 50 This document shows how routing is achieved inside a VLSM tree by 51 setting default route instead of using BGP. With this approach 52 routing information of the external world need not be passed down to 53 the VLSM tree. Thus load inside a router gets reduced substantially. 54 This document shows how RSVP-TE is extended to support IP-VPN with 55 MPLS by setting default route inside a VLSM tree. Inside a customer 56 network, if address space is distributed in the form of a VLSM tree, 57 same approach can be applied in place of using a traditional routing 58 algorithm. 60 2. Setting default route inside VLSM tree 62 Inside a VLSM tree, a node of higher prefix can be divided into 63 number of nodes with lower prefixes. Each divided node can further be 64 subdivided with nodes of further lower prefixes. This process can be 65 continued as long as it is desired or no more division is further 66 possible. 68 +--------------+ 69 | SW-A | 70 | 11.1.16.0/20 | 71 +-+-+------+-+-+ 72 | | | | 73 +---------------+ | | +----------------+ 74 | | | | 75 +------+-----+ +---------+--+ +-+----------+ +-----+------+ 76 | SW-B | | SW-C | | SW-D | | SW-E | 77 |11.1.16.0/21| |11.1.24.0/22| |11.1.28.0/23| |11.1.30.0/23| 78 +---+----+---+ +------------+ +------------+ +--+---------+ 79 | | | 80 | +-------+ | 81 | | +--+--+ 82 +-------+----+ +----+-------+ |CN-D | 83 | SW-F | | SW-G | +-----+ 84 |11.1.16.0/22| |11.1.20.0/22| 11.1.30.0/24 85 +--+---------+ +--+------+--+ 86 | | | 87 | | | 88 +--+--+ +--+--+ +-+---+ 89 |CN-A | |CN-B | |CN-C | 90 +-----+ +-----+ +-----+ 91 11.1.16.0/24 11.1.20.0/24 11.1.21.0/24 92 Figure above shows a typical arrangement of VLSM tree of a service 93 provider's network with IPv4 address space. Switch SW-A is connected 94 to the outside world and maintains global routing table. It acts as 95 the root of a VLSM tree that acts as a stub. It has been assigned an 96 address block 11.1.16.0/20 which is distributed among its four 97 children SW-B, SW-C, SW-D and SW-E with the approach of VLSM. Switch 98 SW-B further divides its address space between switches SW-F and SW- 99 G. Switch SW-F assigns an address block 11.1.16.0/24 to customer 100 network CN-A. Switch SW-G assigns address block 11.1.20.0/24 and 101 11.1.21.0/24 to two customers CN-B and CN-C; where as switch SW-E 102 assigns address block 11.1.30.0/24 to customer network CN-D. 104 Routing inside the tree takes place with the following principle. 106 Inside the tree, if a node (switch/router) that is assigned a domain 107 (NetAddr/NetMask) receives a packet which is destined to somewhere 108 outside of its domain, needs to forward the packet to its parent in 109 the hierarchy. 111 If a host in CN-A wants to send a packet to an address 11.1.21.116, 112 CE router of CN-A forwards it to SW-F. SW-F finds the destination 113 address of the packet to be outside of its domain and forwards the 114 packet to its parent SW-B. SW-B finds that a port that has been 115 configured with the matching destination address and forwards it to 116 its child SW-G. Switch SW-G sends the packet to customer network CN- 117 B. 119 If a host in CN-B wants to send a packet to 11.1.17.120, CE router of 120 CN-B forwards the packet to SW-G. SW-G finds the destination address 121 of the packet to be outside of its domain and forwards the packet to 122 its parent SW-B. SW-B finds that a port that has been configured with 123 the matching destination address and forwards the packet to its child 124 SW-F. SW-F finds the destination address to be within its domain, but 125 no port has been configured with the matching destination address and 126 generates ICMP UNREACHABLE. 128 If a host in CN-C wants to send a packet to 16.2.22.116, CE router of 129 CN-C forwards the packet to SW-G. SW-G finds the destination address 130 of the packet to be outside its domain and forwards the packet to SW- 131 B. SW-B forwards the packet to its parent SW-A. SW-A find the 132 destination address of the packet to be outside its domain and 133 consults with the global forwarding table and forwards the packet 134 through the right port. 136 Section 2.5.4. of RFC 4291[3] defines the format of global unicast 137 addresses in IPv6 in the following manner: 139 | n bits | m bits | 128-n-m bits | 140 +------------------------+-----------+----------------------------+ 141 | global routing prefix | subnet ID | interface ID | 142 +------------------------+-----------+----------------------------+ 144 Inside a provider network in IPv6 environment, only the "global 145 routing prefix" portion has to be considered for setting up default 146 route. Inside a customer network in IPv6 environment, if VLSM tree is 147 used for distribution of address space, "global routing prefix" + 148 "subnet ID" portion has to be considered for setting up default 149 route. 151 If a new specification of IP is designed (say,with 64 bit address 152 space) where customer networks are assigned address space based on 153 their size (need), entire part of the address has to be considered 154 for setting up VLSM tree (the way it works with IPv4). 156 3. IP VPN with MPLS inside VLSM tree 158 Section 2 describes that there is no need to pass down the routing 159 information of the external world inside VLSM tree. This section 160 describes how to make IP VPN work inside VLSM tree without using BGP. 162 RFC4364 [2] describes "IP VPN" with BGP/MPLS. To support VPN, PE 163 routers maintain per-site forwarding table. When a packet arrives 164 from an associated CE router, PE router consults with this forwarding 165 table to forward the packet. If the packet is supposed to be 166 forwarded to another site of VPN through the backbone, it uses two- 167 level label stack. The upper label is used to forward the packet from 168 ingress PE router to the egress PE router; where as, the inner label 169 is used for the egress PE router to identify the associated CE router 170 where the packet is supposed to be forwarded. BGP is used by the 171 Service Provider to exchange the routes of a particular VPN among the 172 PE routers that are attached to that VPN. Configuration takes place 173 on PE routers of both the sides of LSP. The simplest way to achieve 174 this is to configure these attributes manually on PE routers. In 175 order to have dynamic allocation of inner label, MPLS signaling 176 protocols (in place of BGP) need to be extended. Allocation of inner 177 label has to be done by the egress PE router. Same message that is 178 used for the assignment of upper label may be used for the assignment 179 of inner label. Inside the forwarding table, each entry contains the 180 forwarding destination address based on a set of destination 181 addresses (NetAddress/NetMask) of the IP packets received from 182 ingress CE router. While establishing inner label, ingress PE router 183 needs to send these attributes with the signaling message and the 184 egress PE router needs to validate those before assigning label. 186 3.1. Extension to RSVP-TE to support IP VPN inside VLSM tree 188 This section describes extension to RSVP-TE[4] to support dynamic 189 allocation of inner label of two-level label stack used to support 190 VPN services. 192 In order to establish LSP using RSVP-TE, ingress PE router sends Path 193 message to the egress PE router. Path message is augmented with a 194 LABEL_REQUEST object. Labels are allocated downstream and 195 distributed (propagated upstream) by means of RSVP Resv message. For 196 this purpose, the RSVP Resv message is extended with a special LABEL 197 object. In order to support VPN to establish the inner label, Path 198 message is augmented with a VPN_ATTRIBUTE label. Similarly, RSVP Resv 199 message is extended with a VPN_LABEL object. When an egress PE router 200 receives a Path message, it checks the presence of VPN_ATTRIBUTE 201 object. On finding this object, egress PE router checks the viability 202 of assignment of VPN label with the parameters from the VPN_ATTRIBUTE 203 object and the attributes that are already configured with the egress 204 PE router. If the test is positive, it assigns a VPN label and does 205 the rest of the processing of LSP label assignment and sends the RSVP 206 Resv message with the extension of VPN_LABEL object towards the 207 ingress PE router. On receiving Resv message with VPN_LABEL object, 208 ingress PE router assigns VPN label along with the rest of the 209 processing of Resv message and completes the operation. VPN_ATTRIBUTE 210 and VPN_LABEL objects are described below. 212 VPN_LABEL class=, C-Type=1 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | (inner label) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 VPN_ATTRIBUTE class=, C-Type=1 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Global Unicast Address of Ingress CE Router | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Global Unicast Address of Egress CE Router | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Net Address of Destination IP Packet | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Net Mask of Destination IP Packet | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 The format of the Path message is as follows: 234 ::= [ ] 235 236 237 [ ] 238 239 [ ] 240 [ ] 241 [ ... ] 242 244 ::= 245 [ ] 246 [ ] 248 The format of the Resv message is as follows: 250 ::= [ ] 251 252 253 [ ] [ ] 254 [ ... ] 255 [ ] 256