Re: [GROW] AD Review of draft-ietf-idr-bgp-open-policy-15

[Alexander Azimov <[e-mail]>]

Dear Alvaro,

Thank you for your detailed comments.
I will work on the edits during the weekend and after recheck in our small
co-author group, I'll push the next version.

May I ask you to give more details on this part of your comment?
>  Also, I believe the specification is not complete.
Can you amplify what parts of mechanics are missing?

ср, 9 июн. 2021 г. в 22:40, Alvaro Retana <[e-mail]>:

> Dear authors:
>
> Thank you for your work on addressing the route leaks problem!
>
> I think the document still needs a lot of work.  In general, the
> precision in the language is not what I would expect from a Standards
> Track document.  Also, I believe the specification is not complete.
> Please see details inline.
>
> Instead of returning the document to the WG, and because it is short,
> I am including a long list of suggestions below.  Given all the
> proposed changes, we will eventually need to run a new WGLC explicitly
> including the grow WG -- I have cc'd them in this message as well.
>
>
> Thanks!
>
> Alvaro.
>
>
> [Line numbers from idnits.]
>
>
> ...
> 14           Route Leak Prevention using Roles in Update and Open messages
> 15                         draft-ietf-idr-bgp-open-policy-15
>
> [minor] s/Update and Open/UPDATE and OPEN BGP
>
>
> [major] Throughout the document the concept of "sending prefixes" (or
> sometimes announcing them) is used -- I understand that these are
> common phrases.  However, that is not the terminology used in rfc4271.
> Please use "route advertisement" (and variations) instead.  Note that
> "propagated" is also ok.
>
>
> 17      Abstract
>
> 19         Route leaks are the propagation of BGP prefixes which violate
> 20         assumptions of BGP topology relationships; e.g. passing a route
> 21         learned from one lateral peer to another lateral peer or a
> transit
> 22         provider, passing a route learned from one transit provider to
> 23         another transit provider or a lateral peer.  Existing
> approaches to
> 24         leak prevention rely on marking routes by operator
> configuration,
> 25         with no check that the configuration corresponds to that of the
> eBGP
> 26         neighbor, or enforcement that the two eBGP speakers agree on the
> 27         relationship.  This document enhances BGP OPEN to establish
> agreement
> 28         of the (peer, customer, provider, Route Server, Route Server
> client)
> 29         relationship of two neighboring eBGP speakers to enforce
> appropriate
> 30         configuration on both sides.  Propagated routes are then marked
> with
> 31         an Only to Customer (OTC) attribute according to the agreed
> 32         relationship, allowing both prevention and detection of route
> leaks.
>
> [minor]
>
> OLD>
>    This document enhances BGP OPEN to establish agreement of the (peer,
>    customer, provider, Route Server, Route Server client)  relationship of
>    two neighboring eBGP speakers to enforce appropriate configuration on
> both
>    sides. Propagated routes are then marked with an Only to Customer (OTC)
>    attribute according to the agreed relationship, allowing both prevention
>    and detection of route leaks.
>
> Suggestion>
>    This document enhances the BGP OPEN message to establish an agreement of
>    the relationship between two eBGP speakers in order to enforce
> appropriate
>    configuration on both sides.  Propagated routes are then marked
> according
>    to the agreed relationship, allowing both prevention and detection of
> route
>    leaks.
>
>
> ...
> 94      1.  Introduction
>
> 96         A BGP route leak occurs when a route is learned from a transit
> 97         provider or lateral peer and then announced to another provider
> or
> 98         lateral peer.  See [RFC7908].  These are usually the result of
> 99         misconfigured or absent BGP route filtering or lack of
> coordination
> 100        between two eBGP speakers.
>
> [nit] s/peer.  See [RFC7908]./peer [RFC7908].
>
>
> [nit] s/between two eBGP speakers./between autonomous systems.
>
>
> 102        The mechanism proposed in
> 103        [I-D.ietf-grow-route-leak-detection-mitigation] uses large-
> 104        communities to perform detection and mitigation of route leaks.
> 105        While signaling using communities is easy to implement and
> deploy
> 106        quickly, it normally relies on operator-maintained policy
> 107        configuration, which is vulnerable to misconfiguration
> [Streibelt].
> 108        The community signal can also be stripped at the ISP boundaries



-- 
Best regards,
Alexander Azimov