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

Alexander Azimov <a.e.azimov@gmail.com> Sun, 10 May 2020 18:52 UTC

Return-Path: <a.e.azimov@gmail.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6FD3A0B1D for <sidrops@ietfa.amsl.com>; Sun, 10 May 2020 11:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNqkjHYxrEYj for <sidrops@ietfa.amsl.com>; Sun, 10 May 2020 11:52:08 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C403A0B1B for <sidrops@ietf.org>; Sun, 10 May 2020 11:52:08 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id i27so5778385ota.7 for <sidrops@ietf.org>; Sun, 10 May 2020 11:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <C01B0098369B2D4391851938DA6700B7179F9EAB@dggeml512-mbs.china.huawei.com> <CAEGSd=APMCnnd5mrnMKtti-QWy1m7r5JfJsf7HynZqyXWwsZHg@mail.gmail.com> <C01B0098369B2D4391851938DA6700B717A0C386@DGGEML532-MBX.china.huawei.com>
In-Reply-To: <C01B0098369B2D4391851938DA6700B717A0C386@DGGEML532-MBX.china.huawei.com>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Sun, 10 May 2020 21:51:56 +0300
Message-ID: <CAEGSd=Bk3Lgte1L0KKP_GU+ieDpETvLk1JTVTLZTv-Z5NrVUoQ@mail.gmail.com>
To: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <guyunan@huawei.com>
Cc: "rv@nic.dtag.de" <rv@nic.dtag.de>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001fc91605a54fbace"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/pyJaB8sK5HNqAdYwUWba8SlWNhk>
Subject: Re: [Sidrops] question on draft-ietf-sidrops-aspa-verification-04
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=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) <guyunan@huawei.com>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.