Subject: [Idr] WG adoption for draft-kumari-deprecate-as-set-confed-set - 8/16 to 8/30/2019

From: "Susan Hares" <[email-masked]>
Date: Fri, 16 Aug 2019 10:34:10 -0400

Greetings: 

This begins a 2 week WG adoption call for
draft-kumari-deprecate-as-set-confed-set

from 8/16 to 8/30/2019. 

This draft seeks to remove AS_SET and AS_CONFED_SET from RFC4271.   

Draft is at: 

https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14

To quote the draft: 

   "BCP 172 <https://tools.ietf.org/html/bcp172>  [RFC6472
<https://tools.ietf.org/html/rfc6472> ] makes a recommendation for not using
AS_SET and
   AS_CONFED_SET in Border Gateway Protocol (BGP).  This document
   advances the recommendation to a standards requirement in BGP"

        [aka RFC4271].

   "From analysis of past Internet routing data, it is apparent that
   aggregation that involves AS_SETs is very seldom used in practice on
   the public Internet [Analysis
<https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14#ref
-Analysis> ] and when it is used, it is often used
   incorrectly -- reserved AS numbers ([RFC1930
<https://tools.ietf.org/html/rfc1930> ]) and/or only a single
   AS in the AS_SET are by far the most common cases."

In your comments on adoption, consider: 
 
1)  Should the IDR WG remove AS_SET and AS_CONFED_SET from BGP? 
2)  Is this document a reasonable document to document that removal? 
3)  Are there technical flaws in the arguments for removal? 
4)  Are there issues with the text? 
 
Cheerily, Susan Hares

---

From: Job Snijders <[email-masked]>
Date: Fri, 16 Aug 2019 16:37:47 +0200

Dear Susan,

I would like to see the WG adopt this draft.

Kind regards,

Job

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jared Mauch <[email-masked]>
Date: Fri, 16 Aug 2019 10:52:46 -0400

I would also like to support adoption of this.

We should also (in parallel) reach out to some of the networks still using as_sets that are visible in the global BGP table.

- Jared

> On Aug 16, 2019, at 10:37 AM, Job Snijders <[email-masked]> wrote:
> 
> Dear Susan,
>

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 16 Aug 2019 18:01:08 +0300

I support adoption of this document.

пт, 16 авг. 2019 г. в 17:53, Jared Mauch <[email-masked]>:

> We should also (in parallel) reach out to some of the networks still using
> as_sets that are visible in the global BGP table.
>
> - Jared
>
> >> <
> https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14#ref

-- 
Best regards,
Alexander Azimov

---

From: john heasley <[email-masked]>
Date: Fri, 16 Aug 2019 15:48:27 +0000

> 1)  Should the IDR WG remove AS_SET and AS_CONFED_SET from BGP? 

yes

> 2)  Is this document a reasonable document to document that removal? 

yes

> 3)  Are there technical flaws in the arguments for removal? 

no

> 4)  Are there issues with the text? 

imo, wg discussion of this should address how the complete removal will proceed,
such that implementations can drop support entirely, which this draft does not
address.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 16 Aug 2019 20:02:23 +0400

> This draft seeks to remove AS_SET and AS_CONFED_SET from RFC4271.

I'd like to see this adopted.

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 16 Aug 2019 10:13:36 -0700

> imo, wg discussion of this should address how the complete removal
> will proceed, such that implementations can drop support entirely,
> which this draft does not address.

could you explain a bit more?  e.g. do you mean how a conforming
speaker, i.e. one which does not support sets, should act when
receiving a set?  or might you mean an ops plan for moving to no
speakers announcing sets?

randy

---

From: john heasley <[email-masked]>
Date: Fri, 16 Aug 2019 17:22:08 +0000

Fri, Aug 16, 2019 at 10:13:36AM -0700, Randy Bush:
> receiving a set?

yes; wouldnt one respond with an unknown/malformed attribute notification,
unless some alternative were prescribed.

---

From: Job Snijders <[email-masked]>
Date: Fri, 16 Aug 2019 19:24:30 +0200

On Fri, Aug 16, 2019 at 05:22:08PM +0000, john heasley wrote:
> yes; wouldnt one respond with an unknown/malformed attribute
> notification, unless some alternative were prescribed.

'treat as withdraw' would seem more appropriate

Kind regards,

Job

---

From: Brendon H <[email-masked]>
Date: Wed, 21 Aug 2019 00:20:53 +0000

I support the adoption of this document.

- Brendon

On Aug 17, 2019, at 00:34, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Greetings:

This begins a 2 week WG adoption call for draft-kumari-deprecate-as-set-confed-set
from 8/16 to 8/30/2019.

To quote the draft:

   “BCP 172<https://tools.ietf.org/html/bcp172> [RFC6472<https://tools.ietf.org/html/rfc6472>] makes a recommendation for not using AS_SET and

   advances the recommendation to a standards requirement in BGP”
        [aka RFC4271].

   “From analysis of past Internet routing data, it is apparent that

   the public Internet [Analysis<https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14#ref-Analysis>] and when it is used, it is often used

   incorrectly -- reserved AS numbers ([RFC1930<https://tools.ietf.org/html/rfc1930>]) and/or only a single

   AS in the AS_SET are by far the most common cases.”

Cheerily, Susan Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Aug 2019 10:47:16 -0400

> 'treat as withdraw' would seem more appropriate

That's one way to do this.  But as stands, simply saying "deprecated/don't
do this" and urging "don't support" in future implementations will get you
errors at some point if we're not careful.

Right now, we still have BGP speakers on the Internet that are speaking
largely raw RFC 1771.  It largely still works since a lot of the nits that
got addressed between 1771 and 4271 (and related modification RFCs like
confederations) have internal impact to a given AS and don't bleed into the
wider Internet.

It's necessary to presume we SHALL see SET elements in AS_PATHs for the
foreseeable future.  Deprecating needs to be explicit what to do when you
see them.  Treat as withdraw is a fine way to do it.  Encouraging existing
implementations to make sure their policy algebras are sophisticated enough
to match on set elements so you can do discard is another.  (Multiple
implementations are policy ignorant with regard to set matching.)

Saying "I don't recognize these" is not a viable incremental implementation
strategy.

-- Jeff

---

From: Keyur Patel <[email-masked]>
Date: Fri, 23 Aug 2019 15:55:59 +0000

Support. More comments inlined #Keyur

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Friday, August 16, 2019 at 7:34 AM
To: "[email-masked]" <[email-masked]>
Subject: [Idr] WG adoption for draft-kumari-deprecate-as-set-confed-set - 8/16 to 8/30/2019
Resent-From: <[email-masked]>

Greetings:

To quote the draft:

#Keyur: Yes.

#Keyur: Yes.

#Keyur: No.

Regards,

Keyur

Cheerily, Susan Hares

---

From: Melchior Aelmans <[email-masked]>
Date: Sat, 24 Aug 2019 15:28:12 +0200

I support adoption of this draft.

Cheers,
Melchior

On Fri, Aug 16, 2019 at 4:34 PM Susan Hares <[email-masked]> wrote:

>    “BCP 172 <https://tools.ietf.org/html/bcp172> [RFC6472 <https://tools.ietf.org/html/rfc6472>] makes a recommendation for not using AS_SET and
>
>    the public Internet [Analysis <https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14#ref-Analysis>] and when it is used, it is often used
>
>    incorrectly -- reserved AS numbers ([RFC1930 <https://tools.ietf.org/html/rfc1930>]) and/or only a single
>