Re: BGP Roles: Transition to Transit Attribute

Hi Robert,

Please see my comments below.

вс, 6 окт. 2019 г. в 23:59, Robert Raszuk <[email protected]>:

> Hi Alexander,
>
> I am assuming you mean "transitive" not "transit".
>
Yes, it was a typo.


> Still I have few main observations/questions:
>
> A) How do you prevent spoofing (on purpose or by accident) content of this
> attribute ? You you still need to validate by local policy check does it
> really make sense to send this from the peer ?
>
I might not be getting your point. At the receiver side, you can't check
the correctness of the policy several (or even one) hops away. The
attribute limits the way the route is propagated, so I don't see how it can
be maliciously abused. And the roles that are described in the draft should
significantly limit the number of mistakes during configuration.


> B) Draft says:
>
>    As opposed to communities, BGP attributes may not be generally
>    modified or filtered by the operator.  The router(s) enforce them.
>    This is the desired property for the OTC marking.  Hence, this
>    document specifies OTC as an attribute.
>
>
> Well take any attribute .. you can modify most of them with fancy policy
> language. Even critical attributes like AS_PATH can be altered at will in
> transit by most popular BGP implementations. So I guess if you count on
> this one to be immutable make it clearly so as MUST in the draft.
>
Of course, the attribute is not immutable, but the way BGP implementations
should treat unknown attributes should make it more reliable compared to
the community.


> C) How do you plan to handle aggregation of prefixes with different OTCs ?
>
Since normally you are aggregating customer routes, and the draft says that
if you are receiving route with OTC attribute set from customer it MUST be
rejected. So I don't see scenario when we need to aggregate such routes.

_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr