- Test - lists.nanog.org

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 13 Jun '20

13 Jun '20

On Fri, 12 Jun 2020 at 23:25, David Sinn <dsinn(a)dsinn.com> wrote: > > Should we design a rational cost-efficient solution, we should choose > > the lowest overhead and narrowest working keys. > > In the abstract, sure. But if you want a practical, deployable, production network, it's multi-dimensioned. We have probably largely converged to the same place. Your vantage point sees practical offerings where IPIP may make more sense to you than MPLS, my vantage point definitely only implements the rich features I need in MPLS tunnels (RSVP-TE, L2 pseudowires, FRR, L3 MPLS VPN, all of which technically could be done of course with IPIPIP tunnels) And the theory we agree that less is more. ECMP appears to be your main pain point, the rich features are not relevant, and you mentioned commodity hardware being able to hash on IPIP. I feel this may be a very special case where HW can do IPIP hash but not MPLSIP hash. Out of curiosity, what is this hardware? Jericho can do MPLSIP, I know JNPR's pipeline offering, Paradise, can. Or perhaps it's not even that the underlaying hardware you have, cannot do, it's that the NOS you are being offered is so focused on your use-case, it doesn't do anything else reasonably, then of course that use-case is best by default. -- ++ytti

2 1

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 12 Jun '20

12 Jun '20

On 12/Jun/20 17:19, David Sinn wrote: > Yes. Path enumeration when you use mult-tier Clos topologies within a PoP causes you many, many problem. Okay, got you. I thought you were running into these problems on the "usual suspect" platforms. Yes, commodity hardware certainly has a number of trade-offs for the cost benefit. We've been evaluating this path since 2013, and for our use-case, it will actually make less sense because we are more large capacity, small footprint, i.e., typical network service provider. If we were a cloud provider operating at scale in several data centres, our current model of running Cisco's, Juniper's, Arista's, e.t.c., may not necessarily be the right choice in 2020, particularly in the edge. Mark.

1 0

Weekly Routing Table Report
by cscora＠apnic.net 12 Jun '20

