Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04

Alexander Azimov <> Sun, 10 May 2020 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA6FD3A0B1D for <>; Sun, 10 May 2020 11:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 MNqkjHYxrEYj for <>; Sun, 10 May 2020 11:52:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08C403A0B1B for <>; Sun, 10 May 2020 11:52:08 -0700 (PDT)
Received: by with SMTP id i27so5778385ota.7 for <>; Sun, 10 May 2020 11:52:08 -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=QZ73AEHc4VqzAUms6gaqjV08xpZa0eXlG2qUSrL2RTk=; b=Jm9eY6fhwexnCZFE3PmFdqNeg79yXCWSc6lIKOjZv51nXh6lg3QL0Z5Buz36UUrUWy m4EIW/AOxqYqVOvA+MqghWelCDRk3nQhmCLN4c9IN71J3RRVYyE6s8kjqMgWzmwIzcSZ u4x3OmGv77YT/nXP7NDyojooVcu05fTxVkCdsEhN6WfDUmYFcNMqh58LOMzqKMutfWbh +ooKR0mZ0O+LX8KQcToPnbvoJBH449hV7M+mMzpTyMwdlFh0SVt3C0a1t7hLYw5B+qLZ W+i5f8Z0tcX6cNB2clhKj/Q//9kWrvCdHnazEmk7SORsR228nid2yWbVU2NT+MYFGc6p nAPQ==
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=QZ73AEHc4VqzAUms6gaqjV08xpZa0eXlG2qUSrL2RTk=; b=gjg8Eg1L8dBdVNr0EiPbxL82WXtssOTw/haYOaW9eafwHnaNJkyWSFuLx7ZIT7vhV2 ul8VP/btAYb75MECt3L++wwqbYeDfBMntIVesYRxOTFax7G6trrU8jHgX0NuNlNunWle v+ZQx4Sn2u6hSl8HjmUSanCxttg2k1uURw6AgjZgjUmRdH7p3VYlOVhNdUnuOlkMVuCc sl8YtSWdZwV46vSXStNUN6fIad1j1eOH6XWSVJu/5iNJ/4Wu1xAPZQDnBV4BaiEZo5rc aUWkfcDIamFQQZ+r6EJTB925S4bn5y8iyphKV51EMtYPMx7brU48InCWX+TDu0/90dKI BCaA==
X-Gm-Message-State: AGi0PuZupECSNVccY1BCzqB6117413PQztVMVuCheQlv/pDGSpiKKFr9 0Blzf/w93OkL+wV++nEv3rVC72e3TFiyRSv4hNI=
X-Google-Smtp-Source: APiQypJ52QEXkFDSItw/8j6ft71/kS4OlEfmkQSK59or9xIeXhEP51NTlVYWJ9w0Og5LQYP4OiUvpvOJfDqSbAqjSEI=
X-Received: by 2002:a05:6830:1e9c:: with SMTP id n28mr9216260otr.27.1589136727196; Sun, 10 May 2020 11:52:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Sun, 10 May 2020 21:51:56 +0300
Message-ID: <>
To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <>
Cc: "" <>, SIDR Operations WG <>
Content-Type: multipart/alternative; boundary="0000000000001fc91605a54fbace"
Archived-At: <>
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 May 2020 18:52:10 -0000

Hi Yunan,

Please see my comments below.

ср, 6 мая 2020 г. в 10:12, Guyunan (Yunan Gu, IP Technology Research Dept.
NW) <>om>:

> Hi Alex,
> Thanks for the elaboration, which totally makes sense to me. A suggestion
> here, the description of how to deal with the P2P relation using ASPA (just
> as what you described below) can be added to the draft for clarification.
> Further, Section 5.2 says:
> When route is received from provider or RS it may have both Upstream
>    and Downstream paths, where a Downstream follows an Upstream path.
> The “downstream” refers to both P2C path and P2P path, right? If so, I
> suggest to change the usage of “downstream” to “non-upstream” or similar
> wording to avoid confusion.
I do agree, this part isn't clear. I'll try to rephrase it.

> Another point to confirm with you about Section 5.2:
> Additional caution should be exercised when processing prefixes that
>    are received from transparent IXes, as they don't add their ASN in
>    the ASPATH.
> To my understanding, that in this draft, you assume by default that RS
> prepends its own ASN to the AS_Path, right?
No, there is no such assumption.

> And a final question about Section 7 Siblings (Complex Relations),
> regardless of the current description of what sibling relation is, do we
> think that sibling ASes are ASes that belong to the same operator? So any
> type of transition is free of charge?
Speaking about ASPA, we are speaking about peering relations, without any
guess about the business between parties.
And from what I know - siblings are also spread among small networks, so
this term is not strictly bound to the same administrative domain.