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

["Keyur Patel (keyupate)" <[e-mail]>]

Hi Folks,

Comments inlined #Keyur

On 6/9/16, 9:32 AM, "Job Snijders" <[e-mail]> wrote:

>Dear Authors, IDR group,
>
>I'd like to start by thanking you for putting thought and time into the
>route leak problem space. It is encouring to see fellow operators engage
>with the IETF community to address actual, day to day issues.
>
>On Mon, Jun 06, 2016 at 12:40:19PM -0400, Susan Hares wrote:
>> This begins a 2 week WG Adoption call for
>>draft-ymbk-idr-bgp-open-policy.
>> You can find the draft at:
>> 
>> https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/.
>> 
>> In your comments on adopting this draft, please indicate:
>> 
>> 1)      "Support" or "no Support"
>
>No support.
>
>> 2)      Do you feel this is a way to prevent route leaks?
>
>It certainly is a way.

#Keyur: I am not sure if the solution attempts to cover all cases: Open
policy assumes certain peering relationship can be established between BGP
speakers and based on the relationship, the OTC handling is done. This
information is restricted and doesn¹t flow along the path the route is
announced. You do want to carry this information so any AS down the path
can make an independent decision?

>
>> 3)      Are there any deployment issues that might prevent deployment
>> of this enhancement to BGP Open?
>
>I do not think that the OPEN moment in the lifecycle of a BGP session is
>the appropiate place for policy constructs like this.


#Keyur: +1. I completely agree. Furthermore, the draft isn¹t clear about
changing of session level roles (either using dynamic capabilities or upon
a session restart) and its impact on depref/dropped routes and existing
functionality like GR (route based).

> In practise it is
>probably not an issue when you have to flap a BGP session to change the
>relation between two ASNs, but it would be nice if this is not required
>(like today on most platforms).
>
>Secondly (and more importantly), the roles are not necessarily a BGP
>session-specific characteristic, but rather a prefix-specific property.
>The proposed OPEN method does not provide for this level granularity if
>I am reading it correctly. The method would affect all prefixes exchange
>over a BGP session, without exception.

#Keyur: Ack and agree.


Regards,
Keyur

>
>> 4) Does this interact with
>> draft-ietf-idr-route-leak-detection-mitigation?
>
>Yes, in terms of the problem being addressed.
>
>Kind regards,
>
>Job