12 Jun '20

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 13 Jun, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 815015 Prefixes after maximum aggregation (per Origin AS): 309321 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 397070 Total ASes present in the Internet Routing Table: 68301 Prefixes per ASN: 11.93 Origin-only ASes present in the Internet Routing Table: 58705 Origin ASes announcing only one prefix: 24458 Transit ASes present in the Internet Routing Table: 9596 Transit-only ASes present in the Internet Routing Table: 311 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 46 Max AS path prepend of ASN ( 22394) 38 Prefixes from unregistered ASNs in the Routing Table: 830 Number of instances of unregistered ASNs: 832 Number of 32-bit ASNs allocated by the RIRs: 32024 Number of 32-bit ASNs visible in the Routing Table: 26402 Prefixes from 32-bit ASNs in the Routing Table: 121590 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 544 Number of addresses announced to Internet: 2843328512 Equivalent to 169 /8s, 121 /16s and 192 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 274923 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 214406 Total APNIC prefixes after maximum aggregation: 62465 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 208016 Unique aggregates announced from the APNIC address blocks: 86032 APNIC Region origin ASes present in the Internet Routing Table: 10615 APNIC Prefixes per ASN: 19.60 APNIC Region origin ASes announcing only one prefix: 2963 APNIC Region transit ASes present in the Internet Routing Table: 1582 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5695 Number of APNIC addresses announced to Internet: 769451904 Equivalent to 45 /8s, 220 /16s and 231 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 238331 Total ARIN prefixes after maximum aggregation: 109319 ARIN Deaggregation factor: 2.18 Prefixes being announced from the ARIN address blocks: 235619 Unique aggregates announced from the ARIN address blocks: 119621 ARIN Region origin ASes present in the Internet Routing Table: 18513 ARIN Prefixes per ASN: 12.73 ARIN Region origin ASes announcing only one prefix: 6771 ARIN Region transit ASes present in the Internet Routing Table: 1890 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3274 Number of ARIN addresses announced to Internet: 1080400384 Equivalent to 64 /8s, 101 /16s and 154 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 231855 Total RIPE prefixes after maximum aggregation: 107286 RIPE Deaggregation factor: 2.16 Prefixes being announced from the RIPE address blocks: 228420 Unique aggregates announced from the RIPE address blocks: 134280 RIPE Region origin ASes present in the Internet Routing Table: 27153 RIPE Prefixes per ASN: 8.41 RIPE Region origin ASes announcing only one prefix: 11756 RIPE Region transit ASes present in the Internet Routing Table: 3855 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 9226 Number of RIPE addresses announced to Internet: 709126272 Equivalent to 42 /8s, 68 /16s and 104 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-213403 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 106682 Total LACNIC prefixes after maximum aggregation: 24887 LACNIC Deaggregation factor: 4.29 Prefixes being announced from the LACNIC address blocks: 107802 Unique aggregates announced from the LACNIC address blocks: 46512 LACNIC Region origin ASes present in the Internet Routing Table: 9937 LACNIC Prefixes per ASN: 10.85 LACNIC Region origin ASes announcing only one prefix: 2479 LACNIC Region transit ASes present in the Internet Routing Table: 1854 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 46 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 7516 Number of LACNIC addresses announced to Internet: 174407424 Equivalent to 10 /8s, 101 /16s and 63 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 22910 Total AfriNIC prefixes after maximum aggregation: 4698 AfriNIC Deaggregation factor: 4.88 Prefixes being announced from the AfriNIC address blocks: 34614 Unique aggregates announced from the AfriNIC address blocks: 10175 AfriNIC Region origin ASes present in the Internet Routing Table: 1399 AfriNIC Prefixes per ASN: 24.74 AfriNIC Region origin ASes announcing only one prefix: 489 AfriNIC Region transit ASes present in the Internet Routing Table: 274 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 30 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 691 Number of AfriNIC addresses announced to Internet: 109431808 Equivalent to 6 /8s, 133 /16s and 204 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 5516 711 647 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4743 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3447 1330 22 VIETEL-AS-AP Viettel Group, VN 45899 3151 1806 101 VNPT-AS-VN VNPT Corp, VN 7713 2712 829 511 TELKOMNET-AS-AP PT Telekomunikasi Indon 9808 2579 9043 61 CMNET-GD Guangdong Mobile Communication 4766 2280 11101 554 KIXS-AS-KR Korea Telecom, KR 9498 2266 433 219 BBIL-AP BHARTI Airtel Ltd., IN 4755 2133 441 193 TATACOMM-AS TATA Communications formerl 9394 2040 4914 20 CTTNET China TieTong Telecommunications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11492 4452 299 617 CABLEONE, US 7155 4036 264 27 VIASAT-SP-BACKBONE, US 16509 3950 8143 1793 AMAZON-02, US 22773 3561 2968 151 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3358 1324 90 SHAW, CA 16625 3097 1617 2211 AKAMAI-AS, US 209 2434 5076 535 CENTURYLINK-US-LEGACY-QWEST, US 30036 2412 366 189 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2304 2981 1621 FRONTIER-FRTR, US 26484 2184 137 202 IKGUL-26484, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5803 1658 138 UNI2-AS, ES 31334 4923 484 13 KABELDEUTSCHLAND-AS, DE 39891 3458 195 19 ALJAWWALSTC-AS, SA 8551 3181 379 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3055 450 2070 AKAMAI-ASN1, EU 12389 2546 2254 756 ROSTELECOM-AS, RU 9009 2223 235 1215 M247, GB 34984 2132 353 564 TELLCOM-AS, TR 13188 1609 100 35 TRIOLAN, UA 61317 1305 142 566 ASDETUK http://www.heficed.com, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6683 3322 598 Uninet S.A. de C.V., MX 10620 3351 529 507 Telmex Colombia S.A., CO 11830 2665 369 63 Instituto Costarricense de Electricidad 6503 1697 327 388 Axtel, S.A.B. de C.V., MX 7303 1517 988 251 Telecom Argentina S.A., AR 13999 1431 514 334 Mega Cable, S.A. de C.V., MX 28573 1371 2243 206 CLARO S.A., BR 3816 1107 570 149 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1107 379 39 Telefonica del Peru S.A.A., PE 11172 952 111 73 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1488 393 22 LINKdotNET-AS, EG 24835 1120 470 24 RAYA-AS, EG 36992 1086 1539 76 ETISALAT-MISR, EG 36903 900 472 91 MT-MPLS, MA 29571 604 68 11 ORANGE-COTE-IVOIRE, CI 6713 550 1863 34 IAM-AS, MA 37342 481 32 1 MOVITEL, MZ 36935 417 522 44 Vodafone-, EG 23889 366 231 15 MauritiusTelecom, MU 15399 357 45 12 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6683 3322 598 Uninet S.A. de C.V., MX 12479 5803 1658 138 UNI2-AS, ES 7545 5516 711 647 TPG-INTERNET-AP TPG Telecom Limited, AU 31334 4923 484 13 KABELDEUTSCHLAND-AS, DE 4538 4743 4192 73 ERX-CERNET-BKB China Education and Rese 11492 4452 299 617 CABLEONE, US 7155 4036 264 27 VIASAT-SP-BACKBONE, US 16509 3950 8143 1793 AMAZON-02, US 22773 3561 2968 151 ASN-CXA-ALL-CCI-22773-RDC, US 39891 3458 195 19 ALJAWWALSTC-AS, SA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 5803 5665 UNI2-AS, ES 31334 4923 4910 KABELDEUTSCHLAND-AS, DE 7545 5516 4869 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4743 4670 ERX-CERNET-BKB China Education and Research Net 7155 4036 4009 VIASAT-SP-BACKBONE, US 11492 4452 3835 CABLEONE, US 39891 3458 3439 ALJAWWALSTC-AS, SA 7552 3447 3425 VIETEL-AS-AP Viettel Group, VN 22773 3561 3410 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3358 3268 SHAW, CA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 22357 UNALLOCATED 8.7.108.0/24 3356 LEVEL3, US 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 62485 UNALLOCATED 8.23.229.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US 26584 UNALLOCATED 8.42.62.0/23 209 CENTURYLINK-US-LEGACY-QWEST, 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 46766 UNALLOCATED 8.44.208.0/24 3356 LEVEL3, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.148.160.0/24 Origin: 29802 HVC-AS, US Transit: 6939 HURRICANE, US 27.100.7.0/24 Origin: 56096 UNASSIGNED Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 27.126.156.0/22 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 27.126.156.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 27.126.158.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:9 /9:11 /10:38 /11:100 /12:287 /13:579 /14:1172 /15:1914 /16:13349 /17:8237 /18:13949 /19:25851 /20:41190 /21:48401 /22:100881 /23:83476 /24:474286 /25:1285 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4817 5803 UNI2-AS, ES 31334 4769 4923 KABELDEUTSCHLAND-AS, DE 11492 3532 4452 CABLEONE, US 6327 3148 3358 SHAW, CA 7155 3128 4036 VIASAT-SP-BACKBONE, US 22773 2773 3561 ASN-CXA-ALL-CCI-22773-RDC, US 8551 2639 3181 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 39891 2609 3458 ALJAWWALSTC-AS, SA 8151 2373 6683 Uninet S.A. de C.V., MX 30036 2154 2412 MEDIACOM-ENTERPRISE-BUSINESS, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1760 2:1195 3:30 4:19 5:3565 6:52 8:1421 9:1 11:1 12:1778 13:515 14:2310 15:72 16:8 17:293 18:81 20:106 23:3690 24:2309 25:3 27:2524 31:3075 32:127 34:3 35:42 36:951 37:3376 38:2020 39:422 40:129 41:3589 42:901 43:2135 44:206 45:14452 46:3685 47:289 49:1455 50:1469 51:93 52:1053 54:231 55:644 56:6 57:51 58:1848 59:1169 60:743 61:2299 62:2086 63:1989 64:5196 65:2328 66:5034 67:2922 68:1185 69:3963 70:1408 71:680 72:2879 74:2580 75:1447 76:672 77:2926 78:1645 79:2368 80:1953 81:1638 82:1315 83:1307 84:1234 85:2616 86:541 87:1737 88:1129 89:2753 90:390 91:7932 92:1515 93:2518 94:2726 95:3904 96:1235 97:333 98:923 99:978 100:86 101:1008 102:967 103:23839 104:3446 105:397 106:880 107:1999 108:711 109:3671 110:1836 111:2056 112:1605 113:1357 114:1524 115:1839 116:1802 117:2104 118:2135 119:1704 120:921 121:1044 122:2438 123:2051 124:1565 125:2020 128:1362 129:1190 130:649 131:1865 132:754 133:302 134:1325 135:286 136:608 137:851 138:2171 139:998 140:679 141:992 142:925 143:1225 144:1013 145:307 146:1499 147:1016 148:2109 149:1190 150:871 151:1335 152:1497 153:395 154:4672 155:1059 156:3109 157:1122 158:845 159:1974 160:1897 161:1055 162:3090 163:820 164:1475 165:1292 166:558 167:1637 168:3547 169:524 170:4227 171:773 172:1941 173:2572 174:985 175:1047 176:2577 177:4206 178:3040 179:1478 180:2286 181:2462 182:3086 183:1288 184:2424 185:16487 186:3743 187:2816 188:4100 189:2339 190:8731 191:1319 192:10361 193:7543 194:6229 195:4390 196:3254 197:1997 198:6102 199:5907 200:7238 201:5243 202:10505 203:10291 204:4578 205:3107 206:3219 207:3274 208:4063 209:4454 210:4002 211:2030 212:3376 213:3234 214:1194 215:62 216:6095 217:2429 218:856 219:614 220:2014 221:931 222:998 223:1493 End of report

