Re: [Idr] WG Adoption call draft-ymbk-idr-bgp-open-policy - (6/6 to 6/20/2016)

[Alexander Azimov <[e-mail]>]

Copy of my yesterday's email, just in case, if it was not delivered:


Dear Sriram,

Thank you for your input, but I think most of your concerns come out of
confusion. Let me clarify them one by one. My comments are included in text
below

2016-06-08 1:08 GMT+03:00 Sriram, Kotikalapudi (Fed) <
[e-mail]>:
 The above mentioned second part seems to be a compromised subset of

> the proposal in the existing WG draft
> [ietf-idr-route-leak-detection-mitigation].
>
> The bgp-open-policy draft proposes a single OTC flag per update
>
> (as opposed to one flag per AS-hop).
>
> This lacks efficacy as explained with examples in Section 5.5 of
>
> [ietf-idr-route-leak-detection-mitigation] and also in ref [1] noted below.
>
> In contrast, [ietf-idr-route-leak-detection-mitigation] proposes
>
> an RLP flag per AS-hop, which is shown to work well
>
> (i.e. more robust in the presence of errors and partial deployment)
>
> for route leak detection (see Section 5.5 for details).
>
RLP, as its proposed could not be used on “per update basis”. But OTC, with
use of proposed roles, does not share these limitations. This is an excerpt
from [ietf-idr-route-leak-detection-mitigation] draft section 5.5:

        +-----+         +-----+  peer to peer (p2p) relation +-----+
     p--| AS1 |-------->| AS2 |----------------------------->| AS3 |
        +-----+         +-----+            Update -->        +-----+

                                Method B: {p [AS2 AS1] RLP=1}

In our proposal, AS2 would set OTC flag only if AS3 is not supporting
roles, and this can easily be retrieved from OPEN message. So the problem
is not with per-update basis approach, but with RLP attribute itself. I'd
like to mention, that well designed per-update attribute has one more
obvious advantage: fixed size.

> Also, the bgp-open-policy draft mixes up detection and mitigation
>
> into one combined algorithm.
>
> (Mitigation belongs largely in the operator policy space.)
>
> In contrast, [ietf-idr-route-leak-detection-mitigation] describes
>
> the RLP encoding and detection separately.
>
> It leaves the mitigation method entirely to the operator,
>
> while providing only an example of a mitigation policy.
>
> The operator uses the detection algorithm as a tool to
>
> inform their own policy when it comes to mitigation.
>
When dealing with route leaks it’s important to solve the problem. Not just
detect it. What do you think is easier - to prevent leaking or to track
down route leak and stop it propagation? I think there is no real choice -
create or not to create route leak, likewise it is now with community
usage. That is why our draft, with help of roles, proposes full automation
for both leak prevention inside AS and leak detection for leaks that are
made by third parties. I believe it could provide complex approach to solve
the problem.