Return-Path: 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 9796D12003E for ; Fri, 26 Jul 2019 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: 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: 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 cbFMwoolMoXG for ; Fri, 26 Jul 2019 09:07:54 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 5C65C120072 for ; Fri, 26 Jul 2019 09:07:47 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id j19so17391310otq.2 for ; Fri, 26 Jul 2019 09:07:47 -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=4WDJBt0T4lYyEcRvOxoU95FOfElAEyBkXe0BGc6/SYY=; b=fOebjRecFqjcP1tSNbj2BJhkIyEJ5fZF4ZxUbMs36EEl9VqRi4Z3xDk6QI2xy+9pXj vSIK9iNFI2CXKkbKRa1josu5CmxjOM/Zxl5AmL0PsrxQoaHvZexRP/NZpBSJHIg/lRAz Xx/7ASATfgJQ3h0vaFPOVorShGnyusT3GLLlPdtbqjWE3cE9hPdOhfXbHRaaux6PXwzW HsY6hkSr79nEmGhFCxeJ36i7uxH4pF4ybKZYZWuGf7spOXeXxL7FlkjVM9uimriOoF8X 9o515lpvbxSyOpWMPOaIsAZxVr/eodxDSKwmFdV9ee7ubxctCnOPNQInosC3VjfkmCN+ V6Ag== 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=4WDJBt0T4lYyEcRvOxoU95FOfElAEyBkXe0BGc6/SYY=; b=fPaGbIVtA0BmiN8HCMBTgmVSByIHpE3NVY9jIHPSZvqCSbIgam2Csbac/0R9IVZKTf yApAZTx/wZ8yDs7LSWIkZKz8jaJHkOLeLs/Cf+wIsmyh+r7E6RZRnXAus3aASs1zi7Ct htus05rUEnfxxbEtQHOnzmpWP4AgRaKiglPeWYWvWE10cK3uGqszGHfrEZIHubJTaSh0 UZTGHypEPqsKV86K8uiuvonTgm/VE+s4Ex0TixaJiGWJa+m33MyARvaL4O9mUPHcnEYY eWrdJxz3vYOX9vzjhlQpbCo8fVU8I0EfCN9c40uYEsGqL6l5aypxli8/wLaFVHN6Mfeo I2Rw== X-Gm-Message-State: APjAAAUzQuVGnHB/Qt/vhGNZygVOf/MYwiQk06JEJDTPPZgrgkzB6+mx UK844nRFhMN/qGbl07ysCllPxwOcz+WMfr9p7N8= X-Google-Smtp-Source: APXvYqyCiecDicJW3+i9O53SAo59X5VTOGSj3I3nL9g7fLDD5x0BK8AXJBdikrNvUbT0VC9LtcMbR1C/qoQROLjHzsQ= X-Received: by 2002:a9d:7411:: with SMTP id n17mr65498958otk.27.1564157266713; Fri, 26 Jul 2019 09:07:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Fri, 26 Jul 2019 19:07:35 +0300 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000041680e058e97bebe" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns X-BeenThere: sidrops@ietf.org 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: Fri, 26 Jul 2019 16:07:57 -0000 --00000000000041680e058e97bebe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm sorry for the last email. It was supposed to be bigger. =D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:38, Jakob Heitz= (jheitz) : > If you receive an AS-PATH of 2 ASes and neither of them make any > attestation, > > then your procedure calls it valid. It could be invalid, > > so it must be considered unknown. > It an interesting point. When I was writing the ASPATH verification procedure I had in mind that we need to detect invalids. But for debugging purposes, it might be also useful to distinguish fully verified paths where all pairs are valid and those paths that represent a combination of valid and unknown pairs. It will also require clarification that for backward compatibility such unknown paths MUST be treated as valid. We should add this option into consideration. If an AS-PATH contains an AS-SET, then the segments on either side of > > the AS-SET can still be verified. If any such segment turns out to be > > invalid, then the whole path must be considered invalid, not unverifiable= . > I do agree and that's how both downstream path upstream path procedures are defined in the draft. As we discussed in person, we might need additional clarification in the beginning where {AS(I), AS(I-1)...} sequence is defined. > My procedure accounts for these cases and more. > > For the cases where every AS makes an attestation, my procedure agrees > with yours. > If you have ASPA(1, 2) you can't make assumptions about relations of 2. Otherwise, it may lead to incorrect results in the case of siblings. BTW, you have a copy/paste error in 5.2 Downstream paths: > > If a route from ROUTE_AFI address family is received from a customer > > should be: > > If a route from ROUTE_AFI address family is received from a provider > > Yes, you are right. Copy-paste can become tricky. Will be fixed in the next version. --00000000000041680e058e97bebe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry for the last email. It was = supposed to be bigger.

=D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3.= =D0=B2 08:38, Jakob Heitz (jheitz) <jheitz@cisco.com>:

If you receive an AS-PATH of 2 ASes an= d neither of them make any attestation,

then your procedure calls it valid. It= could be invalid,

so it must be considered unknown.

It an interesting point. When I was writing = the ASPATH verification procedure I had in mind that we need to detect inva= lids. But for debugging purposes, it might be also useful to distinguish fu= lly verified paths where all pairs are valid and those paths that represent= a combination of valid and unknown pairs. It will also require clarificati= on that for backward compatibility such unknown paths MUST be treated as va= lid. We should add this option into consideration.

If an AS-PATH contains an AS-SET, then= the segments on either side of

the AS-SET can still be verified. If a= ny such segment turns out to be

invalid, then the whole path must be c= onsidered invalid, not unverifiable.

I do agree and that's how both downstream path upstream path procedur= es are defined in the draft.
As we discussed in person, we m= ight need additional clarification in the beginning where {AS(I), AS(I-1)..= .} sequence is defined.
=C2=A0

My procedure accounts for these cases = and more.

For the cases where every AS makes an = attestation, my procedure agrees with yours.

If you have ASPA(1, 2) you can't make assumptions about relat= ions of 2. Otherwise, it may lead to incorrect results in the case of sibli= ngs.

BTW, you have a copy/paste error in 5.= 2 Downstream paths:

If a route from ROUTE_AFI address family is rece= ived from a customer

should be:

If a route from ROUTE_AFI address family i=
s received from a provider
Yes, y= ou are right. Copy-paste can become tricky. Will be fixed in the next versi= on.

--00000000000041680e058e97bebe--