1 0

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 12 Jun '20

12 Jun '20

On Fri, 12 Jun 2020 at 18:52, David Sinn <dsinn(a)dsinn.com> wrote: > Unless you want ECMP then it VERY much matters. But I guess since we are only talking about theoretical instead of building an actual practical network, it doesn't matter. Well blatantly we are, because in the real world most of the value of MPLS tunnels is not available as IP tunnels. Again technically entirely possible to replace MPLS tunnels with IP tunnels, just question how much overhead you have in transporting the tunnel key and how wide they are. Should we design a rational cost-efficient solution, we should choose the lowest overhead and narrowest working keys. -- ++ytti

2 2

Re: [c-nsp] LDPv6 Census Check
by Christian Meutes 12 Jun '20

12 Jun '20

Salve, On Thu, Jun 11, 2020 at 8:08 PM David Sinn <dsinn(a)dsinn.com> wrote: Rewrites on MPLS is horrible from a memory perspective as maintaining the > state and label transition to explore all possible discrete paths across > the overall end-to-end path you are trying to take is hugely in-efficient. > Applying circuit switching to a packet network was bad from the start. SR > doesn't resolve that, as you are stuck with a global label problem and the > associated lack of being able to engineer your paths, or a label stack > problem on ingress that means you need a massive ASIC's and memories there. > I don't think rewrites are horrible, but just very flexible and this *can* come up with a certain price. Irt to your memory argument that path engineering takes in vanilla TE a lot of forwarding slots we should remind us that this is not a design principle of MPLS. Discrete paths could also be signalled in MPLS with shared link-labels so that you will end up with the same big instructional headend packet as in SR. There are even implementations offering this. IP at least gives you rewrite sharing, so in a lite-core you have way > better trade-off on resources, especially in a heavily ECMP'ed network. > Such as one build of massive number of open small boxes vs. a small number > of huge opaque ones. Pick your poison but saying one is inheriantly better > then another in all cases is just plane false. > If I understand this argument correctly then it shouldn't be one because of "rewrite sharing" being irrelevant for the addressability of single nodes in a BGP network. Why a header lookup depth of 4B per label in engineered and non-engineered paths should be a bad requisite for h/w designers of modern networks is beyond me. In most MPLS networks (unengineered L3VPN) you need to read less of headers than in a eg. VXLAN fabric to make ECMP work (24B vs. 20B).

