Re: [Idr] BGP Roles: Transition to Transit Attribute

Alexander Azimov <> Sat, 12 October 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 238DC1200A4 for <>; Sat, 12 Oct 2019 13:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VRQpDY09SdJQ for <>; Sat, 12 Oct 2019 13:46:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2302912006A for <>; Sat, 12 Oct 2019 13:46:29 -0700 (PDT)
Received: by with SMTP id g13so10814248otp.8 for <>; Sat, 12 Oct 2019 13:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lplu5bFIARuUwzH4hks1Z9xhTU0BdJUBYsjXg8udHBs=; b=huYG6ipsRqLCs7ZAEezYtKZSU4f7gx7V6VYsX/PMdJqCsqYOKZ0VQmqA9g7Q7Mvo5W YiJHwsxLn3xO7SLlDtzOWA/exMYLK+HvfXIXroRrvumO3QuQb7YxggSrFJmPbpY6+fbD FMd6WJpuxqfMadeqXPZLBGdKpgTE6gOT4B18JrJHdYsHsFmd1nLhXaAfgcJCglx7ijMk jHgjSxm46YJ6204OANnYU2yIW7TszhrVYgxMVlDrZhibbLsENXCTAnicDttdJy16yKUY XaQbdCL7YyBU69nmTEUlfbBtgwSk0IzxZdCzCNNudHAGCdkwRzNMUzudIPoy0b2D9j4l Sqxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lplu5bFIARuUwzH4hks1Z9xhTU0BdJUBYsjXg8udHBs=; b=BJjpr4454TxOwvSBldAbyQnvV5Jd8C7lbR+gRYsLtNXo50Gxzjb8oemgZC9daL1f+1 hv/nXIY/+St8gr7UP8ggOPyK37rZW7VdJUtFRIhm0axl9k9xMPa95FJ1HZOpL0Oq9UB5 5NOeR2x0aQqIPwAJJPZSD65kmWaSaY4VH0I31qeaq6DWGMlaRG2VkNFi8lTt01hY/dyW 7BPhpSLEHrf0GqXODPam7oTgeyJmovhEcRvDzqVsTVE7/cKIT1JjQNFqLSKcWq9XSQwh 9cZeXkmDEOVZkoZAnlB8V145zelt+/UYb4fX/3tKC8HI+xdTF7jcEGxeQmNi339BFL+E TGWQ==
X-Gm-Message-State: APjAAAXa3eD8zD6q3h8BxnohswWik7iwsqZikmR4O0rhuh9aSUDcQSmt Ps6PoiD7KkZa9OJnO5T7zgPvEPlOU20Xxlx5P3P3tKnaLx/XOg==
X-Google-Smtp-Source: APXvYqy8+aGzgN28QEhI2jfK0uAi1G9gfiHKLLcBiIO5DboU7QkATlEMe936aWcEaowsKJRUn1ts2gcaUKNUE2HeKIQ=
X-Received: by 2002:a05:6830:1e03:: with SMTP id s3mr8508354otr.289.1570913188402; Sat, 12 Oct 2019 13:46:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Sat, 12 Oct 2019 23:46:14 +0300
Message-ID: <>
To: Robert Raszuk <>
Cc: idr wg <>
Content-Type: multipart/alternative; boundary="000000000000915df60594bcbae2"
Archived-At: <>
Subject: Re: [Idr] BGP Roles: Transition to Transit Attribute
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Oct 2019 20:46:31 -0000

Hi Robert,

Please see my comments below.

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

> 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.