Re: [Idr] Comments on draft-li-idr-flowspec-srv6-05
Huaimo Chen <huaimo.chen@futurewei.com> Fri, 23 July 2021 02:59 UTC
Return-Path: <huaimo.chen@futurewei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CEB3A1913; Thu, 22 Jul 2021 19:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 aeB2N-QJo4kx; Thu, 22 Jul 2021 19:58:58 -0700 (PDT)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2133.outbound.protection.outlook.com [40.107.94.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A63C3A1917; Thu, 22 Jul 2021 19:58:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UTrScvVshN2jR+o1oAPkcgYBogcDYXyHM6Z4TFaAkmpdTU1o+RJy0NiRoIwUx6PLCFp7PPnwzkyDAC5dk+zm0AyWi1tigAJkBQM3CaBDKa6qWlNBklV2BwQQRNTWOakT2ta9s34vLWZ+vGYvCVzeuPzUDF9glQuG2X4C+J5wuadlIi3Rv2pgjL2VyAC3Nycyxt6EC7VVE27LMIVUctOLTX9tMUnDtzE/wX0HuzHP+yEwTqGAH1vbSrPgWwnV6B3YGT6jde1P7G8kLKIU2tJ5W0PzQye2emNrRv+KrouoJ5jBMZqlc5oWOPz+z/Hw9DWOUuBsx8EzDH2XjkfX0+hBWA==
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=N7k1cYBACVe0fu41nicd6d78U/II6SQIiwa0EZNaRA8=; b=TPzT/mYrkPpCsDe9eiriXzQ2cCqR7G4uV6HYoJmxQt1vSJdshahkSPXmdgECgAiI8huC7ymlF4E+F2Cth0SdPisEkmYbyRgBXI9n8vk+9m1vniPZpSqtY5pkjVU2GHy8bdkDe9lUkhybTM7UI039d/PIt0PvnKC7W5M7NAI2hEOircbgkSG2ovWGwp0r9e77zWGSkUwCiL4hNno5INdQGInhwO3rpZbHu6skKbzZ3lLVyUl3pWHijqjAIzM5MUa1RzI0gYO9VHjUJ1tB13gh0omyV2py27WeHJicVGwRzfcOSvABJ9xwbEMY0ATiXTXUtiMJGYxT7YTOX0/yb3vnKw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N7k1cYBACVe0fu41nicd6d78U/II6SQIiwa0EZNaRA8=; b=r9W5EnLuXbX8WZyV2KQZ7L5dDMlL1wn1HRrK2iOHNxEmmD1LP2xzr9GPbcD8DcDOcQlSSYmEaRteLoSDogTz2YI2KwlppjBQuXkyqAzpXnFGU3mMYYMDYI4TiBeXkPWOQ6MLLhsEkrMvICQMlW6dfi4KhB/CCqjhMriU5vodgOo=
Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by BY5PR13MB4551.namprd13.prod.outlook.com (2603:10b6:a03:1d2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.13; Fri, 23 Jul 2021 02:58:54 +0000
Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::3185:17c0:5f45:cf3]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::3185:17c0:5f45:cf3%4]) with mapi id 15.20.4352.025; Fri, 23 Jul 2021 02:58:54 +0000
From: Huaimo Chen <huaimo.chen@futurewei.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "draft-li-idr-flowspec-srv6@ietf.org" <draft-li-idr-flowspec-srv6@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Comments on draft-li-idr-flowspec-srv6-05
Thread-Index: AQHXdPl7CTxIz2lskEiBZM/fvFYw1qtP8lxm
Date: Fri, 23 Jul 2021 02:58:53 +0000
Message-ID: <BY3PR13MB5044BDA4F88C72A6CC0D8BF0F2E59@BY3PR13MB5044.namprd13.prod.outlook.com>
References: <20210709200111.GA13108@pfrc.org>
In-Reply-To: <20210709200111.GA13108@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4bcbbb21-1fb1-4e19-6264-08d94d85ce95
x-ms-traffictypediagnostic: BY5PR13MB4551:
x-microsoft-antispam-prvs: <BY5PR13MB45519CBC9B8807C88865E47EF2E59@BY5PR13MB4551.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BRe9Oc3uZLkNFi0T4FKKXe3QnFOt6IRIFvwT1gXQ5312z1IUvwrqhQ05SNPRUvg7GGVHpWA0d5g5WR0iv/K1LzZc3oE7igesfXhPH89haflSsmonNgYSXDrQrMjnpAD5ApJ9yF4YPmdcu6IaQ2wgkvAAqAbSrTC2i8UToTa3MJvYsxd5rLDjDIHKKJQsqTbzaHU5cJVuJ+Ui5fKarqSVmRGuGN/CoklPAmF0zgF/KWJOD+tLKyAafE7tYjg8fEIyEUR3zlr0FQLh4Y+XLSJhUqcVi+q3R2HhkVqDApns66Z3psiiT5tOfIF6OvPD+QNMb+N5s23+36+oViL02J4ZHGBJ/IsmCO5XFe/ctwN6Gk3UObj3AKByGnlTjCNI7G63XBipIzpovd4VijOPuH3/4pidN/BW2N4Pw+qyKU6hWQIIcyrgdmSQPJtLgg2ij8beQ4x5YJC8ASqvul29ogIyYcKu5XRwgYgMD/sztBoyBDJH2lrJRYwi5uM39j1g2A/U9u18vkdg8RRNXIyNWNixW7gnZpSXPr+JqyVZjKsslISoi1jbUH1gG4b4BuGkjOlN/pW3PNR4SlFdy0TAbvlU+Nx1h5haBCE75xStAridxyOiX0fjrlDVlh26aJFpv/8TtQC1U77XWn3pWz9Zo67/5K0UrsUVIHNLbzcJJL/2eb28MyrPiunMC6kmA57qFoBnnCeuTeYVBkKqa6JyXYMpVg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(316002)(8936002)(19627405001)(110136005)(7696005)(66446008)(66556008)(2906002)(8676002)(55016002)(38100700002)(66476007)(52536014)(64756008)(83380400001)(186003)(9686003)(53546011)(508600001)(122000001)(66946007)(76116006)(71200400001)(33656002)(44832011)(6506007)(5660300002)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: D+pybSiKqHcBwxYA/liAOES8gyIl3TuF2jdb7dhMHVmuRvZ82WhNJmDzQhHOjb8tlRBgeOFgIaAXqJ36D17fudjtxABpTKHJ4sBKBHWef/OjJklP3nPBJYfJeSgGdg+UWCwAA4GCjVEKHZMgm6Erd2CN+QjYiG28Uo+Hog/lxQm/Pi4IY1l+oSD/AEiGdqGm/kVQkDv8kE+7sfyi3FFWzavarRJSsjeIJpo+cdXDY0feoi15XVdzN8pp6263OvEoLfVcE7Rq9s5KT3T88AjrQPRKwZk9NPH1DlsNlT7FohIigZyxofIvHNmvcBcYi3PP4VUnMlb9OwQ2E1Aw5vJd/3jRssF0odFo9CSsDYN3d60JnVYCf/dqTrpFwN/BwTax2D38U5G/zswCOhBoXyRg5KFi4ecAQtz3tTrmmkjK9JwDnSFUWvguGLx2wWmEhS3Ltd0EfPjY0aIRQyjVcDoO7N2AWJ/3eL21Ur0zBW3adZnXpR119LPH0ht1KiXKXww1tZP3vFcQ/+64mciE32ieQygIoupkFhtdYdJN2iRgD7ijNbBKrgDvyZ7baMF3Vxga/GFxfEmN9zyMm2LeOvaUTCV8fesdoufcRM3+ZDHthmodiMXA9CeCn9Fn+G/O6D1AUpirqk6+4F2ocdsMmxmwg1lH7e/oTKCqlIORRXzTbVs0XTdOV9sdBrTdmG21E9G+7XwpqBsVFz0ff7A35kpRcWiRtIG1CyiIjivb/ndapQF9CcV6OKsOLXj1cWBav0OaWvNJvDeMx6pK6t8s2ABV/F//KCHBfm+gVxGu51i9FkTG6YWcyMfG94vxFiqZ++QKgxbd/FZDhKbqFGMjqF+2XMXtOGaZqaa1kEciJ7bvcs/bkTwmngLeUsA5luKSi2b3sB/reowtFv8C/4zUyVBeXf9IJLe8PEImpVXC8qQtv88NIZWK4mB213VKvH570tfLsXu2PPHxyR4LMDSf6ONKB+n2mE0z08I5xKaS8BG2dL90UUwlBQCjtThBQeZx4XWhCeS4TtoodkERXiLBZQFQRZfClRpsAySUZds3/8/g1bTbKEtsBUC2OLAbHaZFeNmQEA2pU1KsSpIP1Fm8qOKCOMBBSyg/vu78rcFdiwc2f2CAjKSkzhr4YSlVNScXaR5TXPJHGZCrAnroN458+e4xnskev9WmWJnpge3EwvrPTZg3aa0H1Omq0zlytYkJznq7ZVkLGzt7C+tZyjQVw5epd7eyOANmqPhDPrCL5WNnQMOo+qNF3ETGTR1ipqtlw5w33mC0BIS4TqGJsu6le9JNR24LudQSVOwbWwLb9b7QzfnnE/R8J9AM6bll9nT+YCVrDTmmpRn7k3Idp6fJZVamZh12zzMxapr84H8npueiqd6v0S6mbuQtHH0dm7u3nLMc
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB5044BDA4F88C72A6CC0D8BF0F2E59BY3PR13MB5044namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bcbbb21-1fb1-4e19-6264-08d94d85ce95
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2021 02:58:53.9331 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JjT6Zzf4ksDEKZt8xLImCCJJqLWqYIL1ju0lLy5yvwrKhv5Zk6e9E/nLLgFp5BABL69yoW5FQKbo0hyBJzQy2w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB4551
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dE4Wx4shtci8nAubLZkejxmFbUQ>
Subject: Re: [Idr] Comments on draft-li-idr-flowspec-srv6-05
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2021 02:59:03 -0000
Hi Jeff, Thank you very much for your valuable comments. My responses are inline below with [HC]. Best Regards, Huaimo ________________________________ From: Jeffrey Haas <jhaas@pfrc.org> Sent: Friday, July 9, 2021 4:01 PM To: draft-li-idr-flowspec-srv6@ietf.org <draft-li-idr-flowspec-srv6@ietf.org>; idr@ietf.org <idr@ietf.org> Subject: Comments on draft-li-idr-flowspec-srv6-05 Authors, I've been selected as the document shepherd from among the IDR chairs for this draft. Thank you for your patience. A few questions and comments on your draft version -05: - Please note per Working Group consensus, this feature MUST implemented in the Flowspec-v2 work and will not currently be permitted to advance as part of Flowspec-v1. [HC]: Agree. - The document is clearly for IPv6 functionality. It would be good to call out in the document that you would expect to use a Flowspec version that is IPv6 capable. I.e., AFI=2. See the similar IPv6-only components in RFC 8956. [HC]: We will add some text about this. - The functionality in this document is intended to operate on the IPv6 destination address in the IP Header. The presumption is that the new Flowspec match fields are appropriate when the IPv6 destination address is an IPv6 SID. Would it make sense for the match capabilities of the proposed features only be permitted to match when there is an accompanying SR Header? [HC]: Yes. You are right. We will add some text accordingly. - In section 3.1, Whole SID, there are three '0' bits: + The Operator field shares similar encoding to the Numeric Operator field from RFC 8955, section 4.2.1. + One of these bits overlaps the '0' in that Numeric Operator field. Its text reads: "MUST be set to 0 on NLRI encoding and MUST be ignored during decoding" + The other two of the '0' bits overlaps the 'len' encoding of the Numeric Operator field. + The text in your draft for these bits reads: "0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during decoding." What is the motivation to have a SHOULD rather than a similar MUST? [HC]: We will use MUST instead of SHOULD. - In section 3.2, Some bits of SID: + The value field includes a LOC Length, FUNCT Length, and ARGS Length field. Since LFA <= 128, is there any desired match behavior on the bits > LFA when LFA < 128? [HC]: Good catches. If matching behavior on bits > LFA, an error occurs. We will add some text about error handling for this case. + Related to the prior point, when LFA < 128, there's no "field type" that matches on LFA. It's understood that when LFA = 128, the feature in section 3.1 is appropraite. + There is no LOC:ARGS field type. Is that intentional? [HC]: Yes. LOC is not adjacent to ARGS. + Since the "field type" match has options that can specify sets of fields that are adjacent, error handling is interesting: * For LOC match, FUNC Length and ARGS Length are irrelevant. However, since this is part of BGP NLRI, we have need of a canonical format when possible for such filters. * The same also applies for LOC:FUNCT matches, where ARGS Length is irrelevant. [HC]: We will add some text about error handling. + This feature is somewhat complicated and would benefit from encoding and use examples. [HC]: We will add examples. - The behavior of the operator bits has clear symmetry with RFC 8955's Numeric Operator field. I'd suggest pointing to that portion of the document to highlight how the combinations of bits are expected to be encoded to achieve the desired filtering logic. [HC]: We will add a pointer accordingly. - Error handling deserves some additional discussion. The Chairs understand that some of the handling of such behaviors may be deferred to the Flowspec v2 document. However, it's worth highlighting some known possible issues: + For Some bits of SID, the component length will have similar considerations. + The field type bits are not exhaustively specific in the document. What is the error condition when receiving an unknown type? [HC]: We will add some text about error handling for an unknown type. + The LOC Length, FUNCT Length, and ARGS Length fields are one octet in size. What is the expected error handling to be when L+F+A > 128? [HC]: We will add some text about error handling for L+F+A > 128. + For Whole SID, the component length is expected to variable. If the full 128 bits is accounted for as L+F+A, the component length would be 1 octet type followed by multiples of 20 octets for the operator byte plus the 128-bit SID. The minimum component length is 1 octet component type, one octet operator, and ... 3? octets for L + F + A length? [HC]: The minimum component length is 1 + 1 + 3. The text surrounding treating SID as a "Prefix" could generally use attention as part of addressing the error handling. [HC]: We will add some text accordingly. - The IANA Considerations refer to RFC 7153. Since this document defines no Extended Communities, it's not clear why this is present? [HC]: We will remove this reference. -- Jeff
- [Idr] Comments on draft-li-idr-flowspec-srv6-05 Jeffrey Haas
- Re: [Idr] Comments on draft-li-idr-flowspec-srv6-… Huaimo Chen