1 0

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 12 Jun '20

12 Jun '20

On Fri, 12 Jun 2020 at 18:42, David Sinn <dsinn(a)dsinn.com> wrote: > But why do you need full table lookup in the middle of the network? Why place that class of gear where it's not needed? Some people do collapsed core. But this is getting bit theoretical, because we definitely could do this on IP, we could do some lookups on on-chip and some off-chip to do both, should market want it. > The label stack question is about the comparisons between the two extremes of SR that you can be in. You either label your packet just for it's ultimate destination or you apply the stack of the points you want to pass through. Quite, but transit won't inspect the stack, it doesn't have to care about it, so it can be very deep. > In the former case you are, at the forwarding plane, equal to what you see with traditional MPLS today, with every node along the path needing to know how to reach the end-point. Yes, you have lowered label space from traditional MPLS, but that can be done with site-cast labels already. And, while the nodes don't have to actually swap labels, when you look at commodity implementations (across the last three generations since you want to do this with what is deployed, not wholesale replace the network) a null swap still ends up eating a unique egress next-hop entry. So from a hardware perspective, you haven't improved anything. Your ECMP group count is high. I don't disagree. What I'm trying to say, however you tunnel, you have the same issues. If you need to tunnel, then MPLS is better tunnel than IP. Ultimately both can be made LEM on-chip should market want it, so difference left is what is the overhead of the tunnel, and MPLS wins here handsdown. This is objectively true, now what practical market reality is, that may be different, because market doesn't optimise for best solution. > So, yes, MPLS works fine if you want to buy big iron boxes. But that come at a cost. So the point about MPLS is always better is not accurate. Engineering is about trade-offs and there are trade-offs to be made when you optimize in a different direction and that points away from MPLS and back to IPIP Always if you need tunnel. Because the fundamental question is how much overhead we have, and what is our key width. In both IP tunnel and MPLS tunnel cases we will assume LEM lookup, to keep the lookup cheap. -- ++ytti

