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

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 <enchen@paloaltonetworks.com>
wrote:

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