Re: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

[Alexander Azimov <[e-mail]>]

Hi Bruno!

Thank you for your feedback! My comments are bellow.


> Possible comments:
>
> - possibly, there could be additional usage/value if the iOTC attribute
> were carrying the role within the AS, rather than being only a flag. For
> example it could be used in routing policies (as a read-only-memory) e.g.
> to set the preference of routes. Indeed, my understanding is that this info
> is double checked hence more reliable than a BGP community that the
> receiver could set with no additional checks. So a priori a better source
> of info for a routing policy
>
I do agree that roles can have other usages, and, for example, default
LOCAL_PREF value may be set according to set role. Still, I do not see use
case, when iOTC itself can provide additional support for routing policies.
IMO - we should keep iOTC as simple as possible.


> - a priori, as per current text, the iOTC attribute seems advertised over
> EBGP session and not removed on the reception side. I'm not sure whether
> this is a design goal or a bug.
>
iOTC is not intended to be sent via Peer/Provider/Customer connections. We
will clarify it in text. Thanks!


> - Possibly, the "Strict mode" could be the only one/the mandated behavior.
> To allow for backward compatibility, the non-compliant peer could tag
> routes with "well-known" BGP communities, to be defined by this document,
> and indicating the role (on a per route basis).
>
> 'Strict mode' by default seems to me too radical. It will result in
problems at state of partial deployment, when after software update BGP
session will not get up back. Also, please keep in mind, that roles are
negotiated via OPEN messages, before any communities can be exchanged.