1 0

IPv4 Broker / Service -
by edwin.mallette＠gmail.com 12 Jun '20

12 Jun '20

Hi Nanog, I have need of a reputable IPv4 broker or service - personal experience with said broker would be preferred. These would be for small blocks - /23, 24s - in the US, so ARIN. I know, I know, IPv6 for life and all that and I agree, but . you know, the business. I'm happy to take responses off-list, but I would really appreciate any recommendations. Thanks! Ed

7 6

Re: [c-nsp] LDPv6 Census Check
by Saku Ytti 12 Jun '20

12 Jun '20

On Fri, 12 Jun 2020 at 18:16, David Sinn <dsinn(a)dsinn.com> wrote: > I'm not sure what implementation you are saying doesn't exist. The Broadcom XGS line is all on-die. The two largest cloud providers are using them in their transport network (to the best of my understanding). So I'm not sure if your saying that no one is using small boxes like I'm describing or what. And it doesn't have to be MPLS over IP. That is one option, but IPIP is another. I'm saying implementation which has off-chip and supports putting some on-chip. So that you could have full table lookup for edge packets and and fast exact lookup for others. Of course we do have platforms which do have large LEM tables off-chip. > Again, feel free to look at only one small aspect and say that it is completely better in all cases. MPLS is not better in wide ECMP cases, full stop. SR doesn't help that when you actually look at the problems at massive scale as I have done. You continually are on the trade-off spectrum of irrationally deep label stacks or enumeration of all of the possible paths through the network and burn all of your next-hop re-writes. At least if you want high-radiux, single chip systems. So this is not sentimentally around a protocol, it's the practical reality when you look at the problems at scale using commodity components. So if you want to optimize for costs and power (which is operational costs), MPLS is not where it is at. I'm not sure why this deep label stack keeps popping, if we need multiple levels of tunneling, we need it in IP too, and it's almost more expensive in IP. Cases I can think of in SR, you'll only loop top label or two, even if you might have 10 labels. For every apples to apples cases MPLS tunnels are superior to IP tunnels. If you want cheap very small FIB backbone, then all traffic will need to be IP tunneled to egress, and you get all the MPLS problems, and you get more overhead and larger keys (larger keys is not a big deal). Now if discussion is do we need tunnelling at all, the discussion is very different. -- ++ytti

1 0

Re: [c-nsp] LDPv6 Census Check
by Mark Tinka 11 Jun '20

11 Jun '20

On 11/Jun/20 17:32, David Sinn wrote: > Respectfully, that is deployment dependent. In a traditional SP topology that focuses on large do everything boxes, where the topology is fairly point-to-point and you only have a small handful of nodes at a PoP, labels can be fast, cheap and easy. Given the lack of ECMP/WECMP, they remain fairly efficient within the hardware. > > However if you move away from large multi-chip systems, which hide internal links which can only be debugged and monitored if you know the the obscure, often different ways in which they are partially exposed to the operator, and to a system of fixed form-factor, single chip systems, labels fall apart at scale with high ECMP. I'm curious about this statement - have you hit practical ECMP issues with label switching at scale? We have ECMP'ed label switch paths with multiple paths for a single FEC all over the place, and those work fine both on Cisco and Junos (of all sizes), both for IPv4 and IPv6 FEC's. Have done for years. Unless I misunderstand your concern. Mark.

1 0

RE: [c-nsp] LDPv6 Census Check
by adamv0025＠netconsultings.com 11 Jun '20

11 Jun '20

> From: David Sinn > Sent: Thursday, June 11, 2020 4:32 PM > > However if you move away from large multi-chip systems, > to a system of fixed form-factor, single chip systems, labels fall > apart at scale with high ECMP. Needing to enumerate every possible path > within the network or having to have a super-deep label stack removes all of > the perceived benefits of cheap and simple. > Looks like the deployments you describe are large DC Clos/Benes fabric, then the potentially deep label imposition would be done by the VMs right? On transit nodes the 64x ECMP or super-deep labels is no problem for NPU/lookup process as it's always just top label lookup and resolving to a single egress interface. adam

1 0