Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-02.txt

Alejandro Acosta <alejandroacostaalamo@gmail.com> Sun, 10 November 2019 23:03 UTC

Return-Path: <alejandroacostaalamo@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC66F1200FD for <idr@ietfa.amsl.com>; Sun, 10 Nov 2019 15:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YknVuU3HZYCb for <idr@ietfa.amsl.com>; Sun, 10 Nov 2019 15:03:40 -0800 (PST)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62B21200E0 for <idr@ietf.org>; Sun, 10 Nov 2019 15:03:39 -0800 (PST)
Received: by mail-vk1-xa2f.google.com with SMTP id p68so2747663vkd.0 for <idr@ietf.org>; Sun, 10 Nov 2019 15:03:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ZARIrqQlSdIllwL3VniOv1foH5OEcv7clMpwty1ngMw=; b=qy+F3f8UWvOOh8j47z1RHfkJmtc6xp51WN9ICaS9HoKGxn0XukqUSPKHy1SWMtR1nK MK4EjcEo16CByrEmpnnlpJdsqxhdCRsolEqAm22Bq7yA0px+iBZlJYbWkvK8Ps/zj9mo mTQeBPqkAQclQHIOu5pZwGa1j2WYGyP44A/IU+zC8jL0UvTncfW7KCAA8znI5UhI+1dH EZNkGGHEk991MIkpd3SqXpoUAkKh/YIZQQB5nH0nqL+k/j8IOEvjufFi5p0kgtzSh/v2 y+IrRxjqilK5JqsVdxBQuIJL45LNP3pBtcIRWLX2OLRaQ3yHcplMmKZwyTJwwXO1B2gA 8rYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZARIrqQlSdIllwL3VniOv1foH5OEcv7clMpwty1ngMw=; b=Jmuyv+GbT5nIvRsOjUpPWhhaB0wZ1lL+f6JfmI+B0F0YAdcyhkPrggIrf2hlPeywDz pPxuoDfaX5aFh/i0+KIMKK1No/Wa4Wjc0OkX5+K2pulo2udIP6C5vb+CCViRwus/7tCJ VafbZevhjqyNZVhsbCKAhYSOjkFtcJbh6sKNOENMuxpiR2LN36U7aHGikw8UbJBrc9jh frzuiZFRJambNmyMxX7Jo+Ei7YHrWoB0YsObTPS3OOlTXIitb/FvTs4+2VZgcPPVTUXU oPHwsR19ltjAAGKzLl0T3mWqJ/WB8+Wj0dB5Kw7lHDDLI+4OVeVPbTzIo33oTnP32hwF jS+w==
X-Gm-Message-State: APjAAAV5tG5o6UQ3phEZAMK29KSWP171vnts5zOfCNSQzFaJq7C5Vk7Y faNu0wtT7rv7kShx5tmY3JE=
X-Google-Smtp-Source: APXvYqzwxKcbAyfXxgo1VOArqXA9tHesWA5SHYTQxLKftxThstnIoJmHl+xA/MdFjBv+kflN23eoJA==
X-Received: by 2002:a1f:a0c3:: with SMTP id j186mr16554855vke.86.1573427018290; Sun, 10 Nov 2019 15:03:38 -0800 (PST)
Received: from Windows10AnyBody.local ([186.188.62.147]) by smtp.gmail.com with ESMTPSA id b186sm3682465vkh.41.2019.11.10.15.03.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Nov 2019 15:03:37 -0800 (PST)
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Sander Steffann <sander@steffann.nl>
Cc: IDR <idr@ietf.org>, Warren Kumari <warren@kumari.net>, Jeffrey Haas <jhaas@pfrc.org>
References: <BN6PR09MB1331565B584CB3175FD97CCF84750@BN6PR09MB1331.namprd09.prod.outlook.com>
From: Alejandro Acosta <alejandroacostaalamo@gmail.com>
Message-ID: <4f6baac8-1466-e931-c123-5c29c2ec9ea1@gmail.com>
Date: Sun, 10 Nov 2019 19:03:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <BN6PR09MB1331565B584CB3175FD97CCF84750@BN6PR09MB1331.namprd09.prod.outlook.com>
Content-Type: multipart/mixed; boundary="------------4C7C4EFCF77A2ED9D98A580B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5O0E1IGekH0eb9RK02Oyw-Z3Kqs>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Nov 2019 23:03:42 -0000

On 11/10/19 1:01 AM, Sriram, Kotikalapudi (Fed) wrote:
> Alejandro,
> Sander,
>
> [Alejandro]
>>> As a comment, we did a small research and 
>>> these are our findings (hope the table shows ok):
>>> .....snip.....
> [Sander]
>> Those numbers are very manageable. If we gather a couple 
>> of volunteers we could personally contact each AS.
> Thanks for the measurement numbers and your comments.
>
> We had earlier reported similar numbers (totals across all RIR regions)
> with many more details:
> https://mailarchive.ietf.org/arch/msg/idr/tE8o0HZeLLUEulMkszVBlxqILeU
>
> The link to our detailed data is here:
> https://www.nist.gov/sites/default/files/documents/2019/10/23/detailed-as_set-analysis.txt 


Thanks for this, happy to see our results are similar.

We also published something, a little bit longer that what I sent to the
list few days ago.

https://labs.lacnic.net/Una_mirada_al_uso_de_BGP_AS_SET_en_la_DFZ/


Regards,

P.S. Sorry, in Spanish :-{}



>
> Our numbers and yours are consistent, except that we also showed that
> globally there only 21 unique routes (prefixes) with AS_SET that seem meaningful!
> The rest of the routes with AS_SET (about 450) seem meaningless; details at the link above.
>
> Even the 21 will likely do fine if they did not use AS_SET. They can deaggregate and 
> provide the full AS path or they can aggregate and put in AGGREGATOR and
> ATOMIC_AGGREGATE.  If you look at this part of our data:
>
> *** When there is AGGREGATOR without AS_SET ***
> 	# Unique prefixes (with or without AS_SET) : 826535
> 	# Unique prefixes without AS_SET but with AGGREGATOR: 75698
> 	% Unique prefixes without AS_SET but with AGGREGATOR: 9.158%
> 	# Unique prefixes with ATOMIC_AGGREGATE: 47258 
> 	# Unique prefixes with AGGREGATOR and ATOMIC_AGGREGATE: 44971
> 	# Unique prefixes with AGGREGATOR and without ATOMIC_AGGREGATE: 31769
>            (the last three lines added newly)
>
> it seems clear that a very large number of routes/ASes aggregate without AS_SET
> and very likely many of them face similar scenario as those with AS_SET
> and yet they do not seem to encounter problems (despite not using AS_SET).
> I think the main reason is that even if the aggregate is received
> via another upstream provider and gets installed in as AS that contributed to the aggregate,
> the AS really never uses that aggregate to route data because it has received 
> the other components (more specifics) of the aggregate from the provider who aggregated.
> As Jeff has pointed out, if a more specific gets cut off (due to outage), then looping
> in the data plane can occur. 
> This would typically last only for a short period until recovery happens.
> Now a days, the recovery times are fast. And possibly looping of data for a brief period
> is not much worse than the data not reaching its destination for that period.  
>
> Sriram    
>   
>
>
>
>
>
>
>