Subject: [Idr] Fwd: I-D Action: draft-chen-idr-asloop-aggr-00.txt

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Oct 2021 20:43:19 +0200

Hi Enke & Stefan,

I have few observations on this draft:

You say:

   Although BCP 172 [RFC6472] makes a recommendation for not using the
   AS_SET path segment in BGP, the AS_SET path segment may remain in use
   for a long time.

Actually RFC6472 goes much further - it discourages use of aggregation from
atomic routes.

Furthermore, isn't the problem you are actually facing very easy to
mitigate by use of different (even private) ASNs in customer's sites ?

The draft is silent on the use case for such essentially significant
and unconditional protocol change.

I hope we are talking about multiple sites - not a single site trying to
learn the aggregate containing its own range.

To me in the light of RFC6472 and all SIDR discussions around it this draft
is trying to move in quite the opposite direction.

Cheers,
Robert

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Oct 18, 2021 at 8:15 PM
Subject: I-D Action: draft-chen-idr-asloop-aggr-00.txt
To: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Relax the AS Loop Detection for Aggregates in BGP
        Authors         : Enke Chen
                          Stefan Olofsson
        Filename        : draft-chen-idr-asloop-aggr-00.txt
        Pages           : 4
        Date            : 2021-10-18

Abstract:
   Currently an BGP aggregate may be denied or excluded by the AS loop
   detection mechanism when a more specific, contributing route contains
   the local AS number.  To help enhance network robustness and simplify
   network operations, in this document we propose that the AS loop
   detection be relaxed for aggregates with an AS_SET path segment.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-chen-idr-asloop-aggr/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-chen-idr-asloop-aggr-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Enke Chen <[email-masked]>
Date: Mon, 18 Oct 2021 12:16:07 -0700

Hi, Robert:

Thank you for your comments. Please see my replies below.

> Actually RFC6472 goes much further - it discourages use of aggregation
from atomic routes.

Regardless, BGP aggregation may continue to exist (Internet and/or
enterprise) for a long time, given how long it has existed and how much
training materials are there.

Wouldn't it be better to mitigate from the source (i.e., protocol) so there
would be one less thing for people to worry about?

Yes, multiple sites / networks.

> To me in the light of RFC6472 and all SIDR discussions around it this
draft is trying to move in quite the opposite direction.

IMO, RFC6472 ("not-to-use") is the eventual goal. This proposal is to
provide immediate/current simplification for network operation (Internet
and/or enterprise). I don't see any conflict.

-- Enke

On Mon, Oct 18, 2021 at 11:43 AM Robert Raszuk <[email-masked]> wrote:

> Actually RFC6472 goes much further - it discourages use of aggregation
> from atomic routes.
>
> To me in the light of RFC6472 and all SIDR discussions around it this
> draft is trying to move in quite the opposite direction.
>
> Cheers,
> Robert
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchen-2Didr-2Dasloop-2Daggr_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=T_xcng-oorVtQ15en_EiOfUtR57jJpXGD_eXZHBAP2w&s=54ussX6B8_-A3VyRuC_Gi08lw8HapbWwsRJdn7CxSBc&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dchen-2Didr-2Dasloop-2Daggr-2D00&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=T_xcng-oorVtQ15en_EiOfUtR57jJpXGD_eXZHBAP2w&s=e4OTI8zgXCY0hTK7rnRn_8XLi6yoGun6f7UPIpmalZo&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=T_xcng-oorVtQ15en_EiOfUtR57jJpXGD_eXZHBAP2w&s=dLm1FtWzLj6mE-5dm1rmsD044hrvUICba6Sz0fdAktQ&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=T_xcng-oorVtQ15en_EiOfUtR57jJpXGD_eXZHBAP2w&s=tBx-YXWDZXWatwUAAkrZQ85LbX_A3qpX1PU7yQXpGUo&e=>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=T_xcng-oorVtQ15en_EiOfUtR57jJpXGD_eXZHBAP2w&s=guMJ7Wovvl8Cgvb1LTnQ4PeLMIRU2vnVCGp9xweGtVc&e=>
> <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=T_xcng-oorVtQ15en_EiOfUtR57jJpXGD_eXZHBAP2w&s=829zSl7wTwqYbVvDWdce7358g3MlKKqTviDgJhOQl_I&e=>
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Oct 2021 21:31:02 +0200

Hey Enke,

> Wouldn't it be better to mitigate from the source (i.e., protocol) so
there would be
> one less thing for people to worry about?

Perhaps, but not at all cost.

See the draft said that creating an aggregate is like generating new prefix
so no need to put atomic ASN members and no need to act on them to prevent
loops.

Well please notice that in many DMZs there is plenty /32s and ASBRs
actually aggregate those /32s into one prefix being injected to the ISPs.
That prefix may be sent with ASN of the src AS or AS-SET containing as a
single AS source AS.

I have seen this in number of enterprise production networks. That ASN
there is really needed to prevent loops or not to break intra vs inter
domain routing today.

So such a bold statement to skip any ASN (even if single one) in AS-SET
during AS-PATH loop check is IMHO very dangerous.

Kind regards,
R.

On Mon, Oct 18, 2021 at 9:16 PM Enke Chen <[email-masked]>
wrote:

> Wouldn't it be better to mitigate from the source (i.e., protocol) so
> there would be one less thing for people to worry about?
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Oct 2021 11:38:58 -0700

hi enke,

> enterprise) for a long time

not if we start dropping it on the floor :)/3

randy