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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 29 Oct 2019 13:50:13 +0000

We have incorporated all WG comments/suggestions ...
from the WG adoption call discussions:
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=PB8YtGMBvVLeAu6dot072VaDJNc 
and also from a related thread (feedback requested):
https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=rqY4ipWnrz2TdYWkKIeZCby9HlY 

The authors feel that the draft is now ready for WGLC.
Do the Chairs and WG think that it is ready?  
Chairs: Please advise if you think it needs to be presented (in Singapore). 

Thank you.
Sriram
   
--------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : Deprecation of AS_SET and AS_CONFED_SET in BGP
        Authors         : Warren Kumari
                          Kotikalapudi Sriram
                          Lilia Hannachi
	Filename        : draft-ietf-idr-deprecate-as-set-confed-set-01.txt
	Pages           : 7
	Date            : 2019-10-29

Abstract:
   BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
   AS_CONFED_SET in the Border Gateway Protocol.  This document advances
   this recommendation to a standards requirement in BGP; it proscribes
   the use of the AS_SET and AS_CONFED_SET types of path segments in the
   AS_PATH.  This is done to simplify the design and implementation of
   BGP and to make the semantics of the originator of a route clearer.
   This will also simplify the design, implementation, and deployment of
   various BGP security mechanisms.  This document (if approved) updates
   RFC 4271 and RFC 5065 by eliminating AS_SET and AS_CONFED_SET types,
   and obsoletes RFC 6472.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/ 

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-deprecate-as-set-confed-set-01 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-01  

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-deprecate-as-set-confed-set-01

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Oct 2019 14:10:34 +0000

> Do the Chairs and WG think that it is ready?

looks good.  Nothing is standing out as either missing or superfluous.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Oct 2019 17:38:45 -0400

Sriram,

Comments somewhat out of order from the diff:

Section 4:
While well intentioned, this is clumsy in terms of a mandate on how BGP-next
is authored.  BGP is all about incremental deployment and thus just like we
can't simply "pretend this doesn't exist" for current code, the same will be
true for future code.

Suggested text:

This document deprecates the AS_SET (type 1)  AS_PATH segment type from RFC
4271.  BGP Speakers conforming to this document SHOULD NOT* send BGP Update
messages containing this AS_SET type.  Upon receipt, BGP Speakers conforming
to this document should use the "Treat-as-withdraw" error handling behavior
as per RFC 7606.

(and similar text for confed-set)

* The case here is SHOULD NOT rather than MUST NOT because you're providing
the option for a knob to let the old behavior work.

Section 1:
"The aggregation as described above could also create traffic engineering
issues, because the precise path information for the component prefixes are
not preserved."

This is rather the whole point of the "atomic aggregate" feature of BGP-4
specs.  But it's a vestigial feature and we shouldn't fix it.  The
underlying point is when you KNOW that it's an aggregate, and there's
components you're not talking about, don't de-aggregate because you may do
Bad Things to the routes in question.  The usual presumption is that the
more specific routes are percolating far enough that this is hopefully NOT a
problem... and good luck with that, because they might get filtered.  (This
is one of the reasons the signaling is vestigial.)

The effective point here is that if you ARE doing any sort of filtering of
more specifics as part of trying to be conformant with this document, we're
hitting exactly that set of considerations.  Ideally, this wouldn't be
important.  Practically, we have outages every few months caused because
people deploy tools that deaggregate routes for traffic optimization
purposes, and those de-aggregated routes get leaked.

The implications:
- You have to provide an entire revised section 9.1.4 for RFC 4271.

Misc. open issue:
- What do you do about "atomic aggregate?"
- You're also deprecating appendix  F.6 of RFC 4271
- You're modifying recommendations for appendix F.4 of RFC 4271.

Section 3:

"Network operators" is likely the wrong voicing here, even though the advice
is to network operators.  (BGP Speakers announce routes.)

The related changed text likely needs something similar to my recommendation
for section 4 above.

:    Route aggregation that was previously performed by proxy aggregation
:    without the use of AS_SETs is still possible under some conditions.
:    When doing this, operators MUST form the aggregate at the border in
:    the outbound BGP policy and omit any prefixes from the AS that the
:    aggregate is being advertised to.  As with any change, the operator
:    should understand the full implications of the change.

This text is very imprecise.

The following things happen in proxy aggregation:
- The aggregated routes are not sent to the networks that provided
  contributors.  This is a side effect of the as-set being formed.
  + As a result, the contributing networks are expected to need the more
    specific routes that are the aggregate contributors.

How do you do this?

-- Jeff

On Tue, Oct 29, 2019 at 01:50:13PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 29 Oct 2019 22:45:56 -0500

Hello,

  As a comment, we did a small research and these are our findings (hope
the table shows ok):

*
*

*

IPv4

IPv6

  RIPE ASs doing AS_SET

52

9

  RIPE Prefixes behind AS_SET 

111

9

  ARIN ASs*doing AS_SET*

50

5

  ARIN *Prefixes behind AS_SET*

127

10

  APNIC ASs *doing AS_SET*

11

4

  APNIC *Prefixes behind AS_SET*

46

8

  AFRINIC ASs*doing AS_SET*

1

0

  AFRINIC *Prefixes behind AS_SET*

7

0

  LACNIC ASs*doing AS_SET*

14

2

  LACNIC *Prefixes behind AS_SET*

96

7

*
**

Thanks,

Alejandro,

---

From: Sander Steffann <[email-masked]>
Date: Wed, 30 Oct 2019 13:19:07 +0300

Hi Alejandro,

> As a comment, we did a small research and these are our findings (hope the table shows ok):

Those numbers are very manageable. If we gather a couple of volunteers we could personally contact each AS.

Cheers,
Sander