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

Alejandro Acosta <> Sun, 10 November 2019 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC66F1200FD for <>; Sun, 10 Nov 2019 15:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YknVuU3HZYCb for <>; Sun, 10 Nov 2019 15:03:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C62B21200E0 for <>; Sun, 10 Nov 2019 15:03:39 -0800 (PST)
Received: by with SMTP id p68so2747663vkd.0 for <>; Sun, 10 Nov 2019 15:03:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ([]) by with ESMTPSA id b186sm3682465vkh.41.2019. (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)" <>, Sander Steffann <>
Cc: IDR <>, Warren Kumari <>, Jeffrey Haas <>
References: <>
From: Alejandro Acosta <>
Message-ID: <>
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: <>
Content-Type: multipart/mixed; boundary="------------4C7C4EFCF77A2ED9D98A580B"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:
> The link to our detailed data is here:

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.


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