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

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.

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

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?

> 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.

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 <robert@raszuk.net> wrote:

> 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: <internet-drafts@ietf.org>
> Date: Mon, Oct 18, 2021 at 8:15 PM
> Subject: I-D Action: draft-chen-idr-asloop-aggr-00.txt
> To: <i-d-announce@ietf.org>
>
>
>
> 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/
> <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=>
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-chen-idr-asloop-aggr-00
> <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=>
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> <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=>
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <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=>
> Internet-Draft directories: http://www.ietf.org/shadow.html
> <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=>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> <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=>
>