Re: [RTG-DIR] Rtgdir Last Call review of draft-ietf-lsvr-bgp-spf-13
"Acee Lindem (acee)" <acee@cisco.com> Thu, 01 July 2021 00:42 UTC
Return-Path: <acee@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D60A3A0654; Wed, 30 Jun 2021 17:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.594
X-Spam-Level:
X-Spam-Status: No, score=-9.594 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GBlXWK0P; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tYHDoUBo
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 nKLRTal_tyKD; Wed, 30 Jun 2021 17:42:54 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52DC3A064A; Wed, 30 Jun 2021 17:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=109803; q=dns/txt; s=iport; t=1625100173; x=1626309773; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kNYsJkJ5YvgcwuJxlbZLi+LauAQ2m27gRIiGtzAZdE0=; b=GBlXWK0PemWq+mZoRbzB4U2wKur3uXlHB2WAeFpmUXKRzw18WdbciI3F A1K7c6Q3CQ5z749XwTPVIIZgsVDQZNjfudWUR6Reba3NZc+c3jOOZba5G OXNg0kyhXH4eMA7JAF9Ddj2WWjDfJOZ5602iw8b1aQosPBxqeecyC+RgG 0=;
X-IPAS-Result: A0BhAwAlD91gl5BdJa1ahAUwIwYoflo3MQuDfz6DSAOFOYhsA4pQj1SBQoERA1QLAQEBDQEBNQoCBAEBhFICF4JbAiU4EwIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GRQEBAQQMBggJHQEBJRIBDwIBBgIRAwECIQEGAwICAh8RFAkIAgQOBSKCTwGBflcDLwEOjHGPNAGBOgKKH3qBMoEBggcBAQYEBIVVDQMIgjIJgTqCe4QMAQGBF4VKJxyCDYEUASccgWGBAD6CIDcLAoFGOgYQCIJZNoIugi9fDAYBPRsLAQMULzINIQE0Ewg6BAoBFAsGBQwSCgSSCIJHAUaIII0nkHU7WwqDIIoijh6FYAUmg2CBRYlzln6YBYoPgy2QCyaEZAIEAgQFAg4BAQaCRSoigVtwFWUBgj4JRxcCDo44gQsBCIJDhRSFSQFzAjYCBgEJAQEDCXyIBC2BBwGBEAEB
IronPort-PHdr: A9a23:NzhqfRfiGKu52PSfhcOa32lGlGM/r4qcDmcuAtIPhLdHc6Dl9JPnb wTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pNVcFhMwakhZmDJuDDkv2f/HvZi0+W s9FUQwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:5WM9bqnQlFqRtSG6pYC3FgnVT9rpDfORimdD5ihNYBxZY6Wkfp +V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYOCGghrpEGgG1+vfKlLbalbDH4JmpM Jdmu1FeaHN5DtB/IXHCWuDYqwdKbC8mcjC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6 Dsn/avyQDQHUg/X4CePD0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZdbxp/hZMZtU TVmQ3w4auu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESotu/oXvUkZ1SxhkFynAid0idyrD AKmWZ5Ay1H0QKXQohym2q35+Cv6kd115ao8y7ovZKqm72IeNt9MbsduWqcGSGptHbJe7pHof 52Niuixuhq5VmrplWP2/HYEx5tjUa6unwkjKoaiGFeS5IXbPtLoZUY5149KuZNIMvW0vFsLA BVNrCQ2B+WSyLSU1nJ+m10hNC8VHU6GRmLBkAEp8yOyjBT2HR01VERysATlmoJsMtVcegL28 3UdqBz0L1eRM4faqxwQO8HXMusE2TIBRbBKnibL1jrHLwOf3jNt5n06rMo4/zCQu1G8HLzou WLbLp8jx9yR6vDM7z44HR7yGGEfIzmZ0WY9ih33ekOhlTTfsufDRG+
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,312,1616457600"; d="scan'208,217";a="738234866"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jul 2021 00:42:52 +0000
Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 1610gpkh005192 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jul 2021 00:42:52 GMT
Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 30 Jun 2021 19:42:51 -0500
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 30 Jun 2021 20:42:50 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 30 Jun 2021 19:42:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dMO/DkojYhwEjncPGEmlCpEzJoJLNsFM0+lGPxP2BmawsUEeFZNpEvCMIWKZJYFd0aJDniqLTH/VtVsMdydjrMeoBbWHPr23i3aRSzvK+1YCfpioxo2Wpgb2psslUhLpCyxIS1syiiTgYxDBG54P38P+3YEr9R4ThgXqbJ9Qu6fHuHmqCdiqahu1QKNFbtIqrnwblf9uu0DyIVGBR+KCkqRnNOX3j6aS7LxeZ3zPvwELJudm1mDwtqdrGSl2RIKNNAar7y6af0dFdOKlionNCpRUh5BMyexIuhtxuJQ6utYyu539pfKCssRHa5GFZxh6zmtWRtlTbucrrBPQ+IEP8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kNYsJkJ5YvgcwuJxlbZLi+LauAQ2m27gRIiGtzAZdE0=; b=O3OpJhxrthUy5wcynyESy2ow9IR34mroPpybJYVCvhUBh01Nuuy07wYEe5AppItGeMD0jklbNL5Y4iFLAYja0/72uqKfAa4tULW1SBRSl7skTEH/6zRDHLyxi1pqVfJPMmd7W5lRa1NJjGJjruRi18S9DP90sayH88MKsRnK/7/wLWDRtDoEZIxD/IdA9JS4IcnLHUOK/ioKJEsagBB5K5oWUiFFo0D2ibsIHbZm35lYoXNW3C1Xlm5L31rE7Lg/WcIXuBYM3EstSPaNhtneZTzbjN4blvjOib84hKrT4VDvZRvdmUOjHbPj27vJ48bnyCYgPwaqwyMqJNO/kxF2Ag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kNYsJkJ5YvgcwuJxlbZLi+LauAQ2m27gRIiGtzAZdE0=; b=tYHDoUBoz6p3KzV27Rl57NQ4K75qd7Rl8W6BiuYPmZxzEetqcUkB+OVVMqJLl2ricIBMJXfoGVjn1FEycxrPxKTpU1pDFk6xIE5Wpm2hh7OkjaRnh3XhPVEuZexKCcKcgUPljfqznLRb4/6P3NAk/XFYrdH8/bytLcaZJCKgK2U=
Received: from BL0PR11MB2884.namprd11.prod.outlook.com (2603:10b6:208:72::25) by BL1PR11MB5495.namprd11.prod.outlook.com (2603:10b6:208:317::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22; Thu, 1 Jul 2021 00:42:47 +0000
Received: from BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::592e:30fd:2fa1:e919]) by BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::592e:30fd:2fa1:e919%5]) with mapi id 15.20.4264.026; Thu, 1 Jul 2021 00:42:47 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Yingzhen Qu <yingzhen.ietf@gmail.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "Yemin (Amy)" <amy.yemin@huawei.com>, "guntervandeveldecc@icloud.com" <guntervandeveldecc@icloud.com>, "lsvr@ietf.org" <lsvr@ietf.org>, "draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>, Luc André Burdet <laburdet.ietf@gmail.com>
Thread-Topic: [RTG-DIR] Rtgdir Last Call review of draft-ietf-lsvr-bgp-spf-13
Thread-Index: AQHXZ59ANzP3r4lPy0uer8J93loFPasscX4AgACzPgD//+VpAIAASRwA//++doA=
Date: Thu, 01 Jul 2021 00:42:47 +0000
Message-ID: <DC159AB3-3AD3-43E2-81B3-25BE610B796F@cisco.com>
References: <305FC57A-8B6B-4718-B61E-A5E7D30431D1@gmail.com> <F6C9EA73-1BCF-4C3C-AC9E-9261D180C1C7@cisco.com> <8152FDDD-A8DE-4930-B53E-5A0D3E0ACF90@gmail.com> <932A097A-5314-4DC1-97A7-0314FB70A4E4@cisco.com> <859A82FB-4E85-4595-A0A2-87E811D39034@gmail.com>
In-Reply-To: <859A82FB-4E85-4595-A0A2-87E811D39034@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4a1bcac4-b613-408a-e363-08d93c292600
x-ms-traffictypediagnostic: BL1PR11MB5495:
x-microsoft-antispam-prvs: <BL1PR11MB54958D13F8C7F45BD12ECDD0C2009@BL1PR11MB5495.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: URkbBljJEzU8DRhGKn3XmEdzXTaP7+6owcpq3CAcuWAKegVWkkiVftxp9zpJ2FIy+4FeCs8oqCKPNoEL7OQvmsgXrQXaVjnuPq6+XlorIhWtZw5/nX8IYFZR+gwKFkdn+2BPX9dC03srtWaDsJt7iCJJcgvGIg2qR7Fb8DUHOL0MSkygFQ/11X9r5KUB4yC5MZjes9jPq3R8G+7hvs/2Wa+q+2tW50vIwY+OFf+rI5K+5e3mj3Te8mTW9DkoAIPx9+MGZlBHUxE7ICDLcGUo7JuiCoKiQS56uqAxHDmI5sAnXGNnoBdyOFxiFk8ZO+BmzP5aIb8uimfSvzjRmnpnC7HmMDabf/VYCVILGUkp5LidIrI/PYjKGRkW3nrzPNKK9jp7pS0f+rq+pN18Ke/diRlgaByTKzEB9JAAi+gqoQau9Z0pVpuMQKQMgPNujHHXpe9XocOaG2TBX8Ez2HCRT/hqcbd9pPH0ejKA8VD4yVQVZSdGGW28yyiQZukRgAmskX8t5H+F3XHKv92iNlDewhNFaJpp0hi4SdcQABK6XvP+xYaUT2pZWmauXVYgy4K2farC3Edu4lWN+vg4mqsc7q3WyU/Nr0REwhorAXzIFu6W6mMiMYZ+3QJjgdTRjm6D3X+yqmepyS86ig5nuJZQoIiiOwzxvbBZAFuRT4kuQvNkj6lct4TVZXhkIP2YHSRcxPRZNE/B4ffeyYIJC7nPvc/QATkDrmxkxeDdAnikT1CCI1xUMwakgoG9ZzvgJApIkxi5nYQgGYsT/JIUK7XrmO5tsMmFRN5vvKhH9Mr6LXLrlEZv9t4TMDRXvpPhHDd7JAyHlLlmfBurgH/tfCCewA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB2884.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(39860400002)(396003)(366004)(64756008)(6486002)(66556008)(66446008)(4326008)(2906002)(316002)(36756003)(86362001)(66946007)(2616005)(33656002)(38100700002)(54906003)(186003)(30864003)(9326002)(8936002)(5660300002)(91956017)(6506007)(53546011)(6916009)(83380400001)(166002)(45080400002)(76116006)(66476007)(122000001)(71200400001)(478600001)(6512007)(8676002)(26005)(45980500001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: aOnCKO/Aq0FGxJzLjlUnvgDEqacUZpAHD2WlgkVxPzAU8ZBRobPq0XXHZD24BNdYz5fRUF6m3nxSTtfUcFvGadaP9ooyeV8u5V+cNvrdJLo0B099HcVRIhCH+ZCKyoBKuufZrsHK/UPWiWbCxuq6cZs2HtuGmJ6eUGb+MkLRnBhQrg5yVHO5dsoQRkWIswIpXhicCOM/uJV+aBvtJMKwvJNyULVN4O7k2pYndmR/lbHeyoc0ZzkktNaDsrCdnhVoaIuDMOlrz6sh0dmSiIVtvzxVS6mZxWMHHwnC3+vjxLcJ2b9hdpV39Gkdz4KqiM1sNncdknLSYAIqGQtlNcGp5e1fucP/Tds/m0t9onkYtc3KbQ7FMAhimJF6Dut/84NLWWQK0yzS/JvEZoHqAsZspipzyH47iKvp5ipJL05t73FqDCf/QgO7WkpJb6auHWjDNFAJY2NJjWHLRZIvOsJmp5v82MfCYMP56j4AWAw9wwLYDmsUjwx7GdABkRj1qR76pSG6hE9S4b0NvAN9F6Lz4BWNz+VTdmoMiHX/t9yMSg4Py/TExt6XBJURjeqKq4KRGvn0nzW27EgNF2x/GACZk8nRqLPNWmDCRlQhoZelZI+Rs8P1zPwjc4GU/TZnnH1o/x0aeeE5+fr+cv20PZiNJroiESlqvgeENs9Ja+jDG9nuQIAnrssXdFeyA2ccPLAU9/ZFZoi7YzptDgwmjKZcG44JE7YxnbA2yEbTir+FbDc22PT010H7P3sC346SWkRaWw5aHOoXiH5N5a2I1kSyHwivh3kjvCObOA33lkOIt1sIlGzKGl6NrQ/RaN9LE4aAMs7cIuTf2F94YZOdNQYcYejSp7YpYuHsJvB9wD99zP0u66wjkoQ4+rYf/SHWLJiWfBOoin/EkssTkefcLjdfhG4XMQhjX3USEfIIWqJll6c5vZ9Lw88//Je0CASLtHSwrY50okcLBo6eSb9eYNCMgatXLkSgJBvvKqMELWqzKniNqEUDdkVVAuTGzteKpCqTJyAFBqJ/3XJwJp6n+5R5Ul4u+mSrInajehqUevTGrrtjOD/9fUUBqWhtM17HSRJVwIIT/JU+u/PI5+73LigjLoSQVzDqPsvypitLzyJVBLKj9qnGmmx47nrg/AECrCtagkPtjLJP6DFsDgwa1pPt25c18xDT6zullMHqCnVjYaKeI2UT/ICgaWG19jKIAhGvWtujRe1tVDOOEeBqeqyNGOEpF5SbzX69ryea9XmL1ZHtnQk4NhO8HBRqGR/bmQxtVQc7ckOAwYXgLauMAIdMLmo8TSZDYPFiKWevbKON9rntsiuDpvhQF+95zGgMjvfS2RSQ181uwSBPy8/PPZDzrA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DC159AB33AD343E281B325BE610B796Fciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB2884.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a1bcac4-b613-408a-e363-08d93c292600
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2021 00:42:47.7514 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1nkJCz056j0mW1K/JUx0PjVuoumd0cOjNM+eSOgdWEEqJ4k1tntrbCMzkbq/lWsB
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5495
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/DYfI4VONrLdBAaUwvFneBkNYLPY>
Subject: Re: [RTG-DIR] Rtgdir Last Call review of draft-ietf-lsvr-bgp-spf-13
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2021 00:42:59 -0000
Hi Yingzhen, From: rtg-dir <rtg-dir-bounces@ietf.org> on behalf of Yingzhen Qu <yingzhen.ietf@gmail.com> Date: Wednesday, June 30, 2021 at 8:37 PM To: Acee Lindem <acee@cisco.com> Cc: Routing Directorate <rtg-dir@ietf.org>, "Yemin (Amy)" <amy.yemin@huawei.com>, "guntervandeveldecc@icloud.com" <guntervandeveldecc@icloud.com>, "lsvr@ietf.org" <lsvr@ietf.org>, "draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>, Luc André Burdet <laburdet.ietf@gmail.com> Subject: Re: [RTG-DIR] Rtgdir Last Call review of draft-ietf-lsvr-bgp-spf-13 Hi Acee, Thanks for the clarification. I thought “current route” meant “the Current-Prefix’s”, hence the confusion. Yes, best case it was ambiguous, worst it was wrong. Thanks for Catching, Acee Thanks, Yingzhen On Jun 30, 2021, at 5:15 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote: Hi Yingzhen, From: Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> Date: Wednesday, June 30, 2021 at 5:51 PM To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>> Cc: Routing Directorate <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>>, "draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>" <draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>>, "lsvr@ietf.org<mailto:lsvr@ietf.org>" <lsvr@ietf.org<mailto:lsvr@ietf.org>>, "guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>" <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>, Luc André Burdet <laburdet.ietf@gmail.com<mailto:laburdet.ietf@gmail.com>>, "Yemin (Amy)" <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>> Subject: Re: Rtgdir Last Call review of draft-ietf-lsvr-bgp-spf-13 Hi Acee, Thanks for addressing my comments. I had a quick look at the changes in version -14, and have a question about the following comment. The change done does make the second point clear, but my original comment was about the fourth point. Please also consider make the term consistent, “Current-Prefix’s” vs. “current route’s”. This is inconsistent but in the case “current route’s” should be “LOC-RIB route’s” to be correct with respect to the rule. There were two instances of this inconsistency. I will fix in the next revision along with a couple comments from Haibo. Thanks, Acee 1017 * If the Current-Prefix's corresponding prefix is in the LOC-RIB 1018 and the cost is less than the current route's metric, the [major]: I think this meant to be "more than the current route's metric" Clarified this so that there is no ambiguity as to which metric is referenced. Thanks, Yingzhen On Jun 30, 2021, at 8:09 AM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote: Hi Yingzhen, Thanks for the review. We’ve incorporated most of your comments into the -14 version. From: Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> Date: Tuesday, June 22, 2021 at 3:46 PM To: Routing Directorate <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>>, "draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>" <draft-ietf-lsvr-bgp-spf@ietf.org<mailto:draft-ietf-lsvr-bgp-spf@ietf.org>>, "lsvr@ietf.org<mailto:lsvr@ietf.org>" <lsvr@ietf.org<mailto:lsvr@ietf.org>> Cc: "guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>" <guntervandeveldecc@icloud.com<mailto:guntervandeveldecc@icloud.com>>, Luc André Burdet <laburdet.ietf@gmail.com<mailto:laburdet.ietf@gmail.com>>, "Yemin (Amy)" <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>> Subject: Rtgdir Last Call review of draft-ietf-lsvr-bgp-spf-13 Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>> Resent-To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Shawn Zandi <szandi@linkedin.com<mailto:szandi@linkedin.com>>, Wim Henderickx <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, Keyur Patel <keyur@arrcus.com<mailto:keyur@arrcus.com>> Resent-Date: Tuesday, June 22, 2021 at 3:45 PM I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please seehttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lsvr-bgp-spf Reviewer: Yingzhen Qu Review Date: Jun 15th, 2021 Intended Status: Standards Track Summary: This document has some issues that should be at least considered prior to publication. Comments: Major issues: • Considering the SPF Status attribute TLV has the same type for Node, Link and Prefix NLRI, it is implied that a BGP update message can only contain a single kind of NLRI (for example, Node or Link). I’d suggest make the draft explicitly state it. I’ve added a paragraph on this in 5.1.1. If we were to make this a restriction, we’d need to discuss in WG. • About SPF Status TLV, use the Node NLRI as an example (section 5.2.1.2), it says in the draft: “If the SPF Status TLV is not included with the Node NLRI, the node is considered to be up and is available for transit traffic.”, then later, “If a BGP speaker received the Node NLRI but the SPF Status TLV is not received, then any previously received information is considered as implicitly withdrawn and the update is propagated to other BGP speakers. “. These two statements seem to conflict. I’ve fixed this for all the status TLVs. Comments inline: [Line numbers from idnits] 78 5.2.1. Node NLRI Usage . . . . . . . . . . . . . . . . . . . 11 79 5.2.1.1. Node NLRI Attribute SPF Capability TLV . . . . . 11 80 5.2.1.2. BGP-LS-SPF Node NLRI Attribute SPF Status TLV . . 12 [Minor]: section 5.2.1.1 should be changed to "BGP-LS-SPF Node NLRI Attribute SPF Capability TLV" to be consistent with other titles. Fixed. 226 Another potential advantage of BGP SPF is that both IPv6 and IPv4 can 227 both be supported using the BGP-LS-SPF SAFI with the same BGP-LS-SPF 228 NLRIs. [Minor]: potential advantage? I'd suggest remove "potential". [nits]: both IPv6 and IPv4 can both be supported Fixed both. 315 The BGP SPF extensions reuse the Node, Link, and Prefix NLRI defined 316 in [RFC7752]. The usage of the BGP-LS NLRI, metric attributes, and 317 attribute extensions is described in Section 5.2.1. [minor]: metric attributes? Might be better just remove it. s/Section 5.2.1/Section 5.2 Changed to just “attributes” and fixed reference. 357 hop sessions) and the direct connection discovery and liveliness 358 detection for the interconnecting links are independent of the BGP 359 protocol. the scope of this document. For example, liveliness [nits]: unfinished sentence: the scope of this document. Removed. 470 5.2. Extensions to BGP-LS 472 [RFC7752] describes a mechanism by which link-state and TE 473 information can be collected from IGPs and shared with external 474 components using the BGP protocol. It describes both the definition 475 of the BGP-LS-SPF NLRI that advertise links, nodes, and prefixes 476 comprising IGP link-state information and the definition of a BGP 477 path attribute (BGP-LS attribute) that carries link, node, and prefix [Major]: line 475: should be "BGP-LS NLRI" Good catch – fixed. 556 If the SPF Status TLV is received and the corresponding Node NLRI has 557 not been received, then the SPF Status TLV is ignored and not used in 558 SPF computation but is still announced to other BGP speakers. An 559 implementation MAY log an error for further analysis. If a BGP 560 speaker received the Node NLRI but the SPF Status TLV is not 561 received, then any previously received information is considered as 562 implicitly withdrawn and the update is propagated to other BGP 563 speakers. A BGP speaker receiving a BGP Update containing a SPF 564 Status TLV in the BGP-LS attribute [RFC7752] with a value that is 565 outside the range of defined values SHOULD be processed and announced 566 to other BGP speakers. However, a BGP speaker MUST not use the 567 Status TLV in its SPF computation. An implementation MAY log this 568 condition for further analysis. [nits]: s/MUST not/MUST NOT [minor]: s/BGP speaker/BGP SPF speaker There are multi places in the draft using "BGP speaker" instead of "BGP SPF speaker", please go over and fix when applicable. For example: 1408 excessive SPF calculations. When a BGP speaker detects that its section 7.1 Used “BGP SPF Speaker” consistently and fixed several “MUST not” instances. 864 When a BGP SPF speaker completely loses its sequence number state, 865 i.e., due to a cold start, or in the unlikely possibility that that [nits]: extra "that". Removed. 943 o Local Route Information Base (LOC-RIB) - This routing table 944 contains reachability information (i.e., next hops) for all 945 prefixes (both IPv4 and IPv6) as well as BGP-LS-SPF node 946 reachability. Implementations may choose to implement this with 947 separate RIBs for each address family and/or Prefix versus Node 948 reachability. It is synonymous with the Loc-RIB specified in 949 [RFC4271]. [nits]: s/Loc-RIB/LOC-RIB In this case, RFC 4271 uses “Loc-RIB”. 1017 * If the Current-Prefix's corresponding prefix is in the LOC-RIB 1018 and the cost is less than the current route's metric, the [major]: I think this meant to be "more than the current route's metric" Clarified this so that there is no ambiguity as to which metric is referenced. 1134 operate today (i.e., "Ships-in-the-Night" mode). There is no 1135 implicit route redistribution between the BGP address families. [major]: what about redistribution from other protocols, say OSPF? This has typically been out of scope in routing protocol documents – although I just saw a new draft dealing with BGP redistribution. In any case, I think this topic would warrant further discussion in a different draft. 1167 prior to withdrawal. If the link becomes available in that period, 1168 the originator of the BGP-LS-SPF LINK NLRI SHOULD advertise a more 1169 recent version of the BGP-LS-SPF Link NLRI without the SPF Status TLV 1170 in the BGP-LS Link Attributes. [major]: "without SPF Status TLV", this is related with the second “Major issues” above. Since all the SPF Status conditions indicate unreachability or a degraded state, this is correct. 1263 A BGP-LS-SPF Speaker MUST perform the following syntactic validation 1264 of the BGP-LS-SPF NLRI to determine if it is malformed. [minor]: there are a few places in the draft using "BGP-LS-SPF Speaker|speaker", may change to "BGP SPF speaker"? Yup – fixed all these. 1425 Within a BGP SPF Routing Domain, the IGP metrics for all advertised 1426 links SHOULD be configured or defaulted consistently. [major]: in section 5.2.2, it says "One possible default for metric would be to give each interface a cost of 1 making it effectively a hop count.". Why not define a default value so all implementations will be consistent? We discussed and don’t want to add a default as different deployments could have totally different requirements. Also, other IGPs don’t have default metrics (at least, the link-state ones). Thanks, Acee
- [RTG-DIR] Rtgdir Last Call review of draft-ietf-l… Yingzhen Qu
- Re: [RTG-DIR] Rtgdir Last Call review of draft-ie… Acee Lindem (acee)
- Re: [RTG-DIR] Rtgdir Last Call review of draft-ie… Yingzhen Qu
- Re: [RTG-DIR] Rtgdir Last Call review of draft-ie… Acee Lindem (acee)
- Re: [RTG-DIR] Rtgdir Last Call review of draft-ie… Yingzhen Qu
- Re: [RTG-DIR] Rtgdir Last Call review of draft-ie… Acee Lindem (acee)