From nobody Wed Dec 2 12:19:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83F3A147E; Wed, 2 Dec 2020 12:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.59 X-Spam-Level: X-Spam-Status: No, score=-9.59 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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=PSjBEG28; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TIpMVCNX 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 uSZdIzk_ypwM; Wed, 2 Dec 2020 12:19:42 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8073A147B; Wed, 2 Dec 2020 12:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=277537; q=dns/txt; s=iport; t=1606940381; x=1608149981; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6ap8u1tYuD7uepLU8NTIhBMb1I4+iSoYHb+vesBMPxw=; b=PSjBEG28oWPX8rei16hpYax5WpmaFVUEYzMz2FDtqwFweSbvj0ykeERl M96YN+5LOlAMWZHMKojFERa/6tQgStT8T0q9OxevBZuEdt1fhdIRNSjE9 WdK4N2KVtLvL0+SdN/csbpBITjOX1nNbB5rkgq0xSNIS5rqNl0rLgldWp I=; X-IPAS-Result: A0BDBABR9cdffZJdJa2FXbUVh1gIAwIPAwYEFQGNATrBe5Ec IronPort-PHdr: =?us-ascii?q?9a23=3AF4NRMBWVivV14gmJ6IHOLe4FJrHV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,387,1599523200"; d="scan'208,217";a="629091271" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2020 20:18:39 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B2KIduF011919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2020 20:18:39 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 14:18:39 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Dec 2020 14:18:38 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 2 Dec 2020 15:18:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VGFV7Gov6RptBu0uXk5ORwiLrJSrCZX9Wqceu+Ofd8qH38BBTo6N02Ufrjsc+w3iMx2YMceE2nW/VzEygCgfuvIo6AN8VwAyxBa6EvdjDVz2sFYbQvISg9HVWCXedLRXh6IBHzEpLDVGetakztatZL1VjQI9zBGVLWCAyUP2xinznHCV5jx66fwP53COB+YOYyG21SBtRkkLeUz+Me8jSxCrOxTKj+2j/02K7NgqR1Gz8DK/clWImQvqkhgxN5Gb1iEVRcoU4JckZ+/lpy2rb2kS0wSeH7QD0UOkAzU7HePdp2i0zQCYblKTpfOpR+u4/LYZA/O/PGt7UpTmBtdKjA== 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=rel2tSbcB8p8NXXL9iGlu3+edkJGampZHwNBb/thT/8=; b=T6w1XqwWI0kHHZf/LRIRyX0PIpDPSx9oUz0LK2pRl6piUdIOsGXwAGQKO9G/8N+AFXWAHqI6gzqvM0lPM/UOvDYBhdggqlVA5DnxeQimWz7ZOAINUvg5pm2dS2+DAWfh1qCzf4uSzXVU/w3iDQOBT0HRYkzA7yuptZiB5lmAs6ZKA6nWlwpW8axXHvtNnis8ICXUvfGXnBYVsJPvrAWKinzkaBsTTu4u/Nx+r2FZimuJIUYd1uK01PIcrm0KWwdZyLIf0mf0S/eqLmBJn48+JUtHzn5ZWKLnfHosBOVWY4EBmPu507y5yzlHHlMfvAN+njqV2mJKnMrvnEgHbreOBQ== 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=rel2tSbcB8p8NXXL9iGlu3+edkJGampZHwNBb/thT/8=; b=TIpMVCNXtzSM0qvm4VAFTGF6HU2SPWlpX9iN/ES51Y3ljZLWeT2Q0rcmh4xVO+r6566Z19otbFTUkVbhoy+aqlIK6ylYpf0Y2x7Gj5ElWBMWky9ieuCfWBHe5/nVDB2I5z0rR/MCd6nNIra/Pu/UL/s/teidOfVaN15tfcGYfBM= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM5PR11MB1355.namprd11.prod.outlook.com (2603:10b6:3:b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Wed, 2 Dec 2020 20:18:35 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3%5]) with mapi id 15.20.3611.031; Wed, 2 Dec 2020 20:18:35 +0000 From: "Rakesh Gandhi (rgandhi)" To: Greg Mirsky CC: Gyan Mishra , IETF IPPM WG , "James Guichard" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Greg Mirsky Thread-Topic: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWw1FAi8Q0V5FtjUGdBFDHCBkgBqnZreOIgAc3iICAA1dl0Q== Date: Wed, 2 Dec 2020 20:18:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1fed9b28-ad19-4194-ed30-08d896ff725f x-ms-traffictypediagnostic: DM5PR11MB1355: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N9bs9zIWonaSKbIlsAPyCv1P61cjC2Ujic+4yIuy+XYEQN21ppGRqg3sOgFkWWK4qaIaQH4wBGEqZawgZfZ18yXBre+Jofx1WbwlL7NdeYzHqfIkYrdpcs4WLc/yy56DTRPBh8aYcyfd7zPq6RAqv2HZbLaPXUX4CItizytTWGDtE5NTw8zTORSCRNPpVqHfzpYM2DLlgQUyW6xdZ5s8KbAspns6en6bfMDqqSZrSQHvK68ujdyuNSTV3emQg08bixEU/6M1A6oViBOUU/+TcQ8CYkQZfVuCzvdeygR8nFPvrqu/B5I2zENne45x+blSGTN5VKiqKABGuvItTO4VB2EIuQ6XInfrUEiMMf/+0dMo3nSanPRBqgoUbHym2T0yyIqXAG+bD/yg/yeKCKQxuSEFF0n2oOTH29pnaR6Y3WY+X5xRItEJJj2BVrHBeoKw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(366004)(136003)(396003)(478600001)(9686003)(4326008)(7696005)(52536014)(186003)(91956017)(76116006)(166002)(55016002)(53546011)(2906002)(86362001)(8676002)(6916009)(6506007)(8936002)(66476007)(66446008)(966005)(64756008)(33656002)(71200400001)(66556008)(66946007)(30864003)(316002)(26005)(5660300002)(83380400001)(54906003)(579004)(569008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?9B3cANixcWt+r4rpY8X/E9BH5oY4pDsFKH/sUm3pd36namGZCjath8aw?= =?Windows-1252?Q?ucUfWT3/afANxVDFMCJsqCrfgg7iQqy0y+ho8SeMXr3Srv51FSjpkzDI?= =?Windows-1252?Q?A1xtDDRWw5bdhnRJNF34ETZEW5p0cHdIAaQQIVZXA19Q+2bxKX2qGEFD?= =?Windows-1252?Q?rS2yIR5oqSsfzqYNOMdWCrRnAOK1B7titBRirLD05lKcFi5MUKS2s+sW?= =?Windows-1252?Q?bHTPVfiit92lS1oJX2N5+hzbhFJtV0/j7cXCazCUupXunhO2XzAlO9eL?= =?Windows-1252?Q?gpSs/gwkQWjwCZMvXRjgvxFCa1RvpDcjsUFLHxf/roxjW2bdfnOC84zi?= =?Windows-1252?Q?1cjWFsvfoYY2lD4s3HSwBze5AzD4F5LMC+oWC36nR6bwlY1Pk/uQdrPU?= =?Windows-1252?Q?cR/eXspNB4p+9i7fxipZ64KriIWYVuIZVcziLXxizhTdOx2xKokir+uR?= =?Windows-1252?Q?gN8HWyxia1nCY9RyZXsUZ9bP2OCvM4cNlTmgtpeQYzkw/wSOIcYXlX2N?= =?Windows-1252?Q?8An8iu/a7aGZprosi9ebAGpPdVjBtbdCdWga28eFkfrAa0MrDXhVsuYQ?= =?Windows-1252?Q?hBPc/0uSLInMDQ1KlLtbjDgtN3PAS0WUQHKmssxfmGq1SIzi+2ZPSwLM?= =?Windows-1252?Q?Nt3a0uuapZLTV4vqjSoOF6cswLRgK4Et64XP7Cx+QLhmmlE64XcIY1xn?= =?Windows-1252?Q?GJK4GNTFaOsxV4t7c1praGmmL/4x3PLB2lIDY54gThVvh+6eF8KQiw0v?= =?Windows-1252?Q?rLkDm6NdIvftxMqGcDFqHZ8uhmnzgU4J9fFSH2xn5nAhn4T0lJ5lDX/T?= =?Windows-1252?Q?VsqDg5aBeA+v8WJYDQRYfjaHs07tQB0QHMLWea+XvJv9QcZAOKONmPr6?= =?Windows-1252?Q?xlH/kLYYqtN7y/6AaIQOz2VEYVPET476AGQAkBlE/Ej01anSWO62nnbK?= =?Windows-1252?Q?MACUJvso0FE+ez9svouxlDuTS1Zi1KOMEp1CPVhlP81ysNGDEw2vowJ4?= =?Windows-1252?Q?J5bxvVSxYYVOkmY1UlVpavOveOM+X8CLYOcf+Vj3UHLiY8PAUM5qcIhB?= =?Windows-1252?Q?XHOje+FdRb1V9DOIxBIkXKahQ1Fq/RzM+FElTA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fed9b28-ad19-4194-ed30-08d896ff725f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 20:18:35.1132 (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: CBQRyKBgG7COWzZsIarGbNqWv8XwBSsBdvdQh4fb9OulZ8BaujWTtn37tNaCwFOAHIofhq5lX38vLTppZ1gxNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1355 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 20:19:49 -0000 --_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Greg for your further reply and the discussions. Good to know that you do see a need for the extensions for the direct-mode = packet loss detection and the authors are actively working on an alternate = methods using BFD (as you mentioned below). Please see replies inline with =85. From: Greg Mirsky Date: Monday, November 30, 2020 at 11:30 AM To: Rakesh Gandhi (rgandhi) Cc: Gyan Mishra , IETF IPPM WG , Jame= s Guichard , ippm-chairs@ietf.org , spring-chairs@ietf.org , spring@ietf= .org , Greg Mirsky Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh, thank you for the continued discussion. I appreciate your responses. I am s= till not convinced of the value these documents add. Please find my follow-= up notes in-line below under the GIM2>> tag. Regards, Greg On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: Thank you Gyan and Greg for your review comments and discussions. Please se= e inline replies with =85 From: Gyan Mishra > Date: Wednesday, November 25, 2020 at 12:34 PM To: Greg Mirsky > Cc: IETF IPPM WG >, James Guichard >, Rakesh= Gandhi (rgandhi) >, ippm-chair= s@ietf.org >, spring-chairs@ietf.org >, spring@ietf.org > Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh I have been following this thread and to help progress the discussion I wou= ld like to provide some comments in-line Gyan> Thanks Gyan On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes i= n-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Please see replies inline with =85 From: ippm > Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard > Cc: spring@ietf.org >, ippm-chairs@ietf.org >, spring-chairs@ietf.org >,= IETF IPPM WG > Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 = and 5357 and introduce their own terminology for Session-Sender and Session= -Reflector. Also, many terms, e.g., Links, "congruent paths", are used in t= he documents without proper definitions. Other than that both drafts are re= adable and reasonably well-written. We are ok to change Sender to Session-Sender and Reflector to Session-= Reflector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. But I d= on't think that switching the terminology will fix the fundamental issue wi= th the proposal. The operation that is required from the remote entity, whe= ther it is referred to as responder or Session-Reflector, is not defined in= Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, th= e behavior required, as described in the draft, cannot be characterized as = an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new = protocol that, if there's a need in the new PM OAM protocol, must be proper= ly defined. Gyan> I am in complete agreement with Greg about terminology and consist= ency. The problem with inconsistency is that that you are not following we= ll known normative references required to understand the specification lead= ing to confusion and misunderstanding of the specification. The goal shoul= d be clear and concise in terminology and verbiage. Agree. Will address the terms from RFC 5357 in the next revision. There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613, = 5340, 8330, etc.) and term =93Congruent Path=94 (e.g. RFC 5921, 6669) witho= ut defining them. I suspect it is because these are well-known terms. Havin= g said that, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "tw= o figures or objects are congruent if they have the same shape and size, or= if one has the same shape and size as the mirror image of the other", it l= ooks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet o= f an active OAM intended to monitor a flow over the SR tunnel is out-of-ban= d relative to that flow and will not produce any meaningful measurement. Of= course, for the case of the extensions in drafts *-twamp-srpm, direct loss= measurement can be performed, as information collected from node F and pac= kets that collect the counters are not required to be in-band with the moni= tored flow. So, this example, in my opinion, illustrates two of my concerns= : =95 using a congruent path for active performance measurement, e.g.= , TWAMP or TWAMP Light, may produce information that does not reflect the c= ondition experienced by the monitored flow. It seems that the terminology s= hould reflect the fundamental requirement of ensuring that active OAM test = packets are in-band with the monitored flow. =95 there are no technical requirements to justify using in-band te= st packets for direct packet loss measurement. In fact, using the in-band m= ethod for collecting in-profile counters leads to a waste of bandwidth, whi= ch may have a negative impact on services that require low-latency and/or l= ow packet loss. As demonstrated in this example, direct packet loss can be = performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notif= ications based on YANG data model. * Does the document solve a real problem? No, it appears that these drafts define a new performance measurement proto= col for the purpose of combining OWAMP and TWAMP functionality and adding t= he ability to collect counters of "in-profile" packets. I couldn't find suf= ficient technical arguments for using a PM protocol instead of, for example= , extending the existing OAM mechanisms like ICMP. Gyan> This may sound basic but is a very critical subject going down the = same lines of clarity in verbiage so their is no misunderstanding. =93Cong= ruent=94 by definition means shape of an object and if you super imposed tw= o objects on top of each other they fit perfectly and the edges coincide id= entically. The problem with congruent is that it is based on the shape and= that shape could be a mirror image or reflection which may not be exact. = So when referring to a SR-TE path taken this could lead to confusion as to = path taken if it=92s the same path or congruent which is vague as to =93exa= ctly=94 which path is taken where here there is criticality as to the path = being referenced in terms of in-band versus out-of-band. I agree that for = direct in band packet loss measurement can be done via existing OAM mechani= sme via ICMP. Ok, we will find an appropriate term for =93sending packets on the sa= me path as data traffic=94. Extending ICMP for direct-mode loss measurement is outside the scope = of this draft. But good to see the agreement for the direct in band packet = loss measurement to be done (albeit by some other means). GIM2>> I feel that you misunderstand my position in regard to the use case = these four documents try to solve. I don't recall that I've stated that "di= rect in-band packet loss measurement" requires any additional standardizati= on work. The Direct Measurement TLV has solved that for STAMP and draft-iet= f-ippm-stamp-option-tlv is now in the RFC Editor's queue. I cannot find any= valid technical reason to re-open this and measure the direct packet loss = in a slightly different way. I must point out that a claim that using fixed= positions for the direct packet loss optimizes performance does not stand = for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when = the return path is specified in the Return Path TLV and, as I understand it= , in some cases even the second TLV, Node Address TLV, is used. Thus, it is= clear that the proposed new method of direct packet loss measurement does = not offer any significant benefits comparing to the STAMP's Direct Measurem= ent TLV and appears nothing but superfluous. The direct-mode packet loss use-case is typically for the forward dir= ection packet loss. And this does not use the return path TLV. We can clari= fy that in the draft. There is a requirement to measure performance delay as well as synthet= ic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP= protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP for exclusive = direct packet loss measurement. Gyan> Agreed There is definitely a need to do direct-mode loss measurement in IP/S= R networks, as RFC 6374 mechanisms are for MPLS networks. Note that there w= as an attempt to extend BFD for direct-mode loss measurement for this purpo= se using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-0= 3). GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense.= The work and discussion of the proposal continues and the new version will= be published soon. Ok, so you do see a need for the extensions for the direct-mode packe= t loss detection and the authors are actively working on an alternate metho= ds using BFD. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security sec= tion in RFC 6936. We will add reference to this RFC in our Security Section= as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough= vetting of RFC 6936. Yes, will add in the next revision. Hope we can work together on nee= ded text. To summarize my review of these two drafts: * these propose a new protocol, not an update or enhancement of the TWA= MP-like protocol; The probe and response messages defined in [RFC 5357] are used for del= ay measurement and synthetic packet loss. The direct-mode packet loss messa= ges are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Ligh= t. GIM>> I cannot find where RFC 5357 defines "the probe and response messages= ". Could you give a more specific reference or provide the text that, in yo= ur opinion, defines such messages? But I'm more concerned with the directio= n of "extending" non-protocol referred to as "TWAMP Light". As a contributo= r to BBF's TR-390, I'm have learned how different are existing implementati= ons of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interopera= bility 2019 white paper. The status of TWAMP Light is explain= ed in RFC 8545 and I cannot see that it can be used as a foundation of any = standard. Gyan> I don=92t see the probe a d response messages in TWAMP RFC 5357 Agree to use term test-packet from RFC 5357. =B7 several parts of the proposed protocol, e.g., Zero UDP checksum= in IPv6, require detailed security analysis, which is currently absent; Gyan> Agreed Please see previous reply. This is specified in RFC 6936 Security Section. We will add reference = to this RFC in our Security Section as well. This is only specific to the U= DP port locally provisioned in the domain by the operator for TWAMP. GIM>> I've noted above that a simple reference does not sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol. I believe that the proposal = to use zero UDP header checksum requires extensive analysis, using the anal= ysis provided in RFC 6936. Gyan> Completely Agree Please see previous reply. * I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on t= he Informational track even though it is essential to the new protocol as i= t defines its key elements This was to address your previous comment quoted as: =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS. GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If= anyone is interested in standardizing an "extension", I'd expect that they= first define the base specification to which the extension applies. I migh= t have missed the definition of TWAMP Light protocol in the draft. Could yo= u point to the definition, for example, of the Authenticated mode in TWAMP = Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? Gyan> Agreed The Appendix I of RFC 5357 does have information on the Authenticatio= n mode. As specified there, this is based on user configured parameters. =B7 I believe that draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol. The TWAMP Light extension draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The= SPRING draft only defines SR PM procedures. Below, please find my detailed comments, questions on these drafts: * draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and App= endix I in RFC 5357 where the idea of a mode known as TWAMP Light has been = mentioned. The nature of the TWAMP Light and what is required to make it a = standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, = I don't think we can have a draft that proposes extensions to a non-standar= d mechanism (Appendix is for Informational material, as I understand it) on= the Standard track. Gyan> Agreed The procedure for using the RFC 5357 defined messages in TWAMP Light = configuration mode is defined in the corresponding spring drafts. It also d= escribes the provisioning model. GIM2>> If a return path can be provisioned for TWAMP Light, why the same me= thod of controlling a test session cannot be used for STAMP? It is not expected that all STAMP TLV extensions need to be supported= for TWAMP Light using provisioning. This was to address your previous comment quoted as =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS as you mentioned above. BTW, despite only difference of fixed vs. variable length payload in S= TAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it = uses the same approach of provisioning as defined in this draft). Hence, s= ecurity considerations for STAMP and TWAMP Light are not different. Note th= at both STAMP and TWAMP Light have authenticated messages defined for Secur= ity purpose. GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the li= ght, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot f= ind in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode = of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the dis= cussion of "extension" to TWAMP Light. The Authentication information is user-configured as shown in Section= 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: * In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for= control-channel signaling". Also, could you point where the referenced doc= uments describe "provisioning UDP paths"? The Appendix I of RFC 5357 has following text. We can reword and match= the exact text if you prefer. =93This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured=94 GIM>> I think that the text you're proposing is even more confusing. It is = not clear which example the sentence is referring to. Also, what is the bas= is for such an assumption? This is the exact text from RFC 5357 Appendix I. Please go through th= e entire Section in that RFC 5357 to avoid =93out of context=94 discussion. * It appears that the last paragraph in the Introduction describes the = relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could= you please specify which extensions of TWAMP Light have been used in this = draft? We can add the Appendix I as reference in the next revision. Extension= s are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference. GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a nor= mative reference while it is, by its nature, an Informational document. If approved, it is fine to have informational draft/RFC in a normativ= e reference. But RFC 5357 is PS. * In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is rel= ated to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? Do you prefer we remove =93typically=94 from the sentence? GIM>> If that fits into the operational model of the new protocol you're de= fining. * Also in Section 2.3 a Link is mentioned as an element directly connec= ting nodes in the presented reference model. Could you clarify what is a Li= nk? Is it always a physical connection between two systems or a virtual? Both, please see Section 4.1.3. =93Link=94 is well known term used in = many existing RFCs (please see RFC 5613, 5340, 8330). GIM>> Thank you for the references. I couldn't find a definition of an obje= ct "Link" (capitalized) but only "link" (lower case). Hence, since the draf= t consistently uses the capitalized form, I consider it to be something els= e, something different from a link. Ok, we can change Link to link in the next revision to avoid confusio= n. * In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as de= fined in RFC 5357. Could you provide a reference to an IETF standard where = this behavior is defined? Also, how, without creating a state at the Sessio= n-Reflector, to achieve one-way delay and synthetic loss measurement on a b= idirectional SR tunnel? Gyan> Valid point Bidirectional SR tunnel may have an SR state but the statement above = is that no PM (i.e. TWAMP Light) protocol session state is created for it. = We can clarify in the next revision. GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one opt= ion. I am well-familiar with the implementation that uses the stateful mode= . What information stateful PM need to maintain in the state on the ref= lector? Doesn=92t that cause scale issues. We can add in the draft you if t= here is anything specifically needed in the spec. Quoting the text from Appendix I in RFC 5357. We can quote the text a= s is. =93In the case of TWAMP Light, the Session-Reflector does not necessarily h= ave knowledge of the session state. =93 GIM>> By the informational nature of Appendix I, the text is not normative.= I am familiar with the implementation of TWAMP Light which does maintain t= he session state and thus supports one-way packet loss measurement. If you = require that the remote node does not maintain the state, the draft must de= fine that as part of the specifying the behavior of the protocol. Ok, we can discuss what information is to be maintained in that stat= e on the reflector for synthetic packet loss. We can add appropriate text i= f you can help please. GIM2>> I don't see any reason to do that as that already defined in RFC 876= 2 and draft-ietf-ippm-stamp-yang Ok. =B7 Further, in Section 3 the selection of UDP port explained as th= e following: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of = RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector= without excluding any type of measurement. Besides, in TWAMP delay and pac= ket loss are measured in the same test session, using the same flow of TWAM= P-Test packets. Gyan> Agreed Yes, we can use port 862 for both delay and synthetic packet loss =96= they are using the same test packet. There is no change proposed in the dr= aft. GIM2>> Packet delay and synthetic packet loss measurements are already supp= orted in RFC 8762. Are you proposing a new protocol to duplicate the STAMP = functionalities? As mentioned, the extensions defined are for the direct-mode packet l= oss measurement for TWAMP Light and STAMP. The packet loss in existing RFC 5357 refers to synthetic loss as there= is no support for direct-mode loss in RFC 5357. We can change the text to = clarify as =93This UDP port however, is not used for direct-mode loss measu= rement probe messages.=94 GIM>> I've found that there's some misconception in the draft. RFC 8545 re-= assigned UDP port 862 not for "delay measurement probe messages" but for TW= AMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, pac= ket loss, reordering (RFC 4737 defines packet reordering metric), and packe= t duplication measurement. * Then the draft states that The sender uses the UDP port number following the guidelines specified in S= ection 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP = port number of a test session? Gyan> Good point Please see section 6 in [RFC6335]. We can cite the range which will be= the same as used in [RFC8762]. This was also discussed earlier. https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ GIM>> I've looked through Section 6 but I don't find anything specifically = applicable to this draft we're discussing. If the protocol to use UDP port = numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it= seems that stating that explicitly would be the best way. This would be, User Ports and Dynamic Ports ranges, which are defined= in [RFC6335]. Yes, we can add this te= xt. * At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the por= t number? UDP ports are user configured for delay and direct-mode loss PM as des= cribed in Section 3.1. GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measur= ement uses port number different from the one used by a TWAMP-Test packet, = in my opinion, is another indication that this is the definition of a diffe= rent from TWAMP Light PM OAM protocol. If we add a field in the packet then UDP port 862 may be used along w= ith the new field. But it will require extra processing in hardware. It is = better to use a different UDP port for processing efficiency in hardware. * Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP= or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender a= nd Session-Reflector respectively? Probe messages follow the same procedure as defined in RFC 4656 and RF= C 5357. GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draf= t-gandhi-ippm-twamp-srpm? Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm. * for both delay and loss measurements draft requires test packet be tr= ansmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruen= cy in geometry tells us that an object B is congruent to object A if it has= the same shape and size, but is allowed to flip, slide or turn. How a path= can be congruent to another path? Gyan> Agreed. The use of congruent in the context of pathing is con= fusing as the path being addressed may not be reflected accurately by the t= erm congruent. As replied above. There are many existing RFCs that use term Congruent Path (e.g. RFC 59= 21, 6669) without defining them. I suspect it is because it is well-known t= erm. Having said that, we can add a reference for it if it helps reader. GIM>> I cannot assume what was the context of these RFCs. I've sketched a n= etwork diagram above to illustrate that a "congruent path" may well lead to= out-of-band path. Is that the intention of the authors of the draft to use= this protocol out-of-band? As replied above. * The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships betw= een iOAM and draft-gandhi-spring-twamp-srpm? As mentioned in the draft, IOAM is outside the scope. GIM>> Yes, but it appears that references to the two IOAM-related drafts ha= ve some purpose. What is it? How are these drafts related to draft-gandhi-s= pring-twamp-srpm? We can remove them if it is confusing. It is informational text (was = added to address a review comment). * Section 3.1 presents an example of the provisioning model but puts th= e definition of the provisioning model outside the scope. Is there an accom= panying specification that defines the provisioning model that can be used = in multi-vendor deployment? Could that be YANG data model? What is the rela= tionship with draft-ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented? Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<= https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any miss= ing items in a separate draft. We can also add a reference in this draft. GIM>> I think that theremust be some discussion on how the new protocol is = configured. If TWAMP YANG data model can be augmented, I'd expect that bein= g defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything abo= ut the configuration of the protocol. The Yang model extensions are not in the scope of this draft * Section 4.1 states that a new message is introduced to perform the Lo= ss Measurement in this protocol Why the capability of TWAMP to measure the = loss in one-way and two-way is not sufficient? Existing TWAMP messages do not support =93direct-mode=94 loss measurem= ent. We can add =93direct-mode=94 in the text to clarify. GIM>> True, direct loss measurement, in fact, is not active measurement and= thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). = The direct-loss measurement is, by the definition of RFC 7799, passive meas= urement method and fetching counters can be done using numerous methods, e.= g., SNMP, Netconf RFC 7799 does not say using Test-packets to collect counters for dire= ct-mod loss measurement is passive. GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic o= f an active measurement method. Using out-of-band transport, e.g., SNMP que= ries, would be an example of a passive measurement method. Ok, so you answered your own question that the direct-mode packet los= s extension defined is =93active measurement=94 method. * Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain? Gyan> Good question Yes, it is unique in the domain. This is user-defined and is up to the user what UDP port to provision = in a domain. GIM>> So, can user configure a port number from the User Ports range? Or, c= an the same port number be used on the same system for a number of test ses= sions? I find the use of UDP port numbers being underspecified. * Section 4.1.2 of RFC 5357 does not define "the delay measurement mess= age" but refers to the definition of the Session-Sender's test packet in RF= C 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet for= mat to perform both delay and packet loss measurement. Ok, we can update the text in the next revision to indicate exact name= from the RFC 4656. We can also add text to include synthetic packet loss. GIM>> I think that making it explicit would help. Also, that will highlight= what is being introduced by *twamp-srpm drafts is, in fact, a new protocol= to perform synthetic packet loss measurement. No, it does not change anything for synthetic packet loss. * Can you explain how "the DM probe query message contains the payload = format defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet? We can update the text in the next revision to indicate query format n= ame from RFC 5357. GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Coul= d you please quote from any of these documents? It is test-packet, we will use RFC 5357 term. * Can clarify the applicability of RFC 6038 and the symmetrical packet = size? Is it required? Can it be non-symmetrical? Yes. Please see section 4.1.1 and quoted below: =93For symmetrical size query and response messages as defined in [RFC6038]= ,=94 GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the sym= metrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Contro= l protocol and Appendix I in RFC 5357 tells us nothing about that either (i= n part because RFC 6038 came later), I don't see that there's any certainty= in what is the sze of a test packet used in the direct-loss measurement. The test-packets as defined in these existing RFCs are used for dela= y and synthetic packet loss. The direct-mode test-packets are defined in th= is draft. GIM2>> This draft defines only a new packet format for the direct packet lo= ss measurement. For STAMP such a mechanism is clearly superfluous given the= Direct Measurement TLV is already defined. As replied earlier. * Can you clarify the use of the timestamp format, NTP or PTPv2? It is = not clear which is the default, mandatory or optional. This is same as TWAMP. There is no change. GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twam= p-srpm? No change in existing in what is there in RFC 5357 and RFC 8186. * Also, is "hardware support in Segment Routing networks" of the PTPv2 = format required, guaranteed, or something else? Hardware timestamps are recommended for SR use-cases. We can change th= e sentence. GIM>> Perhaps you can propose some text, that would be helpful. Ack. * Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and un= authenticated test sessions using this protocol? Would different authentica= tion methods require using unique destination UDP port numbers? Yes, and Yes, and these are based on provisioning. GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357= . Some Session-Sender can use authenticated and some not. It is part o= f RFC 5357. * Section 4.1.2 by introducing the dedicated Loss measurement packet fo= rmat, effectively modifies the behavior defined in RFC 5357 for Session-Sen= der and Session-Reflector. But the document does not state that. Can you cl= arify whether this specification changes the behavior of a Session-Sender a= nd Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for t= he support of packet loss measurement? The direct-mode loss defines new procedure for sender/reflector to col= lect traffic counters, as opposed to timestamp. The rest is the same as RFC= 4656 and 5357. GIM>> I cannot agree with your statement " The rest is the same as RFC 4656= and 5357" because the sender's direct-loss format does not have Error Esti= mate field, Thus, a reflected packet does not have Sender's Error Estimate,= nor Error Estimate of the reflector. And that, in my opinion, is another c= lear indication that *twamp-srpm drafts define a new protocol, separate fro= m OWAMP/TWAMP. That field is specific to timestamps and would not apply to counters= for direct-mode loss measurement. * And a similar question about the use of the separate UDP port number = for the authenticated of the packet loss measurement. * A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. * What are the addresses of a link? I am assuming this well-known (e.g. RFC 2328). GIM>> I am not familiar with the term "pre-routed". What does it mean? Ensure that packets are routed over the link. * In which scenarios an IPv6 LLA can be used? I am assuming this is well-known (e.g. RFC 5613). GIM>> So, LLA may be used as the source and destination addresses when test= ing an SR tunnel? As mentioned this is for links. * Also, could the use of a routable destination IP address be used a= s a DDOS attack vector? Consider the scenario when an attacker generates SR= -encapsulated packets with the destination IP address other than any of the= SR-terminating nodes. Such a packet will be routed, correct? That does app= ear as a security threat, would you agree? Absolutely do not agree. It is no different than IP routed TWAMP packe= t as defined in [RFC5357]. GIM>> You don't agree that the processing described cannot happen because o= f laws of physics or it wouldn't happen because no one will think of that? = If the latter, I think that that is security threat. There is no new threat like you have mentioned. GIM2>> Hmmm, but how the integrity of TLVs proposed in draft-gandhi-ippm-st= amp-srpm can be protected? These are not protected by HMAC as presented in = figures 3 and 5. The extensions do not change the processing of these existing TLVs de= fined for HMAC. We can add text to indicate this. * Section 4.1.4.2 references Figure 5 that, as I understand it, display= s the format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflecto= r's reflected packet. Which of the two is used for the delay measurement in= the proposed protocol? The probe query packet in the Session-Sender text packet. We can updat= e the name. * Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is se= nt not in-band but out-of-band? Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is = existing behaviour for out-of-band. GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another= new protocol OWAMP Light. And it is not clear what you reference as "this = is existing behavior". Is it to reference behavior of TWAMP test packet? Bu= t the behavior of the TWAMP-Test protocol by itself is neither in-band, nor= out-of-band. It is the encapsulation of the TWAMP test packet that makes i= t either in-band or out-of-band. Right. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. GIM>> So, you believe that proposing to use the method described in RFC 840= 3 for the TWAMP packet is innovation? And what are the benefits of using th= e TWAMP test packet format in the Loopback mode? Please see the draft. * What is the rationale for setting TTL/Hop Limit fields always to 255 = for IPv4, MPLS, and IPv6 (per Section 4.3.1)? This is as defined in Section 4.2 of RFC 5357 (Bullet 4). GIM>> I believe you've misunderstood the text in RFC 5357. This bullet spec= ifies the behavior of a Session-Reflector. It is to try to read TTL value o= f the received TWAMP test packet and copy the value in Sender TTL field of = the reflected packet. If the Session-Reflector cannot access the TTL field,= it MUST write 255 in the Sender TTL field. So, I think that my questions s= till remains. Please see Section 4.2.1 of RFC 5357. * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP por= t provisioned for TWAMP. We will add reference to RFC 6936 in Security Sect= ion. GIM>> I don't think that the reference is sufficient for the Securit Consid= eration. I'd expect some extended discussion on why using zero UDP header c= hecksum is not a security threat for *twamp-srpm protocol. Please see reply above. * Section 8 refers to "liveness monitoring of Links and SR Paths". This= appears as the replication of functionality provided by BFD/S-BFD protocol= s. Is such comparison accurate? If it is, shouldn't the proposal be also re= viewed by the BFD WG? TWAMP probe messages are used today for synthetic packet loss which c= an also be used to detect connection loss (performance metric). The section= simply highlights this obvious metric. GIM>> Can you point to a document that has defined "TWAMP probe messages a= re used today for synthetic packet loss"? Also, which document defines loss= of connectivity as a performance metric? Does *twamp-srpm proposes to use = the new protocol to detect the loss of path continuity? For example Y.1731 has such notion of connection loss. TWAMP is used= widely for synthetic packet loss and is well-known. There is no change in = protocol. This is reported metric. GIM2>> What are packet transmission frequencies authors envisioned for that= mode? A single-digit millisecond? It depends on the implementation. * I found the Security Section of the proposed protocol inadequately te= rse and missing very important threats that this protocol introduces in the= network. Other than referring RFC 6936 for zero checksum what else is missing? = Otherwise it is no different than RFC 8762 (STAMP). GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use = of source IP addresses, as mentioned above, appears to be another security = risk introduced by *-twamp-srpm drafts. There is no mention of Source IP address above. * draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in= this specification is to collect "in-profile" counters. Is that correct? D= o you see as essential for this mode that the query messages are in-band wi= th the flow being profiled? In your opinion, how using an out-of-band metho= d of collecting these counters, e.g., by using ICMP multi-part message exte= nsion per RFC 4884, could affect the accuracy comparing with the method in = this protocol? How the impact changes if extended ICMP messages are in-band= with the profiled flow? Yes, they need to be in-band with the flow, to collect the counter f= rom the right forwarding paths for the flow. Discussion of using ICMP for d= irect-mode loss measurement is outside the scope of this draft. GIM2>> I think that the assumption "they need to be in-band with the flow, = to collect the counter from the right forwarding paths for the flow" is tec= hnically inaccurate. Otherwise, how SNMP queries could work for decades of = networking history? The scope of this draft is orthogonal to the out of band schemes thos= e may exist. Thanks, Rakesh As mentioned earlier, I am not sure extending ICMP to do PM is a good = option here. Both TWAMP and OWAMP are widely deployed today for delay and s= ynthetic loss measurement. GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend R= FC 4656 OWAMP as well? Also, what you see as the connection between using a= ctive measurement methods to measure packet delay and packet loss, on one h= and, and collecting packet counters? The Session-Sender test-packet is defined in OWAMP RFC and not TWAMP = RFC. Other than timestamp and its format vs. counter and its format, the me= ssages and processing are the same. Thanks, Rakesh * Section 3.1 introduces the new field, Sender Control Code. The format= of the packet, as I understand it, is presented in Figure 1. When comparin= g with the format of Session-Sender's test packet defined in RFC 4656 OWAMP= in Section 4.1.2 I've noticed that there are no MBZ fields. Are these intr= oduced by your proposal? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. * Also, it appears that the Sequence Number field in TWAMP Session-Send= er's test packet is absent in Figure 1. Is that intentional? It shows the partial message that has new field. We can update it to s= how the full message to avoid such confusion. Thanks, Rakesh Regards, Greg Thanks Gyan On Thu, Oct 22, 2020 at 5:51 AM James Guichard > wrote: Dear WG: This message starts a 3 week WG adoption call for document https://tools.ie= tf.org/html/draft-gandhi-spring-twamp-srpm-11 ending November 12th 2020. Pl= ease note that this document has several changes from v-10 that were reques= ted by the SPRING and IPPM chairs. For this reason, the chairs have extende= d the adoption call for an additional week to allow the WG enough time to r= eview these changes before deciding on WG adoption. Some background: Several review comments were received previously for document https://tools= .ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chair= s considered those comments, and upon review of this version of the documen= t, determined the following: * The SPRING document should describe only the procedures relevant to S= PRING with pointers to non-SPRING document/s that define any extensions. Se= veral extensions including Control Code Field Extension for TWAMP Light Mes= sages, Loss Measurement Query Message Extensions, and Loss Measurement Resp= onse Message Extensions were included in https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-10 and should be removed from the SPRING document. * The TWAMP extensions included in https://tools.ietf.org/html/draft-ga= ndhi-spring-twamp-srpm-10 should be described in a new document published i= n the IPPM WG. These conclusions were discussed with the authors of https://tools.ietf.or= g/html/draft-gandhi-spring-twamp-srpm-10 the result of which is the publica= tion of the following two documents: * https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The su= bject of this WG adoption call. * https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This doc= ument will be progressed (if determined by the WG) within the IPPM WG. After review of the SPRING document please indicate support (or not) for WG= adoption to the mailing list. Please also provide comments/reasons for tha= t support (or lack thereof) as silence will not be considered as consent. Finally, the chairs would like to thank the authors for their efforts in th= is matter. Thanks! Jim, Bruno, & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank you Greg for you= r further reply and the discussions.

Good to know that y= ou do see a need for the extensions for the direct-mode packet loss detecti= on and the authors are actively working on an alternate methods using BFD (= as you mentioned below).

Please see replies inl= ine with <RG3>=85.

 

 

From: Greg Mirsky <gre= gimirsky@gmail.com>
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm= @ietf.org>, James Guichard <james.n.guichard@futurewei.com>, ippm-= chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org <sp= ring-chairs@ietf.org>, spring@ietf.org <spring@ietf.org>, Greg Mirsky <gregory.mirsky@ztetx.com>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-twamp-srpm-11

Hi Rakesh,

thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line below under the GIM2>> t= ag.

 

Regards,

Greg

 

 

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Gyan and Greg for your rev= iew comments and discussions. Please see inline replies with <RG2>=85=

From: Gyan Mishra <hayabusagsm@gmail.c= om>
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

 Hi Rakesh 

I have been following this thread and to help progress the discuss= ion I would like to provide some comments in-line Gyan> =

Thanks

Gyan

On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.com> wrot= e:

Hi Rakesh,

thank you for the response to my comments. Please find my fol= low-up notes in-lined below under the GIM>> tag. 

Regards,

Greg

On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

Please see replies inline with <RG>=85<= /span>

From: ippm <ippm-bounces@ietf.org&= gt;
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,

I've found myself in the situation when two related drafts are in = the WG APs in the SPRING and IPPM WG (with the possibility that expertise f= rom the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a sing= le thread. I hope that would be acceptable and considered by the SPRING WG = as well as IPPM WG.

Usually, the bar for the adoption of a document can be evaluated&n= bsp;by answers to these three questions:

  • Is the document(s) reasonably well-written

I've got surprised that the drafts don't use the terminology from = RFC 4656 and 5357 and introduce their own terminology for Session-Sender an= d Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

<RG> We are ok to change Sender to Se= ssion-Sender and Reflector to Session-Reflector if it helps.

 

GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be pro= perly defined.

   Gyan> I am in complete agreement with Greg about t= erminology and consistency.  The problem with inconsistency is that th= at you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.  The goal should be clear and concise i= n terminology and verbiage.

<RG2> Agree. Will address the = terms from RFC 5357 in the next revision.

<RG> There are many existing RFCs tha= t use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.) and term =93Congrue= nt Path=94 (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                  &nb= sp;    C---------D

                  &nb= sp;  /                 \<= o:p>

            A----B    &nbs= p;              E-----F

                  &nb= sp;  \                  /=

                  &nb= sp;  G------------H

Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of "con= gruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

=B7 &n= bsp;       using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

=B7 &n= bsp;       there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.

  • Does the document solve a real problem?

No, it appears that these drafts define a new performance measurem= ent protocol for the purpose of combining OWAMP and TWAMP functionality and= adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical ar= guments for using a PM protocol instead of, for example, extending the exis= ting OAM mechanisms like ICMP.

 Gyan>  This may sound basic but is a very critical s= ubject going down the same lines of clarity in verbiage so their is no misu= nderstanding.  =93Congruent=94 by definition means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.  The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.  So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=92s the same path or congruent which is vagu= e as to =93exactly=94 which path is taken where here there is criticality a= s to the path being referenced in terms of in-band versus out-of-band.  I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

<RG2> Ok, we will find an appr= opriate term for =93sending packets on the same path as data traffic=94.

<RG2> Extending ICMP for direc= t-mode loss measurement is outside the scope of this draft. But good to see= the agreement for the direct in band packet loss measurement to be done (albeit by some other means).

GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't rec= all that I've stated that "direct in-band packet loss measurement"= ; requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp= -option-tlv is now in the RFC Editor's queue. I cannot find any valid techn= ical reason to re-open this and measure the direct packet loss in a slightl= y different way. I must point out that a claim that using fixed positions for the direct packet loss optimiz= es performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-g= andhi-spring-stamp-srpm) when the return path is specified in the Return Pa= th TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is = clear that the proposed new method of direct packet loss measurement does n= ot offer any significant benefits comparing to the STAMP's Direct Measureme= nt TLV and appears nothing but superfluous.

 

<RG3> The direct= -mode packet loss use-case is typically for the forward direction packet lo= ss. And this does not use the return path TLV. We can clarify that in the d= raft.

<RG> There is a requirement to measur= e performance delay as well as synthetic and direct-mode packet loss in seg= ment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

GIM>> I agree with the requirements you've listed (though the&nb= sp;SPRING WG OAM requirements document has = been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP for exclusi= ve direct packet loss measurement.  

    Gyan> Agreed

<RG2> There is definitely a need to = do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms a= re for MPLS networks. Note that there was an attempt to extend BFD for dire= ct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.

 

<RG3> Ok, so = you do see a need for the extensions for the direct-mode packet loss detect= ion and the authors are actively working on an alternate methods using BFD.   

  • Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly the risk intr= oduced by the protocol on network security, to comprehensively evaluate the= proposed solution.

<RG> About your comment on zer= o checksum, this is described in Security section in RFC 6936. We will add = reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

     Gyan> Agreed 0 UDP MIMA security threats an= d that you need to thorough vetting of RFC 6936.

 <RG2> Yes, will add in t= he next revision. Hope we can work together on needed text.

To summarize my review of these two drafts:

  • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

<RG> The probe and response me= ssages defined in [RFC 5357] are used for delay measurement and synthetic p= acket loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =93extensions=94 = for TWAMP Light.

GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concerned w= ith the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's TR-390, I'm = have learned how different are existing implementations of TWAMP Light. And= that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

  Gyan> I don=92t see the probe a d response messages in T= WAMP RFC 5357 

<RG2> Agree to use term test-p= acket from RFC 5357.

=B7         several parts of the proposed protocol, e.g.= , Zero UDP checksum in IPv6, require detailed security analysis, which is c= urrently absent;

     Gyan> Agreed 

<RG2> Please see previous repl= y.

<RG> This is specified in RFC = 6936 Security Section. We will add reference to this RFC in our Security Se= ction as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

GIM>>  I've noted above that a simple reference does not suffici= ently explains why the use of zero UDP checksum in IPv6 header is not decre= mental, does not create a security risk for the protocol. I believe that th= e proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.=

    Gyan> Completely Agree

 <RG2> Please see previou= s reply.

  • I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
<RG> This was to address your previous comment qu=
oted as:
 =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

   mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

   protocol itself. Since TWAMP Light is not a s= tandard but its idea is

   described in the informational text only, I t= hink that the Informational

  track is more appropriate for this specification.= =94

https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

<RG> Having said that, we are = ok to change to PS.

GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which the= extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you= point to the definition, for example, of the Authenticated mode in TWAMP L= ight in the draft-gandhi-spring-twamp-srpm or RFC 5357? 

     Gyan> Agreed 

<RG2> The Appendix I of RFC 53= 57 does have information on the Authentication mode. As specified there, th= is is based on user configured parameters.

=B7         I believe that draft-gandhi-spring-twam= p-srpm should be anchored at IPPM WG as it does introduce the new PM protoc= ol.

<RG> The TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

 Below, please find my detailed comments, questions on t= hese drafts:

  • draft-gandhi-spring-twamp-srpm

I have several questions about the relationships between this draf= t and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light = has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of RFC 8545 (apologies for the long quote):

   "TWAMP Light" is an idea described in Appen= dix I ("TWAMP Light
   (Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
   control protocol combined with the TWAMP-Test protocol.  = In
   [RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
   TWAMP Light failed to meet the requirements for IETF protocols= (there
   are no specifications for negotiating this form of operation a= nd no
   specifications for mandatory-to-implement security features), = as
   described in Appendix A of this memo.  See also [LarsAD] = and
   [TimDISCUSS].

   Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br>    component of TWAMP, it is considered reasonable for future sys= tems to
   use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
   is specified in this document).  Clearly, the TWAMP Light= idea
   envisions many components and communication capabilities beyon= d
   TWAMP-Test (implementing the security requirements, for exampl= e);
   otherwise, Appendix I of [RFC5357] would be one sentence long<= br>    (equating TWAMP Light with TWAMP-Test only).

 Since we don't have an IETF document that addressed these op= en questions, I don't think we can have a draft that proposes extensions to= a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.

 Gyan> Agreed 

<RG2> The procedure for using = the RFC 5357 defined messages in TWAMP Light configuration mode is defined = in the corresponding spring drafts. It also describes the provisioning model.

GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

 

<RG3> It is not = expected that all STAMP TLV extensions need to be supported for TWAMP Light= using provisioning.

 <RG> This was to address= your previous comment quoted as

 =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

   mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

   protocol itself. Since TWAMP Light is not a s= tandard but its idea is

   described in the informational text only, I t= hink that the Informational

   track is more appropriate for this specificat= ion.=94

https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

<RG> Having said that, we are = ok to change to PS as you mentioned above.

<RG> BTW, despite only differe= nce of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAM= P is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, = and thus the light, simpler, version of TWAMP-Test component of TWAMP proto= col. I cannot find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer not= to refer to RFC 8762 STAMP in the discussion of "extension" to T= WAMP Light.

<RG2> The Authentication infor= mation is user-configured as shown in Section 3.1 of the draft-gandhi-sprin= g-twamp-srpm, and is also described in Appendix I of RFC 5357.

Now a number of more specific questions.

draft-gandhi-spring-twamp-srpm:

  • In the Introduction it is stated that:

  The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provid= es
   simplified mechanisms for active performance measurement in Cu= stomer
   IP networks by provisioning UDP paths and eliminates the need = for
   control-channel signaling.

I can not find where, either Appendix I or TR-390, "elim= inated the need for control-channel signaling". Also, could you point = where the referenced documents describe "provisioning UDP paths"?

<RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.<=
/pre>

 


=93This example eliminates the need=
 for the TWAMP-Control protocol, and


   assumes that the Session-Re=
flector is configured=94

GIM>> I think that the text you're proposing is even more co= nfusing. It is not clear which example the sentence is referring to. Also, = what is the basis for such an assumption? 

<RG2> This is the exact text f= rom RFC 5357 Appendix I. Please go through the entire Section in that RFC 5= 357 to avoid =93out of context=94 discussion.

  • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

   The procedure uses the mechanisms defined in [RFC5357= ]
   (TWAMP Light) and its extensions for Performance Measurement.<= o:p>

I think that the reference must be to Appendix I, not RFC 5357. Al= so, could you please specify which extensions of TWAMP Light have been used= in this draft?

<RG> We can add the Appendix I as ref= erence in the next revision. Extensions are defined in draft-gandhi-ippm-tw= amp-srpm, we can add this reference.

GIM>> The problem, in my view, is that Appendix I of RFC 535= 7 must be a normative reference while it is, by its nature, an Informationa= l document.  

<RG2> If approved, it is fine = to have informational draft/RFC in a normative reference. But RFC 5357 is P= S.

  • In Section 2.3 describing the reference model is noted:

    •    The probe response message is typically sent to the s= ender node R1.

    In which scenarios the reflector acts differently? How such behavi= or is related to the behavior of a TWAMP Session-Reflector, as defined in R= FC 5357?

    <RG> Do you prefer we remove =93typic= ally=94 from the sentence?

GIM>> If that fits into the operational model of the new pro= tocol you're defining. 

  • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

<RG> Both, please see Section = 4.1.3. =93Link=94 is well known term used in many existing RFCs (please see= RFC 5613, 5340, 8330).

GIM>> Thank you for the references. I couldn't find a defini= tion of an object "Link" (capitalized) but only "link" = (lower case). Hence, since the draft consistently uses the capitalized form, I consider it to be something else, something different from a link.=  

<RG2> Ok, we can change Link t= o link in the next revision to avoid confusion.

  • In Section 3 behavior of the reflector described as

   ... no PM state for delay or loss measurement need to= be created on the
   reflector node R5.

That is in contradiction to the behavior of a TWAMP Session-Reflec= tor as defined in RFC 5357. Could you provide a reference to an IETF standa= rd where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?

 Gyan> Valid point 

<RG2> Bidirectional SR tunnel = may have an SR state but the statement above is that no PM (i.e. TWAMP Ligh= t) protocol session state is created for it. We can clarify in the next revision.

GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode. 

 

<RG3> What infor= mation stateful PM need to maintain in the state on the reflector? Doesn=92= t that cause scale issues. We can add in the draft you if there is anything= specifically needed in the spec.

 <RG> Quoting the text fr= om Appendix I in RFC 5357. We can quote the text as is. 

=93In the case of TWAMP Light, the Sessi=
on-Reflector does not necessarily have knowledge of the session state. =93<=
/span>

GIM>> By the informational nature of Appendix I, the text is= not normative. I am familiar with the implementation of TWAMP Light which = does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

 <RG2> Ok, we can discuss= what information is to be maintained in that state on the reflector for sy= nthetic packet loss. We can add appropriate text if you can help please.

GIM2>> I don't see any reason to do that as th= at already defined in RFC 8762 and draft-ietf-ippm-stamp-yang 

 

<RG3> Ok.=  

=B7         Further, in Section 3 the selection of UDP p= ort explained as the following:

   As specified in [RFC8545], the reflector
   supports the destination UDP port 862 for delay measurement pr= obe
   messages by default.  This UDP port however, is not used = for loss
   measurement probe messages.

To the best of my understanding, as one of the contributors and&nb= sp;Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Ses= sion-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.<= /p>

 Gyan> Agreed 

<RG2> Yes, we can use port 862= for both delay and synthetic packet loss =96 they are using the same test = packet. There is no change proposed in the draft.

GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

 

<RG3> As mention= ed, the extensions defined are for the direct-mode packet loss measurement = for TWAMP Light and STAMP.

<RG> The packet loss in existi= ng RFC 5357 refers to synthetic loss as there is no support for direct-mode= loss in RFC 5357. We can change the text to clarify as =93This UDP port however, is not used for direct-mode loss meas= urement probe messages.=94

GIM>> I've found that there's some misconception in the draf= t. RFC 8545 re-assigned UDP port 862 not for "delay measurement probe = messages" but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.

  • Then the draft states that

The sender uses the UDP port number following the guidelines speci= fied in Section 6 in [RFC6335].

Could you point to the guidelines that a user can use when selecti= ng a UDP port number of a test session?

Gyan> Good point  

<RG> Please see section 6 in [RFC6335= ]. We can cite the range which will be the same as used in [RFC8762]. This = was also discussed earlier.

https://mailarchive.ietf.org/arch/msg/i= ppm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

GIM>> I've looked through Section 6 but I don't find anythin= g specifically applicable to this draft we're discussing. If the protocol t= o use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way. 

<RG2> This would be, User Ports and Dynamic Ports=
 ranges, which are defined in [RFC6335=
]. Yes, we can add this text.
  • At the closing of the paragraph, we read that

  The number of UDP ports with PM functionality needs to be m= inimized due
   to limited hardware resources.

Does a UDP port number pose PM functionality? How it is assigned t= o the port number?

<RG> UDP ports are user config= ured for delay and direct-mode loss PM as described in Section 3.1.<= o:p>

GIM>> Can UDP port 862 be used? Also, requiring that the dir= ect-loss measurement uses port number different from the one used by a TWAM= P-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l. 

<RG2> If we add a field in the= packet then UDP port 862 may be used along with the new field. But it will= require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

  • Following the above-quoted text, in Section 3 is noted:

    •    For Performance Measurement, probe query and response= messages are
       sent as following:

    Could you clarify if the listed further procedures deviate from OW= AMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session= -Sender and Session-Reflector respectively?

    <RG> Probe messages follow the same p= rocedure as defined in RFC 4656 and RFC 5357.

GIM>> All messages, i.e., TWAMP-Test packets as well as the = defined in draft-gandhi-ippm-twamp-srpm? 

 <RG2> Yes, unless otherw= ise specified in the draft-gandhi-ippm-twamp-srpm.

  • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

      the probe messages are sent on the
      congruent path of the data traffic by the sender node<= o:p>

It is not clear what "the congruent path" means. The definition o= f congruency in geometry tells us that an object B is congruent t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

       Gyan> Agreed.  The use of congr= uent in the context of pathing is confusing as the path being addressed may= not be reflected accurately by the term congruent.

<RG2> As replied above.=

<RG> There are many existing R= FCs that use term Congruent Path (e.g. RFC 5921, 6669) without defining the= m. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

GIM>> I cannot assume what was the context of these RFCs. I'= ve sketched a network diagram above to illustrate that a "congrue= nt path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

<RG2> As replied above.=

  • The last paragraph in Section 3 refers to work on iOAM:

    •    The In-Situ Operations, Administration, and Maintenan= ce (IOAM)
       mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
       SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
       information such as timestamp in-band as part of the data pack= ets,
       and are outside the scope of this document.

    Is iOAM in the scope of this specification? What are the relations= hips between iOAM and draft-gandhi-spring-twamp-srpm?

    <RG> As mentioned in the draft, IOAM = is outside the scope.

GIM>> Yes, but it appears that references to the two IOAM-re= lated drafts have some purpose. What is it? How are these drafts related to=  draft-gandhi-spring-twamp-srpm? 

<RG2> We can remove them if it= is confusing. It is informational text (was added to address a review comm= ent).

  • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?

<RG> Yes, this can be Yang mod= el. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

GIM>> I think that theremust be some discussion on how = the new protocol is configured. If TWAMP YANG data model can be augmented, = I'd expect that being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything about the configuration of the protocol. = ;

<RG2> The Yang model extension= s are not in the scope of this draft 

  • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

<RG> Existing TWAMP messages d= o not support =93direct-mode=94 loss measurement. We can add =93direct-mode= =94 in the text to clarify.

GIM>> True, direct loss measurement, in fact, is not active = measurement and thus is outside the scope of Two-Way Active Measurement Pro= tocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf 

<RG2> RFC 7799 does not say us= ing Test-packets to collect counters for direct-mod loss measurement is pas= sive.

GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measure= ment method.

 

<RG3> Ok, so you= answered your own question that the direct-mode packet loss extension defi= ned is =93active measurement=94 method.

  • Section 4.1.1 requires that

  The Destination UDP port cannot be used as Source port, sin= ce
   the message does not have any indication to distinguish betwee= n the
   query and response message.

Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

       Gyan> Good question =

<RG2> Yes, it is unique in the= domain.

<RG> This is user-defined and = is up to the user what UDP port to provision in a domain.=

GIM>> So, can user configure a port number from the User Por= ts range? Or, can the same port number be used on the same system for a num= ber of test sessions? I find the use of UDP port numbers being underspecified.

  • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test packet i= n RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet= format to perform both delay and packet loss measurement.

<RG> Ok, we can update the tex= t in the next revision to indicate exact name from the RFC 4656. We can als= o add text to include synthetic packet loss.

GIM>> I think that making it explicit would help. Also, that= will highlight what is being introduced by *twamp-srpm drafts is, in fact,= a new protocol to perform synthetic packet loss measurement. 

 <RG2> No, it does not ch= ange anything for synthetic packet loss.

  • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?

<RG> We can update the text in= the next revision to indicate query format name from RFC 5357.=

GIM>> I cannot find any reference to a query format in RFCs = 4656/5357. Could you please quote from any of these documents?

 <RG2> It is test-packet,= we will use RFC 5357 term.

  • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
<RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
=93For symmetrical size query and respon=
se messages as defined in [RFC6038],=94

GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL= use of the symmetrical test packets. Since *-twamp-srpm proposals do not u= se TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze of a tes= t packet used in the direct-loss measurement. 

 <RG2> The test-packets a= s defined in these existing RFCs are used for delay and synthetic packet lo= ss. The direct-mode test-packets are defined in this draft.

GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.

 

<RG3> As replied= earlier.

  • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

<RG> This is same as TWAMP. Th= ere is no change.

GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the = case for *-twamp-srpm? 

 <RG2> No change in exist= ing in what is there in RFC 5357 and RFC 8186.

  • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

<RG> Hardware timestamps are r= ecommended for SR use-cases. We can change the sentence.<= /p>

GIM>> Perhaps you can propose some text, that would be helpf= ul. 

 <RG2> Ack.

  • Section 4.1.1.1 stated that

   A separate user-configured
   destination UDP port is used for the delay measurement in
   authentication mode due to the different probe message format.=

Can that be interpreted that there could be concurrent authenticat= ed and unauthenticated test sessions using this protocol? Would different a= uthentication methods require using unique destination UDP port numbers?

<RG> Yes, and Yes, and these a= re based on provisioning.

GIM>> But that requirement is far outside the TWAMP, as defi= ned in RFC 5357.

 <RG2> Some Session-Sende= r can use authenticated and some not. It is part of RFC 5357.

  • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

<RG> The direct-mode loss defi= nes new procedure for sender/reflector to collect traffic counters, as oppo= sed to timestamp. The rest is the same as RFC 4656 and 5357.

GIM>> I cannot agree with your statement " The rest is = the same as RFC 4656 and 5357" because the sender's direct-loss format= does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of the re= flector. And that, in my opinion, is another clear indication that *twamp-s= rpm drafts define a new protocol, separate from OWAMP/TWAMP.

 <RG2> That field is spec= ific to timestamps and would not apply to counters for direct-mode loss mea= surement.

  • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
  • A couple of question to the following text in Section 4.1.3:

   The local and remote IP
   addresses of the link are used as Source and Destination Addre= sses.
   They can also be IPv6 link local address as probe messages are= pre-
   routed.

    • What are the addresses of a link?

<RG> I am assuming this well-k= nown (e.g. RFC 2328).

GIM>> I am not familiar with the term "pre-routed"= . What does it mean? 

 <RG2> Ensure that packet= s are routed over the link.

    • In which scenarios an IPv6 LLA can be used?

<RG> I am assuming this is wel= l-known (e.g. RFC 5613).

GIM>> So, LLA may be used as the source and destination addr= esses when testing an SR tunnel? 

 <RG2> As mentioned this = is for links.

    • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree= ?

<RG> Absolutely do not agree. = It is no different than IP routed TWAMP packet as defined in [RFC5357].

GIM>> You don't agree that the processing described cannot h= appen because of laws of physics or it wouldn't happen because no one will = think of that? If the latter, I think that that is security threat.

 <RG2> There is no new th= reat like you have mentioned.

GIM2>> Hmmm, but how the integrity of TLVs pro= posed in draft-gandhi-ippm-stamp-srpm can be protected? These are= not protected by HMAC as presented in figures 3 and 5.   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     

 

<RG3> The extens= ions do not change the processing of these existing TLVs defined for HMAC. = We can add text to indicate this.

  • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the&= nbsp;format of a probe query message. In figure two references to RFC 5357 = are provided - a section that references RFC 4656 OWAMP definition of the S= ession-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is= used for the delay measurement in the proposed protocol?

    • <RG> The probe query packet in= the Session-Sender text packet. We can update the name.<= /p>

    • Section 4.2.1 states that

       In one-way measurement mode, the probe response messa= ge as defined in
       Figure 6 is sent back out-of-band to the sender node ...<= /o:p>

    Could you clarify how the responder controls that the response pac= ket is sent not in-band but out-of-band?

    <RG> Please refer to section 3= .1 in draft-gandhi-ippm-twamp-srpm.  This is existing behaviour for ou= t-of-band.

GIM>> draft-gandhi-ippm-twamp-srpm does not specify tha= t it defines another new protocol OWAMP Light. And it is not clear what you= reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and. 

 <RG2> Right.=

GIM>> So, you believe that proposing to use the method descr= ibed in RFC 8403 for the TWAMP packet is innovation? And what are the benef= its of using the TWAMP test packet format in the Loopback mode?

 <RG2> Please see the dra= ft.

  • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

<RG> This is as defined in Sec= tion 4.2 of RFC 5357 (Bullet 4).

GIM>> I believe you've misunderstood the text in RFC 5357. T= his bullet specifies the behavior of a Session-Reflector. It is to try to r= ead TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

 <RG2> Please see Section= 4.2.1 of RFC 5357.

  • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

<RG> This is described in RFC = 6936. It will be very specific to the UDP port provisioned for TWAMP. We wi= ll add reference to RFC 6936 in Security Section.

GIM>> I don't think that the reference is sufficient for the= Securit Consideration. I'd expect some extended discussion on why usi= ng zero UDP header checksum is not a security threat for *twamp-srpm  protocol.

 <RG2> Please see reply a= bove.

  • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be als= o reviewed by the BFD WG?

<RG> TWAMP  probe message= s are used today for synthetic packet loss which can also be used to detect= connection loss (performance metric). The section simply highlights this obvious metric.

GIM>> Can you point to a document that has defined "TWA= MP  probe messages are used today for synthetic packet loss"? Als= o, which document defines loss of connectivity as a performance metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

 <RG2> For example Y.1731= has such notion of connection loss. TWAMP is used widely for synthetic pac= ket loss and is well-known. There is no change in protocol. This is reported metric.

GIM2>> What are packet transmission frequencie= s authors envisioned for that mode? A single-digit millisecond? <= /o:p>

 

<RG3> It depends= on the implementation.

  • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

<RG> Other than referring RFC = 6936 for zero checksum what else is missing? Otherwise it is no different t= han RFC 8762 (STAMP).

GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm d= rafts. The use of source IP addresses, as mentioned above, appears to be an= other security risk introduced by *-twamp-srpm drafts. 

 <RG2> There is no mentio= n of Source IP address above.

  • draft-gandhi-ippm-twamp-srpm

As I understand it, the motivation for the Loss Measurement mode d= efined in this specification is to collect "in-profile" counters.= Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

 <RG2> Yes, they need to = be in-band with the flow, to collect the counter from the right forwarding = paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.

GIM2>> I think that the assumption "they = need to be in-band with the flow, to collect the counter from the right for= warding paths for the flow" is technically inaccurate. Otherwise, how = SNMP queries could work for decades of networking history?

 

<RG3> The scope = of this draft is orthogonal to the out of band schemes those may exist.

 

Thanks,

Rakesh

 

<RG> As mentioned earlier, I a= m not sure extending ICMP to do PM is a good option here. Both TWAMP and OW= AMP are widely deployed today for delay and synthetic loss measurement.

GIM>> What is the reason mentioning OWAMP? Are drafts *-twam= p-srpm extend RFC 4656 OWAMP as well? Also, what you see as the connection = between using active measurement methods to measure packet delay and packet loss, on one hand, and collecting packet c= ounters?

 

<RG2> The Session-Sender test-= packet is defined in OWAMP RFC and not TWAMP RFC. Other than timestamp and = its format vs. counter and its format, the messages and processing are the same.

 

Thanks,

Rakesh

 

 

  • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP in Se= ction 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?
    • <= /ul>

    <RG> It shows the partial mess= age that has new field. We can update it to show the full message to avoid = such confusion.

    • Also, it appears that the Sequence Number field in TWAMP Session-Sender's t= est packet is absent in Figure 1. Is that intentional?

    <RG> It shows the partial mess= age that has new field. We can update it to show the full message to avoid = such confusion.

    Thanks,

    Rakesh

     

    Regards,

    Greg

     Thanks 

 

          Gyan 

 

On Thu, Oct 22, 2020 at 5:51 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

Dear WG:

 

This message starts a 3 week WG adoption call= for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

 

Some background:  

 

Several review comments were received previou= sly for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:

 

 

These conclusions were discussed with the authors of  https://tools.ietf.org/html/draft-gandhi-s= pring-twamp-srpm-10 the result of which is the publication of the following two documents:

 

 

After review of the SPRING document please indicate support (or no= t) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.=

 

Finally, the chairs would like to thank the a= uthors for their efforts in this matter.

 

Thanks!

 

Jim, Bruno, & Joel

 

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

 

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

--

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD<= /p>

 

--_000_DM6PR11MB31156BE924B8DF1F37E159BEBFF30DM6PR11MB3115namp_-- From nobody Thu Dec 3 09:52:48 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB3F3A0E12; Thu, 3 Dec 2020 09:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 V-UkRHrjViiv; Thu, 3 Dec 2020 09:52:26 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 ACFB63A0DA1; Thu, 3 Dec 2020 09:51:53 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id j205so3987575lfj.6; Thu, 03 Dec 2020 09:51:53 -0800 (PST) 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=uzzt1CuZ4Mk7be/YSAo9fCw4dIwEbK3nkfjUIzdP2os=; b=cQZa1iOLGVFBifMllx01GGV8nddCk7v0suXCOkxoYoPsoata5Jl1pmpd48/X7NiTs5 PoK/1yCnAdLoM2yccPu9pkQVJYWoE/A9jaDhWIkfNbZr/FjFte6njZ+oAEBA8pPerAq/ ugkrCu439TJcz54Eu+odCOg0xTfo1IizhX4AHJVvbbw7NZ9DR6TxfwgfML70FDXE3Vvu ssihG/5vJXWzepneOFMj8FNEspK5ODPBqn98GvAxzL1eNFKhVVpen3vGHtkHohqiSRcv QQqJm+7XgWYBE36KfXVjAmxFKWcBLmtru8Y3s7/xX+bvh6ENkWH5jlHm67oOga9VgWB8 OD0A== 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=uzzt1CuZ4Mk7be/YSAo9fCw4dIwEbK3nkfjUIzdP2os=; b=AG121jelFnCMhi92kYLee94Mx6TlglI2VOA7wAn/O9yZ6BzCNdqkZlU3lSN/O91KCx jpSGBmcE7erKlPHpCQxj5UAzkQudDAg8r2uzJPX7NQRXe8AtaI36tX2eo4njtGQBS3Gs APRT8UNDCn3z9fFDBVwKKMsBqCpLQhGeJwP8BjUavIHJ61DlK7rbFyUjtyVZElpz1fbe wVqfT7/ut0BtI25yL3HJeYfOBy+QknEG9qr4EtXpZLd0kl9A9KnKrZXvAEDp4ABZlGbF k5reGHVA8fD+RKP2jLNmFZBoate58YM5VMEN516rjCIfbDlU0dobMnqgwT7qvHHjbUul WfMg== X-Gm-Message-State: AOAM531aWHwbAQDGBPPulKQsmFguY66cmjd1fFZRMm64HS7R+1gBSakk MXdaFGSXV5GKVql3YM6HnCjYIfBRVmewpe874v8= X-Google-Smtp-Source: ABdhPJw54/mHyGD1o3YaCXXtLZsgBRUeHbgItQjMA+zJcHv96Ir+GKy30Tqd4zGBFN20yxBTdHwLAwuq4bGcrtj3Rj8= X-Received: by 2002:ac2:5190:: with SMTP id u16mr1800314lfi.56.1607017911550; Thu, 03 Dec 2020 09:51:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 3 Dec 2020 09:51:39 -0800 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: Gyan Mishra , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Greg Mirsky Content-Type: multipart/alternative; boundary="000000000000c4089305b59303ef" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:52:46 -0000 --000000000000c4089305b59303ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, thank you for the continued discussion. You can find my follow-up notes in-line below under GIM3>> tag. I felt that one comment is at the root of our different views on what is considered to be a problem that drafts solve. You've said: As mentioned, the extensions defined are for the direct-mode packet loss measurement for TWAMP Light and STAMP. But draft-ietf-ippm-stamp-option-tlv , currently in Submitted to IESG for Publication WG state according to IETF datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in the section: The Direct Measurement TLV enables collection of the number of in- profile packets, i.e., packets that form a specific data flow, that had been transmitted and received by the Session-Sender and Session- Reflector, respectively. The definition of "in-profile packet" is outside the scope of this document and is left to the test operators to determine. Thus I cannot see any technical need for the introduction of yet another way of direct loss measurement in STAMP. As for the case of TWAMP Light, I believe that there's no sufficient evidence that the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historically, all extensions applicable to TWAMP Light have been introduced through extending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 5357= . More notes can be found below. Regards, Greg On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) wrote: > Thank you Greg for your further reply and the discussions. > > *Good to know that you do see a need for the extensions for the > direct-mode packet loss detection and the authors are actively working on > an alternate methods using BFD (as you mentioned below).* > GIM3>> As you've recognized, in draft-mirmin-bfd-extended we build an integrated OAM based on the lightweight Fault Management protocol with optional Performance Monitoring, based on RFC 6374. RFC 6374, in turn, provides a rich set of performance measurement methods, including direct loss measurement. Please see replies inline with =E2=80=A6. > > > > > > *From: *Greg Mirsky > *Date: *Monday, November 30, 2020 at 11:30 AM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Gyan Mishra , IETF IPPM WG , > James Guichard , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > spring@ietf.org , Greg Mirsky > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh, > > thank you for the continued discussion. I appreciate your responses. I am > still not convinced of the value these documents add. Please find my > follow-up notes in-line below under the GIM2>> tag. > > > > Regards, > > Greg > > > > > > On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Gyan and Greg for your review comments and discussions. Please > see inline replies with =E2=80=A6 > > *From: *Gyan Mishra > *Date: *Wednesday, November 25, 2020 at 12:34 PM > *To: *Greg Mirsky > *Cc: *IETF IPPM WG , James Guichard < > james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > I have been following this thread and to help progress the discussion I > would like to provide some comments in-line Gyan> > > Thanks > > Gyan > > On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the response to my comments. Please find my follow-up notes > in-lined below under the GIM>> tag. > > Regards, > > Greg > > On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with =E2=80=A6 > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFC 465= 6 > and 5357 and introduce their own terminology for Session-Sender and > Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are > used in the documents without proper definitions. Other than that both > drafts are readable and reasonably well-written. > > We are ok to change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. But= I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defin= ed > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion= , > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > > Gyan> I am in complete agreement with Greg about terminology and > consistency. The problem with inconsistency is that that you are not > following well known normative references required to understand the > specification leading to confusion and misunderstanding of the > specification. The goal should be clear and concise in terminology and > verbiage. > > Agree. Will address the terms from RFC 5357 in the next revision. > > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, > 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 592= 1, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of > "congruent" as "two figures or objects are congruent if they have the sam= e > shape and size, or if one has the same shape and size as the mirror image > of the other", it looks as the path A-B-G-H-E-F is congruent to that SR > tunnel. But a packet of an active OAM intended to monitor a flow over the > SR tunnel is out-of-band relative to that flow and will not produce any > meaningful measurement. Of course, for the case of the extensions in draf= ts > *-twamp-srpm, direct loss measurement can be performed, as information > collected from node F and packets that collect the counters are not > required to be in-band with the monitored flow. So, this example, in my > opinion, illustrates two of my concerns: > > =C2=B7 using a congruent path for active performance measurement, > e.g., TWAMP or TWAMP Light, may produce information that does not reflect > the condition experienced by the monitored flow. It seems that the > terminology should reflect the fundamental requirement of ensuring that > active OAM test packets are in-band with the monitored flow. > > =C2=B7 there are no technical requirements to justify using in-ba= nd > test packets for direct packet loss measurement. In fact, using the in-ba= nd > method for collecting in-profile counters leads to a waste of bandwidth, > which may have a negative impact on services that require low-latency > and/or low packet loss. As demonstrated in this example, direct packet lo= ss > can be performed using an out-of-band mechanism, e.g., SNMP queries, > Netconf notifications based on YANG data model. > > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality and > adding the ability to collect counters of "in-profile" packets. I couldn'= t > find sufficient technical arguments for using a PM protocol instead of, f= or > example, extending the existing OAM mechanisms like ICMP. > > Gyan> This may sound basic but is a very critical subject going down th= e > same lines of clarity in verbiage so their is no misunderstanding. > =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and i= f you super > imposed two objects on top of each other they fit perfectly and the edges > coincide identically. The problem with congruent is that it is based on > the shape and that shape could be a mirror image or reflection which may > not be exact. So when referring to a SR-TE path taken this could lead to > confusion as to path taken if it=E2=80=99s the same path or congruent whi= ch is > vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality > as to the path being referenced in terms of in-band versus out-of-band. = I > agree that for direct in band packet loss measurement can be done via > existing OAM mechanisme via ICMP. > > Ok, we will find an appropriate term for =E2=80=9Csending packets o= n the > same path as data traffic=E2=80=9D. > > Extending ICMP for direct-mode loss measurement is outside the scop= e > of this draft. But good to see the agreement for the direct in band packe= t > loss measurement to be done (albeit by some other means). > > GIM2>> I feel that you misunderstand my position in regard to the use cas= e > these four documents try to solve. I don't recall that I've stated that > "direct in-band packet loss measurement" requires any additional > standardization work. The Direct Measurement TLV has solved that for STAM= P > and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I > cannot find any valid technical reason to re-open this and measure the > direct packet loss in a slightly different way. I must point out that a > claim that using fixed positions for the direct packet loss optimizes > performance does not stand for cases (Section 4.2.1 and 4.2.2 of > draft-gandhi-spring-stamp-srpm) when the return path is specified in the > Return Path TLV and, as I understand it, in some cases even the second TL= V, > Node Address TLV, is used. Thus, it is clear that the proposed new method > of direct packet loss measurement does not offer any significant benefits > comparing to the STAMP's Direct Measurement TLV and appears nothing but > superfluous. > > > > The direct-mode packet loss use-case is typically for the forward > direction packet loss. And this does not use the return path TLV. We can > clarify that in the draft. > GIM3>> Clarification would be very helpful as your latest note might be interpreted that the proposed mechanisms are not applicable in the case of a bi-directional SR tunnel. > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP for exclusive direct packe= t > loss measurement. > > Gyan> Agreed > > There is definitely a need to do direct-mode loss measurement in > IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that > there was an attempt to extend BFD for direct-mode loss measurement for > this purpose using RFC 6374 loss measurement message (see > draft-mirmin-bfd-extended-03). > > GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended > in the > past tense. The work and discussion of the proposal continues and the new > version will be published soon. > > > > * Ok, so you do see a need for the extensions for the direct-mode > packet loss detection and the authors are actively working on an alternat= e > methods using BFD. * > > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for TWAMP. Other than this, I did not find > any other security related issue in your review below. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > Gyan> Agreed 0 UDP MIMA security threats and that you need to > thorough vetting of RFC 6936. > > Yes, will add in the next revision. Hope we can work together on > needed text. > > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > defines > =E2=80=9Cextensions=E2=80=9D for TWAMP Light. > > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". A= s > a contributor to BBF's TR-390, I'm have learned how different are existin= g > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > . > The status of TWAMP Light is explained in RFC 8545 and I cannot see that = it > can be used as a foundation of any standard. > > Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC = 5357 > > Agree to use term test-packet from RFC 5357. > > =C2=B7 several parts of the proposed protocol, e.g., Zero UDP che= cksum > in IPv6, require detailed security analysis, which is currently absent; > > Gyan> Agreed > > Please see previous reply. > > This is specified in RFC 6936 Security Section. We will add referenc= e > to this RFC in our Security Section as well. This is only specific to the > UDP port locally provisioned in the domain by the operator for TWAMP. > > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > > Gyan> Completely Agree > > Please see previous reply. > > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protoco= l as > it defines its key elements > > This was to address your previous comment quoted as: > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS. > > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. = I > might have missed the definition of TWAMP Light protocol in the draft. Co= uld > you point to the definition, for example, of the Authenticated mode in > TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > Gyan> Agreed > > The Appendix I of RFC 5357 does have information on the > Authentication mode. As specified there, this is based on user configured > parameters. > > =C2=B7 I believe that draft-gandhi-spring-twamp-srpm should be > anchored at IPPM WG as it does introduce the new PM protocol. > > The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to mak= e > it a standard is well-explained in Section 4 of RFC 8545 > (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > Since we don't have an IETF document that addressed these open questions= , > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > Gyan> Agreed > > The procedure for using the RFC 5357 defined messages in TWAMP Ligh= t > configuration mode is defined in the corresponding spring drafts. It also > describes the provisioning model. > > GIM2>> If a return path can be provisioned for TWAMP Light, why the same > method of controlling a test session cannot be used for STAMP? > > > > It is not expected that all STAMP TLV extensions need to be > supported for TWAMP Light using provisioning. > This was to address your previous comment quoted as > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS as you mentioned above. > > BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and = it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cann= ot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mo= de > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > The Authentication information is user-configured as shown in > Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described = in > Appendix I of RFC 5357. > > Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the reference= d > documents describe "provisioning UDP paths"? > > The Appendix I of RFC 5357 has following text. We can reword and mat= ch the exact text if you prefer. > > > > =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol,= and > > assumes that the Session-Reflector is configured=E2=80=9D > > GIM>> I think that the text you're proposing is even more confusing. It i= s > not clear which example the sentence is referring to. Also, what is the > basis for such an assumption? > > This is the exact text from RFC 5357 Appendix I. Please go through > the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. > > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used i= n > this draft? > > We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document= . > > If approved, it is fine to have informational draft/RFC in a > normative reference. But RFC 5357 is PS. > > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the sentenc= e? > > GIM>> If that fits into the operational model of the new protocol you're > defining. > > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify w= hat > is a Link? Is it always a physical connection between two systems or a > virtual? > > Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known= term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since th= e > draft consistently uses the capitalized form, I consider it to be somethi= ng > else, something different from a link. > > Ok, we can change Link to link in the next revision to avoid > confusion. > > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on th= e > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at th= e > Session-Reflector, to achieve one-way delay and synthetic loss measuremen= t > on a bidirectional SR tunnel? > > Gyan> Valid point > > Bidirectional SR tunnel may have an SR state but the statement abov= e > is that no PM (i.e. TWAMP Light) protocol session state is created for it= . > We can clarify in the next revision. > > GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one > option. I am well-familiar with the implementation that uses the stateful > mode. > > > > What information stateful PM need to maintain in the state on the > reflector? Doesn=E2=80=99t that cause scale issues. We can add in the dra= ft you if > there is anything specifically needed in the spec. > GIM3>> RFCs 5357 and 8762 are clear about what information must be maintained by a Session-Reflector. The Session-Reflector must have knowledge of the test session state and count reflected test packets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus the method enables the measurement of the one-way packet loss metric. > Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not neces= sarily have knowledge of the session state. =E2=80=9C > > GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which doe= s > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior = of > the protocol. > > Ok, we can discuss what information is to be maintained in that > state on the reflector for synthetic packet loss. We can add appropriate > text if you can help please. > > GIM2>> I don't see any reason to do that as that already defined in RFC > 8762 and draft-ietf-ippm-stamp-yang > > > > > Ok. > > =C2=B7 Further, in Section 3 the selection of UDP port explained = as > the following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors o= f > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflect= or > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > Gyan> Agreed > > Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 > they are using the same test packet. There is no change proposed in the > draft. > > GIM2>> Packet delay and synthetic packet loss measurements are already > supported in RFC 8762. Are you proposing a new protocol to duplicate the > STAMP functionalities? > > > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as =E2=80=9CThis UDP port however, is not used for direct= -mode loss > measurement probe messages.=E2=80=9D > > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but f= or > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UD= P > port number of a test session? > > Gyan> Good point > > Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > > GIM>> I've looked through Section 6 but I don't find anything specificall= y > applicable to this draft we're discussing. If the protocol to use UDP por= t > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then = it > seems that stating that explicitly would be the best way. > > This would be, User Ports and Dynamic Ports ranges, which are defin= ed in [RFC6335 ]. Yes, we can add this= text. > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition = of > a different from TWAMP Light PM OAM protocol. > > If we add a field in the packet then UDP port 862 may be used along > with the new field. But it will require extra processing in hardware. It = is > better to use a different UDP port for processing efficiency in hardware. > > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > > Yes, unless otherwise specified in the > draft-gandhi-ippm-twamp-srpm. > > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to objec= t > A if it has the same shape and size, but is allowed to flip, slide or tur= n. > How a path can be congruent to another path? > > Gyan> Agreed. The use of congruent in the context of pathing is > confusing as the path being addressed may not be reflected accurately by > the term congruent. > > As replied above. > > There are many existing RFCs that use term Congruent Path (e.g. RFC > 5921, 6669) without defining them. I suspect it is because it is well-kno= wn > term. Having said that, we can add a reference for it if it helps reader. > > GIM>> I cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > > As replied above. > > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > As mentioned in the draft, IOAM is outside the scope. > > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > > We can remove them if it is confusing. It is informational text (wa= s > added to address a review comment). > > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there a= n > accompanying specification that defines the provisioning model that ca= n be > used in multi-vendor deployment? Could that be YANG data model? What i= s the > relationship with draft-ietf-ippm-twamp-yang > ? Would the > TWAMP YANG data model be augmented? > > Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yan= g > and add any > missing items in a separate draft. We can also add a reference in this > draft. > > GIM>> I think that theremust be some discussion on how the new protocol i= s > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anythi= ng > about the configuration of the protocol. > > The Yang model extensions are not in the scope of this draft > > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measu= re > the loss in one-way and two-way is not sufficient? > > Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D= loss > measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clar= ify. > > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numero= us > methods, e.g., SNMP, Netconf > > RFC 7799 does not say using Test-packets to collect counters for > direct-mod loss measurement is passive. > > GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic > of an active measurement method. Using out-of-band transport, e.g., SNMP > queries, would be an example of a passive measurement method. > > > > Ok, so you answered your own question that the direct-mode packet > loss extension defined is =E2=80=9Cactive measurement=E2=80=9D method. > > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > Gyan> Good question > > Yes, it is unique in the domain. > > This is user-defined and is up to the user what UDP port to provisio= n > in a domain. > > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test pac= ket > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a n= ew > protocol to perform synthetic packet loss measurement. > > No, it does not change anything for synthetic packet loss. > > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced sect= ion > of RFC 5357 defines the format of a Session-Reflector's test packet? > > We can update the text in the next revision to indicate query format > name from RFC 5357. > > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > > It is test-packet, we will use RFC 5357 term. > > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > Yes. Please see section 4.1.1 and quoted below: > > =E2=80=9CFor symmetrical size query and response messages as defined in [= RFC6038],=E2=80=9D > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there= 's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > > The test-packets as defined in these existing RFCs are used for > delay and synthetic packet loss. The direct-mode test-packets are defined > in this draft. > > GIM2>> This draft defines only a new packet format for the direct packet > loss measurement. For STAMP such a mechanism is clearly superfluous given > the Direct Measurement TLV is already defined. > > > > As replied earlier. > > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > This is same as TWAMP. There is no change. > > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > > No change in existing in what is there in RFC 5357 and RFC 8186. > > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > > GIM>> Perhaps you can propose some text, that would be helpful. > > Ack. > > > - Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > Yes, and Yes, and these are based on provisioning. > > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > > Some Session-Sender can use authenticated and some not. It is part > of RFC 5357. > > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state = that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 53= 57 > respectively for the support of packet loss measurement? > > The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same a= s > RFC 4656 and 5357. > > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Erro= r > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, i= s > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > > That field is specific to timestamps and would not apply to > counters for direct-mode loss measurement. > > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > I am assuming this well-known (e.g. RFC 2328). > > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > Ensure that packets are routed over the link. > > > - In which scenarios an IPv6 LLA can be used? > > I am assuming this is well-known (e.g. RFC 5613). > > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > > As mentioned this is for links. > > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker genera= tes > SR-encapsulated packets with the destination IP address other than = any of > the SR-terminating nodes. Such a packet will be routed, correct? Th= at does > appear as a security threat, would you agree? > > Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of tha= t? > If the latter, I think that that is security threat. > > There is no new threat like you have mentioned. > > GIM2>> Hmmm, but how the integrity of TLVs proposed > in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected > by HMAC as presented in figures 3 and > 5. > > > > > The extensions do not change the processing of these existing TLVs > defined for HMAC. We can add text to indicate this. > > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references= to > RFC 5357 are provided - a section that references RFC 4656 OWAMP defin= ition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This i= s > existing behaviour for out-of-band. > > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference = as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packe= t > that makes it either in-band or out-of-band. > > Right. > > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403= . > > GIM>> So, you believe that proposing to use the method described in RFC > 8403 for the TWAMP packet is innovation? And what are the benefits of usi= ng > the TWAMP test packet format in the Loopback mode? > > Please see the draft. > > > - What is the rationale for setting TTL/Hop Limit fields always to 255 > for IPv4, MPLS, and IPv6 (per Section 4.3.1)? > > This is as defined in Section 4.2 of RFC 5357 (Bullet 4). > > GIM>> I believe you've misunderstood the text in RFC 5357. This bullet > specifies the behavior of a Session-Reflector. It is to try to read TTL > value of the received TWAMP test packet and copy the value in Sender TTL > field of the reflected packet. If the Session-Reflector cannot access the > TTL field, it MUST write 255 in the Sender TTL field. So, I think that my > questions still remains. > > Please see Section 4.2.1 of RFC 5357. > > > - Section 4.3.3 states that a zero-value UDP checksum may be used in > some scenarios. RFC 8085 allows that but in very specific cases that a= re > documented in detail in Section 3.4.1. Do you believe that the case of= this > protocol checks all the requirements for allowing the use of Zero UDP > checksum as specified in RFC 8085? Also, I believe that allowing the u= se of > Zero UDP checksum in some scenarios, this protocol introduces a securi= ty > threat that must be thoroughly analyzed in the Security Considerations > section. > > This is described in RFC 6936. It will be very specific to the UDP > port provisioned for TWAMP. We will add reference to RFC 6936 in Security > Section. > > GIM>> I don't think that the reference is sufficient for the > Securit Consideration. I'd expect some extended discussion on why using > zero UDP header checksum is not a security threat for *twamp-srpm protoc= ol. > > Please see reply above. > > > - Section 8 refers to "liveness monitoring of Links and SR Paths". > This appears as the replication of functionality provided by BFD/S-BFD > protocols. Is such comparison accurate? If it is, shouldn't the propos= al be > also reviewed by the BFD WG? > > TWAMP probe messages are used today for synthetic packet loss which > can also be used to detect connection loss (performance metric). The > section simply highlights this obvious metric. > > GIM>> Can you point to a document that has defined "TWAMP probe messages > are used today for synthetic packet loss"? Also, which document defines > loss of connectivity as a performance metric? Does *twamp-srpm proposes t= o > use the new protocol to detect the loss of path continuity? > > For example Y.1731 has such notion of connection loss. TWAMP is > used widely for synthetic packet loss and is well-known. There is no chan= ge > in protocol. This is reported metric. > > GIM2>> What are packet transmission frequencies authors envisioned for > that mode? A single-digit millisecond? > > > > It depends on the implementation. > > > - I found the Security Section of the proposed protocol inadequately > terse and missing very important threats that this protocol introduces= in > the network. > > Other than referring RFC 6936 for zero checksum what else is missing= ? > Otherwise it is no different than RFC 8762 (STAMP). > > GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The us= e > of source IP addresses, as mentioned above, appears to be another securit= y > risk introduced by *-twamp-srpm drafts. > > There is no mention of Source IP address above. > > > - draft-gandhi-ippm-twamp-srpm > > As I understand it, the motivation for the Loss Measurement mode defined > in this specification is to collect "in-profile" counters. Is that correc= t? > Do you see as essential for this mode that the query messages are in-band > with the flow being profiled? In your opinion, how using an out-of-band > method of collecting these counters, e.g., by using ICMP multi-part messa= ge > extension per RFC 4884, could affect the accuracy comparing with the meth= od > in this protocol? How the impact changes if extended ICMP messages are > in-band with the profiled flow? > > Yes, they need to be in-band with the flow, to collect the counter > from the right forwarding paths for the flow. Discussion of using ICMP fo= r > direct-mode loss measurement is outside the scope of this draft. > > GIM2>> I think that the assumption "they need to be in-band with the flow= , > to collect the counter from the right forwarding paths for the flow" is > technically inaccurate. Otherwise, how SNMP queries could work for decade= s > of networking history? > > > > The scope of this draft is orthogonal to the out of band schemes > those may exist. > > > > Thanks, > > Rakesh > > > > As mentioned earlier, I am not sure extending ICMP to do PM is a goo= d > option here. Both TWAMP and OWAMP are widely deployed today for delay and > synthetic loss measurement. > > GIM>> What is the reason mentioning OWAMP? Are drafts *-twamp-srpm extend > RFC 4656 OWAMP as well? Also, what you see as the connection between usin= g > active measurement methods to measure packet delay and packet loss, on on= e > hand, and collecting packet counters? > > > > The Session-Sender test-packet is defined in OWAMP RFC and not TWAM= P > RFC. Other than timestamp and its format vs. counter and its format, the > messages and processing are the same. > > > > Thanks, > > Rakesh > > > > > > > - Section 3.1 introduces the new field, Sender Control Code. The > format of the packet, as I understand it, is presented in Figure 1. Wh= en > comparing with the format of Session-Sender's test packet defined in R= FC > 4656 OWAMP in Section 4.1.2 I've noticed that there are no MBZ fields.= Are > these introduced by your proposal? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > - Also, it appears that the Sequence Number field in TWAMP > Session-Sender's test packet is absent in Figure 1. Is that intentiona= l? > > It shows the partial message that has new field. We can update it to > show the full message to avoid such confusion. > > Thanks, > > Rakesh > > > > Regards, > > Greg > > Thanks > > > > Gyan > > > > On Thu, Oct 22, 2020 at 5:51 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > > Dear WG: > > > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 ending > November 12th 2020. Please note that this document has several changes > from v-10 that were requested by the SPRING and IPPM chairs. For this > reason, the chairs have extended the adoption call for an additional week > to allow the WG enough time to review these changes before deciding on WG > adoption. > > > > Some background: > > > > Several review comments were received previously for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10. The SPRING > and IPPM chairs considered those comments, and upon review of this versio= n > of the document, determined the following: > > > > - The SPRING document should describe only the procedures relevant to > SPRING with pointers to non-SPRING document/s that define any extensio= ns. > Several extensions including* Control Code Field Extension for TWAMP > Light Messages*, *Loss Measurement Query Message Extensions*, and *Los= s > Measurement Response Message Extensions *were included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 and > should be removed from the SPRING document. > - The TWAMP extensions included in > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 should > be described in a new document published in the IPPM WG. > > > > These conclusions were discussed with the authors of > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-10 the result > of which is the publication of the following two documents: > > > > - https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11. The > subject of this WG adoption call. > - https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. This > document will be progressed (if determined by the WG) within the IPPM = WG. > > > > After review of the SPRING document please indicate support (or not) for > WG adoption to the mailing list. Please also provide comments/reasons for > that support (or lack thereof) as silence will not be considered as conse= nt. > > > > Finally, the chairs would like to thank the authors for their efforts in > this matter. > > > > Thanks! > > > > Jim, Bruno, & Joel > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike *Silver Spring, MD > > > > --000000000000c4089305b59303ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rakesh,
thank you for the continue= d discussion. You can find my follow-up notes in-line below under GIM3>&= gt; tag. I felt that one comment is at the root of our different views on w= hat is considered to be a problem that drafts solve. You've said:
=
<RG3> As mentioned, the extensions defined are for t= he direct-mode packet loss measurement for TWAMP Light and STAMP.
But draft-ietf-ippm-stamp-option-tlv, currently in= =C2=A0 Submitted to IESG for Publication WG state according to IETF datatra= cker, includes Section 4.5 Direct Measurement TLV. It is noted in the secti= on:
=C2=A0 =C2=A0The Direct Measurement TLV enables collection of the n= umber of in-
=C2=A0 =C2=A0profile packets, i.e., packets that form a spe= cific data flow, that
=C2=A0 =C2=A0had been transmitted and received by = the Session-Sender and Session-
=C2=A0 =C2=A0Reflector, respectively.=C2= =A0 The definition of "in-profile packet" is
=C2=A0 =C2=A0outs= ide the scope of this document and is left to the test operators
=C2=A0 = =C2=A0to determine.
Thus I cannot see any technical need for the = introduction=C2=A0of yet another way of direct loss measurement in STAMP. A= s for the case of TWAMP Light, I believe that there's no sufficient evi= dence that the proposed direct loss-measurement measurement method benefits= existing implementations of TWAMP Light. Also, historically, all extension= s applicable to TWAMP Light have been introduced through extending TWAMP pr= oper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "extend= ing" TWAMP Light presented in the drafts we are discussing is, in my o= pinion, in violation of RFC 5357.

More notes can b= e found below.

Regards,
Greg


On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cisco.com> wro= te:

Thank you Greg= for your further reply and the discussions.

Good to kno= w that you do see a need for the extensions for the direct-mode packet loss= detection and the authors are actively working on an alternate methods usi= ng BFD (as you mentioned below).

GIM3>> As you've recognized, in draft-mirmin-bfd-extended= =C2=A0we build an integrated OAM based on the lightweight Fault Management = protocol with optional Performance Monitoring, based on RFC 6374. RFC 6374,= in turn, provides a rich set of performance measurement methods, including= direct loss measurement.

=

Please see rep= lies inline with <RG3>=E2=80=A6.

=C2=A0<= u>

=C2=A0<= u>

From: Greg Mirsky <gregimirsky@gmail.com= >
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org &l= t;spring-chairs= @ietf.org>, spr= ing@ietf.org <s= pring@ietf.org>, Greg Mirsky <g= regory.mirsky@ztetx.com>
Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

Hi Rakesh,

thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line=C2=A0below under the GIM2>> t= ag.

=C2=A0

Regards,

Greg

=C2=A0

=C2=A0

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Gyan = and Greg for your review comments and discussions. Please see inline replie= s with <RG2>=E2=80=A6

From: Gyan Mishra <hayabusagsm@gmail.com= >
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

=C2=A0Hi Rakesh=C2=A0

I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

Thanks

Gyan

On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Rakesh,

thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=C2=A0<= u>

Regards,

Greg

On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

Please see replies inline with <RG&= gt;=E2=80=A6

From: ippm <ippm-bounces@ietf.org>= ;
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

  • Is the document(s) reasonably well-written

I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

<RG> We are ok to change Sender to Session-Sender and Re= flector to Session-Reflector if it helps.

=C2=A0

GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.

=C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.=C2=A0 The goal should be clear and concise i= n terminology and verbiage.

<RG2> Agr= ee. Will address the terms from RFC 5357 in the next revision.

<RG> There are many existing RFCs that use term =E2=80= =9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongru= ent Path=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.=

  • Does the document solve a real problem?

No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

=C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agr= ee that for direct in band packet loss measurement can be done via existing= OAM mechanisme via ICMP.

<RG2> Ok,= we will find an appropriate term for =E2=80=9Csending packets on the same = path as data traffic=E2=80=9D.

<RG2> Ext= ending ICMP for direct-mode loss measurement is outside the scope of this d= raft. But good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).=

GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't= recall that I've stated that "direct in-band packet loss measurem= ent" requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp= -option-tlv is now in the RFC Editor's queue. I cannot find any valid t= echnical reason to re-open this and measure the direct packet loss in a sli= ghtly different way. I must point out that a claim that using fixed positions for the direct packet loss optimiz= es performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-g= andhi-spring-stamp-srpm) when the return path is specified in the Return Pa= th TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is = clear that the proposed new method of direct packet loss measurement does n= ot offer any significant benefits comparing to the STAMP's Direct Measu= rement TLV and appears nothing but superfluous.

=C2=A0

<RG3> Th= e direct-mode packet loss use-case is typically for the forward direction p= acket loss. And this does not use the return path TLV. We can clarify that = in the draft.

GIM= 3>> Clarification would be very helpful as your latest note might be = interpreted that the proposed mechanisms are not applicable in the case of = a bi-directional SR tunnel.
=

<RG> There is a requirement to measure performance delay= as well as synthetic and direct-mode packet loss in segment-routing networ= ks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

GIM>> I agree with the=C2=A0requirements you've listed (though th= e=C2=A0SPRING WG OAM requirements document=C2=A0= has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to use OWAMP/TWAMP for exc= lusive direct packet loss measurement.=C2=A0=C2=A0

=C2=A0 =C2=A0 Gyan> Agreed

<RG2> There is definitely a n= eed to do direct-mode loss measurement in IP/SR networks, as RFC 6374 mecha= nisms are for MPLS networks. Note that there was an attempt to extend BFD f= or direct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.<= u>

=C2=A0

<RG3>= Ok, so you do see a need for the extensions for the direct-mode packet los= s detection and the authors are actively working on an alternate methods us= ing BFD. =C2=A0=C2=A0=

  • Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

<RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

=C2=A0=C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA secur= ity threats and that you need to thorough vetting of RFC 6936.

=C2=A0<RG2&g= t; Yes, will add in the next revision. Hope we can work together on needed = text.

To summarize my review of=C2=A0these two drafts:<= /u>

  • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

<RG> The = probe and response messages defined in [RFC 5357] are used for delay measur= ement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement messages. As stated, draft-gandhi-= ippm-twamp-srpm defines =E2= =80=9Cextensions=E2=80=9D for TWAMP Light.

GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concern= ed with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's=C2=A0TR-390, = I'm have learned how different are existing implementations of TWAMP Li= ght. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

=C2=A0 Gyan> I don=E2=80=99t see the probe a d re= sponse messages in TWAMP RFC 5357=C2=A0

<RG2> Agr= ee to use term test-packet from RFC 5357.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 several parts of the proposed protocol, e.g., Z= ero UDP checksum in IPv6, require detailed security analysis, which is curr= ently absent;

=C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

<RG2> Ple= ase see previous reply.

<RG> This= is specified in RFC 6936 Security Section. We will add reference to this R= FC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

GIM>>=C2=A0 I've noted above that a simple reference does not suf= ficiently explains why the use of zero UDP checksum in IPv6 header is not d= ecremental, does not create a security risk for the protocol. I believe tha= t the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.

=C2=A0 =C2=A0 Gyan> Completely Agree

=C2=A0<RG2&g= t; Please see previous reply.

  • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
<RG> This was to address your previous comment quoted as=
:
 =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

=C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

=C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

=C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

=C2=A0 track is more appropriate for th= is specification.=E2=80=9D

https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

<RG> Havi= ng said that, we are ok to change to PS.

GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which= the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Coul= d you point to the definition, for example, of the Authenticated mode in TW= AMP Light in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

=C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

<RG2> The= Appendix I of RFC 5357 does have information on the Authentication mode. A= s specified there, this is based on user configured parameters.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 I believe that=C2=A0draft-gandhi-spring-twamp-s= rpm should be anchored at IPPM WG as it does introduce the new PM protocol.=

<RG> The = TWAMP Light extension draft-gandhi-= ippm-twamp-srpm is already in IPPM WG. The SPRING draf= t only defines SR PM procedures.

=C2=A0Below, please find my detailed=C2=A0comments, = questions on these drafts:

  • draft-gandhi-spring-twamp-srpm

I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

=C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
=C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
=C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
=C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
=C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
=C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
=C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
=C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
=C2=A0 =C2=A0[TimDISCUSS].

=C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
=C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
=C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
=C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
=C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
=C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

=C2=A0Since we don't have an IETF document that = addressed these open questions, I don't think we can have a draft that = proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

=C2=A0Gyan> Agreed=C2=A0

<RG2> The= procedure for using the RFC 5357 defined messages in TWAMP Light configura= tion mode is defined in the corresponding spring drafts. It also describes the provisioning model.

GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

=C2=A0

<RG3> It= is not expected that all STAMP TLV extensions need to be supported for TWA= MP Light using provisioning.=C2=A0

=

<= /p>

=C2=A0<RG>= ; This was to address your previous comment quoted as<= /p> 

 =
=E2=80=9C- as I understand, the=
 draft is applicable to TWAMP Light mode,

=C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

=C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

=C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

=C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

<RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

<RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer= not to refer to RFC 8762 STAMP in the discussion of "extension" = to TWAMP Light.

<RG2> The= Authentication information is user-configured as shown in Section 3.1 of t= he draft-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.

Now a number of more specific questions.

draft-gandhi-spring-twamp-srpm:

  • In the Introduction it is stated that:

=C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
=C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
=C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
=C2=A0 =C2=A0control-channel signaling.

I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

<RG> The Appendix I of RFC 5357 has following text. We c=
an reword and match the exact text if you prefer.

=
=C2=A0


=
=E2=80=9CThis example eliminate=
s the need for the TWAMP-Control protocol, and


=C2=A0=C2=A0 assumes that the Ses=
sion-Reflector is configured=E2=80=9D

GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

<RG2> Thi= s is the exact text from RFC 5357 Appendix I. Please go through the entire = Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussi= on.

  • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

=C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
=C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

<RG> We can add the Appendix I as reference in the next = revision. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can ad= d this reference.

GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0=C2=A0

<RG2> If = approved, it is fine to have informational draft/RFC in a normative referen= ce. But RFC 5357 is PS.

  • In Section 2.3 describing the reference model is noted:
    • <= /ul>

    =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

    In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

    <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D= from the sentence?

GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

  • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

<RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.= =C2=A0

<RG2> Ok,= we can change Link to link in the next revision to avoid confusion.=

  • In Section 3 behavior of the reflector described as

=C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
=C2=A0 =C2=A0reflector node R5.

That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

=C2=A0Gyan> Valid point=C2=A0

<RG2> Bid= irectional SR tunnel may have an SR state but the statement above is that n= o PM (i.e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.

GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode.=C2=A0

=C2=A0

<RG3> Wh= at information stateful PM need to maintain in the state on the reflector? = Doesn=E2=80=99t that cause scale issues. We can add in the draft you if the= re is anything specifically needed in the spec.

GIM3>> RFCs 5357 and 8762 are clear ab= out what information must be maintained by a Session-Reflector. The Session= -Reflector must have knowledge of the test session state and count reflecte= d test packets. The value of such a counter must be copied in the Sequence = Number field of the reflected packet. Thus=C2=A0the method enables the meas= urement of the one-way packet loss metric.

=C2=A0<RG>= ; Quoting the text from Appendix I in RFC 5357. We can quote the text as is= .

=E2=80=9CIn the case of TWAMP Lig=
ht, the Session-Reflector does not necessarily have knowledge of the sessio=
n state. =E2=80=9C

GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

=C2=A0<RG2&g= t; Ok, we can discuss what information is to be maintained in that state on= the reflector for synthetic packet loss. We can add appropriate text if you can help please.

GIM2>> I don't see any reason to do that a= s that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang=C2=A0

=C2=A0

<RG3> Ok= .=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Further, in Section 3 the selection of UDP port= explained as the following:

=C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
=C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
=C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
=C2=A0 =C2=A0measurement probe messages.

To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

=C2=A0Gyan> Agreed=C2=A0

<RG2> Yes= , we can use port 862 for both delay and synthetic packet loss =E2=80=93 th= ey are using the same test packet. There is no change proposed in the draft= .

GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

=C2=A0

<RG3> As= mentioned, the extensions defined are for the direct-mode packet loss meas= urement for TWAMP Light and STAMP.

<RG> The = packet loss in existing RFC 5357 refers to synthetic loss as there is no su= pport for direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.=

  • Then the draft states that

The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

Gyan> Good point =C2=A0

<RG> Please see section 6 in [RFC6335]. We can cite the = range which will be the same as used in [RFC8762]. This was also discussed = earlier.

https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

<RG2> This would be, User Ports and Dynamic Ports ranges=
, which are defined in [RFC6335=
]. Yes, we can add this text.
  • At the closing of the paragraph, we read that

=C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
=C2=A0 =C2=A0to limited hardware resources.

Does a UDP port number pose PM functionality? How it= is assigned to the port number?

<RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l.=C2=A0

<RG2> If = we add a field in the packet then UDP port 862 may be used along with the n= ew field. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

  • Following the above-quoted text, in Section 3 is noted:
    • <= /ul>

    =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
    =C2=A0 =C2=A0sent as following:

    Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

    <RG> Probe messages follow the same procedure as defined= in RFC 4656 and RFC 5357.

GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

=C2=A0<RG2&g= t; Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.

  • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

=C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
=C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

=C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

<RG2> As = replied above.

<RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

<RG2> As = replied above.

  • The last paragraph in Section 3 refers to work on iOAM:
    • <= /ul>

    =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
    =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
    =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
    =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
    =C2=A0 =C2=A0and are outside the scope of this document.

    Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

    <RG> As mentioned in the draft, IOAM is outside the scop= e.

GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

<RG2> We = can remove them if it is confusing. It is informational text (was added to = address a review comment).

  • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

<RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.= =C2=A0

<RG2> The= Yang model extensions are not in the scope of this draft=C2=A0

  • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

<RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf=C2=A0<= /u>

<RG2> RFC= 7799 does not say using Test-packets to collect counters for direct-mod lo= ss measurement is passive.

GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measure= ment method.

=C2=A0

<RG3> Ok= , so you answered your own question that the direct-mode packet loss extens= ion defined is =E2=80=9Cactive measurement=E2=80=9D method.

  • Section 4.1.1 requires that

=C2=A0 The Destination UDP port cannot be used as So= urce port, since
=C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
=C2=A0 =C2=A0query and response message.

Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

=C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

<RG2> Yes= , it is unique in the domain.

<RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers being underspecified.

  • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

<RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.=

GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=C2=A0

=C2=A0<RG2&g= t; No, it does not change anything for synthetic packet loss.=

  • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

<RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

=C2=A0<RG2&g= t; It is test-packet, we will use RFC 5357 term.

  • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
<RG> Yes. Please see section 4.1.1 and quoted below:
=E2=80=9CFor symmetrical size que=
ry and response messages as defined in [RFC6038],=E2=80=9D=

GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze = of a test packet used in the direct-loss measurement.=C2=A0

=C2=A0<RG2&g= t; The test-packets as defined in these existing RFCs are used for delay an= d synthetic packet loss. The direct-mode test-packets are defined in this draft.

GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.=

=C2=A0

<RG3> As= replied earlier.

  • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

<RG> This= is same as TWAMP. There is no change.

GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

=C2=A0<RG2&g= t; No change in existing in what is there in RFC 5357 and RFC 8186.<= u>

  • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

<RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

=C2=A0<RG2&g= t; Ack.

  • Section 4.1.1.1 stated that

=C2=A0 =C2=A0A separate user-configured
=C2=A0 =C2=A0destination UDP port is used for the delay measurement in
=C2=A0 =C2=A0authentication mode due to the different probe message format.=

Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

<RG> Yes,= and Yes, and these are based on provisioning.

GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

=C2=A0<RG2&g= t; Some Session-Sender can use authenticated and some not. It is part of RF= C 5357.

  • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

<RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of th= e reflector. And that, in my opinion, is another clear indication that *twa= mp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.<= /u>

=C2=A0<RG2&g= t; That field is specific to timestamps and would not apply to counters for= direct-mode loss measurement.

  • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
  • A couple of question to the following text in Section 4.1.3:<= /li>

=C2=A0 =C2=A0The local and remote IP
=C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
=C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
=C2=A0 =C2=A0routed.

    • What are the addresses of a link?

<RG> I am= assuming this well-known (e.g. RFC 2328).

GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

=C2=A0<RG2&g= t; Ensure that packets are routed over the link.

    • In which scenarios an IPv6 LLA can be used?

<RG> I am= assuming this is well-known (e.g. RFC 5613).

GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

=C2=A0<RG2&g= t; As mentioned this is for links.

    • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

<RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is security threat.

=C2=A0<RG2&g= t; There is no new threat like you have mentioned.

GIM2>> Hmmm, but how the integrity of TLVs pro= posed in=C2=A0draft-gandhi-ippm-stamp-srpm can=C2=A0be protected? These are= not protected by HMAC as presented in figures 3 and 5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

<RG3> Th= e extensions do not change the processing of these existing TLVs defined fo= r HMAC. We can add text to indicate this.

  • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

<RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

  • Section 4.2.1 states that

=C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
=C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

<RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and.=C2=A0

=C2=A0<RG2&g= t; Right.

GIM>> So, you believe that proposing to use th= e method described in RFC 8403 for the TWAMP packet is innovation? And what= are the benefits of using the TWAMP test packet format in the Loopback mode?

=C2=A0<RG2&g= t; Please see the draft.

  • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

<RG> This= is as defined in Section 4.2 of RFC 5357 (Bullet 4).<= /p>

GIM>> I believe you've misunderstood the t= ext in RFC 5357. This bullet specifies the behavior of a Session-Reflector.= It is to try to read TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

=C2=A0<RG2&g= t; Please see Section 4.2.1 of RFC 5357.

  • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

<RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

GIM>> I don't think that the reference is = sufficient for the Securit=C2=A0Consideration. I'd expect some extended= discussion on why using zero UDP header checksum is not a security threat for *twamp-srpm=C2=A0 protocol.

=C2=A0<RG2&g= t; Please see reply above.

  • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

<RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

=C2=A0<RG2&g= t; For example Y.1731 has such notion of connection loss. TWAMP is used wid= ely for synthetic packet loss and is well-known. There is no change in protocol. This is reported metric.

GIM2>> What are packet transmission frequencie= s authors envisioned for that mode? A single-digit millisecond?=C2=A0

=C2=A0

<RG3> It= depends on the implementation.

  • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

<RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

GIM>> I cannot see how RFC 8762 is relevant to= *twamp-srpm drafts. The use of source IP addresses, as mentioned above, ap= pears to be another security risk introduced by *-twamp-srpm drafts.=C2=A0

=C2=A0<RG2&g= t; There is no mention of Source IP address above.

  • draft-gandhi-ippm-twamp-srpm

As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part=C2=A0message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

=C2=A0<RG2&g= t; Yes, they need to be in-band with the flow, to collect the counter from = the right forwarding paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.=

GIM2>> I think that the assumption "they = need to be in-band with the flow, to collect the counter from the right for= warding paths for the flow" is technically inaccurate. Otherwise, how = SNMP queries could work for decades of networking history?

=C2=A0

<RG3> Th= e scope of this draft is orthogonal to the out of band schemes those may ex= ist.

=C2=A0<= u>

Thanks,=

Rakesh<= u>

=C2=A0

<RG> As m= entioned earlier, I am not sure extending ICMP to do PM is a good option he= re. Both TWAMP and OWAMP are widely deployed today for delay and synthetic loss measurement.

GIM>> What is the reason mentioning OWAMP? Are= drafts *-twamp-srpm extend RFC 4656 OWAMP as well? Also, what you see as t= he connection between using active measurement methods to measure packet delay and packet loss, on one hand, and collecting packet c= ounters?

=C2=A0

<RG2> The= Session-Sender test-packet is defined in OWAMP RFC and not TWAMP RFC. Othe= r than timestamp and its format vs. counter and its format, the messages and processing are the same.

=C2=A0

Thanks,<= u>

Rakesh

=C2=A0

=C2=A0

  • Section 3.1 introduces the new field, Sender Control Code. The format of th= e packet, as I understand it, is presented in Figure 1. When comparing with= the format of Session-Sender's test packet defined in RFC 4656 OWAMP i= n Section 4.1.2 I've noticed that there are no MBZ fields. Are these introduced by your proposal?

<RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

  • Also, it appears that the Sequence Number field in TWAMP Session-Sender'= ;s test packet is absent in Figure 1. Is that intentional?

<RG> It s= hows the partial message that has new field. We can update it to show the f= ull message to avoid such confusion.

Thanks,<= u>

Rakesh

=C2=A0

Regards,

Greg

=C2=A0Thanks=C2=A0

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gyan=C2=A0=

=C2=A0

On Thu, Oct 22, 2020 at 5:51 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com" target=3D"_blank">james.n.= guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This message starts a 3 week WG= adoption call for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-11 ending Nove= mber 12th 2020. Please note that this document has several changes from v-10 that were requested by the SPR= ING and IPPM chairs. For this reason, the chairs have extended the adoption= call for an additional week to allow the WG enough time to review these ch= anges before deciding on WG adoption.

=C2=A0

Some background: =C2=A0<= u>

=C2=A0

Several review comments were re= ceived previously for document https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10. The SPRING and IPPM chairs considered those comments, and upon revie= w of this version of the document, determined the following:<= /p>

=C2=A0

=C2=A0

These conclusions were discussed with the authors of= =C2=A0https://tools.ietf.org/html/dr= aft-gandhi-spring-twamp-srpm-10 the result of which is the publication of the following two documents:

=C2=A0

=C2=A0

After review of the SPRING document please indicate = support (or not) for WG adoption to the mailing list. Please also provide comments/reasons for that support = (or lack thereof) as silence will not be considered as consent.

=C2=A0

Finally, the chairs would like = to thank the authors for their efforts in this matter.=

=C2=A0

Thanks!

=C2=A0

Jim, Bruno, & Joel

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

--

=

Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD

=C2=A0

--000000000000c4089305b59303ef-- From nobody Fri Dec 4 22:15:44 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531EF3A0CDA; Fri, 4 Dec 2020 22:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 yI6suHXHupnB; Fri, 4 Dec 2020 22:15:33 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 CBC613A0C97; Fri, 4 Dec 2020 22:15:32 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id t8so5301291pfg.8; Fri, 04 Dec 2020 22:15:32 -0800 (PST) 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=qNMTBUtlj473GnPIKbbbdNt9isAQENx9rJ6k8ECId1I=; b=VTi/PAqfP5FomJWWYim7w4MwyHgo3NUvC2A5xJjPOUA3ZtJF62hmDZ2bvxZJ19EsM0 t2sxFlBoSs+Fp10hh4ultmuyXxygayor8zoGBGc85xM5X+oOQw+A9czWLo3NpHr+RlAh uL4TG26H61L9Ho5cTK1RHToHUXybK1HIkwpadWEISnfwhgTzT0to7iJjEPSzDZq1oy6h imO1c3gLN3Vlk87JT5JSPcIGZPMFbYkc5lh5tb5F52tC4K597DRDdohNdb2lyCu4tOjW /jM4rw4IACAkcTKwTHIT5BhnP7gsnC7RfHwzNpymYFJzGyNhIZxXYylzrjwyQ8YCuIGH mksw== 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=qNMTBUtlj473GnPIKbbbdNt9isAQENx9rJ6k8ECId1I=; b=saiSfCSS/KHDatSB+mo9HFJu9mFAfDCEyDsM9P5y77P7RW6hBcjkT7IzSGbQ2Clnab Y5odSHDj20v9MlOssd33kP6utwQX0CmtKjiibAW3C6yRTFfG4oV/V2jp+UeJJacGj+0F ihQzCcE2ypvkB9S0ZhH2cxTUGcLb/GC7FsPVR4yVyj72KwO2N9aquxcp6wJIjcemLjyD ktL62cj6SC4JEHMotrSQ6xtYsvf4oV0sLbR6C3vK56LShM0lfQf+UPh64yap3YfFfNqd IJtcWQ3EhwEN3X/+HLTDqwd5p3vaRuTMCHVVlu6idqOCuI/mW7/116uRtvCAf9yhDGNI kn/Q== X-Gm-Message-State: AOAM532wCTj5rgfU719G/FQ11wR+z21STeaJxgHaf4iaU++X7XZVwAUa lLMoZmkf7fsyKrMF3upxcc2aYIF0zC2yPL8A8KE= X-Google-Smtp-Source: ABdhPJwi+Fyhrzrl+zHXGlpsys1m3UtoJ/ZBo16DYMjmNbfqs//r5WN8+7BqrqLjT29sEkaJP+gipuv61RaiaHR3BrM= X-Received: by 2002:a65:5ac4:: with SMTP id d4mr1401292pgt.50.1607148931762; Fri, 04 Dec 2020 22:15:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 5 Dec 2020 01:15:20 -0500 Message-ID: To: Greg Mirsky Cc: Greg Mirsky , IETF IPPM WG , James Guichard , "Rakesh Gandhi (rgandhi)" , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002dce6a05b5b185f9" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 06:15:43 -0000 --0000000000002dce6a05b5b185f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh Had a general question. I read through the draft again and a question came to mind as this draft is Standards Track, what new is being introduced other then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane and SRv6 which used the IPv6 data plane. I don=E2=80=99t believe there exists = a Standards track draft procedure for how to use STAMP over IP network or MPLS network as an example. Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there appears to be nothing new introduced such as a new IANA TLV or code point or even a special SID code point for TWAMP, all basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now. What is the new invention here? Sorry but I may have missed something. My thoughts are at most this be a BCP or I am thinking informational draft would be appropriate. Thoughts? Gyan On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for the continued discussion. You can find my follow-up notes > in-line below under GIM3>> tag. I felt that one comment is at the root of > our different views on what is considered to be a problem that drafts > solve. You've said: > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > But draft-ietf-ippm-stamp-option-tlv > , > currently in Submitted to IESG for Publication WG state according to IET= F > datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in > the section: > The Direct Measurement TLV enables collection of the number of in- > profile packets, i.e., packets that form a specific data flow, that > had been transmitted and received by the Session-Sender and Session- > Reflector, respectively. The definition of "in-profile packet" is > outside the scope of this document and is left to the test operators > to determine. > Thus I cannot see any technical need for the introduction of yet another > way of direct loss measurement in STAMP. As for the case of TWAMP Light, = I > believe that there's no sufficient evidence that the proposed direct > loss-measurement measurement method benefits existing implementations of > TWAMP Light. Also, historically, all extensions applicable to TWAMP Light > have been introduced through extending TWAMP proper, i.e., extending > TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presente= d > in the drafts we are discussing is, in my opinion, in violation of RFC 53= 57. > > More notes can be found below. > > Regards, > Greg > > > On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) > wrote: > >> Thank you Greg for your further reply and the discussions. >> >> *Good to know that you do see a need for the extensions for the >> direct-mode packet loss detection and the authors are actively working o= n >> an alternate methods using BFD (as you mentioned below).* >> > GIM3>> As you've recognized, in draft-mirmin-bfd-extended > we > build an integrated OAM based on the lightweight Fault Management protoco= l > with optional Performance Monitoring, based on RFC 6374. RFC 6374, in tur= n, > provides a rich set of performance measurement methods, including direct > loss measurement. > > Please see replies inline with =E2=80=A6. >> >> >> >> >> >> *From: *Greg Mirsky >> *Date: *Monday, November 30, 2020 at 11:30 AM >> *To: *Rakesh Gandhi (rgandhi) >> *Cc: *Gyan Mishra , IETF IPPM WG , >> James Guichard , ippm-chairs@ietf.org < >> ippm-chairs@ietf.org>, spring-chairs@ietf.org , >> spring@ietf.org , Greg Mirsky >> *Subject: *Re: [spring] [ippm] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Hi Rakesh, >> >> thank you for the continued discussion. I appreciate your responses. I a= m >> still not convinced of the value these documents add. Please find my >> follow-up notes in-line below under the GIM2>> tag. >> >> >> >> Regards, >> >> Greg >> >> >> >> >> >> On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com> wrote: >> >> Thank you Gyan and Greg for your review comments and discussions. Please >> see inline replies with =E2=80=A6 >> >> *From: *Gyan Mishra >> *Date: *Wednesday, November 25, 2020 at 12:34 PM >> *To: *Greg Mirsky >> *Cc: *IETF IPPM WG , James Guichard < >> james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com>, ippm-chairs@ietf.org , >> spring-chairs@ietf.org , spring@ietf.org < >> spring@ietf.org> >> *Subject: *Re: [spring] [ippm] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Hi Rakesh >> >> I have been following this thread and to help progress the discussion I >> would like to provide some comments in-line Gyan> >> >> Thanks >> >> Gyan >> >> On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky >> wrote: >> >> Hi Rakesh, >> >> thank you for the response to my comments. Please find my follow-up note= s >> in-lined below under the GIM>> tag. >> >> Regards, >> >> Greg >> >> On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) < >> rgandhi@cisco.com> wrote: >> >> Thank you Greg for taking time for thoroughly reviewing the documents an= d >> providing the comments. >> >> Please see replies inline with =E2=80=A6 >> >> *From: *ippm >> *Date: *Friday, November 6, 2020 at 11:18 AM >> *To: *James Guichard >> *Cc: *spring@ietf.org , ippm-chairs@ietf.org < >> ippm-chairs@ietf.org>, spring-chairs@ietf.org , >> IETF IPPM WG >> *Subject: *Re: [ippm] [spring] WG Adoption Call for >> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >> >> Dear Chairs of the SPRING and IPPM WGs, Authors, et al., >> >> I've found myself in the situation when two related drafts are in the WG >> APs in the SPRING and IPPM WG (with the possibility that expertise from = the >> third WG, BFD WG, might be desirable to review the "liveness monitoring"= ). >> Because these drafts are closely related, I've decided to combine my >> questions and comments in a single thread. I hope that would be acceptab= le >> and considered by the SPRING WG as well as IPPM WG. >> >> Usually, the bar for the adoption of a document can be evaluated by >> answers to these three questions: >> >> - Is the document(s) reasonably well-written >> >> I've got surprised that the drafts don't use the terminology from RFC >> 4656 and 5357 and introduce their own terminology for Session-Sender and >> Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are >> used in the documents without proper definitions. Other than that both >> drafts are readable and reasonably well-written. >> >> We are ok to change Sender to Session-Sender and Reflector to >> Session-Reflector if it helps. >> >> >> >> GIM>> I believe that the consistency in terminology between the core RFC >> and what is intended as its extension is not only helpful to a reader bu= t, >> to the best of my understanding, is required for IETF specifications. Bu= t I >> don't think that switching the terminology will fix the fundamental issu= e >> with the proposal. The operation that is required from the remote entity= , >> whether it is referred to as responder or Session-Reflector, is not defi= ned >> in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinio= n, >> the behavior required, as described in the draft, cannot be characterize= d >> as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completel= y >> new protocol that, if there's a need in the new PM OAM protocol, must be >> properly defined. >> >> Gyan> I am in complete agreement with Greg about terminology and >> consistency. The problem with inconsistency is that that you are not >> following well known normative references required to understand the >> specification leading to confusion and misunderstanding of the >> specification. The goal should be clear and concise in terminology and >> verbiage. >> >> Agree. Will address the terms from RFC 5357 in the next revision. >> >> There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (= e.g. RFC 5613, >> 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 59= 21, 6669) without >> defining them. I suspect it is because these are well-known terms. Havin= g >> said that, we can add a reference for them if it helps. >> >> GIM>> Thank you for listing these RFCs. I think I need to clarify my >> questions. While a reference to any of RFCs you've mentioned, I don't th= ink >> that will address my concern. In reviewed documents, "Link" is capitaliz= ed >> while referenced RFCs used the lower case form for the term "link". Can >> these be used interchangeably? Do they refer to the same network object? >> >> Now I'll try to illustrate my concern with using the term "congruent >> path" in these drafts (using ASCII-art): >> >> C---------D >> >> / \ >> >> A----B E-----F >> >> \ / >> >> G------------H >> >> Consider an SR tunnel from A to F that traverses the network as >> A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of >> "congruent" as "two figures or objects are congruent if they have the sa= me >> shape and size, or if one has the same shape and size as the mirror imag= e >> of the other", it looks as the path A-B-G-H-E-F is congruent to that SR >> tunnel. But a packet of an active OAM intended to monitor a flow over th= e >> SR tunnel is out-of-band relative to that flow and will not produce any >> meaningful measurement. Of course, for the case of the extensions in dra= fts >> *-twamp-srpm, direct loss measurement can be performed, as information >> collected from node F and packets that collect the counters are not >> required to be in-band with the monitored flow. So, this example, in my >> opinion, illustrates two of my concerns: >> >> =C2=B7 using a congruent path for active performance measurement= , >> e.g., TWAMP or TWAMP Light, may produce information that does not reflec= t >> the condition experienced by the monitored flow. It seems that the >> terminology should reflect the fundamental requirement of ensuring that >> active OAM test packets are in-band with the monitored flow. >> >> =C2=B7 there are no technical requirements to justify using in-b= and >> test packets for direct packet loss measurement. In fact, using the in-b= and >> method for collecting in-profile counters leads to a waste of bandwidth, >> which may have a negative impact on services that require low-latency >> and/or low packet loss. As demonstrated in this example, direct packet l= oss >> can be performed using an out-of-band mechanism, e.g., SNMP queries, >> Netconf notifications based on YANG data model. >> >> >> - Does the document solve a real problem? >> >> No, it appears that these drafts define a new performance measurement >> protocol for the purpose of combining OWAMP and TWAMP functionality and >> adding the ability to collect counters of "in-profile" packets. I couldn= 't >> find sufficient technical arguments for using a PM protocol instead of, = for >> example, extending the existing OAM mechanisms like ICMP. >> >> Gyan> This may sound basic but is a very critical subject going down >> the same lines of clarity in verbiage so their is no misunderstanding. >> =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and = if you super >> imposed two objects on top of each other they fit perfectly and the edge= s >> coincide identically. The problem with congruent is that it is based on >> the shape and that shape could be a mirror image or reflection which may >> not be exact. So when referring to a SR-TE path taken this could lead t= o >> confusion as to path taken if it=E2=80=99s the same path or congruent wh= ich is >> vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here the= re is criticality >> as to the path being referenced in terms of in-band versus out-of-band. = I >> agree that for direct in band packet loss measurement can be done via >> existing OAM mechanisme via ICMP. >> >> Ok, we will find an appropriate term for =E2=80=9Csending packets = on the >> same path as data traffic=E2=80=9D. >> >> Extending ICMP for direct-mode loss measurement is outside the >> scope of this draft. But good to see the agreement for the direct in ban= d >> packet loss measurement to be done (albeit by some other means). >> >> GIM2>> I feel that you misunderstand my position in regard to the use >> case these four documents try to solve. I don't recall that I've stated >> that "direct in-band packet loss measurement" requires any additional >> standardization work. The Direct Measurement TLV has solved that for STA= MP >> and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I >> cannot find any valid technical reason to re-open this and measure the >> direct packet loss in a slightly different way. I must point out that a >> claim that using fixed positions for the direct packet loss optimizes >> performance does not stand for cases (Section 4.2.1 and 4.2.2 of >> draft-gandhi-spring-stamp-srpm) when the return path is specified in the >> Return Path TLV and, as I understand it, in some cases even the second T= LV, >> Node Address TLV, is used. Thus, it is clear that the proposed new metho= d >> of direct packet loss measurement does not offer any significant benefit= s >> comparing to the STAMP's Direct Measurement TLV and appears nothing but >> superfluous. >> >> >> >> The direct-mode packet loss use-case is typically for the forward >> direction packet loss. And this does not use the return path TLV. We can >> clarify that in the draft. >> > GIM3>> Clarification would be very helpful as your latest note might be > interpreted that the proposed mechanisms are not applicable in the case o= f > a bi-directional SR tunnel. > >> There is a requirement to measure performance delay as well as >> synthetic and direct-mode packet loss in segment-routing networks. OWAMP >> and TWAMP protocols are widely deployed for performance delay and synthe= tic >> packet loss measurement today. I am not sure extending ICMP for LM is a >> good option here. >> >> GIM>> I agree with the requirements you've listed (though the SPRING WG >> OAM requirements document >> ha= s >> been abandoned and expired 3+ years ago). I believe that there's no >> sufficient technical reason to use OWAMP/TWAMP for exclusive direct pack= et >> loss measurement. >> >> Gyan> Agreed >> >> There is definitely a need to do direct-mode loss measurement in >> IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that >> there was an attempt to extend BFD for direct-mode loss measurement for >> this purpose using RFC 6374 loss measurement message (see >> draft-mirmin-bfd-extended-03). >> >> GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended >> in >> the past tense. The work and discussion of the proposal continues and th= e >> new version will be published soon. >> >> >> >> * Ok, so you do see a need for the extensions for the direct-mode >> packet loss detection and the authors are actively working on an alterna= te >> methods using BFD. * >> >> >> - Is the proposed solution technically viable? >> >> There are too many unaddressed aspects, particularly the risk introduced >> by the protocol on network security, to comprehensively evaluate the >> proposed solution. >> >> About your comment on zero checksum, this is described in Security >> section in RFC 6936. We will add reference to this RFC in our Security >> Section as well. This is only specific to the UDP port locally provision= ed >> in the domain by the operator for TWAMP. Other than this, I did not find >> any other security related issue in your review below. >> >> GIM>> I don't think that a mere reference sufficiently explains why the >> use of zero UDP checksum in IPv6 header is not decremental, does not cre= ate >> a security risk for the protocol. >> >> Gyan> Agreed 0 UDP MIMA security threats and that you need to >> thorough vetting of RFC 6936. >> >> Yes, will add in the next revision. Hope we can work together on >> needed text. >> >> To summarize my review of these two drafts: >> >> - these propose a new protocol, not an update or enhancement of the >> TWAMP-like protocol; >> >> The probe and response messages defined in [RFC 5357] are used for >> delay measurement and synthetic packet loss. The direct-mode packet loss >> messages are defined in draft-gandhi-ippm-twamp-srpm >> that >> match these delay measurement messages. As stated, >> draft-gandhi-ippm-twamp-srpm >> defines >> =E2=80=9Cextensions=E2=80=9D for TWAMP Light. >> >> GIM>> I cannot find where RFC 5357 defines "the probe and response >> messages". Could you give a more specific reference or provide the text >> that, in your opinion, defines such messages? But I'm more concerned wit= h >> the direction of "extending" non-protocol referred to as "TWAMP Light". = As >> a contributor to BBF's TR-390, I'm have learned how different are existi= ng >> implementations of TWAMP Light. And that is also noted in EANTC >> Multi-Vendor Interoperability 2019 white paper >> . >> The status of TWAMP Light is explained in RFC 8545 and I cannot see that= it >> can be used as a foundation of any standard. >> >> Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC= 5357 >> >> Agree to use term test-packet from RFC 5357. >> >> =C2=B7 several parts of the proposed protocol, e.g., Zero UDP >> checksum in IPv6, require detailed security analysis, which is currently >> absent; >> >> Gyan> Agreed >> >> Please see previous reply. >> >> This is specified in RFC 6936 Security Section. We will add >> reference to this RFC in our Security Section as well. This is only >> specific to the UDP port locally provisioned in the domain by the operat= or >> for TWAMP. >> >> GIM>> I've noted above that a simple reference does not sufficiently >> explains why the use of zero UDP checksum in IPv6 header is not >> decremental, does not create a security risk for the protocol. I believe >> that the proposal to use zero UDP header checksum requires extensive >> analysis, using the analysis provided in RFC 6936. >> >> Gyan> Completely Agree >> >> Please see previous reply. >> >> >> - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on >> the Informational track even though it is essential to the new protoc= ol as >> it defines its key elements >> >> This was to address your previous comment quoted as: >> >> =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode= , >> >> mentioned in the informational Appendix I in RFC 5357, not the TWAMP >> >> protocol itself. Since TWAMP Light is not a standard but its idea is >> >> described in the informational text only, I think that the >> Informational >> >> track is more appropriate for this specification.=E2=80=9D >> >> https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ >> >> Having said that, we are ok to change to PS. >> >> GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. >> If anyone is interested in standardizing an "extension", I'd expect that >> they first define the base specification to which the extension applies.= I >> might have missed the definition of TWAMP Light protocol in the draft. C= ould >> you point to the definition, for example, of the Authenticated mode in >> TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? >> >> Gyan> Agreed >> >> The Appendix I of RFC 5357 does have information on the >> Authentication mode. As specified there, this is based on user configure= d >> parameters. >> >> =C2=B7 I believe that draft-gandhi-spring-twamp-srpm should be >> anchored at IPPM WG as it does introduce the new PM protocol. >> >> The TWAMP Light extension draft-gandhi-ippm-twamp-srpm >> is >> already in IPPM WG. The SPRING draft only defines SR PM procedures. >> >> Below, please find my detailed comments, questions on these drafts: >> >> - draft-gandhi-spring-twamp-srpm >> >> I have several questions about the relationships between this draft and >> Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has >> been mentioned. The nature of the TWAMP Light and what is required to ma= ke >> it a standard is well-explained in Section 4 of RFC 8545 >> (apologies for the long >> quote): >> >> "TWAMP Light" is an idea described in Appendix I ("TWAMP Light >> (Informative)") of [RFC5357]; TWAMP Light includes an unspecified >> control protocol combined with the TWAMP-Test protocol. In >> [RFC5357], the TWAMP Light idea was relegated to Appendix I because >> TWAMP Light failed to meet the requirements for IETF protocols (there >> are no specifications for negotiating this form of operation and no >> specifications for mandatory-to-implement security features), as >> described in Appendix A of this memo. See also [LarsAD] and >> [TimDISCUSS]. >> >> Since the idea of TWAMP Light clearly includes the TWAMP-Test >> component of TWAMP, it is considered reasonable for future systems to >> use the TWAMP-Test well-known UDP port (whose reallocated assignment >> is specified in this document). Clearly, the TWAMP Light idea >> envisions many components and communication capabilities beyond >> TWAMP-Test (implementing the security requirements, for example); >> otherwise, Appendix I of [RFC5357] would be one sentence long >> (equating TWAMP Light with TWAMP-Test only). >> >> Since we don't have an IETF document that addressed these open >> questions, I don't think we can have a draft that proposes extensions to= a >> non-standard mechanism (Appendix is for Informational material, as I >> understand it) on the Standard track. >> >> Gyan> Agreed >> >> The procedure for using the RFC 5357 defined messages in TWAMP >> Light configuration mode is defined in the corresponding spring drafts. = It >> also describes the provisioning model. >> >> GIM2>> If a return path can be provisioned for TWAMP Light, why the same >> method of controlling a test session cannot be used for STAMP? >> >> >> >> It is not expected that all STAMP TLV extensions need to be >> supported for TWAMP Light using provisioning. >> > This was to address your previous comment quoted as >> >> =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode= , >> >> mentioned in the informational Appendix I in RFC 5357, not the TWAMP >> >> protocol itself. Since TWAMP Light is not a standard but its idea is >> >> described in the informational text only, I think that the >> Informational >> >> track is more appropriate for this specification.=E2=80=9D >> >> https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ >> >> Having said that, we are ok to change to PS as you mentioned above. >> >> BTW, despite only difference of fixed vs. variable length payload i= n >> STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and= it >> uses the same approach of provisioning as defined in this draft). Hence= , >> security considerations for STAMP and TWAMP Light are not different. Not= e >> that both STAMP and TWAMP Light have authenticated messages defined for >> Security purpose. >> >> GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the >> light, simpler, version of TWAMP-Test component of TWAMP protocol. I can= not >> find in draft-gandhi-spring-twamp-srpm definition of the Authenticated m= ode >> of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the >> discussion of "extension" to TWAMP Light. >> >> The Authentication information is user-configured as shown in >> Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described= in >> Appendix I of RFC 5357. >> >> Now a number of more specific questions. >> >> draft-gandhi-spring-twamp-srpm: >> >> - In the Introduction it is stated that: >> >> The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides >> simplified mechanisms for active performance measurement in Customer >> IP networks by provisioning UDP paths and eliminates the need for >> control-channel signaling. >> >> I can not find where, either Appendix I or TR-390, "eliminated the need >> for control-channel signaling". Also, could you point where the referenc= ed >> documents describe "provisioning UDP paths"? >> >> The Appendix I of RFC 5357 has following text. We can reword and ma= tch the exact text if you prefer. >> >> >> >> =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol= , and >> >> assumes that the Session-Reflector is configured=E2=80=9D >> >> GIM>> I think that the text you're proposing is even more confusing. It >> is not clear which example the sentence is referring to. Also, what is t= he >> basis for such an assumption? >> >> This is the exact text from RFC 5357 Appendix I. Please go through >> the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. >> >> >> - It appears that the last paragraph in the Introduction describes >> the relationship with Appendix I of RFC 5357: >> >> The procedure uses the mechanisms defined in [RFC5357] >> (TWAMP Light) and its extensions for Performance Measurement. >> >> I think that the reference must be to Appendix I, not RFC 5357. Also, >> could you please specify which extensions of TWAMP Light have been used = in >> this draft? >> >> We can add the Appendix I as reference in the next revision. >> Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this >> reference. >> >> GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a >> normative reference while it is, by its nature, an Informational documen= t. >> >> If approved, it is fine to have informational draft/RFC in a >> normative reference. But RFC 5357 is PS. >> >> >> - In Section 2.3 describing the reference model is noted: >> >> The probe response message is typically sent to the sender node R1. >> >> In which scenarios the reflector acts differently? How such behavior is >> related to the behavior of a TWAMP Session-Reflector, as defined in RFC >> 5357? >> >> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the senten= ce? >> >> GIM>> If that fits into the operational model of the new protocol you're >> defining. >> >> >> - Also in Section 2.3 a Link is mentioned as an element directly >> connecting nodes in the presented reference model. Could you clarify = what >> is a Link? Is it always a physical connection between two systems or = a >> virtual? >> >> Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well know= n term used in >> many existing RFCs (please see RFC 5613, 5340, 8330). >> >> GIM>> Thank you for the references. I couldn't find a definition of an >> object "Link" (capitalized) but only "link" (lower case). Hence, since t= he >> draft consistently uses the capitalized form, I consider it to be someth= ing >> else, something different from a link. >> >> Ok, we can change Link to link in the next revision to avoid >> confusion. >> >> >> - In Section 3 behavior of the reflector described as >> >> ... no PM state for delay or loss measurement need to be created on t= he >> reflector node R5. >> >> That is in contradiction to the behavior of a TWAMP Session-Reflector as >> defined in RFC 5357. Could you provide a reference to an IETF standard >> where this behavior is defined? Also, how, without creating a state at t= he >> Session-Reflector, to achieve one-way delay and synthetic loss measureme= nt >> on a bidirectional SR tunnel? >> >> Gyan> Valid point >> >> Bidirectional SR tunnel may have an SR state but the statement >> above is that no PM (i.e. TWAMP Light) protocol session state is created >> for it. We can clarify in the next revision. >> >> GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one >> option. I am well-familiar with the implementation that uses the statefu= l >> mode. >> >> >> >> What information stateful PM need to maintain in the state on the >> reflector? Doesn=E2=80=99t that cause scale issues. We can add in the dr= aft you if >> there is anything specifically needed in the spec. >> > GIM3>> RFCs 5357 and 8762 are clear about what information must be > maintained by a Session-Reflector. The Session-Reflector must have > knowledge of the test session state and count reflected test packets. The > value of such a counter must be copied in the Sequence Number field of th= e > reflected packet. Thus the method enables the measurement of the one-way > packet loss metric. > >> Quoting the text from Appendix I in RFC 5357. We can quote the >> text as is. >> >> =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not nece= ssarily have knowledge of the session state. =E2=80=9C >> >> GIM>> By the informational nature of Appendix I, the text is not >> normative. I am familiar with the implementation of TWAMP Light which do= es >> maintain the session state and thus supports one-way packet loss >> measurement. If you require that the remote node does not maintain the >> state, the draft must define that as part of the specifying the behavior= of >> the protocol. >> >> Ok, we can discuss what information is to be maintained in that >> state on the reflector for synthetic packet loss. We can add appropriate >> text if you can help please. >> >> GIM2>> I don't see any reason to do that as that already defined in RFC >> 8762 and draft-ietf-ippm-stamp-yang >> >> >> >> >> Ok. >> >> =C2=B7 Further, in Section 3 the selection of UDP port explained= as >> the following: >> >> As specified in [RFC8545], the reflector >> supports the destination UDP port 862 for delay measurement probe >> messages by default. This UDP port however, is not used for loss >> measurement probe messages. >> >> To the best of my understanding, as one of the contributors and Editors >> of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP >> Session-Reflector without excluding any type of measurement. Besides, in >> TWAMP delay and packet loss are measured in the same test session, using >> the same flow of TWAMP-Test packets. >> >> Gyan> Agreed >> >> Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 >> they are using the same test packet. There is no change proposed in the >> draft. >> >> GIM2>> Packet delay and synthetic packet loss measurements are already >> supported in RFC 8762. Are you proposing a new protocol to duplicate the >> STAMP functionalities? >> >> >> >> As mentioned, the extensions defined are for the direct-mode packe= t >> loss measurement for TWAMP Light and STAMP. >> >> The packet loss in existing RFC 5357 refers to synthetic loss as >> there is no support for direct-mode loss in RFC 5357. We can change the >> text to clarify as =E2=80=9CThis UDP port however, is not used for direc= t-mode loss >> measurement probe messages.=E2=80=9D >> >> GIM>> I've found that there's some misconception in the draft. RFC 8545 >> re-assigned UDP port 862 not for "delay measurement probe messages" but = for >> TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay= , >> packet loss, reordering (RFC 4737 defines packet reordering metric), and >> packet duplication measurement. >> >> >> - Then the draft states that >> >> The sender uses the UDP port number following the guidelines specified i= n >> Section 6 in [RFC6335]. >> >> Could you point to the guidelines that a user can use when selecting a >> UDP port number of a test session? >> >> Gyan> Good point >> >> Please see section 6 in [RFC6335]. We can cite the range which will >> be the same as used in [RFC8762]. This was also discussed earlier. >> >> https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ >> >> GIM>> I've looked through Section 6 but I don't find anything >> specifically applicable to this draft we're discussing. If the protocol = to >> use UDP port numbers from the Dynamic ports range, a.k.a., Private or >> Ephemeral, then it seems that stating that explicitly would be the best >> way. >> >> This would be, User Ports and Dynamic Ports ranges, which are defi= ned in [RFC6335 ]. Yes, we can add thi= s text. >> >> >> - At the closing of the paragraph, we read that >> >> The number of UDP ports with PM functionality needs to be minimized du= e >> to limited hardware resources. >> >> Does a UDP port number pose PM functionality? How it is assigned to the >> port number? >> >> UDP ports are user configured for delay and direct-mode loss PM as >> described in Section 3.1. >> >> GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss >> measurement uses port number different from the one used by a TWAMP-Test >> packet, in my opinion, is another indication that this is the definition= of >> a different from TWAMP Light PM OAM protocol. >> >> If we add a field in the packet then UDP port 862 may be used alon= g >> with the new field. But it will require extra processing in hardware. It= is >> better to use a different UDP port for processing efficiency in hardware= . >> >> >> - Following the above-quoted text, in Section 3 is noted: >> >> For Performance Measurement, probe query and response messages are >> sent as following: >> >> Could you clarify if the listed further procedures deviate from >> OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for >> Session-Sender and Session-Reflector respectively? >> >> Probe messages follow the same procedure as defined in RFC 4656 and >> RFC 5357. >> >> GIM>> All messages, i.e., TWAMP-Test packets as well as the defined >> in draft-gandhi-ippm-twamp-srpm? >> >> Yes, unless otherwise specified in the >> draft-gandhi-ippm-twamp-srpm. >> >> >> - for both delay and loss measurements draft requires test packet be >> transmitted on a congruent path: >> >> the probe messages are sent on the >> congruent path of the data traffic by the sender node >> >> It is not clear what "the congruent path" means. The definition >> of congruency in geometry tells us that an object B is congruent to obje= ct >> A if it has the same shape and size, but is allowed to flip, slide or tu= rn. >> How a path can be congruent to another path? >> >> Gyan> Agreed. The use of congruent in the context of pathing is >> confusing as the path being addressed may not be reflected accurately by >> the term congruent. >> >> As replied above. >> >> There are many existing RFCs that use term Congruent Path (e.g. RFC >> 5921, 6669) without defining them. I suspect it is because it is well-kn= own >> term. Having said that, we can add a reference for it if it helps reader= . >> >> GIM>> I cannot assume what was the context of these RFCs. I've sketched = a >> network diagram above to illustrate that a "congruent path" may well lea= d >> to out-of-band path. Is that the intention of the authors of the draft t= o >> use this protocol out-of-band? >> >> As replied above. >> >> >> - The last paragraph in Section 3 refers to work on iOAM: >> >> The In-Situ Operations, Administration, and Maintenance (IOAM) >> mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for >> SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM >> information such as timestamp in-band as part of the data packets, >> and are outside the scope of this document. >> >> Is iOAM in the scope of this specification? What are the relationships >> between iOAM and draft-gandhi-spring-twamp-srpm? >> >> As mentioned in the draft, IOAM is outside the scope. >> >> GIM>> Yes, but it appears that references to the two IOAM-related drafts >> have some purpose. What is it? How are these drafts related >> to draft-gandhi-spring-twamp-srpm? >> >> We can remove them if it is confusing. It is informational text >> (was added to address a review comment). >> >> >> - Section 3.1 presents an example of the provisioning model but puts >> the definition of the provisioning model outside the scope. Is there = an >> accompanying specification that defines the provisioning model that c= an be >> used in multi-vendor deployment? Could that be YANG data model? What = is the >> relationship with draft-ietf-ippm-twamp-yang >> ? Would >> the TWAMP YANG data model be augmented? >> >> Yes, this can be Yang model. We can review >> draft-ietf-ippm-twamp-yang >> and add any >> missing items in a separate draft. We can also add a reference in this >> draft. >> >> GIM>> I think that theremust be some discussion on how the new protocol >> is configured. If TWAMP YANG data model can be augmented, I'd expect tha= t >> being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anyth= ing >> about the configuration of the protocol. >> >> The Yang model extensions are not in the scope of this draft >> >> >> - Section 4.1 states that a new message is introduced to perform the >> Loss Measurement in this protocol Why the capability of TWAMP to meas= ure >> the loss in one-way and two-way is not sufficient? >> >> Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80= =9D loss >> measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to cla= rify. >> >> GIM>> True, direct loss measurement, in fact, is not active measurement >> and thus is outside the scope of Two-Way Active Measurement Protocol >> (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, >> passive measurement method and fetching counters can be done using numer= ous >> methods, e.g., SNMP, Netconf >> >> RFC 7799 does not say using Test-packets to collect counters for >> direct-mod loss measurement is passive. >> >> GIM2>> Per RFC 7799, injecting in-band test packets is the characteristi= c >> of an active measurement method. Using out-of-band transport, e.g., SNMP >> queries, would be an example of a passive measurement method. >> >> >> >> Ok, so you answered your own question that the direct-mode packet >> loss extension defined is =E2=80=9Cactive measurement=E2=80=9D method. >> >> >> - Section 4.1.1 requires that >> >> The Destination UDP port cannot be used as Source port, since >> the message does not have any indication to distinguish between the >> query and response message. >> >> Does that imply that the Destination UDP port used for the Delay >> measurement is unique throughout the particular domain? >> >> Gyan> Good question >> >> Yes, it is unique in the domain. >> >> This is user-defined and is up to the user what UDP port to >> provision in a domain. >> >> GIM>> So, can user configure a port number from the User Ports range? Or= , >> can the same port number be used on the same system for a number of test >> sessions? I find the use of UDP port numbers being underspecified. >> >> >> - Section 4.1.2 of RFC 5357 does not define "the delay measurement >> message" but refers to the definition of the Session-Sender's test pa= cket >> in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test >> packet format to perform both delay and packet loss measurement. >> >> Ok, we can update the text in the next revision to indicate exact >> name from the RFC 4656. We can also add text to include synthetic packet >> loss. >> >> GIM>> I think that making it explicit would help. Also, that will >> highlight what is being introduced by *twamp-srpm drafts is, in fact, a = new >> protocol to perform synthetic packet loss measurement. >> >> No, it does not change anything for synthetic packet loss. >> >> >> - Can you explain how "the DM probe query message contains the >> payload format defined in Section 4.2.1 of [RFC5357]" when the refere= nced >> section of RFC 5357 defines the format of a Session-Reflector's test = packet? >> >> We can update the text in the next revision to indicate query forma= t >> name from RFC 5357. >> >> GIM>> I cannot find any reference to a query format in RFCs 4656/5357. >> Could you please quote from any of these documents? >> >> It is test-packet, we will use RFC 5357 term. >> >> >> - Can clarify the applicability of RFC 6038 and the symmetrical >> packet size? Is it required? Can it be non-symmetrical? >> >> Yes. Please see section 4.1.1 and quoted below: >> >> =E2=80=9CFor symmetrical size query and response messages as defined in = [RFC6038],=E2=80=9D >> >> GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the >> symmetrical test packets. Since *-twamp-srpm proposals do not use >> TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about >> that either (in part because RFC 6038 came later), I don't see that ther= e's >> any certainty in what is the sze of a test packet used in the direct-los= s >> measurement. >> >> The test-packets as defined in these existing RFCs are used for >> delay and synthetic packet loss. The direct-mode test-packets are define= d >> in this draft. >> >> GIM2>> This draft defines only a new packet format for the direct packet >> loss measurement. For STAMP such a mechanism is clearly superfluous give= n >> the Direct Measurement TLV is already defined. >> >> >> >> As replied earlier. >> >> >> - Can you clarify the use of the timestamp format, NTP or PTPv2? It >> is not clear which is the default, mandatory or optional. >> >> This is same as TWAMP. There is no change. >> >> GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for >> *-twamp-srpm? >> >> No change in existing in what is there in RFC 5357 and RFC 8186. >> >> >> - Also, is "hardware support in Segment Routing networks" of the >> PTPv2 format required, guaranteed, or something else? >> >> Hardware timestamps are recommended for SR use-cases. We can change >> the sentence. >> >> GIM>> Perhaps you can propose some text, that would be helpful. >> >> Ack. >> >> >> - Section 4.1.1.1 stated that >> >> A separate user-configured >> destination UDP port is used for the delay measurement in >> authentication mode due to the different probe message format. >> >> Can that be interpreted that there could be concurrent authenticated and >> unauthenticated test sessions using this protocol? Would different >> authentication methods require using unique destination UDP port numbers= ? >> >> Yes, and Yes, and these are based on provisioning. >> >> GIM>> But that requirement is far outside the TWAMP, as defined in RFC >> 5357. >> >> Some Session-Sender can use authenticated and some not. It is >> part of RFC 5357. >> >> >> - Section 4.1.2 by introducing the dedicated Loss measurement packet >> format, effectively modifies the behavior defined in RFC 5357 for >> Session-Sender and Session-Reflector. But the document does not state= that. >> Can you clarify whether this specification changes the behavior of a >> Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 5= 357 >> respectively for the support of packet loss measurement? >> >> The direct-mode loss defines new procedure for sender/reflector to >> collect traffic counters, as opposed to timestamp. The rest is the same = as >> RFC 4656 and 5357. >> >> GIM>> I cannot agree with your statement " The rest is the same as RFC >> 4656 and 5357" because the sender's direct-loss format does not have Err= or >> Estimate field, Thus, a reflected packet does not have Sender's Error >> Estimate, nor Error Estimate of the reflector. And that, in my opinion, = is >> another clear indication that *twamp-srpm drafts define a new protocol, >> separate from OWAMP/TWAMP. >> >> That field is specific to timestamps and would not apply to >> counters for direct-mode loss measurement. >> >> >> - And a similar question about the use of the separate UDP port >> number for the authenticated of the packet loss measurement. >> - A couple of question to the following text in Section 4.1.3: >> >> The local and remote IP >> addresses of the link are used as Source and Destination Addresses. >> They can also be IPv6 link local address as probe messages are pre- >> routed. >> >> - What are the addresses of a link? >> >> I am assuming this well-known (e.g. RFC 2328). >> >> GIM>> I am not familiar with the term "pre-routed". What does it mean? >> >> Ensure that packets are routed over the link. >> >> >> - In which scenarios an IPv6 LLA can be used? >> >> I am assuming this is well-known (e.g. RFC 5613). >> >> GIM>> So, LLA may be used as the source and destination addresses when >> testing an SR tunnel? >> >> As mentioned this is for links. >> >> >> - Also, could the use of a routable destination IP address be used as >> a DDOS attack vector? Consider the scenario when an attacker gener= ates >> SR-encapsulated packets with the destination IP address other than= any of >> the SR-terminating nodes. Such a packet will be routed, correct? T= hat does >> appear as a security threat, would you agree? >> >> Absolutely do not agree. It is no different than IP routed TWAMP >> packet as defined in [RFC5357]. >> >> GIM>> You don't agree that the processing described cannot happen becaus= e >> of laws of physics or it wouldn't happen because no one will think of th= at? >> If the latter, I think that that is security threat. >> >> There is no new threat like you have mentioned. >> >> GIM2>> Hmmm, but how the integrity of TLVs proposed >> in draft-gandhi-ippm-stamp-srpm can be protected? These are not protecte= d >> by HMAC as presented in figures 3 and >> 5. >> >> >> >> >> The extensions do not change the processing of these existing TLVs >> defined for HMAC. We can add text to indicate this. >> >> >> - Section 4.1.4.2 references Figure 5 that, as I understand it, >> displays the format of a probe query message. In figure two reference= s to >> RFC 5357 are provided - a section that references RFC 4656 OWAMP defi= nition >> of the Session-Sender test packet, and a section that defines the >> Session-Reflector's reflected packet. Which of the two is used for th= e >> delay measurement in the proposed protocol? >> >> The probe query packet in the Session-Sender text packet. We can >> update the name. >> >> - Section 4.2.1 states that >> >> In one-way measurement mode, the probe response message as defined in >> Figure 6 is sent back out-of-band to the sender node ... >> >> Could you clarify how the responder controls that the response packet is >> sent not in-band but out-of-band? >> >> Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This >> is existing behaviour for out-of-band. >> >> GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines >> another new protocol OWAMP Light. And it is not clear what you reference= as >> "this is existing behavior". Is it to reference behavior of TWAMP test >> packet? But the behavior of the TWAMP-Test protocol by itself is neither >> in-band, nor out-of-band. It is the encapsulation of the TWAMP test pack= et >> that makes it either in-band or out-of-band. >> >> Right. >> >> >> - How's the method described in Section 4.2.3 is different from the >> method described in RFC 8403 ? >> What is distinctly unique about the loopback mode proposed in the sec= tion? >> >> There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 840= 3. >> >> GIM>> So, you believe that proposing to use the method described in RFC >> 8403 for the TWAMP packet is innovation? And what are the benefits of us= ing >> the TWAMP test packet format in the Loopback mode? >> >> Please see the draft. >> >> >> - What is the rationale for setting TTL/Hop Limit fields always to >> 255 for IPv4, MPLS, and IPv6 (per Section 4.3.1)? >> >> This is as defined in Section 4.2 of RFC 5357 (Bullet 4). >> >> GIM>> I believe you've misunderstood the text in RFC 5357. This bullet >> specifies the behavior of a Session-Reflector. It is to try to read TTL >> value of the received TWAMP test packet and copy the value in Sender TTL >> field of the reflected packet. If the Session-Reflector cannot access th= e >> TTL field, it MUST write 255 in the Sender TTL field. So, I think that m= y >> questions still remains. >> >> Please see Section 4.2.1 of RFC 5357. >> >> >> - Section 4.3.3 states that a zero-value UDP checksum may be used in >> some scenarios. RFC 8085 allows that but in very specific cases that = are >> documented in detail in Section 3.4.1. Do you believe that the case o= f this >> protocol checks all the requirements for allowing the use of Zero UDP >> checksum as specified in RFC 8085? Also, I believe that allowing the = use of >> Zero UDP checksum in some scenarios, this protocol introduces a secur= ity >> threat that must be thoroughly analyzed in the Security Consideration= s >> section. >> >> This is described in RFC 6936. It will be very specific to the UDP >> port provisioned for TWAMP. We will add reference to RFC 6936 in Securit= y >> Section. >> >> GIM>> I don't think that the reference is sufficient for the >> Securit Consideration. I'd expect some extended discussion on why using >> zero UDP header checksum is not a security threat for *twamp-srpm proto= col. >> >> Please see reply above. >> >> >> - Section 8 refers to "liveness monitoring of Links and SR Paths". >> This appears as the replication of functionality provided by BFD/S-BF= D >> protocols. Is such comparison accurate? If it is, shouldn't the propo= sal be >> also reviewed by the BFD WG? >> >> TWAMP probe messages are used today for synthetic packet loss whic= h >> can also be used to detect connection loss (performance metric). The >> section simply highlights this obvious metric. >> >> GIM>> Can you point to a document that has defined "TWAMP probe message= s >> are used today for synthetic packet loss"? Also, which document defines >> loss of connectivity as a performance metric? Does *twamp-srpm proposes = to >> use the new protocol to detect the loss of path continuity? >> >> For example Y.1731 has such notion of connection loss. TWAMP is >> used widely for synthetic packet loss and is well-known. There is no cha= nge >> in protocol. This is reported metric. >> >> GIM2>> What are packet transmission frequencies authors envisioned for >> that mode? A single-digit millisecond? >> >> >> >> It depends on the implementation. >> >> >> - I found the Security Section of the proposed protocol inadequately >> terse and missing very important threats that this protocol introduce= s in >> the network. >> >> Other than referring RFC 6936 for zero checksum what else is >> missing? Otherwise it is no different than RFC 8762 (STAMP). >> >> GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The >> use of source IP addresses, as mentioned above, appears to be another >> security risk introduced by *-twamp-srpm drafts. >> >> There is no mention of Source IP address above. >> >> >> - draft-gandhi-ippm-twamp-srpm >> >> As I understand it, the motivation for the Loss Measurement mode defined >> in this specification is to collect "in-profile" counters. Is that corre= ct? >> Do you see as essential for this mode that the query messages are in-ban= d >> with the flow being profiled? In your opinion, how using an out-of-band >> method of collecting these counters, e.g., by using ICMP multi-part mess= age >> extension per RFC 4884, could affect the accuracy comparing with the met= hod >> in this protocol? How the impact changes if extended ICMP messages are >> in-band with the profiled flow? >> >> Yes, they need to be in-band with the flow, to collect the counte= r >> from the right forwarding paths for the flow. Discussion of using ICMP f= or >> direct-mode loss measurement is outside the scope of this draft. >> >> GIM2>> I think that the assumption "they need to be in-band with the >> flow, to collect the counter from the right forwarding paths for the flo= w" >> is technically inaccurate. Otherwise, how SNMP queries could work for >> decades of networking history? >> >> >> >> -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002dce6a05b5b185f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rakesh=C2=A0

Had a general question.

I read through the draft again and a question came to mind as thi= s draft is Standards Track, what new is being introduced other then a proce= dure of how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data = plane and SRv6 which used the IPv6 data plane.=C2=A0 I don=E2=80=99t believ= e there exists =C2=A0a Standards track draft procedure for how to use STAMP= over IP network or MPLS network as an example. =C2=A0

Section 4.1.4 describes SR-MPLS use case and= SRv6 use case.=C2=A0 As there appears to be nothing new introduced such as= a new IANA TLV or code point or even a special SID code point =C2=A0for TW= AMP, all basic vanilla SR, that without this draft you could run STAMP, TWA= MP, OWAMP over SR which has existed for a while now. =C2=A0

What is the new invention here?
=

Sorry but I may have missed s= omething.

My thoughts ar= e at most this be a BCP or I am thinking informational draft would be appro= priate.

Thoughts?
<= div dir=3D"auto">
Gyan

On Thu, Dec 3, 2020 = at 12:51 PM Greg Mirsky <gregim= irsky@gmail.com> wrote:
<= div dir=3D"ltr">Hi Rakesh,
thank you for the continued discussion. You = can find my follow-up notes in-line below under GIM3>> tag. I felt th= at one comment is at the root of our different views on what is considered = to be a problem that drafts solve. You've said:
=
<RG3> As mentioned, the extensions defined are for the direct-mo= de packet loss measurement for TWAMP Light and STAMP.
But draft-ietf-ippm-stamp-option-tlv, currentl= y in=C2=A0 Submitted to IESG for Publication WG state according to IETF dat= atracker, includes Section 4.5 Direct Measurement TLV. It is noted in the s= ection:
=C2=A0 =C2=A0The Direct Measurement TLV enables collection of t= he number of in-
=C2=A0 =C2=A0profile packets, i.e., packets that form a= specific data flow, that
=C2=A0 =C2=A0had been transmitted and received= by the Session-Sender and Session-
=C2=A0 =C2=A0Reflector, respectively= .=C2=A0 The definition of "in-profile packet" is
=C2=A0 =C2=A0= outside the scope of this document and is left to the test operators
=C2= =A0 =C2=A0to determine.
Thus I cannot see any technical need for = the introduction=C2=A0of yet another way of direct loss measurement in STAM= P. As for the case of TWAMP Light, I believe that there's no sufficient= evidence that the proposed direct loss-measurement measurement method bene= fits existing implementations of TWAMP Light. Also, historically, all exten= sions applicable to TWAMP Light have been introduced through extending TWAM= P proper, i.e., extending TWAMP-Control and TWAMP-Test. The way of "ex= tending" TWAMP Light presented in the drafts we are discussing is, in = my opinion, in violation of RFC 5357.

More notes c= an be found below.

Regards,
Greg


On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi= (rgandhi) <rgand= hi@cisco.com> wrote:

Thank you Greg= for your further reply and the discussions.

Good to kno= w that you do see a need for the extensions for the direct-mode packet loss= detection and the authors are actively working on an alternate methods usi= ng BFD (as you mentioned below).

GIM3>> As you've recognized, in draft-mirmi= n-bfd-extended=C2=A0we build an integrated OAM based on the lightweight= Fault Management protocol with optional Performance Monitoring, based on R= FC 6374. RFC 6374, in turn, provides a rich set of performance measurement = methods, including direct loss measurement.

=

Please see rep= lies inline with <RG3>=E2=80=A6.

=C2=A0<= u>

=C2=A0<= u>

From: Greg Mirsky <gregimirsky@gmail.com= >
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.org <ippm-chairs@ietf.org>, spring-chairs@ietf.org &l= t;spring-chairs= @ietf.org>, spr= ing@ietf.org <s= pring@ietf.org>, Greg Mirsky <g= regory.mirsky@ztetx.com>
Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

Hi Rakesh,

thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line=C2=A0below under the GIM2>> t= ag.

=C2=A0

Regards,

Greg

=C2=A0

=C2=A0

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Gyan = and Greg for your review comments and discussions. Please see inline replie= s with <RG2>=E2=80=A6

From: Gyan Mishra <hayabusagsm@gmail.com= >
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

=C2=A0Hi Rakesh=C2=A0

I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

Thanks

Gyan

On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Rakesh,

thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=C2=A0<= u>

Regards,

Greg

On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Greg for taking time for tho= roughly reviewing the documents and providing the comments.

Please see replies inline with <RG&= gt;=E2=80=A6

From: ippm <ippm-bounces@ietf.org>= ;
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

  • Is the document(s) reasonably well-written

I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

<RG> We are ok to change Sender to Session-Sender and Re= flector to Session-Reflector if it helps.

=C2=A0

GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.

=C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.=C2=A0 The goal should be clear and concise i= n terminology and verbiage.

<RG2> Agr= ee. Will address the terms from RFC 5357 in the next revision.

<RG> There are many existing RFCs that use term =E2=80= =9CLink=E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongru= ent Path=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.=

  • Does the document solve a real problem?

No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

=C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agr= ee that for direct in band packet loss measurement can be done via existing= OAM mechanisme via ICMP.

<RG2> Ok,= we will find an appropriate term for =E2=80=9Csending packets on the same = path as data traffic=E2=80=9D.

<RG2> Ext= ending ICMP for direct-mode loss measurement is outside the scope of this d= raft. But good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).=

GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't= recall that I've stated that "direct in-band packet loss measurem= ent" requires any additional standardization work. The Direct Measurement TLV has solved that for STAMP and draft-ietf-ippm-stamp= -option-tlv is now in the RFC Editor's queue. I cannot find any valid t= echnical reason to re-open this and measure the direct packet loss in a sli= ghtly different way. I must point out that a claim that using fixed positions for the direct packet loss optimiz= es performance does not stand for cases (Section 4.2.1 and 4.2.2 of draft-g= andhi-spring-stamp-srpm) when the return path is specified in the Return Pa= th TLV and, as I understand it, in some cases even the second TLV, Node Address TLV, is used. Thus, it is = clear that the proposed new method of direct packet loss measurement does n= ot offer any significant benefits comparing to the STAMP's Direct Measu= rement TLV and appears nothing but superfluous.

=C2=A0

<RG3> Th= e direct-mode packet loss use-case is typically for the forward direction p= acket loss. And this does not use the return path TLV. We can clarify that = in the draft.

GIM3>>= ; Clarification would be very helpful as your latest note might be interpre= ted that the proposed mechanisms are not applicable in the case of a bi-dir= ectional SR tunnel.
<= p class=3D"MsoNormal">

<RG> There is a requirement to measure performance delay= as well as synthetic and direct-mode packet loss in segment-routing networ= ks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

GIM>> I agree with the=C2=A0requirements you've listed (though th= e=C2=A0SPRING WG OAM requirements document=C2=A0= has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to use OWAMP/TWAMP for exc= lusive direct packet loss measurement.=C2=A0=C2=A0

=C2=A0 =C2=A0 Gyan> Agreed

<RG2> There is definitely a n= eed to do direct-mode loss measurement in IP/SR networks, as RFC 6374 mecha= nisms are for MPLS networks. Note that there was an attempt to extend BFD f= or direct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.<= u>

=C2=A0

<RG3>= Ok, so you do see a need for the extensions for the direct-mode packet los= s detection and the authors are actively working on an alternate methods us= ing BFD. =C2=A0=C2=A0=

  • Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

<RG> Abou= t your comment on zero checksum, this is described in Security section in R= FC 6936. We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

=C2=A0=C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA secur= ity threats and that you need to thorough vetting of RFC 6936.

=C2=A0<RG2&g= t; Yes, will add in the next revision. Hope we can work together on needed = text.

To summarize my review of=C2=A0these two drafts:<= /u>

  • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

<RG> The = probe and response messages defined in [RFC 5357] are used for delay measur= ement and synthetic packet loss. The direct-mode packet loss messages are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement messages. As stated, draft-gandhi-= ippm-twamp-srpm defines =E2= =80=9Cextensions=E2=80=9D for TWAMP Light.

GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concern= ed with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's=C2=A0TR-390, = I'm have learned how different are existing implementations of TWAMP Li= ght. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

=C2=A0 Gyan> I don=E2=80=99t see the probe a d re= sponse messages in TWAMP RFC 5357=C2=A0

<RG2> Agr= ee to use term test-packet from RFC 5357.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 several parts of the proposed protocol, e.g., Z= ero UDP checksum in IPv6, require detailed security analysis, which is curr= ently absent;

=C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

<RG2> Ple= ase see previous reply.

<RG> This= is specified in RFC 6936 Security Section. We will add reference to this R= FC in our Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

GIM>>=C2=A0 I've noted above that a simple reference does not suf= ficiently explains why the use of zero UDP checksum in IPv6 header is not d= ecremental, does not create a security risk for the protocol. I believe tha= t the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.

=C2=A0 =C2=A0 Gyan> Completely Agree

=C2=A0<RG2&g= t; Please see previous reply.

  • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
<RG> This was to address=
 your previous comment quoted as:=

 =E2=80=9C- as I understand, the draft is applicable t=
o TWAMP Light mode,

=C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

=C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

=C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

=C2=A0 track is more appropriate for th= is specification.=E2=80=9D

https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

<RG> Havi= ng said that, we are ok to change to PS.

GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which= the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Coul= d you point to the definition, for example, of the Authenticated mode in TW= AMP Light in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

=C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

<RG2> The= Appendix I of RFC 5357 does have information on the Authentication mode. A= s specified there, this is based on user configured parameters.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 I believe that=C2=A0draft-gandhi-spring-twamp-s= rpm should be anchored at IPPM WG as it does introduce the new PM protocol.=

<RG> The = TWAMP Light extension draft-gandhi-= ippm-twamp-srpm is already in IPPM WG. The SPRING draf= t only defines SR PM procedures.

=C2=A0Below, please find my detailed=C2=A0comments, = questions on these drafts:

  • draft-gandhi-spring-twamp-srpm

I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

=C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
=C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
=C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
=C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
=C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
=C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
=C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
=C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
=C2=A0 =C2=A0[TimDISCUSS].

=C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
=C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
=C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
=C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
=C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
=C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

=C2=A0Since we don't have an IETF document that = addressed these open questions, I don't think we can have a draft that = proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

=C2=A0Gyan> Agreed=C2=A0

<RG2> The= procedure for using the RFC 5357 defined messages in TWAMP Light configura= tion mode is defined in the corresponding spring drafts. It also describes the provisioning model.

GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

=C2=A0

<RG3> It= is not expected that all STAMP TLV extensions need to be supported for TWA= MP Light using provisioning.=C2=A0

=

=C2=A0<RG>= ; This was to address your previous comment quoted as<= /p> 

 =E2=80=9C- as I understand, the draft is applicable t=
o TWAMP Light mode,

=C2=A0=C2=A0 mentioned in the informati= onal Appendix I in RFC 5357, not the TWAMP

=C2=A0=C2=A0 protocol itself. Since TWA= MP Light is not a standard but its idea is

=C2=A0=C2=A0 described in the informati= onal text only, I think that the Informational

=C2=A0=C2=A0 track is more appropriate = for this specification.=E2=80=9D

https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXA= FiCAC3o/

<RG> Havi= ng said that, we are ok to change to PS as you mentioned above.

<RG> BTW,= despite only difference of fixed vs. variable length payload in STAMP vs. = TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer= not to refer to RFC 8762 STAMP in the discussion of "extension" = to TWAMP Light.

<RG2> The= Authentication information is user-configured as shown in Section 3.1 of t= he draft-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.

Now a number of more specific questions.

draft-gandhi-spring-twamp-srpm:

  • In the Introduction it is stated that:

=C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
=C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
=C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
=C2=A0 =C2=A0control-channel signaling.

I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

<RG> The Appendix I of R=
FC 5357 has following text. We can reword and match the exact text if you p=
refer.
=C2=A0
=E2=80=9CThis example eliminates the need for the TWAM=
P-Control protocol, and
=C2=A0=C2=A0 assumes that the Session-Reflector is con=
figured=E2=80=9D

GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

<RG2> Thi= s is the exact text from RFC 5357 Appendix I. Please go through the entire = Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussi= on.

  • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

=C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
=C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

<RG> We can add the Appendix I as reference in the next = revision. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can ad= d this reference.

GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0=C2=A0

<RG2> If = approved, it is fine to have informational draft/RFC in a normative referen= ce. But RFC 5357 is PS.

  • In Section 2.3 describing the reference model is noted:
    • <= /ul>

    =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

    In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

    <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D= from the sentence?

GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

  • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

<RG> Both= , please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used = in many existing RFCs (please see RFC 5613, 5340, 8330).

GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.= =C2=A0

<RG2> Ok,= we can change Link to link in the next revision to avoid confusion.=

  • In Section 3 behavior of the reflector described as

=C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
=C2=A0 =C2=A0reflector node R5.

That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

=C2=A0Gyan> Valid point=C2=A0

<RG2> Bid= irectional SR tunnel may have an SR state but the statement above is that n= o PM (i.e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.

GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode.=C2=A0

=C2=A0

<RG3> Wh= at information stateful PM need to maintain in the state on the reflector? = Doesn=E2=80=99t that cause scale issues. We can add in the draft you if the= re is anything specifically needed in the spec.

GIM3>> RFCs 5357 and 8762 are clear about what= information must be maintained by a Session-Reflector. The Session-Reflect= or must have knowledge of the test session state and count reflected test p= ackets. The value of such a counter must be copied in the Sequence Number f= ield of the reflected packet. Thus=C2=A0the method enables the measurement = of the one-way packet loss metric.
=
<= div>

=

=C2=A0<RG>= ; Quoting the text from Appendix I in RFC 5357. We can quote the text as is= .

=E2=80=9CIn the case of TWAMP Light, the Session-Refle=
ctor does not necessarily have knowledge of the session state. =E2=80=9C

GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

=C2=A0<RG2&g= t; Ok, we can discuss what information is to be maintained in that state on= the reflector for synthetic packet loss. We can add appropriate text if you can help please.

GIM2>> I don't see any reason to do that a= s that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang=C2=A0

=C2=A0

<RG3> Ok= .=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Further, in Section 3 the selection of UDP port= explained as the following:

=C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
=C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
=C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
=C2=A0 =C2=A0measurement probe messages.

To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

=C2=A0Gyan> Agreed=C2=A0

<RG2> Yes= , we can use port 862 for both delay and synthetic packet loss =E2=80=93 th= ey are using the same test packet. There is no change proposed in the draft= .

GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

=C2=A0

<RG3> As= mentioned, the extensions defined are for the direct-mode packet loss meas= urement for TWAMP Light and STAMP.

<RG> The = packet loss in existing RFC 5357 refers to synthetic loss as there is no su= pport for direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.=

  • Then the draft states that

The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

Gyan> Good point =C2=A0

<RG> Please see section 6 in [RFC6335]. We can cite the = range which will be the same as used in [RFC8762]. This was also discussed = earlier.

https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

<RG2> This would be, Use=
r Ports and Dynamic Ports ranges, which are defined in [RFC6335]. Yes, we can add this text.
  • At the closing of the paragraph, we read that

=C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
=C2=A0 =C2=A0to limited hardware resources.

Does a UDP port number pose PM functionality? How it= is assigned to the port number?

<RG> UDP = ports are user configured for delay and direct-mode loss PM as described in= Section 3.1.

GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l.=C2=A0

<RG2> If = we add a field in the packet then UDP port 862 may be used along with the n= ew field. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

  • Following the above-quoted text, in Section 3 is noted:
    • <= /ul>

    =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
    =C2=A0 =C2=A0sent as following:

    Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

    <RG> Probe messages follow the same procedure as defined= in RFC 4656 and RFC 5357.

GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

=C2=A0<RG2&g= t; Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.

  • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

=C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
=C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

=C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

<RG2> As = replied above.

<RG> Ther= e are many existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669)= without defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

<RG2> As = replied above.

  • The last paragraph in Section 3 refers to work on iOAM:
    • <= /ul>

    =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
    =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
    =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
    =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
    =C2=A0 =C2=A0and are outside the scope of this document.

    Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

    <RG> As mentioned in the draft, IOAM is outside the scop= e.

GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

<RG2> We = can remove them if it is confusing. It is informational text (was added to = address a review comment).

  • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

<RG> Yes,= this can be Yang model. We can review draft-ietf-ippm-tw= amp-yang and add any missin= g items in a separate draft. We can also add a reference in this draft.

GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.= =C2=A0

<RG2> The= Yang model extensions are not in the scope of this draft=C2=A0

  • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

<RG> Exis= ting TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measu= rement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.

GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf=C2=A0<= /u>

<RG2> RFC= 7799 does not say using Test-packets to collect counters for direct-mod lo= ss measurement is passive.

GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measure= ment method.

=C2=A0

<RG3> Ok= , so you answered your own question that the direct-mode packet loss extens= ion defined is =E2=80=9Cactive measurement=E2=80=9D method.

  • Section 4.1.1 requires that

=C2=A0 The Destination UDP port cannot be used as So= urce port, since
=C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
=C2=A0 =C2=A0query and response message.

Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

=C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

<RG2> Yes= , it is unique in the domain.

<RG> This= is user-defined and is up to the user what UDP port to provision in a doma= in.

GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers being underspecified.

  • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

<RG> Ok, = we can update the text in the next revision to indicate exact name from the= RFC 4656. We can also add text to include synthetic packet loss.=

GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=C2=A0

=C2=A0<RG2&g= t; No, it does not change anything for synthetic packet loss.=

  • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

<RG> We c= an update the text in the next revision to indicate query format name from = RFC 5357.

GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

=C2=A0<RG2&g= t; It is test-packet, we will use RFC 5357 term.

  • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
<RG> Yes. Please see sec=
tion 4.1.1 and quoted below:<=
u style=3D"font-family:monospace">
=E2=80=9CFor symmetrical size query and response messa=
ges as defined in [RFC6038],=E2=80=9D

GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze = of a test packet used in the direct-loss measurement.=C2=A0

=C2=A0<RG2&g= t; The test-packets as defined in these existing RFCs are used for delay an= d synthetic packet loss. The direct-mode test-packets are defined in this draft.

GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.=

=C2=A0

<RG3> As= replied earlier.

  • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

<RG> This= is same as TWAMP. There is no change.

GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

=C2=A0<RG2&g= t; No change in existing in what is there in RFC 5357 and RFC 8186.<= u>

  • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

<RG> Hard= ware timestamps are recommended for SR use-cases. We can change the sentenc= e.

GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

=C2=A0<RG2&g= t; Ack.

  • Section 4.1.1.1 stated that

=C2=A0 =C2=A0A separate user-configured
=C2=A0 =C2=A0destination UDP port is used for the delay measurement in
=C2=A0 =C2=A0authentication mode due to the different probe message format.=

Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

<RG> Yes,= and Yes, and these are based on provisioning.

GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

=C2=A0<RG2&g= t; Some Session-Sender can use authenticated and some not. It is part of RF= C 5357.

  • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

<RG> The = direct-mode loss defines new procedure for sender/reflector to collect traf= fic counters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of th= e reflector. And that, in my opinion, is another clear indication that *twa= mp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.<= /u>

=C2=A0<RG2&g= t; That field is specific to timestamps and would not apply to counters for= direct-mode loss measurement.

  • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
  • A couple of question to the following text in Section 4.1.3:<= /li>

=C2=A0 =C2=A0The local and remote IP
=C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
=C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
=C2=A0 =C2=A0routed.

    • What are the addresses of a link?

<RG> I am= assuming this well-known (e.g. RFC 2328).

GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

=C2=A0<RG2&g= t; Ensure that packets are routed over the link.

    • In which scenarios an IPv6 LLA can be used?

<RG> I am= assuming this is well-known (e.g. RFC 5613).

GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

=C2=A0<RG2&g= t; As mentioned this is for links.

    • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

<RG> Abso= lutely do not agree. It is no different than IP routed TWAMP packet as defi= ned in [RFC5357].

GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is security threat.

=C2=A0<RG2&g= t; There is no new threat like you have mentioned.

GIM2>> Hmmm, but how the integrity of TLVs pro= posed in=C2=A0draft-gandhi-ippm-stamp-srpm can=C2=A0be protected? These are= not protected by HMAC as presented in figures 3 and 5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

<RG3> Th= e extensions do not change the processing of these existing TLVs defined fo= r HMAC. We can add text to indicate this.

  • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

<RG> The = probe query packet in the Session-Sender text packet. We can update the nam= e.

  • Section 4.2.1 states that

=C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
=C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

<RG> Plea= se refer to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is exis= ting behaviour for out-of-band.

GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and.=C2=A0

=C2=A0<RG2&g= t; Right.

GIM>> So, you believe that proposing to use th= e method described in RFC 8403 for the TWAMP packet is innovation? And what= are the benefits of using the TWAMP test packet format in the Loopback mode?

=C2=A0<RG2&g= t; Please see the draft.

  • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

<RG> This= is as defined in Section 4.2 of RFC 5357 (Bullet 4).<= /p>

GIM>> I believe you've misunderstood the t= ext in RFC 5357. This bullet specifies the behavior of a Session-Reflector.= It is to try to read TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

=C2=A0<RG2&g= t; Please see Section 4.2.1 of RFC 5357.

  • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

<RG> This= is described in RFC 6936. It will be very specific to the UDP port provisi= oned for TWAMP. We will add reference to RFC 6936 in Security Section.

GIM>> I don't think that the reference is = sufficient for the Securit=C2=A0Consideration. I'd expect some extended= discussion on why using zero UDP header checksum is not a security threat for *twamp-srpm=C2=A0 protocol.

=C2=A0<RG2&g= t; Please see reply above.

  • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be= also reviewed by the BFD WG?

<RG> TWAM= P=C2=A0 probe messages are used today for synthetic packet loss which can a= lso be used to detect connection loss (performance metric). The section simply highlights this obvious metric.

GIM>> Can you point to a document that has def= ined "TWAMP=C2=A0 probe messages are used today for synthetic packet l= oss"? Also, which document defines loss of connectivity as a performan= ce metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

=C2=A0<RG2&g= t; For example Y.1731 has such notion of connection loss. TWAMP is used wid= ely for synthetic packet loss and is well-known. There is no change in protocol. This is reported metric.

GIM2>> What are packet transmission frequencie= s authors envisioned for that mode? A single-digit millisecond?=C2=A0

=C2=A0

<RG3> It= depends on the implementation.

  • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

<RG> Othe= r than referring RFC 6936 for zero checksum what else is missing? Otherwise= it is no different than RFC 8762 (STAMP).

GIM>> I cannot see how RFC 8762 is relevant to= *twamp-srpm drafts. The use of source IP addresses, as mentioned above, ap= pears to be another security risk introduced by *-twamp-srpm drafts.=C2=A0

=C2=A0<RG2&g= t; There is no mention of Source IP address above.

  • draft-gandhi-ippm-twamp-srpm

As I understand it, the motivation for the Loss Meas= urement mode defined in this specification is to collect "in-profile&q= uot; counters. Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part=C2=A0message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

=C2=A0<RG2&g= t; Yes, they need to be in-band with the flow, to collect the counter from = the right forwarding paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.=

GIM2>> I think that the assumption "they = need to be in-band with the flow, to collect the counter from the right for= warding paths for the flow" is technically inaccurate. Otherwise, how = SNMP queries could work for decades of networking history?

=C2=A0

--
--0000000000002dce6a05b5b185f9-- From nobody Sat Dec 5 07:32:38 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AF43A0D79; Sat, 5 Dec 2020 07:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.59 X-Spam-Level: X-Spam-Status: No, score=-9.59 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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=a4Xa7Jk7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aJjO4Y9t 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 oStTIfJEL9CJ; Sat, 5 Dec 2020 07:32:23 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257593A0D77; Sat, 5 Dec 2020 07:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=267497; q=dns/txt; s=iport; t=1607182343; x=1608391943; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VRmG7hChcT9FeXAwidFxehb+k22h9FUKBqZip4YQsb4=; b=a4Xa7Jk7r//X40YWEcDQJRnv4TrwSimQyAt4PQ8+HJL36tlFkIPEK3ZE 45cmP1bXoMKr4Azzaz/QiMk1Wdj3shRTyJ/dSxYsfLb5DFKsVoy3Qq+PA LeMTPpP3SaHBwKp1D4BTLdQubURk1gElg+BCRS5EKEvCG7gQ55L2JljAp A=; X-IPAS-Result: =?us-ascii?q?A0DjAgCkp8tfmJ1dJa2FXbwAJ0sFAQEBAwIDAQgDAgEGB?= =?us-ascii?q?BUBAQICjHw6hHa9B5Edgcx8GQ0?= IronPort-PHdr: =?us-ascii?q?9a23=3AsMP4MRUypPFZXAPH0TL7cwb6ULLV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,395,1599523200"; d="scan'208,217";a="628878818" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Dec 2020 15:32:22 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B5FWMBo028325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 5 Dec 2020 15:32:22 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 5 Dec 2020 09:32:21 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 5 Dec 2020 09:32:20 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 5 Dec 2020 09:32:20 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jFrXv8G/fvQYgt+o/7bDPNQPBbjCR5TQ7FXzzdGQSeUdtSu/6K40JkKq6aFxuzw1T+iXj4IWgYZ4DGE/seix6BuUNK3GLv0ZAh+WCHg+QR8BHVhQV6ebWTXqZKOgD5eXNNlVAvg6LMk5v8LtEX+OAVMz6OnGV4wMr9GjJ7u1zRSqwIIO5A5byFU6JiHSlOFXVjldeTLBTwJ8G6xxzx7AGJ7/wd1FkvMae4+/VST3KELXuoB0mlwl4RXoez+dxHeqOS1q5tdtatB52JURgLF572+2nitfd39POThCral+6hc8IqcOnThjsivmw4haVmtamMsD4GaZii+zLy0uUT5XMQ== 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=QEGrav0GnBPORA+PdglAPHxWx9tbuUvQEg3Z1ALNxXY=; b=VuwqAyvyMT6tBx6S0JF5J34Q7lwsjWGM7Mk4ZB1/5YY8kVRWng7wx8ruNzhs8ICTgAXagboHF5/iTiYq+TXDC5muXMnBTSM9YDW3jrWE/lOWmx1nUx9jPvgjSscIAc/EUOqzXlTxd1DlazyMLqMtqcwUi+JtlHQY4Cczv3WShBwRQx0Ze05YAtFaMqmNWCOZPcuhNcfPg+XTk5n/a5stCAwdIp77qNYenJkpDov0QeYD8NdlJY9NN7+a4e/rd2t7FKanIeWnIUtMLyAIoFWaOlY/9mQOdnRhIcNAxAaC/f8d96NPKTSZW+knzfnUrDZ1C+Qa1ef8ibagYybm0plT+A== 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=QEGrav0GnBPORA+PdglAPHxWx9tbuUvQEg3Z1ALNxXY=; b=aJjO4Y9tQzAdMdtYz0LA99YXAUVWmiU5sKQS+3O4VCswD5qfp6LqMrm3Ycpyqp2Y3be6DQzGVQFX7dk143CqftnhS1C4mpWCZmyf5gg1oCZqObZgIy/4snB9ih3BOtsZFFfCdLlki/rEvAQ3KIWBcDRY17BL5TTLYGbr+i1VMxw= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB2873.namprd11.prod.outlook.com (2603:10b6:5:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.31; Sat, 5 Dec 2020 15:32:18 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::b0:395a:1430:79d3%5]) with mapi id 15.20.3632.021; Sat, 5 Dec 2020 15:32:18 +0000 From: "Rakesh Gandhi (rgandhi)" To: Gyan Mishra , Greg Mirsky CC: Greg Mirsky , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Thread-Index: AQHWw1FAi8Q0V5FtjUGdBFDHCBkgBqnZreOIgAc3iICAA1dl0YABdnSAgAJiHQCAAJSbyQ== Date: Sat, 5 Dec 2020 15:32:17 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc76f171-407e-45f3-70d4-08d89932f341 x-ms-traffictypediagnostic: DM6PR11MB2873: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZVJ69++5hI6yIuCFnTZvBVoHle4QVaNU43hXNdVIEQa0l3P3I1JJFrWW6TXTW1TfKYU8Gz08T2O1KJS4N65lUXZ7tOblUxBV+pAUlcw3EKLUCYRkpYDlfqPi3oN9QvwWqA441G5dHeDoLduRydcuPN6ZrVbbcBjEmQMAtTROUjvBrvIMxpIw9kox9zCs0swOQAGmsfqTMHGOaAMHNhuvXGGTolxSmu+uIjDFqWtIY07jgtQ13nsaLk9Ztx7mapgz8+9DL/qVsMiR9/QxvuPchdpBqhlHwztz6c2ih07+ZWfFkjKJppA8picbtesnPJhGpWCA33suIW+zvuEYA2olNkMKKT4q6FANE7H13Ie5CLRi22gIBfsPxRT0IJ8YVYR/a398XNuK+e8HiljCGDPE6DvvB83epwOOkCY+qgdhteHWryEAUIb94gCRR//nyKSd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(366004)(136003)(39860400002)(5660300002)(478600001)(8676002)(4326008)(52536014)(55016002)(8936002)(110136005)(6506007)(53546011)(54906003)(966005)(83380400001)(66476007)(316002)(76116006)(66446008)(64756008)(66556008)(91956017)(86362001)(26005)(66946007)(30864003)(9686003)(7696005)(71200400001)(186003)(33656002)(2906002)(166002)(9326002)(579004)(559001)(569008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?Xc8KSzgJb+a5STvTax/ePo1IvcXEnL2eLWdfPdl+d8oSnq8mw08WMh98?= =?Windows-1252?Q?7paXJgu8xEYjYOkFevpYJbx6LH2Swyo9lbBV/ExPzaN5LyktyOTBub8a?= =?Windows-1252?Q?HYhvVMldeC3DoI296Ktf3i71lurcb+SOL8HvhmYYimREBLyXS6840pPj?= =?Windows-1252?Q?ybOz7sbcx3OhDVvsZTmwzozZHhHJFhrHvn+6J9OW3yjSrp3KgcjJYsZ6?= =?Windows-1252?Q?IIl6BtNb2+3RdI2YvzZw+G/yylWpa19RI+F3B/TTX2Dj3k9qM7/1+3Fe?= =?Windows-1252?Q?BFet0oYyBAhi1Hnzf6uOzyFmFbbv2JOGafnr/M0b6UR4bFEO+xO3PsH/?= =?Windows-1252?Q?uI+XEdftfvOIV1W5DQ+x/MiVq20QqXbDwx/N/PMbyTBM7Yc/+H5bD6Fm?= =?Windows-1252?Q?OMqwpw/cJzXSIUicKgUGmGg2JpHodVplIBgH9oRPQF1e52UJd26rZncT?= =?Windows-1252?Q?QtqJfi7l9UMYHNkPRMj41YYlc6macAt7OEBWvlFvLqtNaiK0/eqOo2er?= =?Windows-1252?Q?CkUrKX4S5jDimc/u9OLA5YYGMXkXpQ9BsF1gABWHwXZ+v5UrmhN5SHuF?= =?Windows-1252?Q?jwb0tm9OWs9d8eFG1GdTjwogNjaLpDWTzQSHCFVz9JA84NXGza/JDLKE?= =?Windows-1252?Q?4n3Xgb7ZSdFJzF9MEmRr9cjPuUqZGdiXqEawIa4VA9FTGeQothd7rr+5?= =?Windows-1252?Q?anMM0p0ThtPi/Dnmh6RoJVkgQbRq6vF0133FaCDK0J6nE6IMLu8LhvKl?= =?Windows-1252?Q?VNALsJIXYx2+vT0eMTz5y5FRr1epChGOQN+pAqfeqlb2nnAt9Xgb+2Px?= =?Windows-1252?Q?+Et8Cm5dfAfBFmKX6R+yKZ8WSzm7G1f30wXH5CIgXDx1z2vb1ieBjfC0?= =?Windows-1252?Q?jTab8dDNUEa99GR3Zx/UrXKg7lqsbDXa47YiXhXc5VNz/hfxqxghwIG9?= =?Windows-1252?Q?Q5CnaCMTmAC4AtXqxAddPAaLTVpbPb965MjSFmM10+OS4+yI0IAuMn57?= =?Windows-1252?Q?fwwyFiASjJP++oDUkiSuNyZ1AlklAbRpLQFGqFm6h3pgbJHqfBz68MnF?= =?Windows-1252?Q?q+fFroMs51eeKIxjenNy4dXgNHApfalKQ3UVug=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc76f171-407e-45f3-70d4-08d89932f341 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2020 15:32:18.0062 (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: hzK/SqxoREhVJLPvNqU9gXAJDou/Mn1TlqFO74cwOXP0Jt56+/WznIIcekfCN1iB0edwV3aRCHbg2XC3x5zElg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2873 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 15:32:32 -0000 --_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gyan, Thanks for your review comments. Please see inline with =85 From: Gyan Mishra Date: Saturday, December 5, 2020 at 1:16 AM To: Greg Mirsky Cc: Greg Mirsky , IETF IPPM WG , J= ames Guichard , Rakesh Gandhi (rgandhi) , ippm-chairs@ietf.org , spring-chair= s@ietf.org , spring@ietf.org Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh Had a general question. I read through the draft again and a question came to mind as this draft is= Standards Track, what new is being introduced other then a procedure of ho= w to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane and = SRv6 which used the IPv6 data plane. I don=92t believe there exists a Sta= ndards track draft procedure for how to use STAMP over IP network or MPLS n= etwork as an example. Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there appea= rs to be nothing new introduced such as a new IANA TLV or code point or eve= n a special SID code point for TWAMP, all basic vanilla SR, that without t= his draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a= while now. What is the new invention here? SPRING drafts define the procedure for using TWAMP Light and STAMP te= st-messages for SR path and links. The corresponding IPPM drafts define the= extensions needed for them. The SPRING drafts also use the extensions for = them defined in the corresponding IPPM drafts. The extensions are needed fo= r (1) in-band response request e.g. for two-way mode for links and SR path,= (2) Return path for SR e.g. when using bidirectional SR Path, and (3) for = collecting TX and RX traffic counters in-band for direct-mode loss measurem= ent. Sorry but I may have missed something. My thoughts are at most this be a BCP or I am thinking informational draft = would be appropriate. Given above context, if WG thinks that any of the drafts should be BC= P or Informational or Experimental, we can update the draft accordingly. Thoughts? Gyan On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the continued discussion. You can find my follow-up notes in-= line below under GIM3>> tag. I felt that one comment is at the root of our = different views on what is considered to be a problem that drafts solve. Yo= u've said: As mentioned, the extensions defined are for the direct-mode packet l= oss measurement for TWAMP Light and STAMP. But draft-ietf-ippm-stamp-option-tlv, currently in Submitted to IESG for Publicat= ion WG state according to IETF datatracker, includes Section 4.5 Direct Mea= surement TLV. It is noted in the section: The Direct Measurement TLV enables collection of the number of in- profile packets, i.e., packets that form a specific data flow, that had been transmitted and received by the Session-Sender and Session- Reflector, respectively. The definition of "in-profile packet" is outside the scope of this document and is left to the test operators to determine. Hi Greg, The motivation has been there in the draft-gandhi-ippm-stamp-srpm, Section = 1. Copied below for the convenience. The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization). Furthermore, for hardware-based counter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). Thus I cannot see any technical need for the introduction of yet another wa= y of direct loss measurement in STAMP. As for the case of TWAMP Light, I be= lieve that there's no sufficient evidence that the proposed direct loss-mea= surement measurement method benefits existing implementations of TWAMP Ligh= t. Also, historically, all extensions applicable to TWAMP Light have been i= ntroduced through extending TWAMP proper, i.e., extending TWAMP-Control and= TWAMP-Test. The way of "extending" TWAMP Light presented in the drafts we = are discussing is, in my opinion, in violation of RFC 5357. The IPPM WG Informational draft on TWAMP Light direct-mode loss measu= rement, defines the message format and corresponding SPRING draft defines t= he procedure for using that. It is not clear to me how providing an informa= tional draft gandhi-ippm-twamp-srpm is violating RFC 5357. Thanks, Rakesh More notes can be found below. Regards, Greg On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for your further reply and the discussions. Good to know that you do see a need for the extensions for the direct-mode = packet loss detection and the authors are actively working on an alternate = methods using BFD (as you mentioned below). GIM3>> As you've recognized, in draft-mirmin-bfd-extended we build an integrated OAM= based on the lightweight Fault Management protocol with optional Performan= ce Monitoring, based on RFC 6374. RFC 6374, in turn, provides a rich set of= performance measurement methods, including direct loss measurement. Please see replies inline with =85. From: Greg Mirsky > Date: Monday, November 30, 2020 at 11:30 AM To: Rakesh Gandhi (rgandhi) > Cc: Gyan Mishra >, IETF= IPPM WG >, James Guichard >, ippm-chairs@ie= tf.org >, spring-chairs@ietf.org >, spring@ietf.org >, Greg Mirsky > Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh, thank you for the continued discussion. I appreciate your responses. I am s= till not convinced of the value these documents add. Please find my follow-= up notes in-line below under the GIM2>> tag. Regards, Greg On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: Thank you Gyan and Greg for your review comments and discussions. Please se= e inline replies with =85 From: Gyan Mishra > Date: Wednesday, November 25, 2020 at 12:34 PM To: Greg Mirsky > Cc: IETF IPPM WG >, James Guichard >, Rakesh= Gandhi (rgandhi) >, ippm-chair= s@ietf.org >, spring-chairs@ietf.org >, spring@ietf.org > Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Hi Rakesh I have been following this thread and to help progress the discussion I wou= ld like to provide some comments in-line Gyan> Thanks Gyan On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky > wrote: Hi Rakesh, thank you for the response to my comments. Please find my follow-up notes i= n-lined below under the GIM>> tag. Regards, Greg On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Please see replies inline with =85 From: ippm > Date: Friday, November 6, 2020 at 11:18 AM To: James Guichard > Cc: spring@ietf.org >, ippm-chairs@ietf.org >, spring-chairs@ietf.org >,= IETF IPPM WG > Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/ht= ml/draft-gandhi-spring-twamp-srpm-11 Dear Chairs of the SPRING and IPPM WGs, Authors, et al., I've found myself in the situation when two related drafts are in the WG AP= s in the SPRING and IPPM WG (with the possibility that expertise from the t= hird WG, BFD WG, might be desirable to review the "liveness monitoring"). B= ecause these drafts are closely related, I've decided to combine my questio= ns and comments in a single thread. I hope that would be acceptable and con= sidered by the SPRING WG as well as IPPM WG. Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: * Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFC 4656 = and 5357 and introduce their own terminology for Session-Sender and Session= -Reflector. Also, many terms, e.g., Links, "congruent paths", are used in t= he documents without proper definitions. Other than that both drafts are re= adable and reasonably well-written. We are ok to change Sender to Session-Sender and Reflector to Session-= Reflector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. But I d= on't think that switching the terminology will fix the fundamental issue wi= th the proposal. The operation that is required from the remote entity, whe= ther it is referred to as responder or Session-Reflector, is not defined in= Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion, th= e behavior required, as described in the draft, cannot be characterized as = an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely new = protocol that, if there's a need in the new PM OAM protocol, must be proper= ly defined. Gyan> I am in complete agreement with Greg about terminology and consist= ency. The problem with inconsistency is that that you are not following we= ll known normative references required to understand the specification lead= ing to confusion and misunderstanding of the specification. The goal shoul= d be clear and concise in terminology and verbiage. Agree. Will address the terms from RFC 5357 in the next revision. There are many existing RFCs that use term =93Link=94 (e.g. RFC 5613, = 5340, 8330, etc.) and term =93Congruent Path=94 (e.g. RFC 5921, 6669) witho= ut defining them. I suspect it is because these are well-known terms. Havin= g said that, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . Is A-B-G-H-E-F congruent to it? From the definition of "congruent" as "tw= o figures or objects are congruent if they have the same shape and size, or= if one has the same shape and size as the mirror image of the other", it l= ooks as the path A-B-G-H-E-F is congruent to that SR tunnel. But a packet o= f an active OAM intended to monitor a flow over the SR tunnel is out-of-ban= d relative to that flow and will not produce any meaningful measurement. Of= course, for the case of the extensions in drafts *-twamp-srpm, direct loss= measurement can be performed, as information collected from node F and pac= kets that collect the counters are not required to be in-band with the moni= tored flow. So, this example, in my opinion, illustrates two of my concerns= : =95 using a congruent path for active performance measurement, e.g.= , TWAMP or TWAMP Light, may produce information that does not reflect the c= ondition experienced by the monitored flow. It seems that the terminology s= hould reflect the fundamental requirement of ensuring that active OAM test = packets are in-band with the monitored flow. =95 there are no technical requirements to justify using in-band te= st packets for direct packet loss measurement. In fact, using the in-band m= ethod for collecting in-profile counters leads to a waste of bandwidth, whi= ch may have a negative impact on services that require low-latency and/or l= ow packet loss. As demonstrated in this example, direct packet loss can be = performed using an out-of-band mechanism, e.g., SNMP queries, Netconf notif= ications based on YANG data model. * Does the document solve a real problem? No, it appears that these drafts define a new performance measurement proto= col for the purpose of combining OWAMP and TWAMP functionality and adding t= he ability to collect counters of "in-profile" packets. I couldn't find suf= ficient technical arguments for using a PM protocol instead of, for example= , extending the existing OAM mechanisms like ICMP. Gyan> This may sound basic but is a very critical subject going down the = same lines of clarity in verbiage so their is no misunderstanding. =93Cong= ruent=94 by definition means shape of an object and if you super imposed tw= o objects on top of each other they fit perfectly and the edges coincide id= entically. The problem with congruent is that it is based on the shape and= that shape could be a mirror image or reflection which may not be exact. = So when referring to a SR-TE path taken this could lead to confusion as to = path taken if it=92s the same path or congruent which is vague as to =93exa= ctly=94 which path is taken where here there is criticality as to the path = being referenced in terms of in-band versus out-of-band. I agree that for = direct in band packet loss measurement can be done via existing OAM mechani= sme via ICMP. Ok, we will find an appropriate term for =93sending packets on the sa= me path as data traffic=94. Extending ICMP for direct-mode loss measurement is outside the scope = of this draft. But good to see the agreement for the direct in band packet = loss measurement to be done (albeit by some other means). GIM2>> I feel that you misunderstand my position in regard to the use case = these four documents try to solve. I don't recall that I've stated that "di= rect in-band packet loss measurement" requires any additional standardizati= on work. The Direct Measurement TLV has solved that for STAMP and draft-iet= f-ippm-stamp-option-tlv is now in the RFC Editor's queue. I cannot find any= valid technical reason to re-open this and measure the direct packet loss = in a slightly different way. I must point out that a claim that using fixed= positions for the direct packet loss optimizes performance does not stand = for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm) when = the return path is specified in the Return Path TLV and, as I understand it= , in some cases even the second TLV, Node Address TLV, is used. Thus, it is= clear that the proposed new method of direct packet loss measurement does = not offer any significant benefits comparing to the STAMP's Direct Measurem= ent TLV and appears nothing but superfluous. The direct-mode packet loss use-case is typically for the forward dir= ection packet loss. And this does not use the return path TLV. We can clari= fy that in the draft. GIM3>> Clarification would be very helpful as your latest note might be int= erpreted that the proposed mechanisms are not applicable in the case of a b= i-directional SR tunnel. There is a requirement to measure performance delay as well as synthet= ic and direct-mode packet loss in segment-routing networks. OWAMP and TWAMP= protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP for exclusive = direct packet loss measurement. Gyan> Agreed There is definitely a need to do direct-mode loss measurement in IP/S= R networks, as RFC 6374 mechanisms are for MPLS networks. Note that there w= as an attempt to extend BFD for direct-mode loss measurement for this purpo= se using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-0= 3). GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense.= The work and discussion of the proposal continues and the new version will= be published soon. Ok, so you do see a need for the extensions for the direct-mode packe= t loss detection and the authors are actively working on an alternate metho= ds using BFD. * Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocol on network security, to comprehensively evaluate the proposed= solution. About your comment on zero checksum, this is described in Security sec= tion in RFC 6936. We will add reference to this RFC in our Security Section= as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Gyan> Agreed 0 UDP MIMA security threats and that you need to thorough= vetting of RFC 6936. Yes, will add in the next revision. Hope we can work together on nee= ded text. To summarize my review of these two drafts: * these propose a new protocol, not an update or enhancement of the TWA= MP-like protocol; The probe and response messages defined in [RFC 5357] are used for del= ay measurement and synthetic packet loss. The direct-mode packet loss messa= ges are defined in draft-gandhi-ippm-twamp-srpm that match these delay measurement mes= sages. As stated, draft-gandhi-ippm-twamp-srpm defines =93extensions=94 for TWAMP Ligh= t. GIM>> I cannot find where RFC 5357 defines "the probe and response messages= ". Could you give a more specific reference or provide the text that, in yo= ur opinion, defines such messages? But I'm more concerned with the directio= n of "extending" non-protocol referred to as "TWAMP Light". As a contributo= r to BBF's TR-390, I'm have learned how different are existing implementati= ons of TWAMP Light. And that is also noted in EANTC Multi-Vendor Interopera= bility 2019 white paper. The status of TWAMP Light is explain= ed in RFC 8545 and I cannot see that it can be used as a foundation of any = standard. Gyan> I don=92t see the probe a d response messages in TWAMP RFC 5357 Agree to use term test-packet from RFC 5357. =95 several parts of the proposed protocol, e.g., Zero UDP checksum= in IPv6, require detailed security analysis, which is currently absent; Gyan> Agreed Please see previous reply. This is specified in RFC 6936 Security Section. We will add reference = to this RFC in our Security Section as well. This is only specific to the U= DP port locally provisioned in the domain by the operator for TWAMP. GIM>> I've noted above that a simple reference does not sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol. I believe that the proposal = to use zero UDP header checksum requires extensive analysis, using the anal= ysis provided in RFC 6936. Gyan> Completely Agree Please see previous reply. * I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on t= he Informational track even though it is essential to the new protocol as i= t defines its key elements This was to address your previous comment quoted as: =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS. GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. If= anyone is interested in standardizing an "extension", I'd expect that they= first define the base specification to which the extension applies. I migh= t have missed the definition of TWAMP Light protocol in the draft. Could yo= u point to the definition, for example, of the Authenticated mode in TWAMP = Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? Gyan> Agreed The Appendix I of RFC 5357 does have information on the Authenticatio= n mode. As specified there, this is based on user configured parameters. =95 I believe that draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol. The TWAMP Light extension draft-gandhi-ippm-twamp-srpm is already in IPPM WG. The= SPRING draft only defines SR PM procedures. Below, please find my detailed comments, questions on these drafts: * draft-gandhi-spring-twamp-srpm I have several questions about the relationships between this draft and App= endix I in RFC 5357 where the idea of a mode known as TWAMP Light has been = mentioned. The nature of the TWAMP Light and what is required to make it a = standard is well-explained in Section 4 of RFC 8545 (apologies for the long quote): "TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS]. Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only). Since we don't have an IETF document that addressed these open questions, = I don't think we can have a draft that proposes extensions to a non-standar= d mechanism (Appendix is for Informational material, as I understand it) on= the Standard track. Gyan> Agreed The procedure for using the RFC 5357 defined messages in TWAMP Light = configuration mode is defined in the corresponding spring drafts. It also d= escribes the provisioning model. GIM2>> If a return path can be provisioned for TWAMP Light, why the same me= thod of controlling a test session cannot be used for STAMP? It is not expected that all STAMP TLV extensions need to be supported= for TWAMP Light using provisioning. This was to address your previous comment quoted as =93- as I understand, the draft is applicable to TWAMP Light mode, mentioned in the informational Appendix I in RFC 5357, not the TWAMP protocol itself. Since TWAMP Light is not a standard but its idea is described in the informational text only, I think that the Informational track is more appropriate for this specification.=94 https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ Having said that, we are ok to change to PS as you mentioned above. BTW, despite only difference of fixed vs. variable length payload in S= TAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and it = uses the same approach of provisioning as defined in this draft). Hence, s= ecurity considerations for STAMP and TWAMP Light are not different. Note th= at both STAMP and TWAMP Light have authenticated messages defined for Secur= ity purpose. GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the li= ght, simpler, version of TWAMP-Test component of TWAMP protocol. I cannot f= ind in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode = of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the dis= cussion of "extension" to TWAMP Light. The Authentication information is user-configured as shown in Section= 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described in Append= ix I of RFC 5357. Now a number of more specific questions. draft-gandhi-spring-twamp-srpm: * In the Introduction it is stated that: The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer IP networks by provisioning UDP paths and eliminates the need for control-channel signaling. I can not find where, either Appendix I or TR-390, "eliminated the need for= control-channel signaling". Also, could you point where the referenced doc= uments describe "provisioning UDP paths"? The Appendix I of RFC 5357 has following text. We can reword and match= the exact text if you prefer. =93This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured=94 GIM>> I think that the text you're proposing is even more confusing. It is = not clear which example the sentence is referring to. Also, what is the bas= is for such an assumption? This is the exact text from RFC 5357 Appendix I. Please go through th= e entire Section in that RFC 5357 to avoid =93out of context=94 discussion. * It appears that the last paragraph in the Introduction describes the = relationship with Appendix I of RFC 5357: The procedure uses the mechanisms defined in [RFC5357] (TWAMP Light) and its extensions for Performance Measurement. I think that the reference must be to Appendix I, not RFC 5357. Also, could= you please specify which extensions of TWAMP Light have been used in this = draft? We can add the Appendix I as reference in the next revision. Extension= s are defined in draft-gandhi-ippm-twamp-srpm, we can add this reference. GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a nor= mative reference while it is, by its nature, an Informational document. If approved, it is fine to have informational draft/RFC in a normativ= e reference. But RFC 5357 is PS. * In Section 2.3 describing the reference model is noted: The probe response message is typically sent to the sender node R1. In which scenarios the reflector acts differently? How such behavior is rel= ated to the behavior of a TWAMP Session-Reflector, as defined in RFC 5357? Do you prefer we remove =93typically=94 from the sentence? GIM>> If that fits into the operational model of the new protocol you're de= fining. * Also in Section 2.3 a Link is mentioned as an element directly connec= ting nodes in the presented reference model. Could you clarify what is a Li= nk? Is it always a physical connection between two systems or a virtual? Both, please see Section 4.1.3. =93Link=94 is well known term used in = many existing RFCs (please see RFC 5613, 5340, 8330). GIM>> Thank you for the references. I couldn't find a definition of an obje= ct "Link" (capitalized) but only "link" (lower case). Hence, since the draf= t consistently uses the capitalized form, I consider it to be something els= e, something different from a link. Ok, we can change Link to link in the next revision to avoid confusio= n. * In Section 3 behavior of the reflector described as ... no PM state for delay or loss measurement need to be created on the reflector node R5. That is in contradiction to the behavior of a TWAMP Session-Reflector as de= fined in RFC 5357. Could you provide a reference to an IETF standard where = this behavior is defined? Also, how, without creating a state at the Sessio= n-Reflector, to achieve one-way delay and synthetic loss measurement on a b= idirectional SR tunnel? Gyan> Valid point Bidirectional SR tunnel may have an SR state but the statement above = is that no PM (i.e. TWAMP Light) protocol session state is created for it. = We can clarify in the next revision. GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one opt= ion. I am well-familiar with the implementation that uses the stateful mode= . What information stateful PM need to maintain in the state on the ref= lector? Doesn=92t that cause scale issues. We can add in the draft you if t= here is anything specifically needed in the spec. GIM3>> RFCs 5357 and 8762 are clear about what information must be maintain= ed by a Session-Reflector. The Session-Reflector must have knowledge of the= test session state and count reflected test packets. The value of such a c= ounter must be copied in the Sequence Number field of the reflected packet.= Thus the method enables the measurement of the one-way packet loss metric. Quoting the text from Appendix I in RFC 5357. We can quote the text a= s is. =93In the case of TWAMP Light, the Session-Reflector does not necessarily h= ave knowledge of the session state. =93 GIM>> By the informational nature of Appendix I, the text is not normative.= I am familiar with the implementation of TWAMP Light which does maintain t= he session state and thus supports one-way packet loss measurement. If you = require that the remote node does not maintain the state, the draft must de= fine that as part of the specifying the behavior of the protocol. Ok, we can discuss what information is to be maintained in that stat= e on the reflector for synthetic packet loss. We can add appropriate text i= f you can help please. GIM2>> I don't see any reason to do that as that already defined in RFC 876= 2 and draft-ietf-ippm-stamp-yang Ok. =95 Further, in Section 3 the selection of UDP port explained as th= e following: As specified in [RFC8545], the reflector supports the destination UDP port 862 for delay measurement probe messages by default. This UDP port however, is not used for loss measurement probe messages. To the best of my understanding, as one of the contributors and Editors of = RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflector= without excluding any type of measurement. Besides, in TWAMP delay and pac= ket loss are measured in the same test session, using the same flow of TWAM= P-Test packets. Gyan> Agreed Yes, we can use port 862 for both delay and synthetic packet loss =96= they are using the same test packet. There is no change proposed in the dr= aft. GIM2>> Packet delay and synthetic packet loss measurements are already supp= orted in RFC 8762. Are you proposing a new protocol to duplicate the STAMP = functionalities? As mentioned, the extensions defined are for the direct-mode packet l= oss measurement for TWAMP Light and STAMP. The packet loss in existing RFC 5357 refers to synthetic loss as there= is no support for direct-mode loss in RFC 5357. We can change the text to = clarify as =93This UDP port however, is not used for direct-mode loss measu= rement probe messages.=94 GIM>> I've found that there's some misconception in the draft. RFC 8545 re-= assigned UDP port 862 not for "delay measurement probe messages" but for TW= AMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, pac= ket loss, reordering (RFC 4737 defines packet reordering metric), and packe= t duplication measurement. * Then the draft states that The sender uses the UDP port number following the guidelines specified in S= ection 6 in [RFC6335]. Could you point to the guidelines that a user can use when selecting a UDP = port number of a test session? Gyan> Good point Please see section 6 in [RFC6335]. We can cite the range which will be= the same as used in [RFC8762]. This was also discussed earlier. https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ GIM>> I've looked through Section 6 but I don't find anything specifically = applicable to this draft we're discussing. If the protocol to use UDP port = numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it= seems that stating that explicitly would be the best way. This would be, User Ports and Dynamic Ports ranges, which are defined= in [RFC6335]. Yes, we can add this te= xt. * At the closing of the paragraph, we read that The number of UDP ports with PM functionality needs to be minimized due to limited hardware resources. Does a UDP port number pose PM functionality? How it is assigned to the por= t number? UDP ports are user configured for delay and direct-mode loss PM as des= cribed in Section 3.1. GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss measur= ement uses port number different from the one used by a TWAMP-Test packet, = in my opinion, is another indication that this is the definition of a diffe= rent from TWAMP Light PM OAM protocol. If we add a field in the packet then UDP port 862 may be used along w= ith the new field. But it will require extra processing in hardware. It is = better to use a different UDP port for processing efficiency in hardware. * Following the above-quoted text, in Section 3 is noted: For Performance Measurement, probe query and response messages are sent as following: Could you clarify if the listed further procedures deviate from OWAMP/TWAMP= or follow procedures defined in RFC 4656 and RFC 5357 for Session-Sender a= nd Session-Reflector respectively? Probe messages follow the same procedure as defined in RFC 4656 and RF= C 5357. GIM>> All messages, i.e., TWAMP-Test packets as well as the defined in draf= t-gandhi-ippm-twamp-srpm? Yes, unless otherwise specified in the draft-gandhi-ippm-twamp-srpm. * for both delay and loss measurements draft requires test packet be tr= ansmitted on a congruent path: the probe messages are sent on the congruent path of the data traffic by the sender node It is not clear what "the congruent path" means. The definition of congruen= cy in geometry tells us that an object B is congruent to object A if it has= the same shape and size, but is allowed to flip, slide or turn. How a path= can be congruent to another path? Gyan> Agreed. The use of congruent in the context of pathing is con= fusing as the path being addressed may not be reflected accurately by the t= erm congruent. As replied above. There are many existing RFCs that use term Congruent Path (e.g. RFC 59= 21, 6669) without defining them. I suspect it is because it is well-known t= erm. Having said that, we can add a reference for it if it helps reader. GIM>> I cannot assume what was the context of these RFCs. I've sketched a n= etwork diagram above to illustrate that a "congruent path" may well lead to= out-of-band path. Is that the intention of the authors of the draft to use= this protocol out-of-band? As replied above. * The last paragraph in Section 3 refers to work on iOAM: The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM information such as timestamp in-band as part of the data packets, and are outside the scope of this document. Is iOAM in the scope of this specification? What are the relationships betw= een iOAM and draft-gandhi-spring-twamp-srpm? As mentioned in the draft, IOAM is outside the scope. GIM>> Yes, but it appears that references to the two IOAM-related drafts ha= ve some purpose. What is it? How are these drafts related to draft-gandhi-s= pring-twamp-srpm? We can remove them if it is confusing. It is informational text (was = added to address a review comment). * Section 3.1 presents an example of the provisioning model but puts th= e definition of the provisioning model outside the scope. Is there an accom= panying specification that defines the provisioning model that can be used = in multi-vendor deployment? Could that be YANG data model? What is the rela= tionship with draft-ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented? Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yang<= https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> and add any miss= ing items in a separate draft. We can also add a reference in this draft. GIM>> I think that theremust be some discussion on how the new protocol is = configured. If TWAMP YANG data model can be augmented, I'd expect that bein= g defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything abo= ut the configuration of the protocol. The Yang model extensions are not in the scope of this draft * Section 4.1 states that a new message is introduced to perform the Lo= ss Measurement in this protocol Why the capability of TWAMP to measure the = loss in one-way and two-way is not sufficient? Existing TWAMP messages do not support =93direct-mode=94 loss measurem= ent. We can add =93direct-mode=94 in the text to clarify. GIM>> True, direct loss measurement, in fact, is not active measurement and= thus is outside the scope of Two-Way Active Measurement Protocol (TWAMP). = The direct-loss measurement is, by the definition of RFC 7799, passive meas= urement method and fetching counters can be done using numerous methods, e.= g., SNMP, Netconf RFC 7799 does not say using Test-packets to collect counters for dire= ct-mod loss measurement is passive. GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic o= f an active measurement method. Using out-of-band transport, e.g., SNMP que= ries, would be an example of a passive measurement method. Ok, so you answered your own question that the direct-mode packet los= s extension defined is =93active measurement=94 method. * Section 4.1.1 requires that The Destination UDP port cannot be used as Source port, since the message does not have any indication to distinguish between the query and response message. Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain? Gyan> Good question Yes, it is unique in the domain. This is user-defined and is up to the user what UDP port to provision = in a domain. GIM>> So, can user configure a port number from the User Ports range? Or, c= an the same port number be used on the same system for a number of test ses= sions? I find the use of UDP port numbers being underspecified. * Section 4.1.2 of RFC 5357 does not define "the delay measurement mess= age" but refers to the definition of the Session-Sender's test packet in RF= C 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet for= mat to perform both delay and packet loss measurement. Ok, we can update the text in the next revision to indicate exact name= from the RFC 4656. We can also add text to include synthetic packet loss. GIM>> I think that making it explicit would help. Also, that will highlight= what is being introduced by *twamp-srpm drafts is, in fact, a new protocol= to perform synthetic packet loss measurement. No, it does not change anything for synthetic packet loss. * Can you explain how "the DM probe query message contains the payload = format defined in Section 4.2.1 of [RFC5357]" when the referenced section o= f RFC 5357 defines the format of a Session-Reflector's test packet? We can update the text in the next revision to indicate query format n= ame from RFC 5357. GIM>> I cannot find any reference to a query format in RFCs 4656/5357. Coul= d you please quote from any of these documents? It is test-packet, we will use RFC 5357 term. * Can clarify the applicability of RFC 6038 and the symmetrical packet = size? Is it required? Can it be non-symmetrical? Yes. Please see section 4.1.1 and quoted below: =93For symmetrical size query and response messages as defined in [RFC6038]= ,=94 GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the sym= metrical test packets. Since *-twamp-srpm proposals do not use TWAMP-Contro= l protocol and Appendix I in RFC 5357 tells us nothing about that either (i= n part because RFC 6038 came later), I don't see that there's any certainty= in what is the sze of a test packet used in the direct-loss measurement. The test-packets as defined in these existing RFCs are used for dela= y and synthetic packet loss. The direct-mode test-packets are defined in th= is draft. GIM2>> This draft defines only a new packet format for the direct packet lo= ss measurement. For STAMP such a mechanism is clearly superfluous given the= Direct Measurement TLV is already defined. As replied earlier. * Can you clarify the use of the timestamp format, NTP or PTPv2? It is = not clear which is the default, mandatory or optional. This is same as TWAMP. There is no change. GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for *-twam= p-srpm? No change in existing in what is there in RFC 5357 and RFC 8186. * Also, is "hardware support in Segment Routing networks" of the PTPv2 = format required, guaranteed, or something else? Hardware timestamps are recommended for SR use-cases. We can change th= e sentence. GIM>> Perhaps you can propose some text, that would be helpful. Ack. * Section 4.1.1.1 stated that A separate user-configured destination UDP port is used for the delay measurement in authentication mode due to the different probe message format. Can that be interpreted that there could be concurrent authenticated and un= authenticated test sessions using this protocol? Would different authentica= tion methods require using unique destination UDP port numbers? Yes, and Yes, and these are based on provisioning. GIM>> But that requirement is far outside the TWAMP, as defined in RFC 5357= . Some Session-Sender can use authenticated and some not. It is part o= f RFC 5357. * Section 4.1.2 by introducing the dedicated Loss measurement packet fo= rmat, effectively modifies the behavior defined in RFC 5357 for Session-Sen= der and Session-Reflector. But the document does not state that. Can you cl= arify whether this specification changes the behavior of a Session-Sender a= nd Session-Reflector as defined in RFC 4656 and RFC 5357 respectively for t= he support of packet loss measurement? The direct-mode loss defines new procedure for sender/reflector to col= lect traffic counters, as opposed to timestamp. The rest is the same as RFC= 4656 and 5357. GIM>> I cannot agree with your statement " The rest is the same as RFC 4656= and 5357" because the sender's direct-loss format does not have Error Esti= mate field, Thus, a reflected packet does not have Sender's Error Estimate,= nor Error Estimate of the reflector. And that, in my opinion, is another c= lear indication that *twamp-srpm drafts define a new protocol, separate fro= m OWAMP/TWAMP. That field is specific to timestamps and would not apply to counters= for direct-mode loss measurement. * And a similar question about the use of the separate UDP port number = for the authenticated of the packet loss measurement. * A couple of question to the following text in Section 4.1.3: The local and remote IP addresses of the link are used as Source and Destination Addresses. They can also be IPv6 link local address as probe messages are pre- routed. * What are the addresses of a link? I am assuming this well-known (e.g. RFC 2328). GIM>> I am not familiar with the term "pre-routed". What does it mean? Ensure that packets are routed over the link. * In which scenarios an IPv6 LLA can be used? I am assuming this is well-known (e.g. RFC 5613). GIM>> So, LLA may be used as the source and destination addresses when test= ing an SR tunnel? As mentioned this is for links. * Also, could the use of a routable destination IP address be used a= s a DDOS attack vector? Consider the scenario when an attacker generates SR= -encapsulated packets with the destination IP address other than any of the= SR-terminating nodes. Such a packet will be routed, correct? That does app= ear as a security threat, would you agree? Absolutely do not agree. It is no different than IP routed TWAMP packe= t as defined in [RFC5357]. GIM>> You don't agree that the processing described cannot happen because o= f laws of physics or it wouldn't happen because no one will think of that? = If the latter, I think that that is security threat. There is no new threat like you have mentioned. GIM2>> Hmmm, but how the integrity of TLVs proposed in draft-gandhi-ippm-st= amp-srpm can be protected? These are not protected by HMAC as presented in = figures 3 and 5. The extensions do not change the processing of these existing TLVs de= fined for HMAC. We can add text to indicate this. * Section 4.1.4.2 references Figure 5 that, as I understand it, display= s the format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflecto= r's reflected packet. Which of the two is used for the delay measurement in= the proposed protocol? The probe query packet in the Session-Sender text packet. We can updat= e the name. * Section 4.2.1 states that In one-way measurement mode, the probe response message as defined in Figure 6 is sent back out-of-band to the sender node ... Could you clarify how the responder controls that the response packet is se= nt not in-band but out-of-band? Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This is = existing behaviour for out-of-band. GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines another= new protocol OWAMP Light. And it is not clear what you reference as "this = is existing behavior". Is it to reference behavior of TWAMP test packet? Bu= t the behavior of the TWAMP-Test protocol by itself is neither in-band, nor= out-of-band. It is the encapsulation of the TWAMP test packet that makes i= t either in-band or out-of-band. Right. * How's the method described in Section 4.2.3 is different from the met= hod described in RFC 8403? What is dis= tinctly unique about the loopback mode proposed in the section? There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403. GIM>> So, you believe that proposing to use the method described in RFC 840= 3 for the TWAMP packet is innovation? And what are the benefits of using th= e TWAMP test packet format in the Loopback mode? Please see the draft. * What is the rationale for setting TTL/Hop Limit fields always to 255 = for IPv4, MPLS, and IPv6 (per Section 4.3.1)? This is as defined in Section 4.2 of RFC 5357 (Bullet 4). GIM>> I believe you've misunderstood the text in RFC 5357. This bullet spec= ifies the behavior of a Session-Reflector. It is to try to read TTL value o= f the received TWAMP test packet and copy the value in Sender TTL field of = the reflected packet. If the Session-Reflector cannot access the TTL field,= it MUST write 255 in the Sender TTL field. So, I think that my questions s= till remains. Please see Section 4.2.1 of RFC 5357. * Section 4.3.3 states that a zero-value UDP checksum may be used in so= me scenarios. RFC 8085 allows that but in very specific cases that are docu= mented in detail in Section 3.4.1. Do you believe that the case of this pro= tocol checks all the requirements for allowing the use of Zero UDP checksum= as specified in RFC 8085? Also, I believe that allowing the use of Zero UD= P checksum in some scenarios, this protocol introduces a security threat th= at must be thoroughly analyzed in the Security Considerations section. This is described in RFC 6936. It will be very specific to the UDP por= t provisioned for TWAMP. We will add reference to RFC 6936 in Security Sect= ion. GIM>> I don't think that the reference is sufficient for the Securit Consid= eration. I'd expect some extended discussion on why using zero UDP header c= hecksum is not a security threat for *twamp-srpm protocol. Please see reply above. * Section 8 refers to "liveness monitoring of Links and SR Paths". This= appears as the replication of functionality provided by BFD/S-BFD protocol= s. Is such comparison accurate? If it is, shouldn't the proposal be also re= viewed by the BFD WG? TWAMP probe messages are used today for synthetic packet loss which c= an also be used to detect connection loss (performance metric). The section= simply highlights this obvious metric. GIM>> Can you point to a document that has defined "TWAMP probe messages a= re used today for synthetic packet loss"? Also, which document defines loss= of connectivity as a performance metric? Does *twamp-srpm proposes to use = the new protocol to detect the loss of path continuity? For example Y.1731 has such notion of connection loss. TWAMP is used= widely for synthetic packet loss and is well-known. There is no change in = protocol. This is reported metric. GIM2>> What are packet transmission frequencies authors envisioned for that= mode? A single-digit millisecond? It depends on the implementation. * I found the Security Section of the proposed protocol inadequately te= rse and missing very important threats that this protocol introduces in the= network. Other than referring RFC 6936 for zero checksum what else is missing? = Otherwise it is no different than RFC 8762 (STAMP). GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm drafts. The use = of source IP addresses, as mentioned above, appears to be another security = risk introduced by *-twamp-srpm drafts. There is no mention of Source IP address above. * draft-gandhi-ippm-twamp-srpm As I understand it, the motivation for the Loss Measurement mode defined in= this specification is to collect "in-profile" counters. Is that correct? D= o you see as essential for this mode that the query messages are in-band wi= th the flow being profiled? In your opinion, how using an out-of-band metho= d of collecting these counters, e.g., by using ICMP multi-part message exte= nsion per RFC 4884, could affect the accuracy comparing with the method in = this protocol? How the impact changes if extended ICMP messages are in-band= with the profiled flow? Yes, they need to be in-band with the flow, to collect the counter f= rom the right forwarding paths for the flow. Discussion of using ICMP for d= irect-mode loss measurement is outside the scope of this draft. GIM2>> I think that the assumption "they need to be in-band with the flow, = to collect the counter from the right forwarding paths for the flow" is tec= hnically inaccurate. Otherwise, how SNMP queries could work for decades of = networking history? -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD --_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Gyan,

 

Thanks for your review= comments. Please see inline with <RG4>=85

 

From: Gyan Mishra <hay= abusagsm@gmail.com>
Date: Saturday, December 5, 2020 at 1:16 AM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Greg Mirsky <gregory.mirsky@ztetx.com>, IETF IPPM WG <i= ppm@ietf.org>, James Guichard <james.n.guichard@futurewei.com>, Ra= kesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.org <i= ppm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org&= gt;, spring@ietf.org <spring@ietf.org>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf= .org/html/draft-gandhi-spring-twamp-srpm-11

Hi Rakesh 

 

Had a general question.

 

I read through the draft again and a question came t= o mind as this draft is Standards Track, what new is being introduced other= then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses t= he MPLS data plane and SRv6 which used the IPv6 data plane.  I don=92t believe there exists  a Sta= ndards track draft procedure for how to use STAMP over IP network or MPLS n= etwork as an example.  

 

Section 4.1.4 describes SR-MPLS use case and SRv6 us= e case.  As there appears to be nothing new introduced such as a new I= ANA TLV or code point or even a special SID code point  for TWAMP, all= basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now. &= nbsp;

 

What is the new invention here?

 

<RG4> SPRING dra= fts define the procedure for using TWAMP Light and STAMP test-messages for = SR path and links. The corresponding IPPM drafts define the extensions need= ed for them. The SPRING drafts also use the extensions for them defined in the corresponding IPPM drafts. The extensio= ns are needed for (1) in-band response request e.g. for two-way mode for li= nks and SR path, (2) Return path for SR e.g. when using bidirectional SR Pa= th, and (3) for collecting TX and RX traffic counters in-band for direct-mode loss measurement.

 

Sorry but I may have missed something.

 

My thoughts are at most this be a BCP or I am thinki= ng informational draft would be appropriate.

 

<RG4> Given abov= e context, if WG thinks that any of the drafts should be BCP or Information= al or Experimental, we can update the draft accordingly.<= /p>

 

Thoughts?

 

Gyan

 

Hi Rakesh,

thank you for the continued discussion. You can find= my follow-up notes in-line below under GIM3>> tag. I felt that one c= omment is at the root of our different views on what is considered to be a = problem that drafts solve. You've said:

<RG3> As mentioned, the extensions defined are= for the direct-mode packet loss measurement for TWAMP Light and STAMP.

But draft-ietf-ippm-stamp-option-tlv, currently in  Submitted to IESG = for Publication WG state according to IETF datatracker, includes Section 4.= 5 Direct Measurement TLV. It is noted in the section:

   The Direct Measurement TLV enables coll= ection of the number of in-
   profile packets, i.e., packets that form a specific data flow,= that
   had been transmitted and received by the Session-Sender and Se= ssion-
   Reflector, respectively.  The definition of "in-prof= ile packet" is
   outside the scope of this document and is left to the test ope= rators
   to determine.

 

<RG4>=

Hi Greg,

The motivation has bee= n there in the draft-gandhi-ippm-stamp-srpm, Section 1. Copied below for th= e convenience.

 

   The STAMP message with a TLV fo= r "direct measurement" can be used for

   combined Delay + Loss measureme= nt [I-D.ietf-ippm-stamp-option-tlv].

   However, in order to use only f= or loss measurement purpose, it

   requires the node to support th= e delay measurement messages and

   support timestamp for these mes= sages (which may also require clock

   synchronization).  Further= more, for hardware-based counter collection

   for direct-mode loss measuremen= t, the optional TLV based processing

   adds unnecessary overhead (as c= ounters are not at well-known

   locations).

 

Thus I cannot see any technical need for the introdu= ction of yet another way of direct loss measurement in STAMP. As for t= he case of TWAMP Light, I believe that there's no sufficient evidence that = the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historicall= y, all extensions applicable to TWAMP Light have been introduced through ex= tending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way= of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 535= 7.

 

<RG4> The IPPM W= G Informational draft on TWAMP Light direct-mode loss measurement, defines = the message format and corresponding SPRING draft defines the procedure for= using that. It is not clear to me how providing an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357.<= /o:p>

 

Thanks,

Rakesh

 

 

More notes can be found below.

 

Regards,

Greg

 

 

On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Greg for your further repl= y and the discussions.

Good to know that you do see a ne= ed for the extensions for the direct-mode packet loss detection and the aut= hors are actively working on an alternate methods using BFD (as you mentioned below).

GIM3>> As you've recognized, in draft-mirmin-bfd-extended we build an integrated OAM based on the = lightweight Fault Management protocol with optional Performance Monitoring,= based on RFC 6374. RFC 6374, in turn, provides a rich set of performance m= easurement methods, including direct loss measurement.

Please see replies inline with <R= G3>=85.

From: Greg Mirsky <gregimirsky@gmail.c= om>
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;, Greg Mirsky <gregory.mirsky@ztetx.com>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Hi Rakesh,

thank you for the continued discussion. I appreciate your response= s. I am still not convinced of the value these documents add. Please find m= y follow-up notes in-line below under the GIM2>> tag.

 Regards,

Greg 

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

Thank you Gyan and Greg for your rev= iew comments and discussions. Please see inline replies with <RG2>=85=

From: Gyan Mishra <hayabusagsm@gmail.c= om>
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

 Hi Rakesh 

I have been following this thread and to help progress the discuss= ion I would like to provide some comments in-line Gyan> =

Thanks

Gyan

On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.com> wrot= e:

Hi Rakesh,

thank you for the response to my comments. Please find my fol= low-up notes in-lined below under the GIM>> tag. 

Regards,

Greg

On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

Please see replies inline with <RG>=85<= /span>

From: ippm <ippm-bounces@ietf.org&= gt;
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Dear Chairs of the SPRING and IPPM WGs, Authors, et al.,

I've found myself in the situation when two related drafts are in = the WG APs in the SPRING and IPPM WG (with the possibility that expertise f= rom the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a sing= le thread. I hope that would be acceptable and considered by the SPRING WG = as well as IPPM WG.

Usually, the bar for the adoption of a document can be evaluated&n= bsp;by answers to these three questions:

  • Is the document(s) reasonably well-written

I've got surprised that the drafts don't use the terminology from = RFC 4656 and 5357 and introduce their own terminology for Session-Sender an= d Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

<RG> We are ok to change Sender to Se= ssion-Sender and Reflector to Session-Reflector if it helps.

 

GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be pro= perly defined.

   Gyan> I am in complete agreement with Greg about t= erminology and consistency.  The problem with inconsistency is that th= at you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.  The goal should be clear and concise i= n terminology and verbiage.

<RG2> Agree. Will address the = terms from RFC 5357 in the next revision.

<RG> There are many existing RFCs tha= t use term =93Link=94 (e.g. RFC 5613, 5340, 8330, etc.) and term =93Congrue= nt Path=94 (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                  &nb= sp;    C---------D

                  &nb= sp;  /                 \<= o:p>

            A----B    &nbs= p;              E-----F

                  &nb= sp;  \                  /=

                  &nb= sp;  G------------H

Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of "con= gruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

=B7 &n= bsp;       using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

=B7 &n= bsp;       there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.

  • Does the document solve a real problem?

No, it appears that these drafts define a new performance measurem= ent protocol for the purpose of combining OWAMP and TWAMP functionality and= adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technical ar= guments for using a PM protocol instead of, for example, extending the exis= ting OAM mechanisms like ICMP.

 Gyan>  This may sound basic but is a very critical s= ubject going down the same lines of clarity in verbiage so their is no misu= nderstanding.  =93Congruent=94 by definition means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.  The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.  So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=92s the same path or congruent which is vagu= e as to =93exactly=94 which path is taken where here there is criticality a= s to the path being referenced in terms of in-band versus out-of-band.  I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

<RG2> Ok, we will find an appr= opriate term for =93sending packets on the same path as data traffic=94.

<RG2> Extending ICMP for direc= t-mode loss measurement is outside the scope of this draft. But good to see= the agreement for the direct in band packet loss measurement to be done (albeit by some other means).

GIM2>> I feel that you misunderstand my position in regard t= o the use case these four documents try to solve. I don't recall that I've = stated that "direct in-band packet loss measurement" requires any additional standardization work. The Direct Measurement TLV h= as solved that for STAMP and draft-ietf-ippm-stamp-option-tlv is now in the= RFC Editor's queue. I cannot find any valid technical reason to re-open th= is and measure the direct packet loss in a slightly different way. I must point out that a claim that using= fixed positions for the direct packet loss optimizes performance does not = stand for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm)= when the return path is specified in the Return Path TLV and, as I understand it, in some cases even the sec= ond TLV, Node Address TLV, is used. Thus, it is clear that the proposed new= method of direct packet loss measurement does not offer any significant be= nefits comparing to the STAMP's Direct Measurement TLV and appears nothing but superfluous.

<RG3> The direct-mode packet l= oss use-case is typically for the forward direction packet loss. And this d= oes not use the return path TLV. We can clarify that in the draft.

GIM3>> Clarification would be very helpful as = your latest note might be interpreted that the proposed mechanisms are not = applicable in the case of a bi-directional SR tunnel.

<RG> There is a requirement to measur= e performance delay as well as synthetic and direct-mode packet loss in seg= ment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

GIM>> I agree with the requirements you've listed (though the&nb= sp;SPRING WG OAM requirements document has = been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason to use OWAMP/TWAMP for exclusi= ve direct packet loss measurement.  

    Gyan> Agreed

<RG2> There is definitely a need to = do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms a= re for MPLS networks. Note that there was an attempt to extend BFD for dire= ct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.

<RG3> Ok, so you do see a n= eed for the extensions for the direct-mode packet loss detection and the au= thors are actively working on an alternate methods using BFD.   

  • Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly the risk intr= oduced by the protocol on network security, to comprehensively evaluate the= proposed solution.

<RG> About your comment on zer= o checksum, this is described in Security section in RFC 6936. We will add = reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

     Gyan> Agreed 0 UDP MIMA security threats an= d that you need to thorough vetting of RFC 6936.

 <RG2> Yes, will add in t= he next revision. Hope we can work together on needed text.

To summarize my review of these two drafts:

  • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

<RG> The probe and response me= ssages defined in [RFC 5357] are used for delay measurement and synthetic p= acket loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =93extensions=94 = for TWAMP Light.

GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concerned w= ith the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's TR-390, I'm = have learned how different are existing implementations of TWAMP Light. And= that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

  Gyan> I don=92t see the probe a d response messages in T= WAMP RFC 5357 

<RG2> Agree to use term test-p= acket from RFC 5357.

=B7 &n= bsp;       several parts of the proposed protocol, e.g., Zero UDP checksum in I= Pv6, require detailed security analysis, which is currently absent;

     Gyan> Agreed 

<RG2> Please see previous repl= y.

<RG> This is specified in RFC = 6936 Security Section. We will add reference to this RFC in our Security Se= ction as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

GIM>>  I've noted above that a simple reference does not suffici= ently explains why the use of zero UDP checksum in IPv6 header is not decre= mental, does not create a security risk for the protocol. I believe that th= e proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.=

    Gyan> Completely Agree

 <RG2> Please see previou= s reply.

  • I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
<RG> This was to address your previous comment qu=
oted as:
 =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

   mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

   protocol itself. Since TWAMP Light is not a s= tandard but its idea is

   described in the informational text only, I t= hink that the Informational

  track is more appropriate for this specification.= =94

https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

<RG> Having said that, we are = ok to change to PS.

GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which the= extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you= point to the definition, for example, of the Authenticated mode in TWAMP L= ight in the draft-gandhi-spring-twamp-srpm or RFC 5357? 

     Gyan> Agreed 

<RG2> The Appendix I of RFC 53= 57 does have information on the Authentication mode. As specified there, th= is is based on user configured parameters.

=B7 &n= bsp;       I believe that draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol.

<RG> The TWAMP Light extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

 Below, please find my detailed comments, questions on t= hese drafts:

  • draft-gandhi-spring-twamp-srpm

I have several questions about the relationships between this draf= t and Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light = has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of RFC 8545 (apologies for the long quote):

   "TWAMP Light" is an idea described in Appen= dix I ("TWAMP Light
   (Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
   control protocol combined with the TWAMP-Test protocol.  = In
   [RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
   TWAMP Light failed to meet the requirements for IETF protocols= (there
   are no specifications for negotiating this form of operation a= nd no
   specifications for mandatory-to-implement security features), = as
   described in Appendix A of this memo.  See also [LarsAD] = and
   [TimDISCUSS].

   Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br>    component of TWAMP, it is considered reasonable for future sys= tems to
   use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
   is specified in this document).  Clearly, the TWAMP Light= idea
   envisions many components and communication capabilities beyon= d
   TWAMP-Test (implementing the security requirements, for exampl= e);
   otherwise, Appendix I of [RFC5357] would be one sentence long<= br>    (equating TWAMP Light with TWAMP-Test only).

 Since we don't have an IETF document that addressed these op= en questions, I don't think we can have a draft that proposes extensions to= a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.

 Gyan> Agreed 

<RG2> The procedure for using = the RFC 5357 defined messages in TWAMP Light configuration mode is defined = in the corresponding spring drafts. It also describes the provisioning model.

GIM2>> If a return path can be provisioned for TWAMP Light, = why the same method of controlling a test session cannot be used for STAMP?=

<RG3> It is not expected that = all STAMP TLV extensions need to be supported for TWAMP Light using provisi= oning. 

 <RG> This was to address= your previous comment quoted as

 =93- as I understand, the draft is=
 applicable to TWAMP Light mode,

   mentioned in the informational Appendix I in = RFC 5357, not the TWAMP

   protocol itself. Since TWAMP Light is not a s= tandard but its idea is

   described in the informational text only, I t= hink that the Informational

   track is more appropriate for this specificat= ion.=94

https://m= ailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/

<RG> Having said that, we are = ok to change to PS as you mentioned above.

<RG> BTW, despite only differe= nce of fixed vs. variable length payload in STAMP vs. TWAMP Light, the STAM= P is a proposed standard as RFC 8762 (and it uses the same approach of provisioning  as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, = and thus the light, simpler, version of TWAMP-Test component of TWAMP proto= col. I cannot find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer not= to refer to RFC 8762 STAMP in the discussion of "extension" to T= WAMP Light.

<RG2> The Authentication infor= mation is user-configured as shown in Section 3.1 of the draft-gandhi-sprin= g-twamp-srpm, and is also described in Appendix I of RFC 5357.

Now a number of more specific questions.

draft-gandhi-spring-twamp-srpm:

  • In the Introduction it is stated that:

  The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provid= es
   simplified mechanisms for active performance measurement in Cu= stomer
   IP networks by provisioning UDP paths and eliminates the need = for
   control-channel signaling.

I can not find where, either Appendix I or TR-390, "elim= inated the need for control-channel signaling". Also, could you point = where the referenced documents describe "provisioning UDP paths"?

<RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.<=
/pre>

 


=93This example eliminates the need=
 for the TWAMP-Control protocol, and


   assumes that the Session-Re=
flector is configured=94

GIM>> I think that the text you're proposing is even more co= nfusing. It is not clear which example the sentence is referring to. Also, = what is the basis for such an assumption? 

<RG2> This is the exact text f= rom RFC 5357 Appendix I. Please go through the entire Section in that RFC 5= 357 to avoid =93out of context=94 discussion.

  • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

   The procedure uses the mechanisms defined in [RFC5357= ]
   (TWAMP Light) and its extensions for Performance Measurement.<= o:p>

I think that the reference must be to Appendix I, not RFC 5357. Al= so, could you please specify which extensions of TWAMP Light have been used= in this draft?

<RG> We can add the Appendix I as ref= erence in the next revision. Extensions are defined in draft-gandhi-ippm-tw= amp-srpm, we can add this reference.

GIM>> The problem, in my view, is that Appendix I of RFC 535= 7 must be a normative reference while it is, by its nature, an Informationa= l document.  

<RG2> If approved, it is fine = to have informational draft/RFC in a normative reference. But RFC 5357 is P= S.

  • In Section 2.3 describing the reference model is noted:

    •    The probe response message is typically sent to the s= ender node R1.

    In which scenarios the reflector acts differently? How such behavi= or is related to the behavior of a TWAMP Session-Reflector, as defined in R= FC 5357?

    <RG> Do you prefer we remove =93typic= ally=94 from the sentence?

GIM>> If that fits into the operational model of the new pro= tocol you're defining. 

  • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

<RG> Both, please see Section = 4.1.3. =93Link=94 is well known term used in many existing RFCs (please see= RFC 5613, 5340, 8330).

GIM>> Thank you for the references. I couldn't find a defini= tion of an object "Link" (capitalized) but only "link" = (lower case). Hence, since the draft consistently uses the capitalized form, I consider it to be something else, something different from a link.=  

<RG2> Ok, we can change Link t= o link in the next revision to avoid confusion.

  • In Section 3 behavior of the reflector described as

   ... no PM state for delay or loss measurement need to= be created on the
   reflector node R5.

That is in contradiction to the behavior of a TWAMP Session-Reflec= tor as defined in RFC 5357. Could you provide a reference to an IETF standa= rd where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?

 Gyan> Valid point 

<RG2> Bidirectional SR tunnel = may have an SR state but the statement above is that no PM (i.e. TWAMP Ligh= t) protocol session state is created for it. We can clarify in the next revision.

GIM2>> So-called stateless Session-Reflector in TWAMP Light = is only one option. I am well-familiar with the implementation that uses th= e stateful mode. 

<RG3> What information statefu= l PM need to maintain in the state on the reflector? Doesn=92t that cause s= cale issues. We can add in the draft you if there is anything specifically needed in the spec.

GIM3>> RFCs 5357 and 8762 are clear about what= information must be maintained by a Session-Reflector. The Session-Reflect= or must have knowledge of the test session state and count reflected test p= ackets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus = the method enables the measurement of the one-way packet loss metric.<= /o:p>

 <RG> Quoting the text fr= om Appendix I in RFC 5357. We can quote the text as is. 

=93In the case of TWAMP Light, the Sessi=
on-Reflector does not necessarily have knowledge of the session state. =93<=
/span>

GIM>> By the informational nature of Appendix I, the text is= not normative. I am familiar with the implementation of TWAMP Light which = does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

 <RG2> Ok, we can discuss= what information is to be maintained in that state on the reflector for sy= nthetic packet loss. We can add appropriate text if you can help please.

GIM2>> I don't see any reason to do that as that already def= ined in RFC 8762 and draft-ietf-ippm-stamp-yang 

<RG3> Ok. 

=B7 &n= bsp;       Further, in Section 3 the selection of UDP port explained as the fol= lowing:

   As specified in [RFC8545], the reflector
   supports the destination UDP port 862 for delay measurement pr= obe
   messages by default.  This UDP port however, is not used = for loss
   measurement probe messages.

To the best of my understanding, as one of the contributors and&nb= sp;Editors of RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Ses= sion-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.<= /p>

 Gyan> Agreed 

<RG2> Yes, we can use port 862= for both delay and synthetic packet loss =96 they are using the same test = packet. There is no change proposed in the draft.

GIM2>> Packet delay and synthetic packet loss measurements a= re already supported in RFC 8762. Are you proposing a new protocol to dupli= cate the STAMP functionalities?

<RG3> As mentioned, the extens= ions defined are for the direct-mode packet loss measurement for TWAMP Ligh= t and STAMP.

<RG> The packet loss in existi= ng RFC 5357 refers to synthetic loss as there is no support for direct-mode= loss in RFC 5357. We can change the text to clarify as =93This UDP port however, is not used for direct-mode loss meas= urement probe messages.=94

GIM>> I've found that there's some misconception in the draf= t. RFC 8545 re-assigned UDP port 862 not for "delay measurement probe = messages" but for TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.

  • Then the draft states that

The sender uses the UDP port number following the guidelines speci= fied in Section 6 in [RFC6335].

Could you point to the guidelines that a user can use when selecti= ng a UDP port number of a test session?

Gyan> Good point  

<RG> Please see section 6 in [RFC6335= ]. We can cite the range which will be the same as used in [RFC8762]. This = was also discussed earlier.

https://mailarchive.ietf.org/arch/msg/i= ppm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

GIM>> I've looked through Section 6 but I don't find anythin= g specifically applicable to this draft we're discussing. If the protocol t= o use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way. 

<RG2> This would be, User Ports and Dynamic Ports=
 ranges, which are defined in [RFC6335=
]. Yes, we can add this text.
  • At the closing of the paragraph, we read that

  The number of UDP ports with PM functionality needs to be m= inimized due
   to limited hardware resources.

Does a UDP port number pose PM functionality? How it is assigned t= o the port number?

<RG> UDP ports are user config= ured for delay and direct-mode loss PM as described in Section 3.1.<= o:p>

GIM>> Can UDP port 862 be used? Also, requiring that the dir= ect-loss measurement uses port number different from the one used by a TWAM= P-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l. 

<RG2> If we add a field in the= packet then UDP port 862 may be used along with the new field. But it will= require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

  • Following the above-quoted text, in Section 3 is noted:

    •    For Performance Measurement, probe query and response= messages are
       sent as following:

    Could you clarify if the listed further procedures deviate from OW= AMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for Session= -Sender and Session-Reflector respectively?

    <RG> Probe messages follow the same p= rocedure as defined in RFC 4656 and RFC 5357.

GIM>> All messages, i.e., TWAMP-Test packets as well as the = defined in draft-gandhi-ippm-twamp-srpm? 

 <RG2> Yes, unless otherw= ise specified in the draft-gandhi-ippm-twamp-srpm.

  • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

      the probe messages are sent on the
      congruent path of the data traffic by the sender node<= o:p>

It is not clear what "the congruent path" means. The definition o= f congruency in geometry tells us that an object B is congruent t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

       Gyan> Agreed.  The use of congr= uent in the context of pathing is confusing as the path being addressed may= not be reflected accurately by the term congruent.

<RG2> As replied above.=

<RG> There are many existing R= FCs that use term Congruent Path (e.g. RFC 5921, 6669) without defining the= m. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

GIM>> I cannot assume what was the context of these RFCs. I'= ve sketched a network diagram above to illustrate that a "congrue= nt path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

<RG2> As replied above.=

  • The last paragraph in Section 3 refers to work on iOAM:

    •    The In-Situ Operations, Administration, and Maintenan= ce (IOAM)
       mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
       SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
       information such as timestamp in-band as part of the data pack= ets,
       and are outside the scope of this document.

    Is iOAM in the scope of this specification? What are the relations= hips between iOAM and draft-gandhi-spring-twamp-srpm?

    <RG> As mentioned in the draft, IOAM = is outside the scope.

GIM>> Yes, but it appears that references to the two IOAM-re= lated drafts have some purpose. What is it? How are these drafts related to=  draft-gandhi-spring-twamp-srpm? 

<RG2> We can remove them if it= is confusing. It is informational text (was added to address a review comm= ent).

  • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?

<RG> Yes, this can be Yang mod= el. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

GIM>> I think that theremust be some discussion on how = the new protocol is configured. If TWAMP YANG data model can be augmented, = I'd expect that being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anything about the configuration of the protocol. = ;

<RG2> The Yang model extension= s are not in the scope of this draft 

  • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

<RG> Existing TWAMP messages d= o not support =93direct-mode=94 loss measurement. We can add =93direct-mode= =94 in the text to clarify.

GIM>> True, direct loss measurement, in fact, is not active = measurement and thus is outside the scope of Two-Way Active Measurement Pro= tocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf 

<RG2> RFC 7799 does not say us= ing Test-packets to collect counters for direct-mod loss measurement is pas= sive.

GIM2>> Per RFC 7799, injecting in-band test packets is the c= haracteristic of an active measurement method. Using out-of-band transport,= e.g., SNMP queries, would be an example of a passive measurement method. 

<RG3> Ok, so you answered your= own question that the direct-mode packet loss extension defined is =93acti= ve measurement=94 method.

  • Section 4.1.1 requires that

  The Destination UDP port cannot be used as Source port, sin= ce
   the message does not have any indication to distinguish betwee= n the
   query and response message.

Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

       Gyan> Good question =

<RG2> Yes, it is unique in the= domain.

<RG> This is user-defined and = is up to the user what UDP port to provision in a domain.=

GIM>> So, can user configure a port number from the User Por= ts range? Or, can the same port number be used on the same system for a num= ber of test sessions? I find the use of UDP port numbers being underspecified.

  • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test packet i= n RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test packet= format to perform both delay and packet loss measurement.

<RG> Ok, we can update the tex= t in the next revision to indicate exact name from the RFC 4656. We can als= o add text to include synthetic packet loss.

GIM>> I think that making it explicit would help. Also, that= will highlight what is being introduced by *twamp-srpm drafts is, in fact,= a new protocol to perform synthetic packet loss measurement. 

 <RG2> No, it does not ch= ange anything for synthetic packet loss.

  • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?

<RG> We can update the text in= the next revision to indicate query format name from RFC 5357.=

GIM>> I cannot find any reference to a query format in RFCs = 4656/5357. Could you please quote from any of these documents?

 <RG2> It is test-packet,= we will use RFC 5357 term.

  • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
<RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
=93For symmetrical size query and respon=
se messages as defined in [RFC6038],=94

GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL= use of the symmetrical test packets. Since *-twamp-srpm proposals do not u= se TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze of a tes= t packet used in the direct-loss measurement. 

 <RG2> The test-packets a= s defined in these existing RFCs are used for delay and synthetic packet lo= ss. The direct-mode test-packets are defined in this draft.

GIM2>> This draft defines only a new packet format for the d= irect packet loss measurement. For STAMP such a mechanism is clearly superf= luous given the Direct Measurement TLV is already defined. 

<RG3> As replied earlier.

  • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

<RG> This is same as TWAMP. Th= ere is no change.

GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the = case for *-twamp-srpm? 

 <RG2> No change in exist= ing in what is there in RFC 5357 and RFC 8186.

  • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

<RG> Hardware timestamps are r= ecommended for SR use-cases. We can change the sentence.<= /p>

GIM>> Perhaps you can propose some text, that would be helpf= ul. 

 <RG2> Ack.

  • Section 4.1.1.1 stated that

   A separate user-configured
   destination UDP port is used for the delay measurement in
   authentication mode due to the different probe message format.=

Can that be interpreted that there could be concurrent authenticat= ed and unauthenticated test sessions using this protocol? Would different a= uthentication methods require using unique destination UDP port numbers?

<RG> Yes, and Yes, and these a= re based on provisioning.

GIM>> But that requirement is far outside the TWAMP, as defi= ned in RFC 5357.

 <RG2> Some Session-Sende= r can use authenticated and some not. It is part of RFC 5357.

  • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

<RG> The direct-mode loss defi= nes new procedure for sender/reflector to collect traffic counters, as oppo= sed to timestamp. The rest is the same as RFC 4656 and 5357.

GIM>> I cannot agree with your statement " The rest is = the same as RFC 4656 and 5357" because the sender's direct-loss format= does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of the re= flector. And that, in my opinion, is another clear indication that *twamp-s= rpm drafts define a new protocol, separate from OWAMP/TWAMP.

 <RG2> That field is spec= ific to timestamps and would not apply to counters for direct-mode loss mea= surement.

  • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
  • A couple of question to the following text in Section 4.1.3:

   The local and remote IP
   addresses of the link are used as Source and Destination Addre= sses.
   They can also be IPv6 link local address as probe messages are= pre-
   routed.

    • What are the addresses of a link?

<RG> I am assuming this well-k= nown (e.g. RFC 2328).

GIM>> I am not familiar with the term "pre-routed"= . What does it mean? 

 <RG2> Ensure that packet= s are routed over the link.

    • In which scenarios an IPv6 LLA can be used?

<RG> I am assuming this is wel= l-known (e.g. RFC 5613).

GIM>> So, LLA may be used as the source and destination addr= esses when testing an SR tunnel? 

 <RG2> As mentioned this = is for links.

    • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such a packet will be routed, correct? That does appear as a security threat, would you agree= ?

<RG> Absolutely do not agree. = It is no different than IP routed TWAMP packet as defined in [RFC5357].

GIM>> You don't agree that the processing described cannot h= appen because of laws of physics or it wouldn't happen because no one will = think of that? If the latter, I think that that is security threat.

 <RG2> There is no new th= reat like you have mentioned.

GIM2>> Hmmm, but how the integrity of TLVs proposed in = draft-gandhi-ippm-stamp-srpm can be protected? These are not protected= by HMAC as presented in figures 3 and 5.     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   

<RG3> The extensions do not ch= ange the processing of these existing TLVs defined for HMAC. We can add tex= t to indicate this.

  • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the&= nbsp;format of a probe query message. In figure two references to RFC 5357 = are provided - a section that references RFC 4656 OWAMP definition of the S= ession-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the two is= used for the delay measurement in the proposed protocol?

    • <RG> The probe query packet in= the Session-Sender text packet. We can update the name.<= /p>

    • Section 4.2.1 states that

       In one-way measurement mode, the probe response messa= ge as defined in
       Figure 6 is sent back out-of-band to the sender node ...<= /o:p>

    Could you clarify how the responder controls that the response pac= ket is sent not in-band but out-of-band?

    <RG> Please refer to section 3= .1 in draft-gandhi-ippm-twamp-srpm.  This is existing behaviour for ou= t-of-band.

GIM>> draft-gandhi-ippm-twamp-srpm does not specify tha= t it defines another new protocol OWAMP Light. And it is not clear what you= reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and. 

 <RG2> Right.=

GIM>> So, you believe that proposing to use the method descr= ibed in RFC 8403 for the TWAMP packet is innovation? And what are the benef= its of using the TWAMP test packet format in the Loopback mode?

 <RG2> Please see the dra= ft.

  • What is the rationale for setting TTL/Hop Limit fields always to 255 for IP= v4, MPLS, and IPv6 (per Section 4.3.1)?

<RG> This is as defined in Sec= tion 4.2 of RFC 5357 (Bullet 4).

GIM>> I believe you've misunderstood the text in RFC 5357. T= his bullet specifies the behavior of a Session-Reflector. It is to try to r= ead TTL value of the received TWAMP test packet and copy the value in Sender TTL field of the reflected packet. If the Ses= sion-Reflector cannot access the TTL field, it MUST write 255 in the Sender= TTL field. So, I think that my questions still remains.

 <RG2> Please see Section= 4.2.1 of RFC 5357.

  • Section 4.3.3 states that a zero-value UDP checksum may be used in some sce= narios. RFC 8085 allows that but in very specific cases that are documented= in detail in Section 3.4.1. Do you believe that the case of this protocol = checks all the requirements for allowing the use of Zero UDP checksum as specified in RFC 8085? Also, I be= lieve that allowing the use of Zero UDP checksum in some scenarios, this pr= otocol introduces a security threat that must be thoroughly analyzed in the= Security Considerations section.

<RG> This is described in RFC = 6936. It will be very specific to the UDP port provisioned for TWAMP. We wi= ll add reference to RFC 6936 in Security Section.

GIM>> I don't think that the reference is sufficient for the= Securit Consideration. I'd expect some extended discussion on why usi= ng zero UDP header checksum is not a security threat for *twamp-srpm  protocol.

 <RG2> Please see reply a= bove.

  • Section 8 refers to "liveness monitoring of Links and SR Paths". = This appears as the replication of functionality provided by BFD/S-BFD prot= ocols. Is such comparison accurate? If it is, shouldn't the proposal be als= o reviewed by the BFD WG?

<RG> TWAMP  probe message= s are used today for synthetic packet loss which can also be used to detect= connection loss (performance metric). The section simply highlights this obvious metric.

GIM>> Can you point to a document that has defined "TWA= MP  probe messages are used today for synthetic packet loss"? Als= o, which document defines loss of connectivity as a performance metric? Does *twamp-srpm proposes to use the new protocol to detect the lo= ss of path continuity?

 <RG2> For example Y.1731= has such notion of connection loss. TWAMP is used widely for synthetic pac= ket loss and is well-known. There is no change in protocol. This is reported metric.

GIM2>> What are packet transmission frequencies authors envi= sioned for that mode? A single-digit millisecond? 

<RG3> It depends on the implem= entation.

  • I found the Security Section of the proposed protocol inadequately terse an= d missing very important threats that this protocol introduces in the netwo= rk.

<RG> Other than referring RFC = 6936 for zero checksum what else is missing? Otherwise it is no different t= han RFC 8762 (STAMP).

GIM>> I cannot see how RFC 8762 is relevant to *twamp-srpm d= rafts. The use of source IP addresses, as mentioned above, appears to be an= other security risk introduced by *-twamp-srpm drafts. 

 <RG2> There is no mentio= n of Source IP address above.

  • draft-gandhi-ippm-twamp-srpm

As I understand it, the motivation for the Loss Measurement mode d= efined in this specification is to collect "in-profile" counters.= Is that correct? Do you see as essential for this mode that the query messages are in-band with the flow being profiled= ? In your opinion, how using an out-of-band method of collecting these coun= ters, e.g., by using ICMP multi-part message extension per RFC 4884, c= ould affect the accuracy comparing with the method in this protocol? How the impact changes if extended ICMP messa= ges are in-band with the profiled flow?

 <RG2> Yes, they need to = be in-band with the flow, to collect the counter from the right forwarding = paths for the flow. Discussion of using ICMP for direct-mode loss measurement is outside the scope of this draft.

GIM2>> I think that the assumption "they need to be in-= band with the flow, to collect the counter from the right forwarding paths = for the flow" is technically inaccurate. Otherwise, how SNMP queries could work for decades of networking history?<= /p>

 

--

--_000_DM6PR11MB3115AA86AEB65611AFE973A4BFF00DM6PR11MB3115namp_-- From nobody Sat Dec 5 11:23:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E223A0AC1; Sat, 5 Dec 2020 11:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 gsxzP-VB1aVQ; Sat, 5 Dec 2020 11:23:08 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 46C4B3A0ABE; Sat, 5 Dec 2020 11:23:08 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id f17so5690138pge.6; Sat, 05 Dec 2020 11:23:08 -0800 (PST) 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=DfHTkuCXMb1EwH9YP+h9aoyAU1S3jBx0c/vN2vy8LS8=; b=u1ZzoO1/qJ/Rt/nfevXA2g9Hx7bsunMWCWQyftB9J+Mj6zHjkO2GvCOYi8xEQOLNdz bcwjvvSDdYR+5+/dvdHcik9rfMwSeoJjcnMOI8LGfBpFrrEl74HusEnQUgYV1QhzN3oX NXHYqO4VZnpKyhwV4+j/X/aLhlUbRGpyyw3EDPbZLzZeiXL+uNksWbZvFGiDhG4pGxJ7 EkPrkxZb2Wbl57E1b1FWaLfkR1m7mVTKKFkGaHz4FSguHuhQFqS04IxGAd3c2uk+ZFYB 1uVVU4qSHjSmqIut3AQTVF+GhP4/cn46Q7amcCDDbi+XUBrqF1uarjTxM9K/qzDnkrLj +Tug== 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=DfHTkuCXMb1EwH9YP+h9aoyAU1S3jBx0c/vN2vy8LS8=; b=oqgu27gWbWI12LCn/Gfyxbnz/Ev5phl2T9Zz6sj4HZUceCxpwr5uTy9xC0wC8tQl2y N1+wtxWvssUTDRVQV/6wrJCTKeS3lVx8nzoCAvquEysSopayIhN8b6kPG8fskufwCVGj ffWGkfBm8tizBPbewX0P0iPmq7+ww0awwWTPco8OY0KDWd4HZEU4bZD7J2UeZPIaWnwz o8nhFHpB2PiPETqX9HyVXKJhgOzMfCx/bng8s4R26TLvYlzOri076iSjiNobYe8YHZH1 k4cjk3yfkld3wErtpC8u9eB5uxJhLyQ4ZfAHwDAY5aLes6A049O05aqbPfxSnm/jHG7t t37A== X-Gm-Message-State: AOAM5320gWavV4aKtxB+SQLX5pwlg2BBDDR6kkWNCX0HxkoOpbo2Q9fA 6Ff6B+m+KfubJpiDlzJqRYNOqIIf7vyUQ2YEfko= X-Google-Smtp-Source: ABdhPJzSoneayfQfuWpUrfQsvxfRvZarw1wCmQsyGIXrqnbuu6fCBU0cyaY3QT9iuHhfIvBxXQ1qkRsklEFkUz0GVoA= X-Received: by 2002:a65:5ac4:: with SMTP id d4mr3407642pgt.50.1607196187043; Sat, 05 Dec 2020 11:23:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 5 Dec 2020 14:22:55 -0500 Message-ID: To: "Rakesh Gandhi (rgandhi)" Cc: Greg Mirsky , Greg Mirsky , IETF IPPM WG , James Guichard , "ippm-chairs@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d02cca05b5bc855d" Archived-At: Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 19:23:17 -0000 --000000000000d02cca05b5bc855d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh Please see in-line On Sat, Dec 5, 2020 at 10:32 AM Rakesh Gandhi (rgandhi) wrote: > Hi Gyan, > > > > Thanks for your review comments. Please see inline with =E2=80=A6 > > > > *From: *Gyan Mishra > *Date: *Saturday, December 5, 2020 at 1:16 AM > *To: *Greg Mirsky > *Cc: *Greg Mirsky , IETF IPPM WG , > James Guichard , Rakesh Gandhi (rgandhi) = < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > > > Had a general question. > > > > I read through the draft again and a question came to mind as this draft > is Standards Track, what new is being introduced other then a procedure o= f > how to use TWAMP in SR networks SR-MPLS which reuses the MPLS data plane > and SRv6 which used the IPv6 data plane. I don=E2=80=99t believe there e= xists a > Standards track draft procedure for how to use STAMP over IP network or > MPLS network as an example. > > > > Section 4.1.4 describes SR-MPLS use case and SRv6 use case. As there > appears to be nothing new introduced such as a new IANA TLV or code point > or even a special SID code point for TWAMP, all basic vanilla SR, that > without this draft you could run STAMP, TWAMP, OWAMP over SR which has > existed for a while now. > > > > What is the new invention here? > > > > SPRING drafts define the procedure for using TWAMP Light and STAMP > test-messages for SR path and links. The corresponding IPPM drafts define > the extensions needed for them. The SPRING drafts also use the extensions > for them defined in the corresponding IPPM drafts. The extensions are > needed for (1) in-band response request e.g. for two-way mode for links a= nd > SR path, (2) Return path for SR e.g. when using bidirectional SR Path, an= d > (3) for collecting TX and RX traffic counters in-band for direct-mode los= s > measurement. > > Gyan> Understood. Just to see if a precedence has already been set if > you point me another case where Spring or any other WG RFC Standards Trac= k > that has defined procedures to use IPPM extensions. If this is the firs= t > and may also set a new precedent, I think it=E2=80=99s a valid WG discus= sion. > > Sorry but I may have missed something. > > > > My thoughts are at most this be a BCP or I am thinking informational draf= t > would be appropriate. > > > > Given above context, if WG thinks that any of the drafts should be > BCP or Informational or Experimental, we can update the draft accordingly= . > > Gyan> Agreed. Thank you > > Thoughts? > > > > Gyan > > > > On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the continued discussion. You can find my follow-up notes > in-line below under GIM3>> tag. I felt that one comment is at the root of > our different views on what is considered to be a problem that drafts > solve. You've said: > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > But draft-ietf-ippm-stamp-option-tlv > , > currently in Submitted to IESG for Publication WG state according to IET= F > datatracker, includes Section 4.5 Direct Measurement TLV. It is noted in > the section: > > The Direct Measurement TLV enables collection of the number of in- > profile packets, i.e., packets that form a specific data flow, that > had been transmitted and received by the Session-Sender and Session- > Reflector, respectively. The definition of "in-profile packet" is > outside the scope of this document and is left to the test operators > to determine. > > > > > > Hi Greg, > > The motivation has been there in the draft-gandhi-ippm-stamp-srpm, Sectio= n > 1. Copied below for the convenience. > > > > The STAMP message with a TLV for "direct measurement" can be used for > > combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv > > ]. > > However, in order to use only for loss measurement purpose, it > > requires the node to support the delay measurement messages and > > support timestamp for these messages (which may also require clock > > synchronization). Furthermore, for hardware-based counter collection > > for direct-mode loss measurement, the optional TLV based processing > > adds unnecessary overhead (as counters are not at well-known > > locations). > > > > Thus I cannot see any technical need for the introduction of yet another > way of direct loss measurement in STAMP. As for the case of TWAMP Light, = I > believe that there's no sufficient evidence that the proposed direct > loss-measurement measurement method benefits existing implementations of > TWAMP Light. Also, historically, all extensions applicable to TWAMP Light > have been introduced through extending TWAMP proper, i.e., extending > TWAMP-Control and TWAMP-Test. The way of "extending" TWAMP Light presente= d > in the drafts we are discussing is, in my opinion, in violation of RFC 53= 57. > > > > The IPPM WG Informational draft on TWAMP Light direct-mode loss > measurement, defines the message format and corresponding SPRING draft > defines the procedure for using that. It is not clear to me how providing > an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357. > > > > Thanks, > > Rakesh > > > > > > More notes can be found below. > > > > Regards, > > Greg > > > > > > On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for your further reply and the discussions. > > *Good to know that you do see a need for the extensions for the > direct-mode packet loss detection and the authors are actively working on > an alternate methods using BFD (as you mentioned below).* > > GIM3>> As you've recognized, in draft-mirmin-bfd-extended > we > build an integrated OAM based on the lightweight Fault Management protoco= l > with optional Performance Monitoring, based on RFC 6374. RFC 6374, in tur= n, > provides a rich set of performance measurement methods, including direct > loss measurement. > > Please see replies inline with =E2=80=A6. > > *From: *Greg Mirsky > *Date: *Monday, November 30, 2020 at 11:30 AM > *To: *Rakesh Gandhi (rgandhi) > *Cc: *Gyan Mishra , IETF IPPM WG , > James Guichard , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > spring@ietf.org , Greg Mirsky > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh, > > thank you for the continued discussion. I appreciate your responses. I am > still not convinced of the value these documents add. Please find my > follow-up notes in-line below under the GIM2>> tag. > > Regards, > > Greg > > On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Gyan and Greg for your review comments and discussions. Please > see inline replies with =E2=80=A6 > > *From: *Gyan Mishra > *Date: *Wednesday, November 25, 2020 at 12:34 PM > *To: *Greg Mirsky > *Cc: *IETF IPPM WG , James Guichard < > james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) < > rgandhi@cisco.com>, ippm-chairs@ietf.org , > spring-chairs@ietf.org , spring@ietf.org < > spring@ietf.org> > *Subject: *Re: [spring] [ippm] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Hi Rakesh > > I have been following this thread and to help progress the discussion I > would like to provide some comments in-line Gyan> > > Thanks > > Gyan > > On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky wrote= : > > Hi Rakesh, > > thank you for the response to my comments. Please find my follow-up notes > in-lined below under the GIM>> tag. > > Regards, > > Greg > > On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgandhi) > wrote: > > Thank you Greg for taking time for thoroughly reviewing the documents and > providing the comments. > > Please see replies inline with =E2=80=A6 > > *From: *ippm > *Date: *Friday, November 6, 2020 at 11:18 AM > *To: *James Guichard > *Cc: *spring@ietf.org , ippm-chairs@ietf.org < > ippm-chairs@ietf.org>, spring-chairs@ietf.org , > IETF IPPM WG > *Subject: *Re: [ippm] [spring] WG Adoption Call for > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 > > Dear Chairs of the SPRING and IPPM WGs, Authors, et al., > > I've found myself in the situation when two related drafts are in the WG > APs in the SPRING and IPPM WG (with the possibility that expertise from t= he > third WG, BFD WG, might be desirable to review the "liveness monitoring")= . > Because these drafts are closely related, I've decided to combine my > questions and comments in a single thread. I hope that would be acceptabl= e > and considered by the SPRING WG as well as IPPM WG. > > Usually, the bar for the adoption of a document can be evaluated by > answers to these three questions: > > - Is the document(s) reasonably well-written > > I've got surprised that the drafts don't use the terminology from RFC 465= 6 > and 5357 and introduce their own terminology for Session-Sender and > Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are > used in the documents without proper definitions. Other than that both > drafts are readable and reasonably well-written. > > We are ok to change Sender to Session-Sender and Reflector to > Session-Reflector if it helps. > > > > GIM>> I believe that the consistency in terminology between the core RFC > and what is intended as its extension is not only helpful to a reader but= , > to the best of my understanding, is required for IETF specifications. But= I > don't think that switching the terminology will fix the fundamental issue > with the proposal. The operation that is required from the remote entity, > whether it is referred to as responder or Session-Reflector, is not defin= ed > in Appendix I of RFC 5357, nor in RFCs 4656 or 5357 itself. In my opinion= , > the behavior required, as described in the draft, cannot be characterized > as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely > new protocol that, if there's a need in the new PM OAM protocol, must be > properly defined. > > Gyan> I am in complete agreement with Greg about terminology and > consistency. The problem with inconsistency is that that you are not > following well known normative references required to understand the > specification leading to confusion and misunderstanding of the > specification. The goal should be clear and concise in terminology and > verbiage. > > Agree. Will address the terms from RFC 5357 in the next revision. > > There are many existing RFCs that use term =E2=80=9CLink=E2=80=9D (e= .g. RFC 5613, > 5340, 8330, etc.) and term =E2=80=9CCongruent Path=E2=80=9D (e.g. RFC 592= 1, 6669) without > defining them. I suspect it is because these are well-known terms. Having > said that, we can add a reference for them if it helps. > > GIM>> Thank you for listing these RFCs. I think I need to clarify my > questions. While a reference to any of RFCs you've mentioned, I don't thi= nk > that will address my concern. In reviewed documents, "Link" is capitalize= d > while referenced RFCs used the lower case form for the term "link". Can > these be used interchangeably? Do they refer to the same network object? > > Now I'll try to illustrate my concern with using the term "congruent path= " > in these drafts (using ASCII-art): > > C---------D > > / \ > > A----B E-----F > > \ / > > G------------H > > Consider an SR tunnel from A to F that traverses the network as > A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definition of > "congruent" as "two figures or objects are congruent if they have the sam= e > shape and size, or if one has the same shape and size as the mirror image > of the other", it looks as the path A-B-G-H-E-F is congruent to that SR > tunnel. But a packet of an active OAM intended to monitor a flow over the > SR tunnel is out-of-band relative to that flow and will not produce any > meaningful measurement. Of course, for the case of the extensions in draf= ts > *-twamp-srpm, direct loss measurement can be performed, as information > collected from node F and packets that collect the counters are not > required to be in-band with the monitored flow. So, this example, in my > opinion, illustrates two of my concerns: > > =C2=B7 using a congruent path for active performance measurement, > e.g., TWAMP or TWAMP Light, may produce information that does not reflect > the condition experienced by the monitored flow. It seems that the > terminology should reflect the fundamental requirement of ensuring that > active OAM test packets are in-band with the monitored flow. > > =C2=B7 there are no technical requirements to justify using in-ba= nd > test packets for direct packet loss measurement. In fact, using the in-ba= nd > method for collecting in-profile counters leads to a waste of bandwidth, > which may have a negative impact on services that require low-latency > and/or low packet loss. As demonstrated in this example, direct packet lo= ss > can be performed using an out-of-band mechanism, e.g., SNMP queries, > Netconf notifications based on YANG data model. > > > - Does the document solve a real problem? > > No, it appears that these drafts define a new performance measurement > protocol for the purpose of combining OWAMP and TWAMP functionality and > adding the ability to collect counters of "in-profile" packets. I couldn'= t > find sufficient technical arguments for using a PM protocol instead of, f= or > example, extending the existing OAM mechanisms like ICMP. > > Gyan> This may sound basic but is a very critical subject going down th= e > same lines of clarity in verbiage so their is no misunderstanding. > =E2=80=9CCongruent=E2=80=9D by definition means shape of an object and i= f you super > imposed two objects on top of each other they fit perfectly and the edges > coincide identically. The problem with congruent is that it is based on > the shape and that shape could be a mirror image or reflection which may > not be exact. So when referring to a SR-TE path taken this could lead to > confusion as to path taken if it=E2=80=99s the same path or congruent whi= ch is > vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality > as to the path being referenced in terms of in-band versus out-of-band. = I > agree that for direct in band packet loss measurement can be done via > existing OAM mechanisme via ICMP. > > Ok, we will find an appropriate term for =E2=80=9Csending packets o= n the > same path as data traffic=E2=80=9D. > > Extending ICMP for direct-mode loss measurement is outside the scop= e > of this draft. But good to see the agreement for the direct in band packe= t > loss measurement to be done (albeit by some other means). > > GIM2>> I feel that you misunderstand my position in regard to the use cas= e > these four documents try to solve. I don't recall that I've stated that > "direct in-band packet loss measurement" requires any additional > standardization work. The Direct Measurement TLV has solved that for STAM= P > and draft-ietf-ippm-stamp-option-tlv is now in the RFC Editor's queue. I > cannot find any valid technical reason to re-open this and measure the > direct packet loss in a slightly different way. I must point out that a > claim that using fixed positions for the direct packet loss optimizes > performance does not stand for cases (Section 4.2.1 and 4.2.2 of > draft-gandhi-spring-stamp-srpm) when the return path is specified in the > Return Path TLV and, as I understand it, in some cases even the second TL= V, > Node Address TLV, is used. Thus, it is clear that the proposed new method > of direct packet loss measurement does not offer any significant benefits > comparing to the STAMP's Direct Measurement TLV and appears nothing but > superfluous. > > The direct-mode packet loss use-case is typically for the forward > direction packet loss. And this does not use the return path TLV. We can > clarify that in the draft. > > GIM3>> Clarification would be very helpful as your latest note might be > interpreted that the proposed mechanisms are not applicable in the case o= f > a bi-directional SR tunnel. > > There is a requirement to measure performance delay as well as > synthetic and direct-mode packet loss in segment-routing networks. OWAMP > and TWAMP protocols are widely deployed for performance delay and synthet= ic > packet loss measurement today. I am not sure extending ICMP for LM is a > good option here. > > GIM>> I agree with the requirements you've listed (though the SPRING WG > OAM requirements document > has > been abandoned and expired 3+ years ago). I believe that there's no > sufficient technical reason to use OWAMP/TWAMP for exclusive direct packe= t > loss measurement. > > Gyan> Agreed > > There is definitely a need to do direct-mode loss measurement in > IP/SR networks, as RFC 6374 mechanisms are for MPLS networks. Note that > there was an attempt to extend BFD for direct-mode loss measurement for > this purpose using RFC 6374 loss measurement message (see > draft-mirmin-bfd-extended-03). > > GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended > in the > past tense. The work and discussion of the proposal continues and the new > version will be published soon. > > * Ok, so you do see a need for the extensions for the direct-mode > packet loss detection and the authors are actively working on an alternat= e > methods using BFD. * > > > - Is the proposed solution technically viable? > > There are too many unaddressed aspects, particularly the risk introduced > by the protocol on network security, to comprehensively evaluate the > proposed solution. > > About your comment on zero checksum, this is described in Security > section in RFC 6936. We will add reference to this RFC in our Security > Section as well. This is only specific to the UDP port locally provisione= d > in the domain by the operator for TWAMP. Other than this, I did not find > any other security related issue in your review below. > > GIM>> I don't think that a mere reference sufficiently explains why the > use of zero UDP checksum in IPv6 header is not decremental, does not crea= te > a security risk for the protocol. > > Gyan> Agreed 0 UDP MIMA security threats and that you need to > thorough vetting of RFC 6936. > > Yes, will add in the next revision. Hope we can work together on > needed text. > > To summarize my review of these two drafts: > > - these propose a new protocol, not an update or enhancement of the > TWAMP-like protocol; > > The probe and response messages defined in [RFC 5357] are used for > delay measurement and synthetic packet loss. The direct-mode packet loss > messages are defined in draft-gandhi-ippm-twamp-srpm > that > match these delay measurement messages. As stated, > draft-gandhi-ippm-twamp-srpm > defines > =E2=80=9Cextensions=E2=80=9D for TWAMP Light. > > GIM>> I cannot find where RFC 5357 defines "the probe and response > messages". Could you give a more specific reference or provide the text > that, in your opinion, defines such messages? But I'm more concerned with > the direction of "extending" non-protocol referred to as "TWAMP Light". A= s > a contributor to BBF's TR-390, I'm have learned how different are existin= g > implementations of TWAMP Light. And that is also noted in EANTC > Multi-Vendor Interoperability 2019 white paper > . > The status of TWAMP Light is explained in RFC 8545 and I cannot see that = it > can be used as a foundation of any standard. > > Gyan> I don=E2=80=99t see the probe a d response messages in TWAMP RFC = 5357 > > Agree to use term test-packet from RFC 5357. > > =C2=B7 several parts of the proposed protocol, e.g., Zero UDP che= cksum > in IPv6, require detailed security analysis, which is currently absent; > > Gyan> Agreed > > Please see previous reply. > > This is specified in RFC 6936 Security Section. We will add referenc= e > to this RFC in our Security Section as well. This is only specific to the > UDP port locally provisioned in the domain by the operator for TWAMP. > > GIM>> I've noted above that a simple reference does not sufficiently > explains why the use of zero UDP checksum in IPv6 header is not > decremental, does not create a security risk for the protocol. I believe > that the proposal to use zero UDP header checksum requires extensive > analysis, using the analysis provided in RFC 6936. > > Gyan> Completely Agree > > Please see previous reply. > > > - I was surprised to find out that draft-gandhi-ippm-twamp-srpm is on > the Informational track even though it is essential to the new protoco= l as > it defines its key elements > > This was to address your previous comment quoted as: > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS. > > GIM>> As explained in RFC 8545 "TWAMP Light is an idea", not a protocol. > If anyone is interested in standardizing an "extension", I'd expect that > they first define the base specification to which the extension applies. = I > might have missed the definition of TWAMP Light protocol in the draft. Co= uld > you point to the definition, for example, of the Authenticated mode in > TWAMP Light in the draft-gandhi-spring-twamp-srpm or RFC 5357? > > Gyan> Agreed > > The Appendix I of RFC 5357 does have information on the > Authentication mode. As specified there, this is based on user configured > parameters. > > =C2=B7 I believe that draft-gandhi-spring-twamp-srpm should be > anchored at IPPM WG as it does introduce the new PM protocol. > > The TWAMP Light extension draft-gandhi-ippm-twamp-srpm > is > already in IPPM WG. The SPRING draft only defines SR PM procedures. > > Below, please find my detailed comments, questions on these drafts: > > - draft-gandhi-spring-twamp-srpm > > I have several questions about the relationships between this draft and > Appendix I in RFC 5357 where the idea of a mode known as TWAMP Light has > been mentioned. The nature of the TWAMP Light and what is required to mak= e > it a standard is well-explained in Section 4 of RFC 8545 > (apologies for the long > quote): > > "TWAMP Light" is an idea described in Appendix I ("TWAMP Light > (Informative)") of [RFC5357]; TWAMP Light includes an unspecified > control protocol combined with the TWAMP-Test protocol. In > [RFC5357], the TWAMP Light idea was relegated to Appendix I because > TWAMP Light failed to meet the requirements for IETF protocols (there > are no specifications for negotiating this form of operation and no > specifications for mandatory-to-implement security features), as > described in Appendix A of this memo. See also [LarsAD] and > [TimDISCUSS]. > > Since the idea of TWAMP Light clearly includes the TWAMP-Test > component of TWAMP, it is considered reasonable for future systems to > use the TWAMP-Test well-known UDP port (whose reallocated assignment > is specified in this document). Clearly, the TWAMP Light idea > envisions many components and communication capabilities beyond > TWAMP-Test (implementing the security requirements, for example); > otherwise, Appendix I of [RFC5357] would be one sentence long > (equating TWAMP Light with TWAMP-Test only). > > Since we don't have an IETF document that addressed these open questions= , > I don't think we can have a draft that proposes extensions to a > non-standard mechanism (Appendix is for Informational material, as I > understand it) on the Standard track. > > Gyan> Agreed > > The procedure for using the RFC 5357 defined messages in TWAMP Ligh= t > configuration mode is defined in the corresponding spring drafts. It also > describes the provisioning model. > > GIM2>> If a return path can be provisioned for TWAMP Light, why the same > method of controlling a test session cannot be used for STAMP? > > It is not expected that all STAMP TLV extensions need to be > supported for TWAMP Light using provisioning. > > This was to address your previous comment quoted as > > =E2=80=9C- as I understand, the draft is applicable to TWAMP Light mode, > > mentioned in the informational Appendix I in RFC 5357, not the TWAMP > > protocol itself. Since TWAMP Light is not a standard but its idea is > > described in the informational text only, I think that the Information= al > > track is more appropriate for this specification.=E2=80=9D > > https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o/ > > Having said that, we are ok to change to PS as you mentioned above. > > BTW, despite only difference of fixed vs. variable length payload in > STAMP vs. TWAMP Light, the STAMP is a proposed standard as RFC 8762 (and = it > uses the same approach of provisioning as defined in this draft). Hence, > security considerations for STAMP and TWAMP Light are not different. Note > that both STAMP and TWAMP Light have authenticated messages defined for > Security purpose. > > GIM>> RFC 5357 mentioned TWAMP Light as an unauthenticated, and thus the > light, simpler, version of TWAMP-Test component of TWAMP protocol. I cann= ot > find in draft-gandhi-spring-twamp-srpm definition of the Authenticated mo= de > of TWAMP Light. Also, I'll prefer not to refer to RFC 8762 STAMP in the > discussion of "extension" to TWAMP Light. > > The Authentication information is user-configured as shown in > Section 3.1 of the draft-gandhi-spring-twamp-srpm, and is also described = in > Appendix I of RFC 5357. > > Now a number of more specific questions. > > draft-gandhi-spring-twamp-srpm: > > - In the Introduction it is stated that: > > The TWAMP Light [Appendix I in RFC5357] [BBF.TR-390] provides > simplified mechanisms for active performance measurement in Customer > IP networks by provisioning UDP paths and eliminates the need for > control-channel signaling. > > I can not find where, either Appendix I or TR-390, "eliminated the need > for control-channel signaling". Also, could you point where the reference= d > documents describe "provisioning UDP paths"? > > The Appendix I of RFC 5357 has following text. We can reword and mat= ch the exact text if you prefer. > > > > =E2=80=9CThis example eliminates the need for the TWAMP-Control protocol,= and > > assumes that the Session-Reflector is configured=E2=80=9D > > GIM>> I think that the text you're proposing is even more confusing. It i= s > not clear which example the sentence is referring to. Also, what is the > basis for such an assumption? > > This is the exact text from RFC 5357 Appendix I. Please go through > the entire Section in that RFC 5357 to avoid =E2=80=9Cout of context=E2= =80=9D discussion. > > > - It appears that the last paragraph in the Introduction describes the > relationship with Appendix I of RFC 5357: > > The procedure uses the mechanisms defined in [RFC5357] > (TWAMP Light) and its extensions for Performance Measurement. > > I think that the reference must be to Appendix I, not RFC 5357. Also, > could you please specify which extensions of TWAMP Light have been used i= n > this draft? > > We can add the Appendix I as reference in the next revision. > Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add this > reference. > > GIM>> The problem, in my view, is that Appendix I of RFC 5357 must be a > normative reference while it is, by its nature, an Informational document= . > > If approved, it is fine to have informational draft/RFC in a > normative reference. But RFC 5357 is PS. > > > - In Section 2.3 describing the reference model is noted: > > The probe response message is typically sent to the sender node R1. > > In which scenarios the reflector acts differently? How such behavior is > related to the behavior of a TWAMP Session-Reflector, as defined in RFC > 5357? > > Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from the sentenc= e? > > GIM>> If that fits into the operational model of the new protocol you're > defining. > > > - Also in Section 2.3 a Link is mentioned as an element directly > connecting nodes in the presented reference model. Could you clarify w= hat > is a Link? Is it always a physical connection between two systems or a > virtual? > > Both, please see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known= term used in > many existing RFCs (please see RFC 5613, 5340, 8330). > > GIM>> Thank you for the references. I couldn't find a definition of an > object "Link" (capitalized) but only "link" (lower case). Hence, since th= e > draft consistently uses the capitalized form, I consider it to be somethi= ng > else, something different from a link. > > Ok, we can change Link to link in the next revision to avoid > confusion. > > > - In Section 3 behavior of the reflector described as > > ... no PM state for delay or loss measurement need to be created on th= e > reflector node R5. > > That is in contradiction to the behavior of a TWAMP Session-Reflector as > defined in RFC 5357. Could you provide a reference to an IETF standard > where this behavior is defined? Also, how, without creating a state at th= e > Session-Reflector, to achieve one-way delay and synthetic loss measuremen= t > on a bidirectional SR tunnel? > > Gyan> Valid point > > Bidirectional SR tunnel may have an SR state but the statement abov= e > is that no PM (i.e. TWAMP Light) protocol session state is created for it= . > We can clarify in the next revision. > > GIM2>> So-called stateless Session-Reflector in TWAMP Light is only one > option. I am well-familiar with the implementation that uses the stateful > mode. > > What information stateful PM need to maintain in the state on the > reflector? Doesn=E2=80=99t that cause scale issues. We can add in the dra= ft you if > there is anything specifically needed in the spec. > > GIM3>> RFCs 5357 and 8762 are clear about what information must be > maintained by a Session-Reflector. The Session-Reflector must have > knowledge of the test session state and count reflected test packets. The > value of such a counter must be copied in the Sequence Number field of th= e > reflected packet. Thus the method enables the measurement of the one-way > packet loss metric. > > Quoting the text from Appendix I in RFC 5357. We can quote the text > as is. > > =E2=80=9CIn the case of TWAMP Light, the Session-Reflector does not neces= sarily have knowledge of the session state. =E2=80=9C > > GIM>> By the informational nature of Appendix I, the text is not > normative. I am familiar with the implementation of TWAMP Light which doe= s > maintain the session state and thus supports one-way packet loss > measurement. If you require that the remote node does not maintain the > state, the draft must define that as part of the specifying the behavior = of > the protocol. > > Ok, we can discuss what information is to be maintained in that > state on the reflector for synthetic packet loss. We can add appropriate > text if you can help please. > > GIM2>> I don't see any reason to do that as that already defined in RFC > 8762 and draft-ietf-ippm-stamp-yang > > > Ok. > > =C2=B7 Further, in Section 3 the selection of UDP port explained = as > the following: > > As specified in [RFC8545], the reflector > supports the destination UDP port 862 for delay measurement probe > messages by default. This UDP port however, is not used for loss > measurement probe messages. > > To the best of my understanding, as one of the contributors and Editors o= f > RFC 8545, it re-allocated UDP port 862 for use by a TWAMP Session-Reflect= or > without excluding any type of measurement. Besides, in TWAMP delay and > packet loss are measured in the same test session, using the same flow of > TWAMP-Test packets. > > Gyan> Agreed > > Yes, we can use port 862 for both delay and synthetic packet loss = =E2=80=93 > they are using the same test packet. There is no change proposed in the > draft. > > GIM2>> Packet delay and synthetic packet loss measurements are already > supported in RFC 8762. Are you proposing a new protocol to duplicate the > STAMP functionalities? > > As mentioned, the extensions defined are for the direct-mode packet > loss measurement for TWAMP Light and STAMP. > > The packet loss in existing RFC 5357 refers to synthetic loss as > there is no support for direct-mode loss in RFC 5357. We can change the > text to clarify as =E2=80=9CThis UDP port however, is not used for direct= -mode loss > measurement probe messages.=E2=80=9D > > GIM>> I've found that there's some misconception in the draft. RFC 8545 > re-assigned UDP port 862 not for "delay measurement probe messages" but f= or > TWAMP-Test protocol. TWAMP-Test protocol, in turn, supports packet delay, > packet loss, reordering (RFC 4737 defines packet reordering metric), and > packet duplication measurement. > > > - Then the draft states that > > The sender uses the UDP port number following the guidelines specified in > Section 6 in [RFC6335]. > > Could you point to the guidelines that a user can use when selecting a UD= P > port number of a test session? > > Gyan> Good point > > Please see section 6 in [RFC6335]. We can cite the range which will > be the same as used in [RFC8762]. This was also discussed earlier. > > https://mailarchive.ietf.org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/ > > GIM>> I've looked through Section 6 but I don't find anything specificall= y > applicable to this draft we're discussing. If the protocol to use UDP por= t > numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then = it > seems that stating that explicitly would be the best way. > > This would be, User Ports and Dynamic Ports ranges, which are defin= ed in [RFC6335 ]. Yes, we can add this= text. > > > - At the closing of the paragraph, we read that > > The number of UDP ports with PM functionality needs to be minimized due > to limited hardware resources. > > Does a UDP port number pose PM functionality? How it is assigned to the > port number? > > UDP ports are user configured for delay and direct-mode loss PM as > described in Section 3.1. > > GIM>> Can UDP port 862 be used? Also, requiring that the direct-loss > measurement uses port number different from the one used by a TWAMP-Test > packet, in my opinion, is another indication that this is the definition = of > a different from TWAMP Light PM OAM protocol. > > If we add a field in the packet then UDP port 862 may be used along > with the new field. But it will require extra processing in hardware. It = is > better to use a different UDP port for processing efficiency in hardware. > > > - Following the above-quoted text, in Section 3 is noted: > > For Performance Measurement, probe query and response messages are > sent as following: > > Could you clarify if the listed further procedures deviate from > OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 5357 for > Session-Sender and Session-Reflector respectively? > > Probe messages follow the same procedure as defined in RFC 4656 and > RFC 5357. > > GIM>> All messages, i.e., TWAMP-Test packets as well as the defined > in draft-gandhi-ippm-twamp-srpm? > > Yes, unless otherwise specified in the > draft-gandhi-ippm-twamp-srpm. > > > - for both delay and loss measurements draft requires test packet be > transmitted on a congruent path: > > the probe messages are sent on the > congruent path of the data traffic by the sender node > > It is not clear what "the congruent path" means. The definition > of congruency in geometry tells us that an object B is congruent to objec= t > A if it has the same shape and size, but is allowed to flip, slide or tur= n. > How a path can be congruent to another path? > > Gyan> Agreed. The use of congruent in the context of pathing is > confusing as the path being addressed may not be reflected accurately by > the term congruent. > > As replied above. > > There are many existing RFCs that use term Congruent Path (e.g. RFC > 5921, 6669) without defining them. I suspect it is because it is well-kno= wn > term. Having said that, we can add a reference for it if it helps reader. > > GIM>> I cannot assume what was the context of these RFCs. I've sketched a > network diagram above to illustrate that a "congruent path" may well lead > to out-of-band path. Is that the intention of the authors of the draft to > use this protocol out-of-band? > > As replied above. > > > - The last paragraph in Section 3 refers to work on iOAM: > > The In-Situ Operations, Administration, and Maintenance (IOAM) > mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] and for > SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry PM > information such as timestamp in-band as part of the data packets, > and are outside the scope of this document. > > Is iOAM in the scope of this specification? What are the relationships > between iOAM and draft-gandhi-spring-twamp-srpm? > > As mentioned in the draft, IOAM is outside the scope. > > GIM>> Yes, but it appears that references to the two IOAM-related drafts > have some purpose. What is it? How are these drafts related > to draft-gandhi-spring-twamp-srpm? > > We can remove them if it is confusing. It is informational text (wa= s > added to address a review comment). > > > - Section 3.1 presents an example of the provisioning model but puts > the definition of the provisioning model outside the scope. Is there a= n > accompanying specification that defines the provisioning model that ca= n be > used in multi-vendor deployment? Could that be YANG data model? What i= s the > relationship with draft-ietf-ippm-twamp-yang > ? Would the > TWAMP YANG data model be augmented? > > Yes, this can be Yang model. We can review draft-ietf-ippm-twamp-yan= g > and add any > missing items in a separate draft. We can also add a reference in this > draft. > > GIM>> I think that theremust be some discussion on how the new protocol i= s > configured. If TWAMP YANG data model can be augmented, I'd expect that > being defined in draft-gandhi-ippm-twamp-srpm. But I couldn't find anythi= ng > about the configuration of the protocol. > > The Yang model extensions are not in the scope of this draft > > > - Section 4.1 states that a new message is introduced to perform the > Loss Measurement in this protocol Why the capability of TWAMP to measu= re > the loss in one-way and two-way is not sufficient? > > Existing TWAMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D= loss > measurement. We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clar= ify. > > GIM>> True, direct loss measurement, in fact, is not active measurement > and thus is outside the scope of Two-Way Active Measurement Protocol > (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, > passive measurement method and fetching counters can be done using numero= us > methods, e.g., SNMP, Netconf > > RFC 7799 does not say using Test-packets to collect counters for > direct-mod loss measurement is passive. > > GIM2>> Per RFC 7799, injecting in-band test packets is the characteristic > of an active measurement method. Using out-of-band transport, e.g., SNMP > queries, would be an example of a passive measurement method. > > Ok, so you answered your own question that the direct-mode packet > loss extension defined is =E2=80=9Cactive measurement=E2=80=9D method. > > > - Section 4.1.1 requires that > > The Destination UDP port cannot be used as Source port, since > the message does not have any indication to distinguish between the > query and response message. > > Does that imply that the Destination UDP port used for the Delay > measurement is unique throughout the particular domain? > > Gyan> Good question > > Yes, it is unique in the domain. > > This is user-defined and is up to the user what UDP port to provisio= n > in a domain. > > GIM>> So, can user configure a port number from the User Ports range? Or, > can the same port number be used on the same system for a number of test > sessions? I find the use of UDP port numbers being underspecified. > > > - Section 4.1.2 of RFC 5357 does not define "the delay measurement > message" but refers to the definition of the Session-Sender's test pac= ket > in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test > packet format to perform both delay and packet loss measurement. > > Ok, we can update the text in the next revision to indicate exact > name from the RFC 4656. We can also add text to include synthetic packet > loss. > > GIM>> I think that making it explicit would help. Also, that will > highlight what is being introduced by *twamp-srpm drafts is, in fact, a n= ew > protocol to perform synthetic packet loss measurement. > > No, it does not change anything for synthetic packet loss. > > > - Can you explain how "the DM probe query message contains the payload > format defined in Section 4.2.1 of [RFC5357]" when the referenced sect= ion > of RFC 5357 defines the format of a Session-Reflector's test packet? > > We can update the text in the next revision to indicate query format > name from RFC 5357. > > GIM>> I cannot find any reference to a query format in RFCs 4656/5357. > Could you please quote from any of these documents? > > It is test-packet, we will use RFC 5357 term. > > > - Can clarify the applicability of RFC 6038 and the symmetrical packet > size? Is it required? Can it be non-symmetrical? > > Yes. Please see section 4.1.1 and quoted below: > > =E2=80=9CFor symmetrical size query and response messages as defined in [= RFC6038],=E2=80=9D > > GIM>> RFC 6038 defines an extension to RFC 5357 for OPTIONAL use of the > symmetrical test packets. Since *-twamp-srpm proposals do not use > TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about > that either (in part because RFC 6038 came later), I don't see that there= 's > any certainty in what is the sze of a test packet used in the direct-loss > measurement. > > The test-packets as defined in these existing RFCs are used for > delay and synthetic packet loss. The direct-mode test-packets are defined > in this draft. > > GIM2>> This draft defines only a new packet format for the direct packet > loss measurement. For STAMP such a mechanism is clearly superfluous given > the Direct Measurement TLV is already defined. > > As replied earlier. > > > - Can you clarify the use of the timestamp format, NTP or PTPv2? It is > not clear which is the default, mandatory or optional. > > This is same as TWAMP. There is no change. > > GIM>> Per RFC 5357, TWAMP uses only NTP format. Is that the case for > *-twamp-srpm? > > No change in existing in what is there in RFC 5357 and RFC 8186. > > > - Also, is "hardware support in Segment Routing networks" of the PTPv2 > format required, guaranteed, or something else? > > Hardware timestamps are recommended for SR use-cases. We can change > the sentence. > > GIM>> Perhaps you can propose some text, that would be helpful. > > Ack. > > > - Section 4.1.1.1 stated that > > A separate user-configured > destination UDP port is used for the delay measurement in > authentication mode due to the different probe message format. > > Can that be interpreted that there could be concurrent authenticated and > unauthenticated test sessions using this protocol? Would different > authentication methods require using unique destination UDP port numbers? > > Yes, and Yes, and these are based on provisioning. > > GIM>> But that requirement is far outside the TWAMP, as defined in RFC > 5357. > > Some Session-Sender can use authenticated and some not. It is part > of RFC 5357. > > > - Section 4.1.2 by introducing the dedicated Loss measurement packet > format, effectively modifies the behavior defined in RFC 5357 for > Session-Sender and Session-Reflector. But the document does not state = that. > Can you clarify whether this specification changes the behavior of a > Session-Sender and Session-Reflector as defined in RFC 4656 and RFC 53= 57 > respectively for the support of packet loss measurement? > > The direct-mode loss defines new procedure for sender/reflector to > collect traffic counters, as opposed to timestamp. The rest is the same a= s > RFC 4656 and 5357. > > GIM>> I cannot agree with your statement " The rest is the same as RFC > 4656 and 5357" because the sender's direct-loss format does not have Erro= r > Estimate field, Thus, a reflected packet does not have Sender's Error > Estimate, nor Error Estimate of the reflector. And that, in my opinion, i= s > another clear indication that *twamp-srpm drafts define a new protocol, > separate from OWAMP/TWAMP. > > That field is specific to timestamps and would not apply to > counters for direct-mode loss measurement. > > > - And a similar question about the use of the separate UDP port number > for the authenticated of the packet loss measurement. > - A couple of question to the following text in Section 4.1.3: > > The local and remote IP > addresses of the link are used as Source and Destination Addresses. > They can also be IPv6 link local address as probe messages are pre- > routed. > > - What are the addresses of a link? > > I am assuming this well-known (e.g. RFC 2328). > > GIM>> I am not familiar with the term "pre-routed". What does it mean? > > Ensure that packets are routed over the link. > > > - In which scenarios an IPv6 LLA can be used? > > I am assuming this is well-known (e.g. RFC 5613). > > GIM>> So, LLA may be used as the source and destination addresses when > testing an SR tunnel? > > As mentioned this is for links. > > > - Also, could the use of a routable destination IP address be used as > a DDOS attack vector? Consider the scenario when an attacker genera= tes > SR-encapsulated packets with the destination IP address other than = any of > the SR-terminating nodes. Such a packet will be routed, correct? Th= at does > appear as a security threat, would you agree? > > Absolutely do not agree. It is no different than IP routed TWAMP > packet as defined in [RFC5357]. > > GIM>> You don't agree that the processing described cannot happen because > of laws of physics or it wouldn't happen because no one will think of tha= t? > If the latter, I think that that is security threat. > > There is no new threat like you have mentioned. > > GIM2>> Hmmm, but how the integrity of TLVs proposed > in draft-gandhi-ippm-stamp-srpm can be protected? These are not protected > by HMAC as presented in figures 3 and > 5. > > > The extensions do not change the processing of these existing TLVs > defined for HMAC. We can add text to indicate this. > > > - Section 4.1.4.2 references Figure 5 that, as I understand it, > displays the format of a probe query message. In figure two references= to > RFC 5357 are provided - a section that references RFC 4656 OWAMP defin= ition > of the Session-Sender test packet, and a section that defines the > Session-Reflector's reflected packet. Which of the two is used for the > delay measurement in the proposed protocol? > > The probe query packet in the Session-Sender text packet. We can > update the name. > > - Section 4.2.1 states that > > In one-way measurement mode, the probe response message as defined in > Figure 6 is sent back out-of-band to the sender node ... > > Could you clarify how the responder controls that the response packet is > sent not in-band but out-of-band? > > Please refer to section 3.1 in draft-gandhi-ippm-twamp-srpm. This i= s > existing behaviour for out-of-band. > > GIM>> draft-gandhi-ippm-twamp-srpm does not specify that it defines > another new protocol OWAMP Light. And it is not clear what you reference = as > "this is existing behavior". Is it to reference behavior of TWAMP test > packet? But the behavior of the TWAMP-Test protocol by itself is neither > in-band, nor out-of-band. It is the encapsulation of the TWAMP test packe= t > that makes it either in-band or out-of-band. > > Right. > > > - How's the method described in Section 4.2.3 is different from the > method described in RFC 8403 ? > What is distinctly unique about the loopback mode proposed in the sect= ion? > > There is no mention of Loopback mode or TWAMP / RFC 5357 in RFC 8403= . > > GIM>> So, you believe that proposing to use the > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000d02cca05b5bc855d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rakesh

Please see in-line=C2=A0

On Sat, Dec 5, 2020 at 10:32 AM Rakesh Gan= dhi (rgandhi) <rgandhi@cisco.com> wrote:

Hi Gyan,=

=C2=A0

Thanks for your review= comments. Please see inline with <RG4>=E2=80=A6=

=C2=A0

From: Gyan Mishra <hayabusagsm@gmail.c= om>
Date: Saturday, December 5, 2020 at 1:16 AM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Greg Mirsky <gregory.mirsky@ztetx.com>, IETF IPPM WG <ippm@ietf.org>, James Guich= ard <james.n.guichard@futurewei.com>, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>,= ippm-chairs@ietf= .org <ippm= -chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, spring@ietf.org &= lt;spring@ietf.org= >
Subject: Re: [spring] [ippm] WG Adoption Call for h= ttps://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11<= /u>

Hi Rakesh=C2=A0

=C2=A0

Had a general question.

=C2=A0

I read through the draft again and a question came t= o mind as this draft is Standards Track, what new is being introduced other= then a procedure of how to use TWAMP in SR networks SR-MPLS which reuses t= he MPLS data plane and SRv6 which used the IPv6 data plane.=C2=A0 I don=E2=80=99t believe there exists =C2= =A0a Standards track draft procedure for how to use STAMP over IP network o= r MPLS network as an example. =C2=A0

=C2=A0

Section 4.1.4 describes SR-MPLS use case and SRv6 us= e case.=C2=A0 As there appears to be nothing new introduced such as a new I= ANA TLV or code point or even a special SID code point =C2=A0for TWAMP, all= basic vanilla SR, that without this draft you could run STAMP, TWAMP, OWAMP over SR which has existed for a while now. = =C2=A0

=C2=A0

What is the new invention here?

=C2=A0

<RG4> SPRING dra= fts define the procedure for using TWAMP Light and STAMP test-messages for = SR path and links. The corresponding IPPM drafts define the extensions need= ed for them. The SPRING drafts also use the extensions for them defined in the corresponding IPPM drafts. The extensio= ns are needed for (1) in-band response request e.g. for two-way mode for li= nks and SR path, (2) Return path for SR e.g. when using bidirectional SR Pa= th, and (3) for collecting TX and RX traffic counters in-band for direct-mode loss measurement.

=C2=A0Gyan> Understood.=C2=A0= Just to see if a precedence has already been set if you point me another c= ase where Spring or any other WG RFC Standards Track that =C2=A0has defined= procedures to use IPPM extensions.=C2=A0 If this is the first and may also= set a new precedent, =C2=A0I think it=E2=80=99s a valid WG discussion.<= /u>

Sorry but I may have missed something.=

=C2=A0

My thoughts are at most this be a BCP or I am thinki= ng informational draft would be appropriate.

=C2=A0

<RG4> Given abov= e context, if WG thinks that any of the drafts should be BCP or Information= al or Experimental, we can update the draft accordingly.

Gyan> Agreed.=C2=A0 Thank you= =C2=A0

Thoughts?

=C2=A0

Gyan

=C2=A0

On Thu, Dec 3, 2020 at 12:51 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Rakesh,

thank you for the continued discussion. You can find= my follow-up notes in-line below under GIM3>> tag. I felt that one c= omment is at the root of our different views on what is considered to be a = problem that drafts solve. You've said:

<RG3> As mentioned, the extensions defined are= for the direct-mode packet loss measurement for TWAMP Light and STAMP.<= /u>

But draft-ietf-ippm-stamp-option-tlv, currently in=C2=A0 Submitted to IESG = for Publication WG state according to IETF datatracker, includes Section 4.= 5 Direct Measurement TLV. It is noted in the section:

=C2=A0 =C2=A0The Direct Measurement TLV enables coll= ection of the number of in-
=C2=A0 =C2=A0profile packets, i.e., packets that form a specific data flow,= that
=C2=A0 =C2=A0had been transmitted and received by the Session-Sender and Se= ssion-
=C2=A0 =C2=A0Reflector, respectively.=C2=A0 The definition of "in-prof= ile packet" is
=C2=A0 =C2=A0outside the scope of this document and is left to the test ope= rators
=C2=A0 =C2=A0to determine.

=C2=A0

<RG4><= /u>

Hi Greg,=

The motivation has bee= n there in the draft-gandhi-ippm-stamp-srpm, Section 1. Copied below for th= e convenience.

=C2=A0

=C2=A0=C2=A0 The STAMP message with a TLV fo= r "direct measurement" can be used for

=C2=A0=C2=A0 combined Delay + Loss measureme= nt [I-D.ietf-ippm-stamp-option-tlv].

=C2=A0=C2=A0 However, in order to use only f= or loss measurement purpose, it

=C2=A0=C2=A0 requires the node to support th= e delay measurement messages and

=C2=A0=C2=A0 support timestamp for these mes= sages (which may also require clock

=C2=A0=C2=A0 synchronization).=C2=A0 Further= more, for hardware-based counter collection

=C2=A0=C2=A0 for direct-mode loss measuremen= t, the optional TLV based processing

=C2=A0=C2=A0 adds unnecessary overhead (as c= ounters are not at well-known

=C2=A0=C2=A0 locations).

=C2=A0

Thus I cannot see any technical need for the introdu= ction=C2=A0of yet another way of direct loss measurement in STAMP. As for t= he case of TWAMP Light, I believe that there's no sufficient evidence t= hat the proposed direct loss-measurement measurement method benefits existing implementations of TWAMP Light. Also, historicall= y, all extensions applicable to TWAMP Light have been introduced through ex= tending TWAMP proper, i.e., extending TWAMP-Control and TWAMP-Test. The way= of "extending" TWAMP Light presented in the drafts we are discussing is, in my opinion, in violation of RFC 535= 7.

=C2=A0

<RG4> The IPPM W= G Informational draft on TWAMP Light direct-mode loss measurement, defines = the message format and corresponding SPRING draft defines the procedure for= using that. It is not clear to me how providing an informational draft gandhi-ippm-twamp-srpm is violating RFC 5357.

=C2=A0

Thanks,<= /span>

Rakesh

=C2=A0

=C2=A0

More notes can be found below.

=C2=A0

Regards,

Greg

=C2=A0

=C2=A0

On Wed, Dec 2, 2020 at 12:18 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Greg for you= r further reply and the discussions.

Good to know that y= ou do see a need for the extensions for the direct-mode packet loss detecti= on and the authors are actively working on an alternate methods using BFD (as you mentioned below).

GIM3>> As you've recognized, in draft-mirmin-bfd-extended=C2=A0we build an integrated OAM based on the = lightweight Fault Management protocol with optional Performance Monitoring,= based on RFC 6374. RFC 6374, in turn, provides a rich set of performance m= easurement methods, including direct loss measurement.

Please see replies inl= ine with <RG3>=E2=80=A6.

From: Greg Mirsky <gregimirsky@gmail.c= om>
Date: Monday, November 30, 2020 at 11:30 AM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, IETF IPPM WG <ippm@ietf.org>, James Guichard &= lt;jame= s.n.guichard@futurewei.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;, Greg Mirsky <gregory.mirsky@ztetx.com>
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

Hi Rakesh,

thank you for the continued discussion. I appreciate= your responses. I am still not convinced of the value these documents add.= Please find my follow-up notes in-line=C2=A0below under the GIM2>> tag.

=C2=A0Regards,

Greg=C2=A0

On Wed, Nov 25, 2020 at 8:19 PM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Gyan and Gre= g for your review comments and discussions. Please see inline replies with = <RG2>=E2=80=A6

From: Gyan Mishra <hayabusagsm@gmail.c= om>
Date: Wednesday, November 25, 2020 at 12:34 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, James Guichard <james.n.guichard@futurewei.com&g= t;, Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, spring@ietf.org &l= t;spring@ietf.org&= gt;
Subject: Re: [spring] [ippm] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

=C2=A0Hi Rakesh=C2=A0

I have been following this thread and to help progre= ss the discussion I would like to provide some comments in-line Gyan>=C2= =A0

Thanks

Gyan

On Sun, Nov 15, 2020 at 7:08 PM Greg Mirsky <gregimirsky@gmail.co= m> wrote:

Hi Rakesh,

thank you for the response to my comments.=C2=A0Plea= se find my follow-up notes in-lined below under the GIM>> tag.=C2=A0<= u>

Regards,

Greg

On Tue, Nov 10, 2020 at 7:33 AM Rakesh Gandhi (rgand= hi) <rgandhi@cisc= o.com> wrote:

Thank you Greg for taking time for thoroughly= reviewing the documents and providing the comments.

Please see replies inline with <RG>=E2= =80=A6

From: ippm <ippm-bounces@ietf.org&= gt;
Date: Friday, November 6, 2020 at 11:18 AM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: spring@ietf= .org <spring@ie= tf.org>, ippm-chairs@ietf.= org <ippm-= chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11=

Dear Chairs of the SPRING and IPPM WGs, Authors, et = al.,

I've found myself in the situation when two rela= ted drafts are in the WG APs in the SPRING and IPPM WG (with the possibilit= y that expertise from the third WG, BFD WG, might be desirable to review the "liveness monitoring"). Because these drafts are c= losely related, I've decided to combine my questions and comments in a = single thread. I hope that would be acceptable and considered by the SPRING= WG as well as IPPM WG.

Usually, the bar for the adoption of a document can = be evaluated=C2=A0by answers to these three questions:

  • Is the document(s) reasonably well-written

I've got surprised that the drafts don't use= the terminology from RFC 4656 and 5357 and introduce their own terminology= for Session-Sender and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", are used in the documents withou= t proper definitions. Other than that both drafts are readable and reasonab= ly well-written.

<RG> We are ok to change Sender to Session-Sender and Reflect= or to Session-Reflector if it helps.

=C2=A0

GIM>> I believe that the consistency in terminology between the core = RFC and what is intended as its extension is not only helpful to a reader b= ut, to the best of my understanding, is required for IETF specifications. B= ut I don't think that switching the terminology will fix the fundamental issue with the proposal. The operation that is re= quired from the remote entity, whether it is referred to as responder or Se= ssion-Reflector, is not defined in Appendix I of RFC 5357, nor in RFCs 4656= or 5357 itself. In my opinion, the behavior required, as described in the draft, cannot be characterized = as an extension of OWAMP, TWAMP, or TWAMP Light but presents a completely n= ew protocol that, if there's a need in the new PM OAM protocol, must be= properly defined.

=C2=A0 =C2=A0Gyan> I am in complete agreement wit= h Greg about terminology and consistency.=C2=A0 The problem with inconsiste= ncy is that that you are not following well known normative references required to understand the specification leading to confusion and misunder= standing of the specification.=C2=A0 The goal should be clear and concise i= n terminology and verbiage.

<RG2> Agree. Wil= l address the terms from RFC 5357 in the next revision.

<RG> There are many existing RFCs that use term =E2=80=9CLink= =E2=80=9D (e.g. RFC 5613, 5340, 8330, etc.) and term =E2=80=9CCongruent Pat= h=E2=80=9D (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that, we c= an add a reference for them if it helps.

GIM>> Thank you for listing these RFCs. I thin= k I need to clarify my questions. While a reference to any of RFCs you'= ve mentioned, I don't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

Now I'll try to illustrate my concern with using= the term "congruent path" in these drafts (using ASCII-art):<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C---------D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A----B=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E-----F

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0G------------H

Consider an SR tunnel from A to F that traverses the= network as A-B-C-D-E-F. Is A-B-G-H-E-F congruent to it? From the definitio= n of "congruent" as "two figures or objects are congruent if they have the same shape and size, or if one has the same shape and siz= e as the mirror image of the other", it looks as the path A-B-G-H-E-F = is congruent to that SR tunnel. But a packet of an active OAM intended to m= onitor a flow over the SR tunnel is out-of-band relative to that flow and will not produce any meaningful measurement. Of = course, for the case of the extensions in drafts *-twamp-srpm, direct loss = measurement can be performed, as information collected from node F and pack= ets that collect the counters are not required to be in-band with the monitored flow. So, this example, in m= y opinion, illustrates two of my concerns:

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a congruent path for active performance measurement, e.g., TWA= MP or TWAMP Light, may produce information that does not reflect the condit= ion experienced by the monitored flow. It seems that the terminology should= reflect the fundamental requirement of ensuring that active OAM test packets are in-band with the monitored fl= ow.

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are no technical requirements to justify using in-band test pa= ckets for direct packet loss measurement. In fact, using the in-band method= for collecting in-profile counters leads to a waste of bandwidth, which ma= y have a negative impact on services that require low-latency and/or low packet loss. As demonstrated in this e= xample, direct packet loss can be performed using an out-of-band mechanism,= e.g., SNMP queries, Netconf notifications based on YANG data model.=

  • Does the document solve a real problem?

No, it appears that these drafts define a new perfor= mance measurement protocol for the purpose of combining OWAMP and TWAMP fun= ctionality and adding the ability to collect counters of "in-profile" packets. I couldn't find sufficient technica= l arguments for using a PM protocol instead of, for example, extending the = existing OAM mechanisms like ICMP.

=C2=A0Gyan> =C2=A0This may sound basic but is a v= ery critical subject going down the same lines of clarity in verbiage so th= eir is no misunderstanding. =C2=A0=E2=80=9CCongruent=E2=80=9D by definition= means shape of an object and if you super imposed two objects on top of each other the= y fit perfectly and the edges coincide identically.=C2=A0 The problem with = congruent is that it is based on the shape and that shape could be a mirror= image or reflection which may not be exact.=C2=A0 So when referring to a SR-TE path taken this could lead to co= nfusion as to path taken if it=E2=80=99s the same path or congruent which i= s vague as to =E2=80=9Cexactly=E2=80=9D which path is taken where here ther= e is criticality as to the path being referenced in terms of in-band versus out-of-band.=C2=A0 I agree th= at for direct in band packet loss measurement can be done via existing OAM = mechanisme via ICMP.

<RG2> Ok, we wil= l find an appropriate term for =E2=80=9Csending packets on the same path as= data traffic=E2=80=9D.

<RG2> Extending = ICMP for direct-mode loss measurement is outside the scope of this draft. B= ut good to see the agreement for the direct in band packet loss measurement to be done (albeit by some other means).=

GIM2>> I feel that you misunderstand my positi= on in regard to the use case these four documents try to solve. I don't= recall that I've stated that "direct in-band packet loss measurem= ent" requires any additional standardization work. The Direct Measurement TLV h= as solved that for STAMP and draft-ietf-ippm-stamp-option-tlv is now in the= RFC Editor's queue. I cannot find any valid technical reason to re-ope= n this and measure the direct packet loss in a slightly different way. I must point out that a claim that using= fixed positions for the direct packet loss optimizes performance does not = stand for cases (Section 4.2.1 and 4.2.2 of draft-gandhi-spring-stamp-srpm)= when the return path is specified in the Return Path TLV and, as I understand it, in some cases even the sec= ond TLV, Node Address TLV, is used. Thus, it is clear that the proposed new= method of direct packet loss measurement does not offer any significant be= nefits comparing to the STAMP's Direct Measurement TLV and appears nothing but superfluous.<= /p>

<RG3> The direct= -mode packet loss use-case is typically for the forward direction packet lo= ss. And this does not use the return path TLV. We can clarify that in the draft.

GIM3>> Clarification would be very helpful as = your latest note might be interpreted that the proposed mechanisms are not = applicable in the case of a bi-directional SR tunnel.

<RG> There is a requirement to measure performance delay as w= ell as synthetic and direct-mode packet loss in segment-routing networks. O= WAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet loss measur= ement today. I am not sure extending ICMP for LM is a good option here.

GIM>> I agree with the=C2=A0requirements you've listed (though th= e=C2=A0SPRING WG OAM requirements document=C2=A0= has been abandoned and expired 3+ years ago). I believe that there's no sufficient technical reason=C2=A0to use OWAMP/TWAMP for exc= lusive direct packet loss measurement.=C2=A0=C2=A0

=C2=A0 =C2=A0 Gyan> Agreed

<RG2> There is definitely a need to = do direct-mode loss measurement in IP/SR networks, as RFC 6374 mechanisms a= re for MPLS networks. Note that there was an attempt to extend BFD for dire= ct-mode loss measurement for this purpose using RFC 6374 loss measurement message (see draft-mirmin-bfd-extended-03)= .

GIM2>> I am surprised that you refer to draft-mirmin-bfd-extended in the past tense. The work and discussion of= the proposal continues and the new version will be published soon.<= u>

<RG3> Ok, so = you do see a need for the extensions for the direct-mode packet loss detect= ion and the authors are actively working on an alternate methods using BFD. =C2=A0=C2=A0=

  • Is the proposed solution technically viable?

There are too many unaddressed aspects, particularly= the risk introduced by the protocol on network security, to comprehensivel= y evaluate the proposed solution.

<RG> About your = comment on zero checksum, this is described in Security section in RFC 6936= . We will add reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for TWAMP. Other than this, I did not find any other= security related issue in your review below.

GIM>> I don't think that a mere reference = sufficiently explains why the use of zero UDP checksum in IPv6 header is no= t decremental, does not create a security risk for the protocol.<= /u>

=C2=A0=C2=A0 =C2=A0 Gyan> Agreed 0 UDP MIMA secur= ity threats and that you need to thorough vetting of RFC 6936.

=C2=A0<RG2> Yes,= will add in the next revision. Hope we can work together on needed text.

To summarize my review of=C2=A0these two drafts:<= /u>

  • these propose a new protocol, not an update or enhancement of the TWAMP-lik= e protocol;

<RG> The probe a= nd response messages defined in [RFC 5357] are used for delay measurement a= nd synthetic packet loss. The direct-mode packet loss messages are defined in draf= t-gandhi-ippm-twamp-srpm that matc= h these delay measurement messages. As stated, draft-gandhi-ippm-tw= amp-srpm defines =E2=80=9Cextensio= ns=E2=80=9D for TWAMP Light.

GIM>> I cannot find where RFC 5357 defines "the probe and respon= se messages". Could you give a more specific reference or provide the = text that, in your opinion, defines such messages? But I'm more concern= ed with the direction of "extending" non-protocol referred to as "TWAMP Light". As a contributor to BBF's=C2=A0TR-390, = I'm have learned how different are existing implementations of TWAMP Li= ght. And that is also noted in EANTC Multi-Vendor Interoperability 2019 white paper. The status of TWA= MP Light is explained in RFC 8545 and I cannot see that it can be used as a= foundation of any standard.

=C2=A0 Gyan> I don=E2=80=99t see the probe a d re= sponse messages in TWAMP RFC 5357=C2=A0

<RG2> Agree to u= se term test-packet from RFC 5357.

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 several parts of the proposed protocol, e.g., Zero UDP checksum in I= Pv6, require detailed security analysis, which is currently absent;<= u>

=C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

<RG2> Please see= previous reply.

<RG> This is spe= cified in RFC 6936 Security Section. We will add reference to this RFC in o= ur Security Section as well. This is only specific to the UDP port locally provisioned in the domain by the operator for TWAMP.

GIM>>=C2=A0 I've noted above that a simple reference does not suf= ficiently explains why the use of zero UDP checksum in IPv6 header is not d= ecremental, does not create a security risk for the protocol. I believe tha= t the proposal to use zero UDP header checksum requires extensive analysis, using the analysis provided in RFC 6936.

=C2=A0 =C2=A0 Gyan> Completely Agree

=C2=A0<RG2> Plea= se see previous reply.

  • I was surprised to find out that=C2=A0draft-gandhi-ippm-twamp-srpm is on th= e Informational track even though it is essential to the new protocol as it= defines its key elements
<RG> This was to address your previous comment qu=
oted as:
 =E2=80=9C- as I understand, the dr=
aft is applicable to TWAMP Light mode,

=C2=A0=C2=A0 mentioned in the informational = Appendix I in RFC 5357, not the TWAMP

=C2=A0=C2=A0 protocol itself. Since TWAMP Li= ght is not a standard but its idea is

=C2=A0=C2=A0 described in the informational = text only, I think that the Informational

=C2=A0 track is more appropriate for this sp= ecification.=E2=80=9D

https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o= /

<RG> Having said= that, we are ok to change to PS.

GIM>> As explained in RFC 8545 "TWAMP Light is an idea", no= t a protocol. If anyone is interested in standardizing an "extension&q= uot;, I'd expect that they first define the base specification to which= the extension applies. I might have missed the definition of TWAMP Light protocol in the draft. Could you= point to the definition, for example, of the Authenticated mode in TWAMP L= ight in the=C2=A0draft-gandhi-spring-twamp-srpm or RFC 5357?=C2=A0

=C2=A0 =C2=A0 =C2=A0Gyan> Agreed=C2=A0<= /u>

<RG2> The Append= ix I of RFC 5357 does have information on the Authentication mode. As speci= fied there, this is based on user configured parameters.

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I believe that=C2=A0draft-gandhi-spring-twamp-srpm should be anchore= d at IPPM WG as it does introduce the new PM protocol.

<RG> The TWAMP L= ight extension draft-gandhi-ippm-tw= amp-srpm is already in IPPM WG. The SPRING draft only = defines SR PM procedures.

=C2=A0Below, please find my detailed=C2=A0comments, = questions on these drafts:

  • draft-gandhi-spring-twamp-srpm

I have several questions about the relationships bet= ween this draft and Appendix I in RFC 5357 where the idea of a mode known a= s TWAMP Light has been mentioned. The nature of the TWAMP Light and what is required to make it a standard is well-explained i= n Section 4 of=C2=A0RFC 8545=C2=A0(apologies for the long quote):

=C2=A0 =C2=A0"TWAMP Light" is an idea desc= ribed in Appendix I ("TWAMP Light
=C2=A0 =C2=A0(Informative)") of [RFC5357]; TWAMP Light includes an uns= pecified
=C2=A0 =C2=A0control protocol combined with the TWAMP-Test protocol.=C2=A0 = In
=C2=A0 =C2=A0[RFC5357], the TWAMP Light idea was relegated to Appendix I be= cause
=C2=A0 =C2=A0TWAMP Light failed to meet the requirements for IETF protocols= (there
=C2=A0 =C2=A0are no specifications for negotiating this form of operation a= nd no
=C2=A0 =C2=A0specifications for mandatory-to-implement security features), = as
=C2=A0 =C2=A0described in Appendix A of this memo.=C2=A0 See also [LarsAD] = and
=C2=A0 =C2=A0[TimDISCUSS].

=C2=A0 =C2=A0Since the idea of TWAMP Light clearly includes the TWAMP-Test<= br> =C2=A0 =C2=A0component of TWAMP, it is considered reasonable for future sys= tems to
=C2=A0 =C2=A0use the TWAMP-Test well-known UDP port (whose reallocated assi= gnment
=C2=A0 =C2=A0is specified in this document).=C2=A0 Clearly, the TWAMP Light= idea
=C2=A0 =C2=A0envisions many components and communication capabilities beyon= d
=C2=A0 =C2=A0TWAMP-Test (implementing the security requirements, for exampl= e);
=C2=A0 =C2=A0otherwise, Appendix I of [RFC5357] would be one sentence long<= br> =C2=A0 =C2=A0(equating TWAMP Light with TWAMP-Test only).

=C2=A0Since we don't have an IETF document that = addressed these open questions, I don't think we can have a draft that = proposes extensions to a non-standard mechanism (Appendix is for Informational material, as I understand it) on the Standard track.<= u>

=C2=A0Gyan> Agreed=C2=A0

<RG2> The proced= ure for using the RFC 5357 defined messages in TWAMP Light configuration mo= de is defined in the corresponding spring drafts. It also describes the provisioning model.

GIM2>> If a return path can be provisioned for= TWAMP Light, why the same method of controlling a test session cannot be u= sed for STAMP?

<RG3> It is not = expected that all STAMP TLV extensions need to be supported for TWAMP Light= using provisioning.=C2=A0

=C2=A0<RG> This = was to address your previous comment quoted as

 =E2=80=9C- as I understand, the dr=
aft is applicable to TWAMP Light mode,

=C2=A0=C2=A0 mentioned in the informational = Appendix I in RFC 5357, not the TWAMP

=C2=A0=C2=A0 protocol itself. Since TWAMP Li= ght is not a standard but its idea is

=C2=A0=C2=A0 described in the informational = text only, I think that the Informational

=C2=A0=C2=A0 track is more appropriate for t= his specification.=E2=80=9D

https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o= /

<RG> Having said= that, we are ok to change to PS as you mentioned above.

<RG> BTW, despit= e only difference of fixed vs. variable length payload in STAMP vs. TWAMP L= ight, the STAMP is a proposed standard as RFC 8762 (and it uses the same approach of provisioning=C2=A0 as defined in this draft). He= nce, security considerations for STAMP and TWAMP Light are not different. N= ote that both STAMP and TWAMP Light have authenticated messages defined for= Security purpose.

GIM>> RFC 5357 mentioned TWAMP Light as an una= uthenticated, and thus the light, simpler, version of TWAMP-Test component = of TWAMP protocol. I cannot find in=C2=A0draft-gandhi-spring-twamp-srpm definition of the Authenticated mode of TWAMP Light. Also, I'll prefer= not to refer to RFC 8762 STAMP in the discussion of "extension" = to TWAMP Light.

<RG2> The Authen= tication information is user-configured as shown in Section 3.1 of the draf= t-gandhi-spring-twamp-srpm, and is also described in Appendix I of RFC 5357.

Now a number of more specific questions.

draft-gandhi-spring-twamp-srpm:

  • In the Introduction it is stated that:

=C2=A0 The TWAMP Light [Appendix I in RFC5357] [BBF.= TR-390] provides
=C2=A0 =C2=A0simplified mechanisms for active performance measurement in Cu= stomer
=C2=A0 =C2=A0IP networks by provisioning UDP paths and eliminates the need = for
=C2=A0 =C2=A0control-channel signaling.

I can not=C2=A0find where, either Appendix I or TR-3= 90, "eliminated the need for control-channel signaling". Also, co= uld you point where the referenced documents describe "provisioning UDP paths"?

<RG> The Appendix I of RFC 5357 has following tex=
t. We can reword and match the exact text if you prefer.
=C2=A0
=E2=80=9CThis example eliminates th=
e need for the TWAMP-Control protocol, and
=C2=A0=C2=A0 assumes that the Session-Re=
flector is configured=E2=80=9D

GIM>> I think that the text you're proposi= ng is even more confusing. It is not clear which example the sentence is re= ferring to. Also, what is the basis for such an assumption?=C2=A0=

<RG2> This is th= e exact text from RFC 5357 Appendix I. Please go through the entire Section= in that RFC 5357 to avoid =E2=80=9Cout of context=E2=80=9D discussion.

  • It appears that the last paragraph in the Introduction describes the relati= onship with Appendix I of RFC 5357:

=C2=A0 =C2=A0The procedure uses the mechanisms defin= ed in [RFC5357]
=C2=A0 =C2=A0(TWAMP Light) and its extensions for Performance Measurement.<= u>

I think that the reference must be to Appendix I, no= t RFC 5357. Also, could you please specify which extensions of TWAMP Light = have been used in this draft?

<RG> We can add the Appendix I as reference in the next revis= ion. Extensions are defined in draft-gandhi-ippm-twamp-srpm, we can add thi= s reference.

GIM>> The problem, in my view, is that Appendi= x I of RFC 5357 must be a normative reference while it is, by its nature, a= n Informational document.=C2=A0=C2=A0

<RG2> If approve= d, it is fine to have informational draft/RFC in a normative reference. But= RFC 5357 is PS.

  • In Section 2.3 describing the reference model is noted:
    • <= /ul>

    =C2=A0 =C2=A0The probe response message is typically= sent to the sender node R1.

    In which scenarios the reflector acts differently? H= ow such behavior is related to the behavior of a TWAMP Session-Reflector, a= s defined in RFC 5357?

    <RG> Do you prefer we remove =E2=80=9Ctypically=E2=80=9D from= the sentence?

GIM>> If that fits into the operational model = of the new protocol you're defining.=C2=A0

  • Also in Section 2.3 a Link is mentioned as an element directly connecting n= odes in the presented reference model. Could you clarify what is a Link? Is= it always a physical connection between two systems or a virtual?

<RG> Both, pleas= e see Section 4.1.3. =E2=80=9CLink=E2=80=9D is well known term used in many= existing RFCs (please see RFC 5613, 5340, 8330).

GIM>> Thank you for the references. I couldn&#= 39;t find a definition of an object "Link" (capitalized) but only= "link" (lower case). Hence, since the draft consistently uses th= e capitalized form, I consider it to be something else, something different from a link.= =C2=A0

<RG2> Ok, we can= change Link to link in the next revision to avoid confusion.=

  • In Section 3 behavior of the reflector described as

=C2=A0 =C2=A0... no PM state for delay or loss measu= rement need to be created on the
=C2=A0 =C2=A0reflector node R5.

That is in contradiction to the behavior of a TWAMP = Session-Reflector as defined in RFC 5357. Could you provide a reference to = an IETF standard where this behavior is defined? Also, how, without creating a state at the Session-Reflector, to achieve one-way= delay and synthetic loss measurement on a bidirectional SR tunnel?<= u>

=C2=A0Gyan> Valid point=C2=A0

<RG2> Bidirectio= nal SR tunnel may have an SR state but the statement above is that no PM (i= .e. TWAMP Light) protocol session state is created for it. We can clarify in the next revision.

GIM2>> So-called stateless Session-Reflector i= n TWAMP Light is only one option. I am well-familiar with the implementatio= n that uses the stateful mode.=C2=A0

<RG3> What infor= mation stateful PM need to maintain in the state on the reflector? Doesn=E2= =80=99t that cause scale issues. We can add in the draft you if there is anything specifically needed in the spec.

GIM3>> RFCs 5357 and 8762 are clear about what= information must be maintained by a Session-Reflector. The Session-Reflect= or must have knowledge of the test session state and count reflected test p= ackets. The value of such a counter must be copied in the Sequence Number field of the reflected packet. Thus=C2=A0= the method enables the measurement of the one-way packet loss metric.

=C2=A0<RG> Quoti= ng the text from Appendix I in RFC 5357. We can quote the text as is.

=E2=80=9CIn the case of TWAMP Light, the=
 Session-Reflector does not necessarily have knowledge of the session state=
. =E2=80=9C

GIM>> By the informational nature of Appendix = I, the text is not normative. I am familiar with the implementation of TWAM= P Light which does maintain the session state and thus supports one-way packet loss measurement. If you require that the remote node does = not maintain the state, the draft must define that as part of the specifyin= g the behavior of the protocol.

=C2=A0<RG2> Ok, = we can discuss what information is to be maintained in that state on the re= flector for synthetic packet loss. We can add appropriate text if you can help please.

GIM2>> I don't see any reason to do that a= s that already defined in RFC 8762 and draft-ietf-ippm-stamp-yang=C2=A0

<RG3> Ok.= =C2=A0

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Further, in Section 3 the selection of UDP port explained as the fol= lowing:

=C2=A0 =C2=A0As specified in [RFC8545], the reflecto= r
=C2=A0 =C2=A0supports the destination UDP port 862 for delay measurement pr= obe
=C2=A0 =C2=A0messages by default.=C2=A0 This UDP port however, is not used = for loss
=C2=A0 =C2=A0measurement probe messages.

To the best of my understanding, as one of the contr= ibutors and=C2=A0Editors of RFC 8545, it re-allocated UDP port 862 for use = by a TWAMP Session-Reflector without excluding any type of measurement. Besides, in TWAMP delay and packet loss are measured in th= e same test session, using the same flow of TWAMP-Test packets.

=C2=A0Gyan> Agreed=C2=A0

<RG2> Yes, we ca= n use port 862 for both delay and synthetic packet loss =E2=80=93 they are = using the same test packet. There is no change proposed in the draft.

GIM2>> Packet delay and synthetic packet loss = measurements are already supported in RFC 8762. Are you proposing a new pro= tocol to duplicate the STAMP functionalities?

<RG3> As mention= ed, the extensions defined are for the direct-mode packet loss measurement = for TWAMP Light and STAMP.

<RG> The packet = loss in existing RFC 5357 refers to synthetic loss as there is no support f= or direct-mode loss in RFC 5357. We can change the text to clarify as =E2=80=9CThis UDP port however, is not used for direct-mode los= s measurement probe messages.=E2=80=9D

GIM>> I've found that there's some mis= conception in the draft. RFC 8545 re-assigned UDP port 862 not for "de= lay measurement probe messages" but for TWAMP-Test protocol. TWAMP-Tes= t protocol, in turn, supports packet delay, packet loss, reordering (RFC 473= 7 defines packet reordering metric), and packet duplication measurement.=

  • Then the draft states that

The sender uses the UDP port number following the gu= idelines specified in Section 6 in [RFC6335].

Could you point to the guidelines that a user can us= e when selecting a UDP port number of a test session?

Gyan> Good point =C2=A0

<RG> Please see section 6 in [RFC6335]. We can cite the range= which will be the same as used in [RFC8762]. This was also discussed earli= er.

https://mailarchive.ietf.= org/arch/msg/ippm/ONYYhG9Y8sbiNO15bxWIRM9ymEE/

GIM>> I've looked through Section 6 but I = don't find anything specifically applicable to this draft we're dis= cussing. If the protocol to use UDP port numbers from the Dynamic ports range, a.k.a., Private or Ephemeral, then it seems that stating that expli= citly would be the best way.=C2=A0

<RG2> This would be, User Ports and Dynamic Ports=
 ranges, which are defined in [RFC6335=
]. Yes, we can add this text.
  • At the closing of the paragraph, we read that

=C2=A0 The number of UDP ports with PM functionality= needs to be minimized due
=C2=A0 =C2=A0to limited hardware resources.

Does a UDP port number pose PM functionality? How it= is assigned to the port number?

<RG> UDP ports a= re user configured for delay and direct-mode loss PM as described in Sectio= n 3.1.

GIM>> Can UDP port 862 be used? Also, requirin= g that the direct-loss measurement uses port number different from the one = used by a TWAMP-Test packet, in my opinion, is another indication that this is the definition of a different from TWAMP Light PM OAM protoco= l.=C2=A0

<RG2> If we add = a field in the packet then UDP port 862 may be used along with the new fiel= d. But it will require extra processing in hardware. It is better to use a different UDP port for processing efficiency in hardware.<= /span>

  • Following the above-quoted text, in Section 3 is noted:
    • <= /ul>

    =C2=A0 =C2=A0For Performance Measurement, probe quer= y and response messages are
    =C2=A0 =C2=A0sent as following:

    Could you clarify if the listed further procedures d= eviate from OWAMP/TWAMP or follow procedures defined in RFC 4656 and RFC 53= 57 for Session-Sender and Session-Reflector respectively?

    <RG> Probe messages follow the same procedure as defined in R= FC 4656 and RFC 5357.

GIM>> All messages, i.e., TWAMP-Test packets a= s well as the defined in=C2=A0draft-gandhi-ippm-twamp-srpm?=C2=A0=

=C2=A0<RG2> Yes,= unless otherwise specified in the draft-gandhi-ippm-twamp-srpm.<= /u>

  • for both delay and loss measurements draft requires test packet be transmit= ted on a congruent path:

=C2=A0 =C2=A0 =C2=A0 the probe messages are sent on = the
=C2=A0 =C2=A0 =C2=A0 congruent path of the data traffic by the sender node<= u>

It is not clear what "the congruent path" means. The definition o= f=C2=A0congruency in geometry tells us that an object B is congruent=C2=A0t= o object A if it has the same shape and size, but is allowed to flip, slide= or turn. How a path can be congruent to another path?

=C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Agreed.=C2=A0 Th= e use of congruent in the context of pathing is confusing as the path being= addressed may not be reflected accurately by the term congruent.=

<RG2> As replied= above.

<RG> There are m= any existing RFCs that use term Congruent Path (e.g. RFC 5921, 6669) withou= t defining them. I suspect it is because it is well-known term. Having said that, we can add a reference for it if it helps reader.<= /span>

GIM>> I cannot assume what was the context of = these RFCs. I've sketched a network diagram above to illustrate=C2=A0th= at a "congruent path" may well lead to out-of-band path. Is that the intention of the authors of the draft to use this protocol out-of-band= ?

<RG2> As replied= above.

  • The last paragraph in Section 3 refers to work on iOAM:
    • <= /ul>

    =C2=A0 =C2=A0The In-Situ Operations, Administration,= and Maintenance (IOAM)
    =C2=A0 =C2=A0mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] an= d for
    =C2=A0 =C2=A0SRv6 defined in [I-D.ali-spring-ioam-srv6] are used to carry P= M
    =C2=A0 =C2=A0information such as timestamp in-band as part of the data pack= ets,
    =C2=A0 =C2=A0and are outside the scope of this document.

    Is iOAM in the scope of this specification? What are= the relationships between iOAM and=C2=A0draft-gandhi-spring-twamp-srpm?=

    <RG> As mentioned in the draft, IOAM is outside the scope.

GIM>> Yes, but it appears that references to t= he two IOAM-related drafts have some purpose. What is it? How are these dra= fts related to=C2=A0draft-gandhi-spring-twamp-srpm?=C2=A0

<RG2> We can rem= ove them if it is confusing. It is informational text (was added to address= a review comment).

  • Section 3.1 presents an example of the provisioning model but puts the defi= nition of the provisioning model outside the scope. Is there an accompanyin= g specification that defines the provisioning model that can be used in mul= ti-vendor deployment? Could that be YANG data model? What is the relationship with=C2=A0draft-= ietf-ippm-twamp-yang? Would the TWAMP YANG data model be augmented?<= /u>

<RG> Yes, this c= an be Yang model. We can review draft-ietf-ippm-twamp-yan= g and add any missing items in a s= eparate draft. We can also add a reference in this draft.

GIM>> I think that theremust=C2=A0be some disc= ussion on how the new protocol is configured. If TWAMP YANG data model can = be augmented, I'd expect that being defined in=C2=A0draft-gandhi-ippm-t= wamp-srpm. But I couldn't find anything about the configuration of the protocol.= =C2=A0

<RG2> The Yang m= odel extensions are not in the scope of this draft=C2=A0

  • Section 4.1 states that a new message is introduced to perform the Loss Mea= surement in this protocol Why the capability of TWAMP to measure the loss i= n one-way and two-way is not sufficient?

<RG> Existing TW= AMP messages do not support =E2=80=9Cdirect-mode=E2=80=9D loss measurement.= We can add =E2=80=9Cdirect-mode=E2=80=9D in the text to clarify.=

GIM>> True, direct loss measurement, in fact, = is not active measurement and thus is outside the scope of Two-Way Active M= easurement Protocol (TWAMP). The direct-loss measurement is, by the definition of RFC 7799, passive measurement method and fetching= counters can be done using numerous methods, e.g., SNMP, Netconf=C2=A0<= /u>

<RG2> RFC 7799 d= oes not say using Test-packets to collect counters for direct-mod loss meas= urement is passive.

GIM2>> Per RFC 7799, injecting in-band test pa= ckets is the characteristic of an active measurement method. Using out-of-b= and transport, e.g., SNMP queries, would be an example of a passive measurement method.=C2=A0

<RG3> Ok, so you= answered your own question that the direct-mode packet loss extension defi= ned is =E2=80=9Cactive measurement=E2=80=9D method.

  • Section 4.1.1 requires that

=C2=A0 The Destination UDP port cannot be used as So= urce port, since
=C2=A0 =C2=A0the message does not have any indication to distinguish betwee= n the
=C2=A0 =C2=A0query and response message.

Does that imply that the Destination UDP port used for the Delay measuremen= t is unique throughout the particular domain?

=C2=A0 =C2=A0 =C2=A0 =C2=A0Gyan> Good question=C2= =A0

<RG2> Yes, it is= unique in the domain.

<RG> This is use= r-defined and is up to the user what UDP port to provision in a domain.

GIM>> So, can user configure a port number fro= m the User Ports range? Or, can the same port number be used on the same sy= stem for a number of test sessions? I find the use of UDP port numbers being underspecified.

  • Section 4.1.2 of RFC 5357 does not define "the delay measurement messa= ge" but refers to the definition of the Session-Sender's test pack= et in RFC 4656 OWAMP. Note, that OWAMP and TWAMP are using a single test pa= cket format to perform both delay and packet loss measurement.

<RG> Ok, we can = update the text in the next revision to indicate exact name from the RFC 46= 56. We can also add text to include synthetic packet loss.=

GIM>> I think that making it explicit would he= lp. Also, that will highlight what is being introduced by *twamp-srpm draft= s is, in fact, a new protocol to perform synthetic packet loss measurement.=C2=A0

=C2=A0<RG2> No, = it does not change anything for synthetic packet loss.=

  • Can you explain how "the DM probe query message contains the payload f= ormat defined in Section 4.2.1 of [RFC5357]" when the referenced secti= on of RFC 5357 defines the format of a Session-Reflector's test packet?=

<RG> We can upda= te the text in the next revision to indicate query format name from RFC 535= 7.

GIM>> I cannot find any reference to a query f= ormat in RFCs 4656/5357. Could you please quote from any of these documents= ?

=C2=A0<RG2> It i= s test-packet, we will use RFC 5357 term.

  • Can clarify the applicability of RFC 6038 and the symmetrical packet size? = Is it required? Can it be non-symmetrical?
<RG> Yes. Please see section 4.1.1 and quoted bel=
ow:
=E2=80=9CFor symmetrical size query and =
response messages as defined in [RFC6038],=E2=80=9D

GIM>> RFC 6038 defines an extension to RFC 535= 7 for OPTIONAL use of the symmetrical test packets. Since *-twamp-srpm prop= osals do not use TWAMP-Control protocol and Appendix I in RFC 5357 tells us nothing about that either (in part because RFC 6038 came= later), I don't see that there's any certainty in what is the sze = of a test packet used in the direct-loss measurement.=C2=A0

=C2=A0<RG2> The = test-packets as defined in these existing RFCs are used for delay and synth= etic packet loss. The direct-mode test-packets are defined in this draft.

GIM2>> This draft defines only a new packet fo= rmat for the direct packet loss measurement. For STAMP such a mechanism is = clearly superfluous given the Direct Measurement TLV is already defined.=C2=A0

<RG3> As replied= earlier.

  • Can you clarify the use of the timestamp format, NTP or PTPv2? It is not cl= ear which is the default, mandatory or optional.

<RG> This is sam= e as TWAMP. There is no change.

GIM>> Per RFC 5357, TWAMP uses only NTP format= . Is that the case for *-twamp-srpm?=C2=A0

=C2=A0<RG2> No c= hange in existing in what is there in RFC 5357 and RFC 8186.<= u>

  • Also, is "hardware support in Segment Routing networks" of the PT= Pv2 format required, guaranteed, or something else?

<RG> Hardware ti= mestamps are recommended for SR use-cases. We can change the sentence.

GIM>> Perhaps you can propose some text, that = would be helpful.=C2=A0

=C2=A0<RG2> Ack.=

  • Section 4.1.1.1 stated that

=C2=A0 =C2=A0A separate user-configured
=C2=A0 =C2=A0destination UDP port is used for the delay measurement in
=C2=A0 =C2=A0authentication mode due to the different probe message format.=

Can that be interpreted that there could be concurre= nt authenticated and unauthenticated test sessions using this protocol? Wou= ld different authentication methods require using unique destination UDP port numbers?

<RG> Yes, and Ye= s, and these are based on provisioning.

GIM>> But that requirement is far outside the = TWAMP, as defined in RFC 5357.

=C2=A0<RG2> Some= Session-Sender can use authenticated and some not. It is part of RFC 5357.=

  • Section 4.1.2 by introducing the dedicated Loss measurement packet format, = effectively modifies the behavior defined in RFC 5357 for Session-Sender an= d Session-Reflector. But the document does not state that. Can you clarify = whether this specification changes the behavior of a Session-Sender and Session-Reflector as defined in RFC 4= 656 and RFC 5357 respectively for the support of packet loss measurement?

<RG> The direct-= mode loss defines new procedure for sender/reflector to collect traffic cou= nters, as opposed to timestamp. The rest is the same as RFC 4656 and 5357.

GIM>> I cannot agree with your statement "= ; The rest is the same as RFC 4656 and 5357" because the sender's = direct-loss format does not have Error Estimate field, Thus, a reflected packet does not have Sender's Error Estimate, nor Error Estimate of th= e reflector. And that, in my opinion, is another clear indication that *twa= mp-srpm drafts define a new protocol, separate from OWAMP/TWAMP.<= /u>

=C2=A0<RG2> That= field is specific to timestamps and would not apply to counters for direct= -mode loss measurement.

  • And a similar question about the use of the separate UDP port number for th= e authenticated of the packet loss measurement.
  • A couple of question to the following text in Section 4.1.3:<= /li>

=C2=A0 =C2=A0The local and remote IP
=C2=A0 =C2=A0addresses of the link are used as Source and Destination Addre= sses.
=C2=A0 =C2=A0They can also be IPv6 link local address as probe messages are= pre-
=C2=A0 =C2=A0routed.

    • What are the addresses of a link?

<RG> I am assumi= ng this well-known (e.g. RFC 2328).

GIM>> I am not familiar with the term "pr= e-routed". What does it mean?=C2=A0

=C2=A0<RG2> Ensu= re that packets are routed over the link.

    • In which scenarios an IPv6 LLA can be used?

<RG> I am assumi= ng this is well-known (e.g. RFC 5613).

GIM>> So, LLA may be used as the source and de= stination addresses when testing an SR tunnel?=C2=A0

=C2=A0<RG2> As m= entioned this is for links.

    • Also, could the use of a routable destination IP address be used as a DDOS = attack vector? Consider the scenario when an attacker generates SR-encapsul= ated packets with the destination IP address other than any of the SR-termi= nating nodes. Such=C2=A0a=C2=A0packet will be routed, correct? That does appear as a security threat, would you agree= ?

<RG> Absolutely = do not agree. It is no different than IP routed TWAMP packet as defined in = [RFC5357].

GIM>> You don't agree that the processing = described cannot happen because of laws of physics or it wouldn't happe= n because no one will think of that? If the latter, I think that that is security threat.

=C2=A0<RG2> Ther= e is no new threat like you have mentioned.

GIM2>> Hmmm, but how the integrity of TLVs pro= posed in=C2=A0draft-gandhi-ippm-stamp-srpm can=C2=A0be protected? These are= not protected by HMAC as presented in figures 3 and 5.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

<RG3> The extens= ions do not change the processing of these existing TLVs defined for HMAC. = We can add text to indicate this.

  • Section 4.1.4.2 references Figure 5 that, as I understand it, displays the= =C2=A0format of a probe query message. In figure two references to RFC 5357= are provided - a section that references RFC 4656 OWAMP definition of the = Session-Sender test packet, and a section that defines the Session-Reflector's reflected packet. Which of the tw= o is used for the delay measurement in the proposed protocol?=

<RG> The probe q= uery packet in the Session-Sender text packet. We can update the name.

  • Section 4.2.1 states that

=C2=A0 =C2=A0In one-way measurement mode, the probe = response message as defined in
=C2=A0 =C2=A0Figure 6 is sent back out-of-band to the sender node ...

Could you clarify how the responder controls that th= e response packet is sent not in-band but out-of-band?

<RG> Please refe= r to section 3.1 in draft-gandhi-ippm-twamp-srpm.=C2=A0 This is existing be= haviour for out-of-band.

GIM>>=C2=A0draft-gandhi-ippm-twamp-srpm does n= ot specify that it defines another new protocol OWAMP Light. And it is not = clear what you reference as "this is existing behavior". Is it to reference behavior of TWAMP test packet? But the behavior of the TWAMP-= Test protocol by itself is neither in-band, nor out-of-band. It is the enca= psulation of the TWAMP test packet that makes it either in-band or out-of-b= and.=C2=A0

=C2=A0<RG2> Righ= t.

GIM>> So, you believe that proposing to use th= e

<= /div>
--
--000000000000d02cca05b5bc855d-- From nobody Tue Dec 8 03:52:33 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346573A0C3A; Tue, 8 Dec 2020 03:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 IA7CS3iqRTf5; Tue, 8 Dec 2020 03:52:22 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 DBD2B3A0C38; Tue, 8 Dec 2020 03:52:21 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id d3so1849700wmb.4; Tue, 08 Dec 2020 03:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=RgwFfSNn6LNGzncG/Y9+lRm7eQMenEcKzxIH3g029+w=; b=GmEJ+T019RYAHRHwMwUnLul3FhdXrU9W8AyWenYF9fjSvfmd066yikEfaDRvBP7YvO fOMS+j475UE4zc9N7hctvJantucgO66ef/dExlMhvWR8nIYpkczsjDR/phJYcZYITQ0x mHyLziIvcgu3JkuVfZe2+HyWYOYG6Sa4/pglpD9PSVp5gwDgT0v0AFpPIfFUO6PLMbWy 3Ad2jRW4svUSS0xR3kiY26Fzbz/jn5HuukuCaaj9WBhJCITAMnVZlXvcVMa4Am5a/TUh 1WBy8WjYy3ii2v5YY3xPm7DnQdFskr836JD3FDYKb5iy/hDdSvAJjyImKDyAyziKBQWz 4nmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=RgwFfSNn6LNGzncG/Y9+lRm7eQMenEcKzxIH3g029+w=; b=O3dqffMtbNbiTEejyc+q6AQ0/zHQxRyKZAOguLqvi8vluaVdGo3bJRNXZYKG/DmRrh EHOcJes3bh56JyEbI4/Fhi9u9cQNHzA0fjpcyUffS3D4/0Q+XA7Oi24Pyg0L0VRtJMgF yKJ1oQorhxrx6Qh7y4NxY3oLS6eo1KsDdZpmIXthPwNe+R7dE9hW+xNmaR8tXhBTTE2Q tT3u9sNO6MXQNcru24dqjrX5lh5aaV3sEyZXgdI4w15IHHFzFvCQ627AqrydeUK3zb6G n1e2+aumy48ZLTgNsUXJE/Ois2nq82lCzOigALSCDPW4GxgN70WQjZwf9YoKRFCExzx+ OiZw== X-Gm-Message-State: AOAM532uop/R2pnbxl5sB35HQZ8bUSJVhh6JGa+lIBfOFqL9waI6qDf9 +UjCWe50+CQiUBCsoURiz3NOpUjseWjmi36xoVrMrUSxbqFPRA== X-Google-Smtp-Source: ABdhPJyPJtLQX+VXoTBL7yimZ/+v/Iv25QSoCL/C94X4bXrlEnANKL30qQ8BD3jJQ7mKpTle/129Bpa4zph8FLCC0aI= X-Received: by 2002:a1c:bb07:: with SMTP id l7mr3574315wmf.9.1607428339788; Tue, 08 Dec 2020 03:52:19 -0800 (PST) MIME-Version: 1.0 From: Tal Mizrahi Date: Tue, 8 Dec 2020 13:52:08 +0200 Message-ID: To: rtg-ads@ietf.org, draft-ietf-spring-sr-yang@ietf.org Cc: rtg-dir@ietf.org, spring@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [spring] RtgDir Review: draft-ietf-spring-sr-yang-28 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 11:52:24 -0000 Hello, 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 see http://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-spring-sr-yang-28 Reviewer: Tal Mizrahi Review Date: 08-Dec-2020 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The document defines a YANG data model for MPLS segment routing. The document is in good shape, and I believe it is almost ready for publication. My comments are mainly about the need for a clear definition of the scope of the document. While these comments do not require major changes in the document, a bit of rephrasing and clarifying text will go a long way here. Issues: - The document is focused on SR-MPLS, while RFC8402 discusses both SR-MPLS and SRv6. I am sure there is a good reason for this, but it is important to point out at the very beginning of the document that it does not cover SRv6 and preferably also the reason for this. - It is important to clarify the scope of the YANG models in the introduction: do they refer only to SR routers, or also to SR ingress/egress nodes? - The Common Types module is mentioned for the first time in Section 8. It would be appropriate to mention it and describe its purpose in Section 3. - In the following text it would be more accurate to replace: "with Segment Routing (SR)." ==> "with MPLS Segment Routing (SR)." "This augments routing data model (RFC 8349) with Segment Routing (SR)."; From nobody Tue Dec 8 12:11:50 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F31733A1128; Tue, 8 Dec 2020 12:11:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160745830892.24810.4016859024083365178@ietfa.amsl.com> Date: Tue, 08 Dec 2020 12:11:48 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-29.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 20:11:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Acee Lindem Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-29.txt Pages : 40 Date : 2020-12-08 Abstract: This document defines a YANG data model for segment routing configuration and operation, which is to be augmented by different segment routing data planes. The document also defines a YANG model that is intended to be used on network elements to configure or operate segment routing MPLS data plane, as well as some generic containers to be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-29 https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 8 12:14:05 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661033A084D; Tue, 8 Dec 2020 12:13:59 -0800 (PST) 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 olIsDCeHbFzo; Tue, 8 Dec 2020 12:13:57 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 430FE3A1123; Tue, 8 Dec 2020 12:13:52 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id z136so18172995iof.3; Tue, 08 Dec 2020 12:13:52 -0800 (PST) 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=EydDMxkF4C/DlxzEghjgsedx1VfV7jdOxq6yewlWVZY=; b=pXfQhf+BUYAYwSNSsU1L/WmD5nOA4Ofdp8Dtic1nbdFC75Hcs3qR1BIJPhiDPx9ykt PN/+N+0L9DXUrk4F30puF+n4aluP+0TcL5sJm9CIUnju4MjxjM+czrx14rtvZk7Esc6L Uqyol4frP7JfLFfSJNsXzstVdiCrTaAN0lgvVkGVJzD5FTvG1ce2goTKNbMIZta0oMCb 4MmU3K+yD0ppVYqkPSPaCsa4AvzGGO+L/vDW3eIXiyCxvsgTbouk6teSOy0IvtvcJk8H +7hH8DVpwI/s8p2NAORlOKHX/cinRFc8+pXly0aQqNKwUyLMxJWA1M+QQhePu8GvZOh1 6V6g== 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=EydDMxkF4C/DlxzEghjgsedx1VfV7jdOxq6yewlWVZY=; b=G7VA7n9Pso8rfQ/UEwohhsHlHNuNfEkBsXiKpVdV+CRWNrnYII+HJdUOIU4VUdkniY cgskYeF1rSrQLvoX9S6QSIYLtBeHOapiWfYkGlmIP8Nvp90X3OvzyK9GqqQ8XL12Zy+M z7/e2uNVMd/qTV9yRVJvSJwn25iplKApxLrNhp0ZBprnu55lc1tzZ3C81d4v4O8qgw7d ZYmkI/KFpDsf2IGTu2qUXHVzLXMr/yBMGILesTBKWyIZNy9IRTHGJy5MmM4gr67kLxqm +VB2XNckzjjPPw3BuYfM2qps+xGw4/oxEjcA5cYon9CkGTIpWkP/dm9clonUq5MghDx4 nfSw== X-Gm-Message-State: AOAM5307ph8r9DCNtX+7eYrNh1QmsQQgMF7KdANR3rtXuwP/qZB+nV9k AzfxRBlMddKUmSebU6QSOI3vKAwaNt+15M2ARg== X-Google-Smtp-Source: ABdhPJzkX8L27iOh27gp6pUSLXAhStMFPCMFvV+W9ic489M8JQDRFIWuc3EH4z4JTP1q4bJs8j331zvdarZnd5KYne4= X-Received: by 2002:a02:930e:: with SMTP id d14mr27821226jah.92.1607458431250; Tue, 08 Dec 2020 12:13:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yingzhen Qu Date: Tue, 8 Dec 2020 12:13:39 -0800 Message-ID: To: Tal Mizrahi Cc: rtg-ads@ietf.org, draft-ietf-spring-sr-yang@ietf.org, rtg-dir@ietf.org, spring@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000c93b1705b5f9945a" Archived-At: Subject: Re: [spring] [RTG-DIR] RtgDir Review: draft-ietf-spring-sr-yang-28 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 20:14:00 -0000 --000000000000c93b1705b5f9945a Content-Type: text/plain; charset="UTF-8" Hi Tal, Thank you for your review and comments, we have published version -29 to address your comments. Please see my detailed answers below inline. Thanks, Yingzhen On Tue, Dec 8, 2020 at 3:52 AM Tal Mizrahi wrote: > Hello, > > 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 see > http://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-spring-sr-yang-28 > Reviewer: Tal Mizrahi > Review Date: 08-Dec-2020 > Intended Status: Standards Track > > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > > Comments: > The document defines a YANG data model for MPLS segment routing. The > document is in good shape, and I believe it is almost ready for > publication. > > My comments are mainly about the need for a clear definition of the > scope of the document. While these comments do not require major > changes in the document, a bit of rephrasing and clarifying text will > go a long way here. > > > Issues: > - The document is focused on SR-MPLS, while RFC8402 discusses both > SR-MPLS and SRv6. I am sure there is a good reason for this, but it is > important to point out at the very beginning of the document that it > does not cover SRv6 and preferably also the reason for this. > [Yingzhen]: yes, this document focuses on the SR-MPLS data plane. However there is ietf-segment-routing.yang module defined as the generic frame, which is meant to be augmented by different data planes, including both SR-MPLS and SRv6. This was the consensus between the authors of this draft and authors of SRv6 YANG model. If you think the abstract and introduction is not clear, please let us know. > - It is important to clarify the scope of the YANG models in the > introduction: do they refer only to SR routers, or also to SR > ingress/egress nodes? > [Yingzhen]: for ingress/egress nodes, do you mean SR policy? which is defined in a separate draft: https://tools.ietf.org/html/draft-raza-spring-sr-policy-yang-03 > - The Common Types module is mentioned for the first time in Section > 8. It would be appropriate to mention it and describe its purpose in > Section 3. > [Yingzhen]: Good suggestion. I added a small paragraph for the common yang module. > - In the following text it would be more accurate to replace: "with > Segment Routing (SR)." ==> "with MPLS Segment Routing (SR)." > > "This augments routing data model (RFC 8349) > with Segment Routing (SR)."; > > [Yingzhen]: fixed. --000000000000c93b1705b5f9945a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal,

Thank you for your review and=C2=A0comments, we have published version= =C2=A0-29 to address your comments. Please see my detailed answers below in= line.

Thanks,
Yingzhen

On Tue, Dec = 8, 2020 at 3:52 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
Hel= lo,

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 see
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

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-spring-sr-yang-28
Reviewer: Tal Mizrahi
Review Date: 08-Dec-2020
Intended Status: Standards Track


Summary:
I have some minor concerns about this document that I think should be
resolved before publication.


Comments:
The document defines a YANG data model for MPLS segment routing. The
document is in good shape, and I believe it is almost ready for
publication.

My comments are mainly about the need for a clear definition of the
scope of the document. While these comments do not require major
changes in the document, a bit of rephrasing and clarifying text will
go a long way here.


Issues:
- The document is focused on SR-MPLS, while RFC8402 discusses both
SR-MPLS and SRv6. I am sure there is a good reason for this, but it is
important to point out at the very beginning of the document that it
does not cover SRv6 and preferably also the reason for this.
=C2=A0
=C2=A0[Yingzhen]: yes, this document focuses on the= SR-MPLS data plane. However there is ietf-segment-routing.yang module defi= ned as the generic frame, which is meant to be augmented by different data = planes, including both SR-MPLS and SRv6. This was the consensus between the= authors of this draft and authors of SRv6 YANG model. If you think the abs= tract and introduction is not clear, please let us know.=C2=A0
= =C2=A0=C2=A0
- It is important to clarify the scope of the YANG models in the
introduction: do they refer only to SR routers, or also to SR
ingress/egress nodes?

[Yingzhen]: =C2= =A0for ingress/egress nodes, do you mean SR policy? which is defined in a s= eparate draft: https://tools.ietf.org/html/draft-raza-spring-sr-policy-yan= g-03=C2=A0
=C2=A0
- The Common Types module is mentioned for the first time in Section
8. It would be appropriate to mention it and describe its purpose in
Section 3.

[Yingzhen]: Good suggestion.= I added a small paragraph for the common yang module.
=C2=A0
- In the following text it would be more accurate to replace: "with Segment Routing (SR)." =3D=3D> "with MPLS Segment Routing (SR)= ."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This augments routing data model (R= FC 8349)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with Segment Routing (SR).";

[Yingzhen]: fixed.
=C2=A0
= --000000000000c93b1705b5f9945a-- From nobody Tue Dec 8 22:03:07 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228713A0C93; Tue, 8 Dec 2020 22:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 waYpfzlLfNzK; Tue, 8 Dec 2020 22:02:52 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 2F12C3A0C90; Tue, 8 Dec 2020 22:02:52 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id c198so374248wmd.0; Tue, 08 Dec 2020 22:02:52 -0800 (PST) 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:content-transfer-encoding; bh=97voWjYgdVB0SgG03VBhF5f04clSUzfbqFXjIb+f0ek=; b=mRKZY/9wwyadWwcGIvGf6RPwXolqXtxQFyl23uKUI5uYVUKdG08fxSPfODr9AGxmgE 8d84YIpgI6r5GNTnnH6VTT4LuA24xNkyuOrgXFAVRwPCGYyn2DCEICizHGlWYh2veuaE PoM13N5JEV5u6AisZJasVmjbMWMGr0E0KEQynkMNb3dDY7YjsAxso/mwgYKsYGOR5Ds0 3+q9xT/c+lD9Sd5bTH2TALupfdcKIKm+N7tyu90T2XRTdY7qvE0amSZodKc2UIz1ZBX+ CvRsvdobCzo+iCX6Ixoda2RSthO4d0UThoGB9VejZUAOLglgFdyswNqwjnPucIEztdzF TU2w== 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:content-transfer-encoding; bh=97voWjYgdVB0SgG03VBhF5f04clSUzfbqFXjIb+f0ek=; b=VTFxeoak97i0LGDO8uzzQ1sbi0pxqS+z0yGUe9VHVSXiBcFP+xAPmjVmlxFr4Sw+Sl cQzzgU5FktV1dZsz8ax8X5abyH4aE7DLJ8TpWtTEmGwp+N8vKj363XPzokBg99iwwFvQ XYtWafQaRj43NQP/BVmVL4KaA6aNivT+dB/82aN6FwbfGLxU7ll7Va3yJN4opnrNgXz9 v1XRrGeTO2SkT2rLgPEry3HoJM1yaxwar3WOvYKaRO1MmsZKI4YoWpnL4FsDgr50/Dte WhNyETlidF99dGkk84l6ooI0hUbM7brRwSv7AW1sAT24aZVQBWfIkEy5LGSKmzT+fu6d ooiA== X-Gm-Message-State: AOAM531tCt6QuYFVyZEJ8NOF6BfGaHx6ONLFJudCFDYNqf4IjQBaIQp+ h/ykdNwB1viBh4Y+hb70pYBebrHhspp8jAHEqHY= X-Google-Smtp-Source: ABdhPJzCqLAoWN/bff7CJaSOyynWVg11qlekRbXymqbozxiXmW1sGDWzE7Ejawv7Xe0Sa+AS3QWe3TUEND3lIELGVbU= X-Received: by 2002:a1c:5459:: with SMTP id p25mr847347wmi.19.1607493770563; Tue, 08 Dec 2020 22:02:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Wed, 9 Dec 2020 08:02:38 +0200 Message-ID: To: Yingzhen Qu Cc: rtg-ads@ietf.org, draft-ietf-spring-sr-yang@ietf.org, rtg-dir@ietf.org, spring@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] [RTG-DIR] RtgDir Review: draft-ietf-spring-sr-yang-28 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 06:02:54 -0000 Hi Yingzhen, Thanks for the quick response. Please see below. > [Yingzhen]: yes, this document focuses on the SR-MPLS data plane. Howeve= r there is ietf-segment-routing.yang module defined as the generic frame, w= hich is meant to be augmented by different data planes, including both SR-M= PLS and SRv6. This was the consensus between the authors of this draft and = authors of SRv6 YANG model. If you think the abstract and introduction is n= ot clear, please let us know. Right. I believe this point should be clarified in the introduction with an informative reference to the SRv6 YANG draft. > [Yingzhen]: for ingress/egress nodes, do you mean SR policy? which is de= fined in a separate draft: https://tools.ietf.org/html/draft-raza-spring-sr= -policy-yang-03 Right, again I suggest to clarify this point in the draft. Cheers, Tal. On Tue, Dec 8, 2020 at 10:13 PM Yingzhen Qu wrote= : > > Hi Tal, > > Thank you for your review and comments, we have published version -29 to = address your comments. Please see my detailed answers below inline. > > Thanks, > Yingzhen > > On Tue, Dec 8, 2020 at 3:52 AM Tal Mizrahi wr= ote: >> >> Hello, >> >> 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 see >> http://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-spring-sr-yang-28 >> Reviewer: Tal Mizrahi >> Review Date: 08-Dec-2020 >> Intended Status: Standards Track >> >> >> Summary: >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> >> Comments: >> The document defines a YANG data model for MPLS segment routing. The >> document is in good shape, and I believe it is almost ready for >> publication. >> >> My comments are mainly about the need for a clear definition of the >> scope of the document. While these comments do not require major >> changes in the document, a bit of rephrasing and clarifying text will >> go a long way here. >> >> >> Issues: >> - The document is focused on SR-MPLS, while RFC8402 discusses both >> SR-MPLS and SRv6. I am sure there is a good reason for this, but it is >> important to point out at the very beginning of the document that it >> does not cover SRv6 and preferably also the reason for this. > > > [Yingzhen]: yes, this document focuses on the SR-MPLS data plane. Howeve= r there is ietf-segment-routing.yang module defined as the generic frame, w= hich is meant to be augmented by different data planes, including both SR-M= PLS and SRv6. This was the consensus between the authors of this draft and = authors of SRv6 YANG model. If you think the abstract and introduction is n= ot clear, please let us know. > >> >> - It is important to clarify the scope of the YANG models in the >> introduction: do they refer only to SR routers, or also to SR >> ingress/egress nodes? > > > [Yingzhen]: for ingress/egress nodes, do you mean SR policy? which is de= fined in a separate draft: https://tools.ietf.org/html/draft-raza-spring-sr= -policy-yang-03 > >> >> - The Common Types module is mentioned for the first time in Section >> 8. It would be appropriate to mention it and describe its purpose in >> Section 3. > > > [Yingzhen]: Good suggestion. I added a small paragraph for the common yan= g module. > >> >> - In the following text it would be more accurate to replace: "with >> Segment Routing (SR)." =3D=3D> "with MPLS Segment Routing (SR)." >> >> "This augments routing data model (RFC 8349) >> with Segment Routing (SR)."; >> > [Yingzhen]: fixed. > From nobody Wed Dec 9 01:36:29 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337E93A0FB3; Wed, 9 Dec 2020 01:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kLJ2ORbV71iD; Wed, 9 Dec 2020 01:36:26 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359113A003E; Wed, 9 Dec 2020 01:36:26 -0800 (PST) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CrX1d0nHdz67Nfj; Wed, 9 Dec 2020 17:34:13 +0800 (CST) Received: from fraeml798-chm.china.huawei.com (10.206.15.19) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 9 Dec 2020 10:36:18 +0100 Received: from fraeml798-chm.china.huawei.com (10.206.15.19) by fraeml798-chm.china.huawei.com (10.206.15.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 9 Dec 2020 10:36:18 +0100 Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by fraeml798-chm.china.huawei.com (10.206.15.19) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 9 Dec 2020 10:36:18 +0100 Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.75]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Wed, 9 Dec 2020 17:36:11 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: Meeting minutes for the SPRING sessions @IETF109 Thread-Index: AdbAGRfGMzWYxb4KQLio+b88ZU92fAN9U9vg Date: Wed, 9 Dec 2020 09:36:11 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE196A5FD5@dggeml512-mbx.china.huawei.com> References: <4278D47A901B3041A737953BAA078ADE19616F3A@dggeml512-mbx.china.huawei.com> In-Reply-To: <4278D47A901B3041A737953BAA078ADE19616F3A@dggeml512-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.194.142] Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE196A5FD5dggeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Meeting minutes for the SPRING sessions @IETF109 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 09:36:28 -0000 --_000_4278D47A901B3041A737953BAA078ADE196A5FD5dggeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find the published meeting minutes and relevant materials. https://datatracker.ietf.org/meeting/109/session/spring Best regards, Shuping From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Pen= g Shuping) Sent: Saturday, November 21, 2020 11:15 PM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] Meeting minutes for the SPRING sessions @IETF109 Hi Folks, Please find the meeting minutes for the two SPRING sessions @IETF109. https://codimd.ietf.org/notes-ietf-109-spring?edit Please check and correct. e.g. , your name and your comments. Thank you! Cheers! Best regards, Shuping --_000_4278D47A901B3041A737953BAA078ADE196A5FD5dggeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear al= l,

&n= bsp;

Please = find the published meeting minutes and relevant materials.

https://datatr= acker.ietf.org/meeting/109/session/spring

&n= bsp;

Best re= gards,

Shuping=

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Saturday, November 21, 2020 11:15 PM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: [spring] Meeting minutes for the SPRING sessions @IETF109

 

Hi Folks,

 

Please find the meeting minutes= for the two SPRING sessions @IETF109.

https://codimd.ietf.org/notes-ietf-109-spri= ng?edit

 

Please check and correct. e.g. = , your name and your comments. Thank you!

 

Cheers!

 

Best regards,

Shuping

 

 

--_000_4278D47A901B3041A737953BAA078ADE196A5FD5dggeml512mbxchi_-- From nobody Wed Dec 9 09:04:31 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E9A3A0FDE; Wed, 9 Dec 2020 09:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aqI2FLR4QFZt; Wed, 9 Dec 2020 09:04:25 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 ECBD13A0FD5; Wed, 9 Dec 2020 09:04:24 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B9H4EgA018689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 9 Dec 2020 12:04:19 -0500 Date: Wed, 9 Dec 2020 09:04:13 -0800 From: Benjamin Kaduk To: "Pablo Camarillo (pcamaril)" Cc: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Message-ID: <20201209170413.GU64351@kduck.mit.edu> References: <160093393224.24080.1727360124332839831@ietfa.amsl.com> <20201125011313.GH39170@kduck.mit.edu> <20201126001143.GO39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 17:04:30 -0000 Hi Pablo, Thanks for the updates through the -26; I'll be posting an updated ballot position shortly (with one late-breaking but hopefully trivial to resolve new discuss point, plus more comments). A few notes inline as well... On Thu, Nov 26, 2020 at 04:50:36PM +0000, Pablo Camarillo (pcamaril) wrote: > Hi Ben, >=20 > Please see inline with PC3. > Note that we've posted rev26: https://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-spring-srv6-network-programming-26 >=20 > Many thanks for your time, > Pablo. >=20 > -----Original Message----- > From: Benjamin Kaduk =20 > Sent: jueves, 26 de noviembre de 2020 1:12 > To: Pablo Camarillo (pcamaril) > Cc: The IESG ; draft-ietf-spring-srv6-network-programming@= ietf.org; spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene ; Joel Halpern > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-p= rogramming-20: (with DISCUSS and COMMENT) >=20 > Hi Pablo, >=20 > Thanks for the updates; the changes in the -25 all look good to me. >=20 > More inline... >=20 > On Wed, Nov 25, 2020 at 09:42:42PM +0000, Pablo Camarillo (pcamaril) wrot= e: > > Hi Ben, > >=20 > > Thanks for your careful review. Replies to your comments inline with PC= 2. > > Note that I=E2=80=99ve posted rev25 of the draft. > >=20 > > Thanks, > > Pablo. > >=20 > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: mi=C3=A9rcoles, 25 de noviembre de 2020 2:13 > > To: Pablo Camarillo (pcamaril) > > Cc: The IESG ;=20 > > draft-ietf-spring-srv6-network-programming@ietf.org;=20 > > spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene=20 > > ; Joel Halpern > > Subject: Re: Benjamin Kaduk's Discuss on=20 > > draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and=20 > > COMMENT) > >=20 > > Hi Pablo, > >=20 > > I must apologize twice over: first for the delay in responding, and sec= ond for the number of points in my discuss ballot that are not actual probl= ems. > > I recently had the time to go over the document again, with benefit of = your responses here, and now have a better understanding of some aspects th= at were confusing to me during my first reading. I still have a few things= I want to take another look at, but I can respond to your comments now -- = the good news is that these discuss points all look to be resolved. > >=20 > > More inline... > >=20 > > On Fri, Sep 25, 2020 at 06:31:52PM +0000, Pablo Camarillo (pcamaril) wr= ote: > > > Hi Benjamin, > > > > > > Thank you for your time and review. Please see inline with [PC]. > > > > > > Regards, > > > Pablo. > > > > > > -----Original Message----- > > > From: Benjamin Kaduk via Datatracker > > > Sent: jueves, 24 de septiembre de 2020 9:52 > > > To: The IESG > > > Cc: draft-ietf-spring-srv6-network-programming@ietf.org; > > > spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene=20 > > > ; Joel Halpern ;=20 > > > jmh@joelhalpern.com > > > Subject: Benjamin Kaduk's Discuss on > > > draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and > > > COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-spring-srv6-network-programming-20: Discuss > > > > > > When responding, please keep the subject line intact and reply to=20 > > > all email addresses included in the To and CC lines. (Feel free to=20 > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-prog > > > ra > > > mming/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > [edited to remove nonsensical point that had crept in about the SRH= =20 > > > being a new extension header; it's "just" a routing header] > > > > > > The current requirement that IANA-assigned SRv6 Endpoint Behavior cod= epoints are used, with no range reserved for local assignment, seems to be = inviting codepoint squatting from the nominally reserved range. > > > Why is there an absolute requirement for registration (even FCFS)=20 > > > without ranges for local or experimental use? (What are the various = reserved ranges reserved for?) [PC] I agree with you that a range for local= use would come useful. Hence, we=E2=80=99ve carved 2k entries of the regis= try for Private Use. > > > The Reserved range (half of the 65k registry) is for future allocatio= n by IETF. Future RFCs might decide how to use that. > >=20 > > Sounds good; thanks! > >=20 > > > The (normative) pseudocode does not seem to handle the case when the = SRH is omitted for the degenerate case where there is only a single segment= , or for the PSP flavor. > > > [PC] Each one of the pseudocodes provides the SRH processing and the = Upper-Layer processing. If there is no SRH, then the SRH processing is not = executed, but the Upper-layer Header processing is. This is the same as in = RFC8754. > >=20 > > To expand a bit more on how I was confused here, I was looking particul= arly at the End, End.X, and End.T cases (though I guess it also applies to = the Encaps cases). In the normal flavor, upper-layer processing gets shunt= ed over to section 4.1.1 that doesn't really do much -- in particular, ther= e is no interconnect for End.X and no table lookup for End.T! But this rea= lly is the right behavior, since the SRH is only absent when this SID is th= e final destination of the packet, and in that case we really must act as a= n endpoint and not a router. If we did send the packet onward it would mos= t likely just get looped back to us until the hop limit expires (or get som= e other error), so generating a local ICMP error is the right thing to do i= n the general case, unless there is local configuration for that upper-laye= r protocol. > >=20 > > [PC2] Ack > >=20 > > > The pseudocode for the PSP and USP procedures seem incorrect -- Hdr E= xt Len is measured in units of 8 octets, and does not include the first 8 o= ctets of the extension header, but Payload Length is measured in octets. L= iterally decreasing the Payload Length by the Hdr Ext Len value will produc= e a malformed IPv6 packet. > > > [PC] Indeed. Fixed. > > > > > > If "PSP operation is deterministically controlled by the SR Source No= de", why do we need to define behavior codepoints that (for example) use bo= th PSP and USP? I don't see how there is full determinism in this case whi= le being different from the "PSP only" flavor. > > > [PC] In order for the PSP behavior to be executed there must happen t= wo things. First, the SR Source Node must instruct it wants to use the PSP = behavior. This is done by using an SRv6 SID associated with a behavior that= support the PSP flavor (either End with PSP alone, or End with PSP in comb= ination of other). Then, the second thing is that the received packet at th= e node it must have a SL value of 1, that during processing is decremented = to 0. (In other words, it must be the penultimate segment). If both conditi= ons are given, then lines S14.2-S14.4 of the pseudocode are executed. > >=20 > > I understand now; thanks for explaining it again. (To reiterate: any= =20 > > given SID can appear "anywhere" in the segment list, so USP is=20 > > relevant when it is last and PSP is relevant when it appears=20 > > second-to-last. The USP/PSP flavor doesn't need to be the same for=20 > > all SIDs in the path, so marking a single SID with both can be=20 > > relevant for different paths.) > >=20 > > [PC2] Correct > >=20 > > > There are numerous factual errors and un/under-specified protocol beh= avior (see COMMENT), including: how to set the outer Hop Limit (multiple in= stances), the order of segments in the SRH, specification of headend behavi= or by reference to informal example, L2 frame en/decapsulation procedures, = and the "Opaque" note for endpoint behavior 65535. > > > [PC] I=E2=80=99ll comment on each point in the comment. > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > I note that this document references=20 > > > draft-filsfils-spring-srv6-net-pgm-illustration, which uses the IPv4 = CIDR 20/8 in examples instead of addresses from the RFC 5737 range. It wou= ld be disappointing to have a PS refer to a draft that squats on the IPv4 n= amespace in such a manner. > > > [PC] Ack. I=E2=80=99ve updated draft-filsfils-spring-srv6-net-pgm-ill= ustration to correct that. > >=20 > > Thank you! > >=20 > > > Abstract, Introduction > > > > > > This document defines the SRv6 Network Programming concept and > > > specifies the base set of SRv6 behaviors that enables the creation= of > > > interoperable overlays with underlay optimization (Service Level > > > Agreements). > > > > > > I don't understand what the parenthetical is intending to convey. > > > [PC] I=E2=80=99ve removed the parenthesis. Its unneeded. > > > > > > Section 2 > > > > > > The following terms used within this document are defined in > > > [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 > > > SID, SR Policy, Prefix SID, and Adjacency SID. > > > > > > [RFC 8402 spells it Prefix-SID (with hyphen) and Adj-SID.] [PC]=20 > > > Fixed in rev21. > > > > > > Section 3 > > > > > > The text allegedly reproduced from RFC 8754 =C2=A74.3 differs in case= and hyphenation. > > > [PC] Fixed in rev21. > > > > > > Section 3.1 > > > > > > This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, > > > where a locator (LOC) is encoded in the L most significant bits of > > > the SID, followed by F bits of function (FUNCT) and A bits of > > > arguments (ARG). L, the locator length, is flexible, and an opera= tor > > > is free to use the locator length of their choice. F and A may be > > > any value as long as L+F+A <=3D 128. When L+F+A is less than 128 = then > > > the remaining bits of the SID MUST be zero. > > > > > > Why does A have to be a fixed value; can't it safely be a function of= F (even if we exclude things like huffman coding for F)? > > > [PC] Can you please re-state your point? The text above does not sugg= est that A is a fixed value, hence I=E2=80=99m not sure I fully understand = what you mean. > >=20 > > It's true that there is no specific statement "A is a constant across= =20 > > ". However, there is also not a specific=20 > > statement "the value of A can depend on ", so=20 > > the reader has to make an interpretation. We do say that L is=20 > > flexible and the operator can choose that length; I interpreted this=20 > > to mean that the operator makes the choice once, and that L is fixed=20 > > for the entire SR domain. With that in my head, it was also natural=20 > > to infer that F and A are also fixed for the entire SR domain. (Is L= =20 > > allowed to vary even within the domain?) > >=20 > > [PC2] Note that in RFC8754 we have =E2=80=9CWhen an SRv6-capable node = receives an IPv6 packet, it performs longest-prefix-match lookup on the pac= ket=E2=80=99s destination address.=E2=80=9D. Hence things work even if two= nodes use a different L for their locators or different sizes of F and A = for their SIDs. >=20 > I guess so. (In my head the ability to use longest-prefix was useful for= when the SID and non-SID addresses could be consolidated into a single pre= fix applicable to that node, but I have no particular reason to have been t= hinking that.) >=20 > If I might make a suggestion, writing "free to use the locator length of = their choice for any given SID" would have forestalled my confusion in this= regard, and seems like a minor change to make. But it is your decision as= to whether or not to make any changes here; I am satisfied just with the e= xplanation above. >=20 > [PC3] Ack=20 >=20 > > If we do want to allow F and A to vary at a (e.g.) per-LOC scope, we sh= ould probably make some statement about being able to decode them properly = on receipt; this could be done in many ways, including a strict lookup tabl= e and a self-deliniating length-encoding scheme, but there cannot be ambigu= ity about how to partition a given IP address into LOC:FUNCT:ARG. > >=20 > > [PC2] Please refer to previous comments and also the text in Sec 3. The= SR Endpoint Node performs LPM lookup to match the FIB entry corresponding = to SIDs that it has instantiated in order to execute the instructions speci= fic to its behavior. The packet with the SID in the DA is routed through tr= ansit nodes based on LPM lookup that happens on the locator parts that are = advertised via routing/control plane as described in Sec 3.3. The transit n= odes do not have to decode or program SIDs that have been instantiated by o= ther SR Endpoint nodes in the domain. >=20 > I agree that the transit nodes don't need to know anything about this. > The node that instantiates the SID, however, does. As a totally contrive= d example, suppose that I have a prefix of abcd:abcd:: as my LOC and I want= to use FUNCT of 0x1234 to indicate behavior codepoint 1, FUNCT of > 0x12351235 to indicate behavior codepoint 2, and FUNCT of 0x12351236 to i= ndicate behavior codepoint 3. I basically have to store that in a table, a= nd can't write some logic that looks at the 16 bits after the LOC. If I in= stead used 0x1234, 0x22351235, and 0x22351236, then the first four bits aft= er LOC could be the length of FUNCT encoding in 2-byte increments, and I co= uld have some "simple" code to unpack the self-delineating encoding. >=20 > [PC3] Lets remind that RFC8754 explicitly states "it performs a longest-p= refix-match lookup". Anything after that is a local implementation decision= by the segment endpoint that instantiates the SID and is outside the scope= of this document.=20 >=20 > In short: this topic only considers how a given node assigns its own LOC:= FUNCT:ARG values, and may be self-evident to most readers, but it can still= be helpful to note as guidance on how to make those allocations. >=20 > > > An SRv6 Segment Endpoint Behavior may require additional informati= on > > > for its processing (e.g. related to the flow or service). This > > > information may be encoded in the ARG bits of the SID. > > > > > > (Assuming that it can be sufficiently compactly encoded?) [PC]=20 > > > Correct > > > > > > The ARG value of a routed SID SHOULD remain constant among packets= in > > > a given flow. Varying ARG values among packets in a flow may=20 > > > result > > > > > > (Thus limiting the type of information that can be represented in=20 > > > the > > > ARG?) > > > [PC] This text provides a SHOULD, and a reason for it. If other behav= iors defined in future documents would like to have ARG value varying for p= ackets belonging to the same flow, it is important that they take this into= consideration. > > > > > > Section 3.2 > > > > > > SIDs. The provider historically deployed IPv6 and assigned > > > infrastructure addresses from a portion of the fc00::/7 prefix. T= hey > > > further subdivided the prefix into three /48 prefixes (Country X, > > > Country Y, Country Z) to support their SRv6 infrastructure. From > > > those /48 prefixes each router is assigned a /64 prefix from which > > > all SIDs of that router are allocated. > > > > > > This is not the language I would have expected for use of the ULA add= ress range. It looks like this may be related to Erik Kline's Discuss poin= t... > > > [PC] Indeed related. Erik Kline has suggested text. Ill use Erik=E2= =80=99s text as provided. > > > > > > IPv6 address consumption in both these examples is minimal, > > > representing one billionth and one millionth of the assigned addre= ss > > > space, respectively. > > > > > > I'm not sure I understand the calculation that produced these values. > > > [PC] If the operator got assigned a /20 by the RIR, then they have 2^= 28 /48 prefixes available. Thus, if they are only using a few /48 prefixes,= then they are using less than a millionth of the available /48 prefixes. > >=20 > > Apparently I didn't take notes on my initial calculations that left me = confused. Assuming I have it right this time... > >=20 > > # Use 3 /48s in the whole ULA /40 > > >>> 3./2**40 > > 2.7284841053187847e-12 > > # Use "a few" 3 /48s from the assigned /20 > > >>> 3./2**28 > > 1.1175870895385742e-08 > >=20 > > This seems to be well less than a billionth and a millionth, respective= ly, so I'm not sure if I am doing the math as intended. > >=20 > > [PC2] I believe your maths are right. > > If an operator is allocated a /20, they can allocate 2**28 /48 prefixe= s. > > 2**28 =3D 268435456. > > Thus, If SRv6 requires 3 of such /48 prefixes, then we are using only 1= =2E12e-8 of that space, which is less than a millionth (e-6). > > No? > > In other words: if we do a million of deployments of SRv6, there would= =20 > > be space to fit them all within that /20. (and actually there is=20 > > slightly more) >=20 > I would suggest adding "less than" in the text, then. >=20 > [PC3] Got it. Updated. > =20 > > > An SR Source Node cannot infer the behavior by examination of the > > > FUNCT value of a SID. > > > > > > Therefore, the SRv6 Endpoint Behavior codepoint is advertised along > > > with the SID in the control plane. > > > > > > These two sentences feel a little out of place in this spot, occurrin= g after previous discussion that the endpoint behavior codepoint is adverti= sed in the control plane. > > > [PC] Other ADs have expressed the value of precisely those two senten= ces. > >=20 > > I agree that these sentences are valuable. I was proposing to move the= m two paragraphs earlier, so we transition directly from "advertises the SI= D ... in the control plane" to (paraphrasing) "cannot infer behavior by exa= mining FUNCT" and "behavior codepoint is advertised along with SID". > >=20 > > [PC2] Misunderstood your original point. I moved those two up as you su= ggest. > >=20 > > > o At Router 3, within the locator 2001:db8:bbbb:3::/64, network > > > operator or the router performs dynamic assignment for: > > > > > > nit: missing article ("the network operator"). > > > [PC] Ack. Fixed in rev21. > > > > > > * Function 100 associated with the behavior End.X (Endpoint wi= th > > > cross-connect) between router 3 and its connected neighbor > > > router, for example Router 4. This function is encoded as > > > 16-bit value and has no arguments. > > > > > > Please clarify that "function 100" is a hex literal. > > > [PC] Ack. Fixed in rev21. > > > > > > I also suggest noting clearly at the start of the example that F is 1= 6 and A is 0. > > > [PC] Ack. Added for each SID in rev21. > > > > > > * Function 101 associated with the behavior End.X (Endpoint wi= th > > > cross-connect) between router 3 and its connected neighbor > > > router, for example Router 2. This function is encoded as > > > 16-bit value and has no arguments. > > > > > > F is a constant for the SR domain; saying it at each SID assignment i= s misleading. > > > [PC] Function is the bits in the SID instantiated by the router. Can = you please explain what text gives the impression that F is a constant? > >=20 > > FUNCT is instantiated by the router, yes, and it is F bits long. This = ties in to my previous comment about L, F, and A (maybe) being constants ac= ross the SR domain, or clarifying at which scope they can vary. > >=20 > > [PC2] Indeed, see previous answer. > >=20 > > > [same note about hex for 101] > > > [PC] Ack. Added for each SID in rev21. > > > > > > Section 4 > > > > > > The list is not exhaustive. In practice, any function can be > > > attached to a local SID: e.g. a node N can bind a SID to a local VM > > > or container which can apply any complex processing on the packet. > > > > > > Yes, but it can't advertise the behavior corresponding to that functi= on without a codepoint. > > > [PC] This is intended to be an introductory paragraph to the behavior= s. But you are absolutely right: for any new behavior you need to write a n= ew I-D (as its currently happening in other SPRING WG docs), and then -once= RFCed- get an SRv6 Endpoint Behavior codepoint for it. > >=20 > > Maybe we could add at the end ", provided there is a behavior=20 > > codepoint allocated for that processing" or some similar edit? (We=20 > > don't have to; the decision is up to you.) > >=20 > > [PC2] I'm fine with it. Added as suggested. > >=20 > > > Section 4.1.1 > > > > > > When processing the Upper-layer Header of a packet matching a FIB > > > entry locally instantiated as an SRv6 End SID, if Upper-layer Head= er > > > processing is allowed by local configuration (e.g. ICMPv6), then > > > > > > nit: the parenthetical is placed so as to apply to "local configurati= on", which doesn't really make sense; I presume the intent is to say that u= pper-layer header processing is allowed *for that upper-layer protocol*. A= lso, comma after "e.g.". > > > [PC] Agreed, but see next point. > > > > > > problem message to the Source Address and discard the packet. Err= or > > > code 4 (SR Upper-layer Header Error) and Pointer set to the offset= of > > > the upper-layer header. > > > > > > nit: this is not a complete sentence. > > > [PC] We have been asked to change the entire 4.1.1 to a pseudocode. P= lease review the pseudocode in revision 21 and let me know your feedback. > >=20 > > Yes, this pseudocode looks much better -- thank you! > >=20 > > That said, I am not sure that I understand why it is only RECOMMENDED= =20 > > (not > > REQUIRED) to only allow upper-layer processing when that does not resul= t in the packet being forwarded. Are there cases when this would be useful= and not result in a packet loop? > >=20 > > [PC2] We believe that RECOMMENDATION is strong enough for this scenario= =2E I am not sure that we can say that packets forwarded after local proces= sing will always result in a loop e.g. if there is an inner encapsulated IP= packet that needs to get forwarded further. >=20 > Okay. >=20 > > > Section 4.2 > > > > > > It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it = is > > > required to express any traffic-engineering policy. > > > > > > This text reads as if End.X specifically is required for TE, which do= es not seem correct to me. > > > [PC] Fixed. > > > OLD: and it is required to express any traffic-engineering policy. > > > NEW: and its main use is for traffic-engineering policies. > > > > > > Section 4.4, 4.5 > > > > > > This is equivalent to the per= -CE > > > VPN label in MPLS [RFC4364]. > > > > > > The phrase "per-CE VPN" does not appear in RFC 4364. > > > [PC] Added to the terminology section. > > > > > > Section 4.5 > > > > > > S05. If the End.DX4 SID is bound to an array of L3 adjacencies, t= hen > > > one entry of the array is selected based on the hash of the packet= 's > > > header Section 7. > > > > > > nit: I suggest "(see Section 7)" to match section 4.4. > > > [PC] Indeed. Fixed. > > > > > > Section 4.6, 4.7 > > > > > > is required. This is equivalent to the per-VRF VPN label in MPLS > > > [RFC4364]. > > > > > > The phrase "per-VRF VPN" does not appear in RFC 4364. > > > (A similar comment applies to Section 4.8 as well.) [PC] Added to=20 > > > the terminology section of the document. > > > > > > Note that an End.DT6 may be defined for the main IPv6 table in whi= ch > > > case and End.DT6 supports the equivalent of an IPv6inIPv6 > > > > > > nit: s/and/an/ > > > [PC] Thanks. Fixed. > > > > > > Section 4.7 > > > > > > The "Endpoint with decapsulation and specific IPv4 table lookup" > > > behavior (End.DT4 for short) is a variant of the End behavior. > > > > > > nit: variant of End.T, just like End.DT6, no? > > > [PC] Correct, fixed. > > > > > > Section 4.9 > > > > > > S04. An End.DX2 behavior could be customized to expect a specific > > > IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header > > > before forwarding on the outgoing interface. > > > > > > Would this customized behavior require a new codepoint? > > > Similarly for End.DX2V (Section 4.10) [PC] No, that customization is= =20 > > > local config to the node. > >=20 > > That is surprising to me (it seems like an important part of the behavi= or that should be signalled explicitly), but I am not familiar enough with = this domain in order to argue about it any further. > >=20 > > [PC2] In MPLS this is local config. While someone might think about sig= naling it in the future -intuitively makes sense-, in today=E2=80=99s use-c= ase it isn=E2=80=99t. >=20 > Thanks for the pointer about MPLS, that helps. > And I agree that it seems straightforward to add signaling in the future = if needed. >=20 > > > Section 4.10 > > > > > > S04. Remove the outer IPv6 Header with all its extension headers, > > > lookup the exposed VLANs in L2 table T, and forward > > > via the matched table entry. > > > > > > Just to check my understanding: the "exposed VLANs" (plural?!) are in= the Ethernet header of the packet that we are left with after removing the= outer IPv6 header, right? > > > [PC] Correct. And multiple tags in case of Q-in-Q. > > > > > > S01. IANA has allocated the Internet Protocol number 143 to Ether= net > > > (see Section 10.1). > > > > > > This seems like a copy/paste leftover from End.DX2 -- we don't=20 > > > mention > > > 143 in this section. > > > [PC] Indeed. I added by mistake on rev20 to address an AD comment and= I have just removed in rev21 again. > > > > > > Section 4.12 > > > > > > Two of the applications of the End.DT2M behavior are the EVPN > > > Bridging of broadcast, unknown and multicast (BUM) traffic with > > > Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use- > > > cases. > > > > > > Are there references for either/both of these? > > > [PC] Added in rev21. > >=20 > > Thanks! > >=20 > > > S04. Remove the IPv6 header and all its extension headers > > > > > > nit: the rest of the document uses "Remove the outer IPv6 header with= all its extension headers". > > > [PC] Fixed. Thanks. > > > > > > S06. Forward via all L2 OIFs excluding the one specified in=20 > > > Arg.FE2 > > > > > > nit: s/one/ones/ > > > [PC] Fixed. Thanks. > > > > > > Arg.FE2 is encoded in the SID as an (k*x)-bit value. These bits > > > represent a list of up to k OIFs, each identified with an x-bit > > > value. Values k and x are defined on a per End.DT2M SID basis. T= he > > > interface identifier 0 indicates an empty entry in the interface > > > list. > > > > > > (editorial) rather than have to come up with the concept of an "empty= entry" in the interface list, I would probably just say that the identifie= r 0 is reserved and is ignored when doing the exclusion of OIFs. > > > > > > I also think we need to say that the order and identifier assignment= =20 > > > of elements of the interface list (that is, what the x-bit values=20 > > > index > > > into) is under the local control of N, but has to remain stable as=20 > > > long as SIDs are advertised that list members of the list in ARG. (T= here is otherwise a great deal of freedom in assignment since the values ar= e only consumed by the node that advertises them.) [PC] This text is update= d as part of Alvaro=E2=80=99s comment. Can you please check the current tex= t in rev21? > >=20 > > I think the new text is doing the right thing -- the structure of the v= alue is entirely local to the SR Endpoint advertising it. I will have an e= ditorial comment in my updated ballot position about the "signaling of the = argument to other nodes..." clause, though. > >=20 > > > Section 4.13 > > > > > > It's probably worth calling out the MTU considerations of pushing=20 > > > the new IPv6 header+SRH and tunneling the packets. (I know we=20 > > > reference > > > 2473 already, but the MTU is pretty important.) [PC] MTU=20 > > > considerations are covered in RFC8754. > > > > > > S17. The Payload Length, Traffic Class and Next-Header fields are > > > set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. > > > > > > How is the Hop Limit set for the outer header? > > > (I assume =C2=A76.3 of RFC 2473, but given that you provide a referen= ce=20 > > > for all the other fields, it seems like an omission to not mention Ho= p Limit as well.) [PC] Sure, added. > >=20 > > [Thanks. I'll note some similar reference nits regarding =C2=A75.1 in m= y=20 > > updated comments] > >=20 > > > Section 4.14 > > > > > > The SRH MAY be omitted when the SRv6 Policy only contains one segm= ent > > > and there is no need to use any flag, tag or TLV. > > > > > > If this is the case does it matter if I use End.B6.Encaps or End.B6.E= ncaps.Red? > > > [PC] If you only have a single segment, then it does not matter. Howe= ver when you have more than one segment the change is significant. > > > > > > Section 4.16 > > > > > > I don't think I understand what it would mean for a specific SID to s= upport the multiple flavors "in combinations". > > > [PC] Convoluted sentence indeed. > > > > > > For each of these > > > behaviors these flavors MAY be supported for a SID either > > > individually or in combinations. > > > > > > > > > The End, End.X or End.T behaviors could support these flavors either = individually or in combination. > > > > >=20 > > Much better; thanks! It may be less relevant now that we are=20 > > assigning behavior codepoints for each flavor combination, but IMO the= =20 > > USD flavor fits more naturally into being "part of the main behavior". = =20 > > E.g., we have > > End.DT46 already, and I'm not sure how that (behavior codepoint 20) dif= fers from End.T with USD (behavior codepoint 36). I think it's generally a= bad idea to have multiple ways of expressing the same behavior. > >=20 > > [PC2] End.T with USD and End.DT46 are the same only when they are the l= ast SID of the SID list. Note that when they are used as intermediate segme= nt they do different things. If End.DT46 is used as an intermediate segment= in the sid list it will result in an ICMP Parameter Problem. If End.T is u= sed as an intermediate segment the packet is forwarded. >=20 > I seem to still be having a hard time getting the hang of this stuff; tha= nk you again for your patience with explanations! >=20 > So, a node would have to advertise both End.DT46 and End.T and have the r= oute calculation use the respective one in order to get the same effect as = End.T + USD. That is different enough that I will not complain too loudly = about it, though in a greenfield ecosystem one could conceivably go with ei= ther approach... >=20 > > > Section 4.16.1.2 > > > > > > A penultimate SR Segment Endpoint Node is one that, as part of the > > > SID processing, copies the last SID from the SRH into the IPv6 > > > Destination Address and decrements Segments Left value from one to > > > zero. > > > > > > I think technically it copies the first SID from the SRH (SRH.Segment= List[0]), which is the last SID from the SR Policy. > > > [PC] RFC8754 uses the term =E2=80=9Clast SID=E2=80=9D to refer to SRH= =2ESegmentList[0]. Please refer RFC8754 Sec 6.1 for details. > > > Also, nit: "the" for "the Segments Left value". > > > [PC] Ack. Corrected. > > > > > > S14.2. Update the Next Header field in the preceding header to = the > > > Next Header value of the SRH > > > > > > nit: personally, I would write "from the SRH", since "next header val= ue of the SRH" is very close to "next header value of SRH", i.e., 43. > > > [PC] Reads better indeed. Corrected. > > > > > > As a reminder, [RFC8754] defines in section 5 the SR Deployment Mo= del > > > within the SR Domain [RFC8402]. Within this framework, the > > > Authentication Header (AH) is not used to secure the SRH as descri= bed > > > in Section 7.5 of [RFC8754]. > > > > > > I strongly recommend adding another sentence clarifying why this is r= elevant to discussion of removing an extension header from the packet. > > > [PC] I suggest that is not relevant to the discussion of PSP since AH= is not defined for the SRH. > >=20 > > We should explain why we are saying anything at all about AH. Right no= w it sounds like an irrelevant piece of information that should have been e= dited out of the document, but it actually is quite important in attempting= to justify the design decision of allowing PSP! > >=20 > > [PC2] Actually, it was a requested clarification to be added to convey = that AH not being specified and used for securing SRH results in there not = being any issue with AH when doing PSP. >=20 > Yes, and I support that request. This text seems to only do half of that= , though -- it says that AH is not used for securing SRH, but skips the par= t about there not being any issue with AH when doing PSP. >=20 > [PC3] We are not considering the use of AH to protect the SR Domain as de= fined in Section 7.5 of RFC8754. Future documents may define the use of AH = in the SR Domain. Yes, I agree. I still think that, from a rhetorical perspective, this statement lacks a purpose as written. (IMO) we should either say why a reminder is needed or not say anything. > > > Section 5 > > > > > > This list can be expanded in case any new functionality requires i= t. > > > > > > How? By an RFC that Updates: this one? > > > [PC] New functionality would have to be introduced via a new document= but it does not have to update this one since it is not modifying what is = in this document but adding something new. > > > We have updated the text as s/This list can be expanded in case any n= ew functionality requires it/This list is not exhaustive and future documen= ts may define additional behaviors. > >=20 > > Thanks. > >=20 > > > Section 5.x > > > > > > I agree with the directorate reviewer that the protocol behavior shou= ld be written out explicitly, without reference to the handling of example = packet(s). > > > [PC] There is already pseudocode and descriptions in these sections t= hat describes the behavior. Examples are to help understanding. Can you cla= rify what more is required? > >=20 > > The pseudocode hardcodes that the segment list is (S3, S2, S1; SL=3D2),= which is just an example of what the SRH could be. It's not truly generic= pseudocode. > >=20 > > [PC2] Agreed. I=E2=80=99ve removed the =E2=80=9C(S3, S2, S1; SL=3D2) fr= om the pseudocode. Its specific to the example, and it does not bring any v= alue (the encoding of the SRH is already defined in RFC8754). >=20 > Ah, that looks to be a good resolution; thank you! > We might want to do a minor follow-up and say "outer IPv6 DA as the first= SID in the segment list" (since 'S1' is no longer defined as part of the p= seudocode). >=20 > [PC3] Changed. > =20 > > Also, I think it would be great if 5.2, 5.3, and 5.4 could do the sort = of thing we did for the endpoitn behaviors where it replaces the definition= of one or more of the numbered pseudocode steps. (I don't think we can, r= ight now, since the numbered pseudocode doesn't cover all the relevant part= s that are changing, and I didn't think about how hard it would be to chang= e the pseudocode to make that the case. > >=20 > > > Section 5.1 > > > > > > S03. Set outer payload length, traffic class and flow label > > > > > > What about the outer Hop Limit? > > > [PC] Added. > > > > > > S03: As described in [RFC6437] (IPv6 Flow Label Specification) > > > > > > Why is this all the way at the bottom of the section instead of inclu= ded with the corresponding content? > > > [PC] Ack. Brought up. > > > > > > Section 5.3 > > > > > > The encapsulating node MUST remove the preamble or frame check > > > sequence (FCS) from the Ethernet frame upon encapsulation and the > > > decapsulating node MUST regenerate the preamble or FCS before > > > forwarding Ethernet frame. > > > > > > "or"? I get to choose one or the other? It's okay to only put back = a preamble but no FCS (or vice versa)? > > > [PC] Good catch. s/or/and; also preamble removed only if present > > > > > > Section 6 > > > > > > traffic that matched that SID and was processed correctly. The > > > retrieval of these counters via MIB, NETCONF/YANG or any other mea= ns > > > is outside the scope of this document. > > > > > > (editorial) a MIB is an abstract data structure (likewise a YANG modu= le); information might be retrieved *from* it but not *via* it. For *via*,= that would be SNMP, NETCONF, and/or RESTCONF. > > > [PC] Fixed. > > > > > > Section 8.1 > > > > > > Does it make sense to reference RFCs 8491, 8476, 8841, etc. for adver= tising MSD via IGP? > > > [PC] I would leave that up to the srv6 control plane drafts; but no s= trong preference. > > > > > > In particular, the SR source (e.g., H.Encaps), intermediate endpoi= nt > > > (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6) > > > behaviors. [...] > > > > > > This is not a complete sentence, and I really have no idea what verb = was intended. > > > [PC] Indeed, fixed in rev21. > > > > > > Section 8.2, 8.3 > > > > > > Can we get references for the BGP variants here and their usage for s= ignaling SRv6 capabilities and (SID,behavior codepoint) pairs? > > > [PC] The references to the BGP features have already been provided in= the respective sections where these behaviors are specified. There are WG = drafts in progress for SRv6 extensions to routing protocols (not just BGP) = that normatively reference this document. There used to be informative refe= rences the other way around from this document which were removed during WG= LC based on feedback. We can add them back if that makes sense for the IESG. > >=20 > > I think that those informative references would be helpful, but I also = don't know how strong the WG consensus was to remove them (or what reasonin= g was offered for doing so). > >=20 > > [PC2] I=E2=80=99ll leave it up to Martin (responsible AD). > > On a separate note, on 8.3 I=E2=80=99ve also added the note on the Opaq= ue as discussed. > > > > In some scenarios, an egress PE advertising a VPN route might wish to a= bstract the specific behavior bound to the SID from the ingress PE and othe= r routers in the network. In such case, the SID may be advertised using the= Opaque SRv6 Endpoint Behavior codepoint defined in [Section 10.2.1]. The d= etails of such control plane signaling mechanisms are out of the scope of t= his document. > > >=20 > Thanks again for this clarification; this behavior feels perfectly natura= l once explained, but really confused me on first reading. >=20 > > > Section 9 > > > > > > I would really like to have a stronger reference to Section 5 of RFC > > > 8754 where the conceptual model of a SR Domain as a single system, wh= ere all packets in the domain are encapsulated using IPv6 headers [with SID= s as SA/DA]. The part in brackets is not spelled out very clearly and coul= d well be expounded upon in this document. I can write up some (very ad ho= c) ideas for what I had in mind, which you are welcome to adopt but expecte= d to wordsmith/edit appropriately: > > > > > > % Section 5 of [RFC8754] describes the SR deployment model and the % = baseline requirements for securing the SR Domain. In many ways the SR % Do= main is analogous to an MPLS domain -- it's a tightly controlled % system w= here packet processing is controlled by a list (or stack) of % opaque ident= ifiers that, by and large, only have defined semantics in % the context of = the node that receives and processes the packet when % that identifier is "= topmost" or "current". Experience in securing and % operating MPLS domains= should be readily transferrable to SRv6 % domains, in ensuring that all tr= affic within the network is tightly % controlled, with all external inputs = being properly encapsulated (for % SRv6, by an IPv6 header usually with SRH= ; for MPLS, by the label % stack). The dedicated format for the MPLS label= stack and label % identifiers makes a clear mechanical separation between = "internal" and % "external" identifiers. In contrast, SRv6 uses SIDs for th= e internal % identifiers, which have format and operation of IPv6 addresses= =2E While % this lets SRv6 benefit from IP longest-prefix routing and thus= the % structure of SID values, it also means that there is not a crisp % m= echanical separation between "internal" and "external" identifiers. > > > % As such, care and rigor in annotating which IPv6 addresses/headers = are % internal vs external is required in order to maintain the integrity %= and security of the SRv6 domain. > > > > > > [PC] Thanks for your suggestions. Indeed we should update the draft w= ith something along those lines. > > > The comparison or equivalence to MPLS is likely going to be confusing= and hence we avoid going down that path. We were thinking on something lik= e the following. > > > Please let me know of what you think. (I have not pushed this into th= e draft yet). > > > > > > > >=20 > > [re-wrapped for ease of inline commenting] > >=20 > > That said, I am just offering editorial suggestions; I really like what= you came up with -- thank you! > >=20 > > > The security considerations for Segment Routing are discussed in > > > [RFC8402]. Section 5 of [RFC8754] describes the SR Deployment Model= and > > > the requirements for securing the SR Domain. The security > > > considerations of [RFC8754] also cover aspects such as attack=20 > > > vectors > >=20 > > nit: I'd consider s/aspects/topics/ but it's a bit of a judgment call= =20 > > [PC2] Changed. > >=20 > > > and their mitigation mechanisms that also apply to the behaviors > > > introduced in this document. Together, they describe the required > > > security mechanisms that allow establishment of an SR domain of=20 > > > trust > >=20 > > I would end the sentence here, after "SR domain of trust". Then we cou= ld continue on as "Having such a well-defined trust boundary is necessary i= n order to operate [...]" > > [PC2] Changed. Thanks. > >=20 > > > to operate SRv6-based services for internal traffic while preventing > > > any external traffic from accessing or exploiting the SRv6-based > > > services. Care and rigor in IPv6 address allocation for use for SR= v6 > > > SID allocations and network infrastructure addresses to be separate > > > from IPv6 addresses allocated for end-users/systems (as illustrated= in > > > Section 5.1 of [RFC8754]) help differentiate internal vs external > > > address space that is required to maintain the integrity and securi= ty > > > of the SRv6 Domain. Additionally, [RFC8754] defines an HMAC TLV > >=20 > > This sentence got a bit convoluted and maybe a bit long. I propose (on= ly helping with the "convoluted" but not the "long" part): > >=20 > > % Care and rigor in IPv6 address allocation for use for SRv6 SID % allo= cations and network infrastructure addresses, as distinct from IPv6 % addre= sses allocated for end-users/systems (as illustrated in Section 5.1 % of [R= FC8754]), can provide the clear distinction between internal and % external= address space that is required to maintain the integrity and % security of= the SRv6 Domain. > > [PC2] Changed. Thanks. > >=20 > > > permitting SR Endpoint Nodes in the SR domain to verify that the SRH > > > applied to a packet was selected by an authorized party and to ensu= re > > > that the segment list is not modified after generation, regardless = of > > > the number of segments in the segment list. When enabled by local > > > configuration, HMAC processing occurs at the beginning of SRH > > > processing as defined in [RFC8754] Section 2.1.2.1. > > > > > > This document introduces SRv6 Endpoint and SR Policy Headend behavi= ors > > > for implementation on SRv6 capable nodes in the network. As such, t= his > > > document does not introduce any new security considerations. > > > > >=20 > > I'm less sure that we want to keep the "no new security considerations" > > text. I have a few notes staged in my updated ballot comments, but one= noteworthy thing that comes to mind is that PSP prevents the egress node f= rom validating the HMAC TLV. > >=20 > > [PC2] If you would like to use the HMAC TLV then why would the source c= hoose to use a PSP-flavored SID? The SR Policy computation is aware of this= and takes it into account upon doing path computation. Note that in rev24 = we added this text as well: >=20 > It would be a pretty bizzare choice, but (even with the following > paragraph) we don't seem to completely prohibit it. >=20 > > > > The headend policy definition should be consistent with the specific > > behavior used and any local configuration (as specified in > > Section 4.1.1). > > >=20 > I think I had failed to internalize what this was saying, so thank you fo= r pointing it out specifically. It helps a lot, but I still think that "no= new security considerations" is contingent on the headend policy heeding t= hat advice. We typically do not make such assumptions when writing securit= y considerations sections, and describe the risks that can occur when a dep= loyment diverges from the recommended configuration. >=20 > [PC3] The very essence of SR is about source routing of packets using a l= ist of segments. The very basis of the source routing model is that the SR = Source Node=E2=80=99s selection of these segments is based on some sound lo= gic and awareness of their characteristics. This is data plane independent.= So, I fail to understand what is it that you seek to add to the text and h= ow it helps. I don=E2=80=99t think this document has anything further to ad= d in that matter besides what is discussed in RFC8402. In short, this is an additional consideration that the source node has to take into account when deciding on the SR policy. We are introducing the ability to do PSP/etc., and the potential presence of them is a factor in when and how HMAC TLV can be used, etc. > > > There might also be room for discussion (in the main body of the > > > document) of how the various decapsulation procedures occur precisely= when the packet is leaving the SR Domain. > > > [PC] The sections 4.4 through 4.12 do describe these procedures for t= he decapsulation behaviors specified in this document. > >=20 > > Yes, the decapsulation procedures themselves are covered well. I am su= ggesting to mention that the act of decapsulation (generally) signals that = the packet is leaving the SR domain, where we describe the procedures thems= elves. > >=20 > > [PC2] Decapsulation may primarily occur at the edge of an SR Domain, an= d RFC8754 describes this scenario in section 5. >=20 > I agree. I'm not sure whether you are rejecting my suggestion (which, to= be clear, is a perfectly fine thing to do) or it just wasn't coming across= as I intended. For clarity, I was proposing to add something like "a deca= psulating behavior such as End.DX6 is typically (but not exclusively) used = at the egress of the SR Domain in accordance with Section 5 of [RFC8754]" a= s a note at the end of (e.g.) =C2=A74.4, and similarly for the other decaps= ulating behaviors. >=20 > [PC3] The current text explicitly states that it is used at an egress PE = for an L3VPN use-case.=20 > e.g. for End.DX4: > One of the applications of the End.DX4 behavior is the L3VPNv4 use- > case where a FIB lookup in a specific tenant table at the egress > Provider Edge (PE) is not required. This is equivalent to the per-CE > VPN label in MPLS [RFC4364]. > =20 > > > Having the ARG structure specified as part of the behavior codepoint = registration means that a node that can apply that SID can also spoof the A= RG to force a different (e.g.) outgoing interface list. > > > Specifically, it gives the attacker a degree of freedom greater than = just the SID behaviors that the node advertises. The HMAC TLV would mitiga= te this to the extent that it limits what SIDs the node in question is allo= wed to apply and what changes can be made on-path. > > > [PC] The processing of ARG is specific to a behavior defined and not = generic. Please refer to the updated text in Sec 4.12 for End.DT2M (which i= s currently the only specified behavior that accepts ARGs). Since the ARG b= its are part of the SID there are no other considerations for them apart fr= om the ones that apply to the SID as a whole. > >=20 > > Even though the ARG bits are specific to a behavior (a function,=20 > > really, IIUC), if there is a need to have ARG bits then there is going= =20 > > to be more than one valid value for the ARG bits. Now that we have=20 > > removed a description for the structure of the ARG bits, it becomes a= =20 > > little harder to spoof them, but only a little bit. Given the=20 > > L+F+A<128 constraint, A may very well be something small, on the order= =20 > > of 10; an exhaustive search over the 2**10 possible values for ARG to= =20 > > see which are valid and what they do would be fairly easy to do. An=20 > > attacker in a position to do that exhaustive search (admittedly, one=20 > > would be violating the "trusted SR domain" assumption to get there)=20 > > could be able to observe the different behaviors provided by the=20 > > different ARG values and select what behavior they wanted by spoofing= =20 > > ARG. If A was larger, like 64 or 128, this search and guessing would= =20 > > be much less practical, but we don't really have that many bits lying= =20 > > around. So, I think this is a new security consideration introduced=20 > > by the presence of the ARG bits in the SID, and we should mention it. = =20 > > (We would also mention that the risk is largely mitigated by the=20 > > assumption that the SR domain is trusted, of course.) > >=20 > > [PC2] This service theft consideration exists for every SID, regardless= of the use of arguments. It is discussed in RFC8754 section 7.2 and refer= enced from section 9 of this draft. >=20 > Well, yes and no. I am imagining some risk about service theft for an SI= D that is not explicitly advertised anywhere, if the implementation does no= t specifically check for the exact SID values that are advertised. >=20 > Consider the case where a single node has SIDs that use multiple distinct= LOCs, call them LOCs A and B. If a SID (call it Q) is advertised with A a= nd behavior code X with ARG1, and a different SID (call it O) is advertised= with B and behavior code X with ARG2, then this implementation is likely t= o also process an SID with LOC A, the FUNCT value from Q, and ARG2, even th= ough such an SID is not actually advertised. So, the spoofing allows to cr= eate new behaviors in addition to just service theft of expected behaviors. >=20 > [PC3] Arguments do not create behaviors. So, the handling of unexpected a= rguments is entirely dependent on the behavior and its pseudocode. So in ef= fect it is not different if someone were to spoof the entire SID as we were= discussing earlier. Arguments do not create "behavior"s in the sense that we use "behavior" as a technical term for something that is tied to a function, yes. They do create different observable behaviors in the normal english usage of "behavior", though -- the specific actions that the SR node takes will depend on the argument. When SIDs have no internal structure, the ability to spoof (or not) an SID is a "one-shot" thing that is limited in scope to being able to spoof a SID value that was advertised. Now that there is internal structure within SIDs, in certain implementation models, it is possible to spoof even SID values that were not advertised, to cause the observable operational behavior of the SR node to include actions that were never advertised. IMO, this is a new risk/new consideration due to the functionality defined in this document, and should be documented as such. (If the implementation chooses to ignore the internal structure of the SID and retain a ~lookup table with the specific SIDs advertised, then there is no new risk that I can see.) Thanks again, Ben >=20 > > > services. Additionally, [RFC8754] defines an HMAC TLV permitting = SR > > > Endpoint Nodes in the SR domain to verify that the SRH applied to a > > > packet was selected by an authorized party and to ensure that the > > > segment list is not modified after generation, regardless of the > > > number of segments in the segment list. When enabled by local > > > > > > I suggest adding a sentence similar to "(This does, however, require = that the segment list, and thus, the SRH is present in the packet; the opti= onal ability to elide the SRH when there is only a single segment and no fl= ags, tags, or TLVs needed inherently excludes the protection of the HMAC TL= V.)" > > > [PC] All the SR Policy Headend (i.e. the SR Source Node) behaviors de= fined in Sec 5 state: > > > > The push of the SRH MAY be omitted when the SRv6 Policy only conta= ins one segment and there is no need to use any flag, tag or TLV. > > > So, it follows that if HMAC protection is required, then SRH has to b= e used even with a single segment. > >=20 > > Ah, I see your point, yes. Sorry for missing that. > > (But I think my earlier comment about PSP still applies.) > >=20 > > > Section 10.1 > > > > > > definition: The value 143 in the Next Header field of an IPv6 head= er > > > or any extension header indicates that the payload is an Ethernet > > > [IEEE.802.3_2018]. > > > > > > nit: is there a missing word here ("frame"?)? > > > [PC] Ack, fixed. > > > > > > Many thanks for your time. > >=20 > > Thank you for yours as well, and the updates already present and queued. > >=20 > > Sorry again for taking so long to get back to you. > >=20 > > -Ben From nobody Wed Dec 9 09:05:07 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 060773A0FD2; Wed, 9 Dec 2020 09:05:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-spring-srv6-network-programming@ietf.org, spring-chairs@ietf.org, spring@ietf.org, Bruno Decraene , Joel Halpern , jmh@joelhalpern.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160753350153.28997.1345859562639063746@ietfa.amsl.com> Date: Wed, 09 Dec 2020 09:05:02 -0800 Archived-At: Subject: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 17:05:03 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-spring-srv6-network-programming-26: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the updates through to the -26; they help a lot. However, I do think there is one final Discuss-level point that needs to be resolved: it's mostly a process point, to make sure that what we say in this document complies to the requirements that were laid out in RFC 8754 for the procedure we're trying to follow. Specifically, in the process of trying to finalize my review comments, I ended up doing a lot of background reading, in which I noticed that RFC 8754 says: New SIDs defined in the future MUST specify the mutability properties of the Flags, Tag, and Segment List and indicate how the Hashed Message Authentication Code (HMAC) TLV (Section 2.1.2) verification works. Note that, in effect, these fields are mutable. This is a bit confusing to me, in that the SIDs themselves appear as entries in the Segment List, and it's not quite clear when or how a per-SID behavior relating to fields in the containing SRH might come into play. However, given that we allocate a behavior codepoint for "the SID defined in RFC 8754", I am forced to conclude that the behaviors specified in this document meet the definition of "new SIDs" that are being defined "in the future" (from the reference point of RFC 8754), and therefore that they must specify the indicated properties. I'm told out of band that the intent is to do the same thing that RFC 8754 does for the SID it defines, and so this should be trivial to resolve just by adding a brief note that (e.g.) "the SIDs specified in this document have the same HMAC TLV handling and mutability properties of the Flags, Tag, and Segment List field as the SID specified in RFC 8754". However, I believe that such an explicit statement is required, and that we would introduce an internal inconsistency between this document and RFC 8754 if we say nothing on this topic. In particular, I think that we would not inherit that behavior as some kind of default behavior if we make no statement at all. I am sorry that I did not notice this earlier, but I feel that it is important to remain consistent with the requirements of RFC 8754 and thus that this is appropriate to raise as a Discuss-level point, even if I have previously reviewed the text in question. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [note: I originally prepared these comments when looking at the -24. I tried to remove comments about things fixed in the -25 or -26, but may have missed a couple; please ignore any such already-addressed comments. There are also a couple points that we have already been discussing in the other thread but I retain as a "placeholder"; hopefully we can keep the actual discussion about them in just one place.] As mentioned in the Discuss section, I did a lot of background reading while preparing this updated ballot position. Another thing I noticed while doing that reading is that the pseudocode in https://tools.ietf.org/html/rfc8754#section-4.3.1.1 explicitly mentions "perform TLV processing"; we might consider repeating that step in our pseudocode procedures, and otherwise making our procedures as analogous as possible to the RFC 8754 procedures, just from the perspective of keeping the writing style as consistent as possible across the related documents. However, that's entirely an editorial matter and thus left to the discretion of the authors/AD. Section 2 The following terms used within this document are defined in [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint Node, Reduced SRH, Segments Left and Last Entry. It's slightly unfortunate that 8754 didn't have a dedicated terminology section containing these, though it's too late to really do anything about it now. Section 3 The term "function" refers to the bit-string in the SRv6 SID. The term "behavior" identifies the behavior bound to the SID. The behaviors are defined in Section 4 of this document. (nit) using "the behaviors" to some extent implies that these are the only ones allowed or defined, which is not true. Perhaps "some behaviors" would be more accurate (or some other phrasing would also cover the expected evolution of the ecosystem)? Section 3.3 A packet could be steered to a non-routed SID 2001:db8:b:2:101:: by using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...> where the non-routed SID is preceded by a routed SID to the same node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of global and local segments, respectively [RFC8402]. If it's (also) possible to steer a packet to a non-routed SID without a preceding routed SID for the same node (e.g., via End.X), it seems like that might be worth listing an example of as well. Otherwise a reader might assume that the global segment is a necessary part of using the non-routed SID. Section 4 End.DT2U Endpoint with decaps and unicast MAC L2table lookup e.g. EVPN Bridging unicast use-case (nit) we seem to put a space in "L2 table" the other times it appears. The list is not exhaustive. In practice, any function can be attached to a local SID: e.g. a node N can bind a SID to a local VM or container which can apply any complex processing on the packet. (nit) the preceding list was a list of well-known behaviors, not a list of functions. IIUC, it is more appropriate to use "behavior" here than "function", since the "function" is just the opaque bitstring. Section 4.1.1, ... When processing the Upper-layer Header of a packet matching a FIB entry locally instantiated as an SRv6 End SID do the following: (editorial, I think) I find it interesting to compare the phrasing here to what was used in §4.1 (when processing an SRH), where the text is "receives a packet whose IPv6 DA is S and S is a local End SID". Why the distinction between "End SID" and 'SRv6 End SID"? IIUC the distinction between checking "IPv6 DA" and "matching a FIB entry locally instantiated" is important and the language should not be harmonized between occurrences. The "..." in the Section number listing indicates that this (or similar) phrasing appears throughout, whenever we talk about processing an upper-layer header. Section 4.2 Note that if N has an outgoing interface bundle I to a neighbor Q made of 10 member links, N may allocate up to 11 End.X local SIDs: one for the bundle itself and then up to one for each Layer-2 member link. The flows steered using the End.X SID corresponding to the (nit) I think that while "up to 11" might be the situation that makes the most sense (in that having many distinct subgroups with 1 < n < 10 member links doesn't make sense), it is not strictly speaking a physical or protocol requirement. Perhaps "might allocate 11" is better than "may allocate up to 11" for that reason. Section 4.4, ... When N receives a packet destined to S and S is a local End.DX6 SID, N does the following processing: (nit) we have a mismatch of "N does the following processing" (like appears here) and "N does" or similar; it is probably worth normalizing on one phrasing. When processing the Upper-layer header of a packet matching a FIB entry locally instantiated as an SRv6 End.DX6 SID, the following is done: Similarly here, we use "the following is done" but the "N does the following" phrasing used in some other sections is probably preferred, as it avoids the passive voice. Section 4.12 We might give some mnemonic explanation for how the name "FE2" was chosen to identify the argument value. table T flooding. The allocation of the argument values is local to the SR Endpoint Node instantiating this behavior and the signaling of the argument to other nodes for the EVPN functionality via control plane. nit(?): s/via control plane/occurs via the control plane/? Section 4.13 S05. If (IPv6 Hop Limit <= 1) { S06. Send an ICMP Time Exceeded message to the Source Address, Code 0 (Hop limit exceeded in transit), (nit) the indentation seems off by one space in the first line of S06 (it doesn't match the other two places where this chunk occurs). S14. The SRH MAY be omitted when the SRv6 Policy B only contains one SID and there is no need to use any flag, tag or TLV. S17. The Payload Length, Traffic Class, Hop Limit and Next-Header fields are set as per [RFC2473]. The Flow Label is computed as per [RFC6437]. (These look to be S15 and S18, respectively, now.) Section 4.14 The SRH MAY be omitted when the SRv6 Policy only contains one segment and there is no need to use any flag, tag or TLV. (nit) it's probably worth harmonizing the phrasing between here and the note on S15 in §4.13 (specifically, "only contains one SID" vs "only contains one segment"). Section 4.15 (nit) there's a blank line at the end of S06 that doesn't occur in the other two locations where this pseudocode appears. S16. Submit the packet to the MPLS engine for transmission to the topmost label. (nit) I suggest rewording slightly so as to not imply that the node to transmit to is determined by the topmost label -- IIUC it's determined by the MPLS policy, since the interpretation of the label is in general local to the receiving node. Section 4.16.1.2 As a reminder, [RFC8754] defines in section 5 the SR Deployment Model within the SR Domain [RFC8402]. Within this framework, the Authentication Header (AH) is not used to secure the SRH as described in Section 7.5 of [RFC8754]. (repeating from the previous thread as a placeholder) I think we need another sentence or clause here to clarify why this statement is relevant, e.g., "Thus, while the AH can detect changes to the IPv6 header chain, it will not be used in combination with the SRH, so use of PSP will not cause delivery failure due to AH validation checks." Section 5 (editorial) This is the first place in the document that we talk about the "headend" or its policy at all, so a bit of background on why it's useful to tabulate potential headend policy/behaviors might be helpful. Section 5.x Tying the other policies more precisely to the pseudocode for H.Encaps (e.g., replacing S01) seems like it would be useful, to avoid the appearance of specifying behavior by appealing to examples. Section 5.1 Note: S03: As described in [RFC6437] (IPv6 Flow Label Specification). We need to pull in RFC 2473 for payload length, traffic class, and next-header, IIUC. (hop-limit is covered a few paragraphs down.) Also to say how the next-header value is selected. Section 8.1 The presence of SIDs in the IGP does not imply any routing semantics to the addresses represented by these SIDs. The routing reachability to an IPv6 address is solely governed by the non-SID-related IGP prefix reachability information that includes locators. Routing is neither governed nor influenced in any way by a SID advertisement in the IGP. It seems like this is trying to say "the IGP must not advertise prefixes contained within the LOC part of an SID", but in a very roundabout way. Section 8.3 The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V, End.DT2U and End.DT2M SIDs can be signaled in BGP. Since we said earlier that the signaling of SIDs needs to include the behavior codepoint for each function bitstring, it seems like we should provide a reference to how BGP will encode the behavior codepoint. Section 9 There seem to be some security considerations relating to the use of PSP, in that the egress node loses visibility into which policy was used for a given packet, so all packets from all policies that egress via that SID are in the same anonymity (and policy!) set. In particular, even if an HMAC TLV was present in the SRH, it is not available and cannot be validated. I recognize that the headend (or whatever entity is assigning SR policy) should know when such validation would be intended to occur and not assign a policy incompatible with it, but there are still new considerations in the sense that the headend needs to be aware of these considerations. (repeating as a placeholder from the previous thread) I think we should also say that in the absence of the HMAC TLV, valid FUNC and ARG values on any given node may be guessable and spoofable, along with the standard disclaimer that risks are minimal since all nodes in the SR domain are assumed to be trusted. This is distinct from the already-extant ability to spoof a SID in that the underlying structure in the SID may allow the attacker to induce behavior that was never intended to be a SID, for example if the implementation logically separates FUNC and ARG processing and the attacker makes a combination that was never advertised. Also, IIUC, the "Segments Left == 0" handling for, e.g., End.X is important to prevent traffic loops -- if a node fails to perform that check and blindly sends the packet to the interconnect it will get returned to that node/SID and loop until the IP hop limit is exhausted. From nobody Wed Dec 9 11:02:05 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BC73A1706; Wed, 9 Dec 2020 11:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=hG0OJwv4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TWaVoeEz 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 f5q92p_SplDJ; Wed, 9 Dec 2020 11:02:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FC53A1704; Wed, 9 Dec 2020 11:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20076; q=dns/txt; s=iport; t=1607540520; x=1608750120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QSnb2SSrXS8iHcJUYo/Hc9ZqnuglZ///d8WxbfMNGIY=; b=hG0OJwv4R5hzR7TRsfh6gwTs+/+ZUpUy7M1nSY7hartbO8C07xFDuEvH Hz/5fRWwV1EQJcieExxQ3ufIPRT/aZ91E3KR9Uwaj11Db32nt0AAZ2+Az Exs71qMY6LQYY6dJWzHJbcfjXqXB7MIBsRcuC9owo/0qQcVo+vNPbBvPL E=; IronPort-PHdr: =?us-ascii?q?9a23=3AXpqlchU8cVuWM+g19THzgcQvcffV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyDufdFl6zbv72zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutYlzO5HC+8G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAACqHtFf/4oNJK1YCg4LAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBEgEBAQEBAQEBAQEBAUCBPQIBAQEBAQsBgVEjLgd1Wy8?= =?us-ascii?q?uCoQ0g0gDjWEDjwqJf4EuFIERA1QLAQEBDQEBJQgCBAEBhEoCF4FoAiU2Bw4?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBgRxhWEMhXIBAQEBAxIREQwBATcBCwQCAQgRBAEBAwI?= =?us-ascii?q?fBwICAjAVCAgCBAENBQgagwWCVQMuAQMLohoCgTyIaXaBMoMEAQEFgUdBgyg?= =?us-ascii?q?YghADBoEOKgGCc4N2gkSCd4EeG4FBP4ERQ4JVPoJdAQEBAQEBgSYBAQYFBgE?= =?us-ascii?q?jgxUzgiyBWSo+CARaAQMdBQ0CChYCBCoXCiMMAQUSKQgCDQQLFAUCBAsBEwU?= =?us-ascii?q?FARgCH48PJIJsPodQnCaBDwqCdIkehh+FeHaFOYMkOolrlG6TfIsMkSASFgQ?= =?us-ascii?q?ODYQwAgQCBAUCDgEBBYFdCSpnWBEHcBU7gmlQFwINjiEMFxSDOoUUhQRAdAI?= =?us-ascii?q?BATMCBgEJAQEDCXyHGgEBBSEHgQYBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.78,405,1599523200"; d="scan'208";a="812537654" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 19:01:58 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B9J1w2t021604 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2020 19:01:58 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 13:01:57 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 13:01:57 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 9 Dec 2020 13:01:57 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GJnJDXzp6UxpB4SzjanKoP18oIPod7sENm175IAnYn97xAmEeu0/2i0Ce5JZ6maGUcvWGGvrTuDMuon3HhD0ycHD9rgLKG8k881pu20RliJJFHCiFUra7UDzyoLVE9u3TcL32mmzGGicyiqCK+PsSNoNdFrJkm5FlcUsipxAmT6CYloWNd9aqYGA8punejxnzrOCwV0Uafawu4rByD3q9nZv2bMBQdsYgjVFOzjjXnNkebCOHsDVfh6eO2ou1fSta9qHZUrM3CEsmoavATileuei1wquqs1z5avq0PWIXrL1yUh7dNBDPA0QhiUjysOysdWD2hoawL3kl3E7T+qTrQ== 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=QSnb2SSrXS8iHcJUYo/Hc9ZqnuglZ///d8WxbfMNGIY=; b=Tm7pNN7mUk9ZhLYZP6G6KmI6uCOZZrrP4j8T9j8+go9Tdr0HW9VZFwAEn3lLlZaaBbN+kHd5ottpILu3zSUc34Lj5ErIjwO5czmvKdhpcfRKMSv8F3otBKydqXDRQrCy2PGd+eo9fTAVOg3sn2i+SPe0IUC8NB3CCqxgrcVSsXKn8++HZvcYYQRhFrfCtJOM2tpTmaKr4dfQtdthcBgFt3VObcgxNCsRcTpIKR2btOkzcwBm0mbXbchhFGDNGfoQwpdXcR9dBlb/Jgezn8iTVy4/fSkhJruacWMT5E2NzKFXEDmtvSWCu52H7gRcDa9eExz8B1QjkDunU/PgwwY/lw== 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=QSnb2SSrXS8iHcJUYo/Hc9ZqnuglZ///d8WxbfMNGIY=; b=TWaVoeEz/bopxMLrLq2lF0SrGTDOyw8AZFVl8U5iu+ez068VeVYjR3lm7ePSoksDUxLvx1srzpDgystfF3lw1OPFdvmSA5PqAcuKaD7/kLpgOAorvDhOljLljZkQE10wFSRDLMQ3vY0xTQ32b85Doxsbe6nkc0vf3yybTxUBnxE= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SN6PR11MB2798.namprd11.prod.outlook.com (2603:10b6:805:58::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Wed, 9 Dec 2020 19:01:55 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d%4]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 19:01:55 +0000 From: "Pablo Camarillo (pcamaril)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) Thread-Index: AQHWzk11hJlsON8AwUKTQpqAtVRetqnvHdDQ Date: Wed, 9 Dec 2020 19:01:55 +0000 Message-ID: References: <160753350153.28997.1345859562639063746@ietfa.amsl.com> In-Reply-To: <160753350153.28997.1345859562639063746@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [37.10.144.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1113561e-019d-4acb-840a-08d89c74e5d9 x-ms-traffictypediagnostic: SN6PR11MB2798: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nZSHDeYITEUVM4zPpsz9T5DeRq5eoiTxJfKOd0gxXb6k3aFgUzWG49L+27h3y5Yhy4SWURP4LpE7iXQjraWMS124csCEUThkeRUI0563mVFy+vB4JChoJ1uA3kG87evjCHuBijv4N1VrhCSPYFbS8n75VOCL6OQS4W7J/kNuk39WVfPp44P5gViGkgnBHYXZspY/Y2Ld1KMj3mibEMOeN3Bh4YaKx/nUhspjd/irWbWRP62jBQeEjVE41kz55Y9fGU/XIl0r+lwvwgoGM+1MSxo+RFb0oBElmdNWpVV0OlGk9YMb5p4pjTjlPNr/hPCZDbeQKAS4AUSZevEf+SdRhjybN8SoNzG8lSltICgLVG45ZbDE00TLYxgEmvw7muA3ultu5AVokBeFD598MSh1LQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(366004)(396003)(376002)(26005)(110136005)(64756008)(66476007)(54906003)(316002)(186003)(966005)(9686003)(76116006)(71200400001)(4326008)(478600001)(86362001)(8676002)(7696005)(55016002)(2906002)(8936002)(66556008)(83380400001)(66446008)(66946007)(66574015)(5660300002)(33656002)(30864003)(52536014)(6506007)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NDNjbE5YMlo5U2VIYVJQQXNHa3c5Wmp1VnZ5d2RKZnY3bDlKVVBuUER4NkZo?= =?utf-8?B?VFBDaURYSjdiQ284YTF1ZDJrZTV1M0h6YzRHRzZHS1djTG5tVUozWlc4dkIv?= =?utf-8?B?THJWZGw1MVNJbkZuRzFKbzVlcElneG83ZmhIK3Zac2dxOHJmM1VGbmhUdklM?= =?utf-8?B?ai9PZFFpRCtvMVVXcFBWcUVZWXVZS2duR2lvWVdMU3FnZ1FxR2dXdE9qSzhQ?= =?utf-8?B?TnAxcFkwbk10K1BqSlI5ZFNYQUVPR1JITGNCNE5xMUhEMjl5bERwaVZIYmlx?= =?utf-8?B?c3NWWC9KSHpjMHpZZ25ObWs3cDVXQzNQbE5yUUQzZXJ0RGpnYmhLc2QwODhL?= =?utf-8?B?N2MyMnExbWdLaWsrVGZ0eVEvWm1ONjZjWDB1OVA4OTIrNzlqWVgvMG1PWmFR?= =?utf-8?B?WG1iY1puRVl0ajI3UzlvcHVpNGRHVno0My9ETEJxTDlXbzRxVmd2TVZLMUFQ?= =?utf-8?B?d2pBRUtMQ1pvR2pxQ0VOWmY0VGdHY3plYTBXTjMxdS9lYzRlQkR3Q0Y0d0Ir?= =?utf-8?B?ZndTWmpQa2dFTFVydm5QQkVjcFdXYU8wZU9kZFNjUGovYXc4TWVJY1doK2k2?= =?utf-8?B?VGFvZWRVRzhNdWhDSkduZzNPRkd3WDA5Q1U2YXNkK2VKbTFwaXRpVzVhZzV6?= =?utf-8?B?N2Y5K29ZNGNUMmVyV3pkejVMeElSeFExdUtnRlh2bGNza0FxNEgwT1U0eFFH?= =?utf-8?B?cGgrd2cyYkMxalpabEJjckRmaCt4MWNQSGRsMjdyc2Q3OEJWR1IxRGd2L0tG?= =?utf-8?B?d2hjVFZkTnlydGFOUjFMekRBblg1ZVJITFhPanRjaFV1YnRMeDJxcTExWVM1?= =?utf-8?B?bUx2Yjc2UlFxcGNNSFdyUXhPdWZlS0xQVFh5Z2I0M1BMbGp3VFBzeW9LNVgv?= =?utf-8?B?N2cwcjRWY0Q4RytDQkV2TWhNbHdGbGlFbXNtOHp4TmkvaGpBSXNSSVZKdEJj?= =?utf-8?B?R0NtOVQzQXhUVUU5cTdLa2lMOVN6TkVtSGJPZVphMzI2bVVTWEV1RmlpM3Bl?= =?utf-8?B?OXFscldEeTBqbDd6YnRkVFZjYjJDa2d6RHgxbW9tSE9JMkw1aTY2dXRLS1J6?= =?utf-8?B?STljZWZDM0JFQk50YVJxdFZocGF1K3d5NjAvR1NpUVV2N25rTkFwT3FlSktU?= =?utf-8?B?aG5hSWNxZVR6VHpIME00c0lPVExiaWVyTmlyTzV4cGdhUm00c1Y2azcrZy9u?= =?utf-8?B?OFZhbmtHU1QzNnd5WjFhVnFLK0hMc28rdUxYT04zWDlvelhrdGUxNGh1bW9W?= =?utf-8?B?b0YwZm8yT2ZYQWJoSVFHeFlUTlhkaVViZG10Y0JUUWVhS3RuZVNUZkxGR21L?= =?utf-8?Q?4iSjkmNlNsxbo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1113561e-019d-4acb-840a-08d89c74e5d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 19:01:55.8246 (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: hIAO2l7r1EomAsQBU/0D0shla6vRrGnifvrv3Jp078o+W7V8+BJrwg+l+LoIpFj42sqZ4mqe5SU/J2NgiqD2LQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2798 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 19:02:03 -0000 SGkgQmVuLA0KDQpPSywgSSB3aWxsIGFkZCBzb21lIHRleHQgaW4gdGhlIHN1Z2dlc3RlZCBsaW5l Lg0KDQpNYW55IHRoYW5rcywNClBhYmxvLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiAN ClNlbnQ6IG1pw6lyY29sZXMsIDkgZGUgZGljaWVtYnJlIGRlIDIwMjAgMTg6MDUNClRvOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmst cHJvZ3JhbW1pbmdAaWV0Zi5vcmc7IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRm Lm9yZzsgQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+OyBKb2VsIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBqbWhAam9lbGhhbHBlcm4uY29tDQpTdWJqZWN0 OiBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3 b3JrLXByb2dyYW1taW5nLTI2OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpCZW5qYW1p biBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRy YWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy0yNjogRGlzY3Vzcw0KDQpX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmst cHJvZ3JhbW1pbmcvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGVzIHRocm91Z2ggdG8gdGhlIC0yNjsgdGhleSBoZWxw IGEgbG90Lg0KSG93ZXZlciwgSSBkbyB0aGluayB0aGVyZSBpcyBvbmUgZmluYWwgRGlzY3Vzcy1s ZXZlbCBwb2ludCB0aGF0IG5lZWRzIHRvIGJlIHJlc29sdmVkOiBpdCdzIG1vc3RseSBhIHByb2Nl c3MgcG9pbnQsIHRvIG1ha2Ugc3VyZSB0aGF0IHdoYXQgd2Ugc2F5IGluIHRoaXMgZG9jdW1lbnQg Y29tcGxpZXMgdG8gdGhlIHJlcXVpcmVtZW50cyB0aGF0IHdlcmUgbGFpZCBvdXQgaW4gUkZDDQo4 NzU0IGZvciB0aGUgcHJvY2VkdXJlIHdlJ3JlIHRyeWluZyB0byBmb2xsb3cuICBTcGVjaWZpY2Fs bHksIGluIHRoZSBwcm9jZXNzIG9mIHRyeWluZyB0byBmaW5hbGl6ZSBteSByZXZpZXcgY29tbWVu dHMsIEkgZW5kZWQgdXAgZG9pbmcgYSBsb3Qgb2YgYmFja2dyb3VuZCByZWFkaW5nLCBpbiB3aGlj aCBJIG5vdGljZWQgdGhhdCBSRkMgODc1NCBzYXlzOg0KDQogICBOZXcgU0lEcyBkZWZpbmVkIGlu IHRoZSBmdXR1cmUgTVVTVCBzcGVjaWZ5IHRoZSBtdXRhYmlsaXR5IHByb3BlcnRpZXMNCiAgIG9m IHRoZSBGbGFncywgVGFnLCBhbmQgU2VnbWVudCBMaXN0IGFuZCBpbmRpY2F0ZSBob3cgdGhlIEhh c2hlZA0KICAgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlIChITUFDKSBUTFYgKFNlY3Rpb24g Mi4xLjIpIHZlcmlmaWNhdGlvbg0KICAgd29ya3MuICBOb3RlIHRoYXQsIGluIGVmZmVjdCwgdGhl c2UgZmllbGRzIGFyZSBtdXRhYmxlLg0KDQpUaGlzIGlzIGEgYml0IGNvbmZ1c2luZyB0byBtZSwg aW4gdGhhdCB0aGUgU0lEcyB0aGVtc2VsdmVzIGFwcGVhciBhcyBlbnRyaWVzIGluIHRoZSBTZWdt ZW50IExpc3QsIGFuZCBpdCdzIG5vdCBxdWl0ZSBjbGVhciB3aGVuIG9yIGhvdyBhIHBlci1TSUQg YmVoYXZpb3IgcmVsYXRpbmcgdG8gZmllbGRzIGluIHRoZSBjb250YWluaW5nIFNSSCBtaWdodCBj b21lIGludG8gcGxheS4gIEhvd2V2ZXIsIGdpdmVuIHRoYXQgd2UgYWxsb2NhdGUgYSBiZWhhdmlv ciBjb2RlcG9pbnQgZm9yICJ0aGUgU0lEIGRlZmluZWQgaW4gUkZDIDg3NTQiLCBJIGFtIGZvcmNl ZCB0byBjb25jbHVkZSB0aGF0IHRoZSBiZWhhdmlvcnMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1l bnQgbWVldCB0aGUgZGVmaW5pdGlvbiBvZiAibmV3IFNJRHMiDQp0aGF0IGFyZSBiZWluZyBkZWZp bmVkICJpbiB0aGUgZnV0dXJlIiAoZnJvbSB0aGUgcmVmZXJlbmNlIHBvaW50IG9mIFJGQyA4NzU0 KSwgYW5kIHRoZXJlZm9yZSB0aGF0IHRoZXkgbXVzdCBzcGVjaWZ5IHRoZSBpbmRpY2F0ZWQgcHJv cGVydGllcy4NCkknbSB0b2xkIG91dCBvZiBiYW5kIHRoYXQgdGhlIGludGVudCBpcyB0byBkbyB0 aGUgc2FtZSB0aGluZyB0aGF0IFJGQw0KODc1NCBkb2VzIGZvciB0aGUgU0lEIGl0IGRlZmluZXMs IGFuZCBzbyB0aGlzIHNob3VsZCBiZSB0cml2aWFsIHRvIHJlc29sdmUganVzdCBieSBhZGRpbmcg YSBicmllZiBub3RlIHRoYXQgKGUuZy4pICJ0aGUgU0lEcyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1 bWVudCBoYXZlIHRoZSBzYW1lIEhNQUMgVExWIGhhbmRsaW5nIGFuZCBtdXRhYmlsaXR5IHByb3Bl cnRpZXMgb2YgdGhlIEZsYWdzLCBUYWcsIGFuZCBTZWdtZW50IExpc3QgZmllbGQgYXMgdGhlIFNJ RCBzcGVjaWZpZWQgaW4gUkZDIDg3NTQiLiAgSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgc3VjaCBh biBleHBsaWNpdCBzdGF0ZW1lbnQgaXMgcmVxdWlyZWQsIGFuZCB0aGF0IHdlIHdvdWxkIGludHJv ZHVjZSBhbiBpbnRlcm5hbCBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQg UkZDIDg3NTQgaWYgd2Ugc2F5IG5vdGhpbmcgb24gdGhpcyB0b3BpYy4gIEluIHBhcnRpY3VsYXIs IEkgdGhpbmsgdGhhdCB3ZSB3b3VsZCBub3QgaW5oZXJpdCB0aGF0IGJlaGF2aW9yIGFzIHNvbWUg a2luZCBvZiBkZWZhdWx0IGJlaGF2aW9yIGlmIHdlIG1ha2Ugbm8gc3RhdGVtZW50IGF0IGFsbC4N Cg0KSSBhbSBzb3JyeSB0aGF0IEkgZGlkIG5vdCBub3RpY2UgdGhpcyBlYXJsaWVyLCBidXQgSSBm ZWVsIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIHJlbWFpbiBjb25zaXN0ZW50IHdpdGggdGhlIHJl cXVpcmVtZW50cyBvZiBSRkMgODc1NCBhbmQgdGh1cyB0aGF0IHRoaXMgaXMgYXBwcm9wcmlhdGUg dG8gcmFpc2UgYXMgYSBEaXNjdXNzLWxldmVsIHBvaW50LCBldmVuIGlmIEkgaGF2ZSBwcmV2aW91 c2x5IHJldmlld2VkIHRoZSB0ZXh0IGluIHF1ZXN0aW9uLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCltub3RlOiBJIG9yaWdpbmFsbHkgcHJlcGFyZWQgdGhl c2UgY29tbWVudHMgd2hlbiBsb29raW5nIGF0IHRoZSAtMjQuICBJIHRyaWVkIHRvIHJlbW92ZSBj b21tZW50cyBhYm91dCB0aGluZ3MgZml4ZWQgaW4gdGhlIC0yNSBvciAtMjYsIGJ1dCBtYXkgaGF2 ZSBtaXNzZWQgYSBjb3VwbGU7IHBsZWFzZSBpZ25vcmUgYW55IHN1Y2ggYWxyZWFkeS1hZGRyZXNz ZWQgY29tbWVudHMuDQpUaGVyZSBhcmUgYWxzbyBhIGNvdXBsZSBwb2ludHMgdGhhdCB3ZSBoYXZl IGFscmVhZHkgYmVlbiBkaXNjdXNzaW5nIGluIHRoZSBvdGhlciB0aHJlYWQgYnV0IEkgcmV0YWlu IGFzIGEgInBsYWNlaG9sZGVyIjsgaG9wZWZ1bGx5IHdlIGNhbiBrZWVwIHRoZSBhY3R1YWwgZGlz Y3Vzc2lvbiBhYm91dCB0aGVtIGluIGp1c3Qgb25lIHBsYWNlLl0NCg0KQXMgbWVudGlvbmVkIGlu IHRoZSBEaXNjdXNzIHNlY3Rpb24sIEkgZGlkIGEgbG90IG9mIGJhY2tncm91bmQgcmVhZGluZyB3 aGlsZSBwcmVwYXJpbmcgdGhpcyB1cGRhdGVkIGJhbGxvdCBwb3NpdGlvbi4gIEFub3RoZXIgdGhp bmcgSSBub3RpY2VkIHdoaWxlIGRvaW5nIHRoYXQgcmVhZGluZyBpcyB0aGF0IHRoZSBwc2V1ZG9j b2RlIGluDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODc1NCNzZWN0aW9uLTQuMy4x LjEgZXhwbGljaXRseSBtZW50aW9ucyAicGVyZm9ybSBUTFYgcHJvY2Vzc2luZyI7IHdlIG1pZ2h0 IGNvbnNpZGVyIHJlcGVhdGluZyB0aGF0IHN0ZXAgaW4gb3VyIHBzZXVkb2NvZGUgcHJvY2VkdXJl cywgYW5kIG90aGVyd2lzZSBtYWtpbmcgb3VyIHByb2NlZHVyZXMgYXMgYW5hbG9nb3VzIGFzIHBv c3NpYmxlIHRvIHRoZSBSRkMgODc1NCBwcm9jZWR1cmVzLCBqdXN0IGZyb20gdGhlIHBlcnNwZWN0 aXZlIG9mIGtlZXBpbmcgdGhlIHdyaXRpbmcgc3R5bGUgYXMgY29uc2lzdGVudCBhcyBwb3NzaWJs ZSBhY3Jvc3MgdGhlIHJlbGF0ZWQgZG9jdW1lbnRzLiAgSG93ZXZlciwgdGhhdCdzIGVudGlyZWx5 IGFuIGVkaXRvcmlhbCBtYXR0ZXIgYW5kIHRodXMgbGVmdCB0byB0aGUgZGlzY3JldGlvbiBvZiB0 aGUgYXV0aG9ycy9BRC4NCg0KU2VjdGlvbiAyDQoNCiAgIFRoZSBmb2xsb3dpbmcgdGVybXMgdXNl ZCB3aXRoaW4gdGhpcyBkb2N1bWVudCBhcmUgZGVmaW5lZCBpbg0KICAgW1JGQzg3NTRdOiBTUkgs IFNSIFNvdXJjZSBOb2RlLCBUcmFuc2l0IE5vZGUsIFNSIFNlZ21lbnQgRW5kcG9pbnQNCiAgIE5v ZGUsIFJlZHVjZWQgU1JILCBTZWdtZW50cyBMZWZ0IGFuZCBMYXN0IEVudHJ5Lg0KDQpJdCdzIHNs aWdodGx5IHVuZm9ydHVuYXRlIHRoYXQgODc1NCBkaWRuJ3QgaGF2ZSBhIGRlZGljYXRlZCB0ZXJt aW5vbG9neSBzZWN0aW9uIGNvbnRhaW5pbmcgdGhlc2UsIHRob3VnaCBpdCdzIHRvbyBsYXRlIHRv IHJlYWxseSBkbyBhbnl0aGluZyBhYm91dCBpdCBub3cuDQoNClNlY3Rpb24gMw0KDQogICBUaGUg dGVybSAiZnVuY3Rpb24iIHJlZmVycyB0byB0aGUgYml0LXN0cmluZyBpbiB0aGUgU1J2NiBTSUQu ICBUaGUNCiAgIHRlcm0gImJlaGF2aW9yIiBpZGVudGlmaWVzIHRoZSBiZWhhdmlvciBib3VuZCB0 byB0aGUgU0lELiAgVGhlDQogICBiZWhhdmlvcnMgYXJlIGRlZmluZWQgaW4gU2VjdGlvbiA0IG9m IHRoaXMgZG9jdW1lbnQuDQoNCihuaXQpIHVzaW5nICJ0aGUgYmVoYXZpb3JzIiB0byBzb21lIGV4 dGVudCBpbXBsaWVzIHRoYXQgdGhlc2UgYXJlIHRoZSBvbmx5IG9uZXMgYWxsb3dlZCBvciBkZWZp bmVkLCB3aGljaCBpcyBub3QgdHJ1ZS4gIFBlcmhhcHMgInNvbWUgYmVoYXZpb3JzIiB3b3VsZCBi ZSBtb3JlIGFjY3VyYXRlIChvciBzb21lIG90aGVyIHBocmFzaW5nIHdvdWxkIGFsc28gY292ZXIg dGhlIGV4cGVjdGVkIGV2b2x1dGlvbiBvZiB0aGUgZWNvc3lzdGVtKT8NCg0KU2VjdGlvbiAzLjMN Cg0KICAgQSBwYWNrZXQgY291bGQgYmUgc3RlZXJlZCB0byBhIG5vbi1yb3V0ZWQgU0lEIDIwMDE6 ZGI4OmI6MjoxMDE6OiBieQ0KICAgdXNpbmcgYSBTSUQgbGlzdCA8Li4uLDIwMDE6ZGI4OmI6MTox MDA6OiwyMDAxOmRiODpiOjI6MTAxOjosLi4uPg0KICAgd2hlcmUgdGhlIG5vbi1yb3V0ZWQgU0lE IGlzIHByZWNlZGVkIGJ5IGEgcm91dGVkIFNJRCB0byB0aGUgc2FtZQ0KICAgbm9kZS4gIFJvdXRl ZCBhbmQgbm9uLXJvdXRlZCBTUnY2IFNJRHMgYXJlIHRoZSBTUnY2IGluc3RhbnRpYXRpb24gb2YN CiAgIGdsb2JhbCBhbmQgbG9jYWwgc2VnbWVudHMsIHJlc3BlY3RpdmVseSBbUkZDODQwMl0uDQoN CklmIGl0J3MgKGFsc28pIHBvc3NpYmxlIHRvIHN0ZWVyIGEgcGFja2V0IHRvIGEgbm9uLXJvdXRl ZCBTSUQgd2l0aG91dCBhIHByZWNlZGluZyByb3V0ZWQgU0lEIGZvciB0aGUgc2FtZSBub2RlIChl LmcuLCB2aWEgRW5kLlgpLCBpdCBzZWVtcyBsaWtlIHRoYXQgbWlnaHQgYmUgd29ydGggbGlzdGlu ZyBhbiBleGFtcGxlIG9mIGFzIHdlbGwuICBPdGhlcndpc2UgYSByZWFkZXIgbWlnaHQgYXNzdW1l IHRoYXQgdGhlIGdsb2JhbCBzZWdtZW50IGlzIGEgbmVjZXNzYXJ5IHBhcnQgb2YgdXNpbmcgdGhl IG5vbi1yb3V0ZWQgU0lELg0KDQpTZWN0aW9uIDQNCg0KICBFbmQuRFQyVSAgICAgICAgICAgRW5k cG9pbnQgd2l0aCBkZWNhcHMgYW5kIHVuaWNhc3QgTUFDIEwydGFibGUgbG9va3VwDQogICAgICAg ICAgICAgICAgICAgICBlLmcuIEVWUE4gQnJpZGdpbmcgdW5pY2FzdCB1c2UtY2FzZQ0KDQoobml0 KSB3ZSBzZWVtIHRvIHB1dCBhIHNwYWNlIGluICJMMiB0YWJsZSIgdGhlIG90aGVyIHRpbWVzIGl0 IGFwcGVhcnMuDQoNCiAgIFRoZSBsaXN0IGlzIG5vdCBleGhhdXN0aXZlLiAgSW4gcHJhY3RpY2Us IGFueSBmdW5jdGlvbiBjYW4gYmUNCiAgIGF0dGFjaGVkIHRvIGEgbG9jYWwgU0lEOiBlLmcuIGEg bm9kZSBOIGNhbiBiaW5kIGEgU0lEIHRvIGEgbG9jYWwgVk0NCiAgIG9yIGNvbnRhaW5lciB3aGlj aCBjYW4gYXBwbHkgYW55IGNvbXBsZXggcHJvY2Vzc2luZyBvbiB0aGUgcGFja2V0Lg0KDQoobml0 KSB0aGUgcHJlY2VkaW5nIGxpc3Qgd2FzIGEgbGlzdCBvZiB3ZWxsLWtub3duIGJlaGF2aW9ycywg bm90IGEgbGlzdCBvZiBmdW5jdGlvbnMuICBJSVVDLCBpdCBpcyBtb3JlIGFwcHJvcHJpYXRlIHRv IHVzZSAiYmVoYXZpb3IiIGhlcmUgdGhhbiAiZnVuY3Rpb24iLCBzaW5jZSB0aGUgImZ1bmN0aW9u IiBpcyBqdXN0IHRoZSBvcGFxdWUgYml0c3RyaW5nLg0KDQpTZWN0aW9uIDQuMS4xLCAuLi4NCg0K ICAgV2hlbiBwcm9jZXNzaW5nIHRoZSBVcHBlci1sYXllciBIZWFkZXIgb2YgYSBwYWNrZXQgbWF0 Y2hpbmcgYSBGSUINCiAgIGVudHJ5IGxvY2FsbHkgaW5zdGFudGlhdGVkIGFzIGFuIFNSdjYgRW5k IFNJRCBkbyB0aGUgZm9sbG93aW5nOg0KDQooZWRpdG9yaWFsLCBJIHRoaW5rKSBJIGZpbmQgaXQg aW50ZXJlc3RpbmcgdG8gY29tcGFyZSB0aGUgcGhyYXNpbmcgaGVyZSB0byB3aGF0IHdhcyB1c2Vk IGluIMKnNC4xICh3aGVuIHByb2Nlc3NpbmcgYW4gU1JIKSwgd2hlcmUgdGhlIHRleHQgaXMgInJl Y2VpdmVzIGEgcGFja2V0IHdob3NlIElQdjYgREEgaXMgUyBhbmQgUyBpcyBhIGxvY2FsIEVuZCBT SUQiLiAgV2h5IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuICJFbmQgU0lEIiBhbmQgJ1NSdjYgRW5k IFNJRCI/ICBJSVVDIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGNoZWNraW5nICJJUHY2IERBIiBh bmQgIm1hdGNoaW5nIGEgRklCIGVudHJ5IGxvY2FsbHkgaW5zdGFudGlhdGVkIiBpcyBpbXBvcnRh bnQgYW5kIHRoZSBsYW5ndWFnZSBzaG91bGQgbm90IGJlIGhhcm1vbml6ZWQgYmV0d2VlbiBvY2N1 cnJlbmNlcy4NClRoZSAiLi4uIiBpbiB0aGUgU2VjdGlvbiBudW1iZXIgbGlzdGluZyBpbmRpY2F0 ZXMgdGhhdCB0aGlzIChvciBzaW1pbGFyKSBwaHJhc2luZyBhcHBlYXJzIHRocm91Z2hvdXQsIHdo ZW5ldmVyIHdlIHRhbGsgYWJvdXQgcHJvY2Vzc2luZyBhbiB1cHBlci1sYXllciBoZWFkZXIuDQoN ClNlY3Rpb24gNC4yDQoNCiAgIE5vdGUgdGhhdCBpZiBOIGhhcyBhbiBvdXRnb2luZyBpbnRlcmZh Y2UgYnVuZGxlIEkgdG8gYSBuZWlnaGJvciBRDQogICBtYWRlIG9mIDEwIG1lbWJlciBsaW5rcywg TiBtYXkgYWxsb2NhdGUgdXAgdG8gMTEgRW5kLlggbG9jYWwgU0lEczoNCiAgIG9uZSBmb3IgdGhl IGJ1bmRsZSBpdHNlbGYgYW5kIHRoZW4gdXAgdG8gb25lIGZvciBlYWNoIExheWVyLTIgbWVtYmVy DQogICBsaW5rLiAgVGhlIGZsb3dzIHN0ZWVyZWQgdXNpbmcgdGhlIEVuZC5YIFNJRCBjb3JyZXNw b25kaW5nIHRvIHRoZQ0KDQoobml0KSBJIHRoaW5rIHRoYXQgd2hpbGUgInVwIHRvIDExIiBtaWdo dCBiZSB0aGUgc2l0dWF0aW9uIHRoYXQgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UgKGluIHRoYXQgaGF2 aW5nIG1hbnkgZGlzdGluY3Qgc3ViZ3JvdXBzIHdpdGggMSA8IG4gPCAxMCBtZW1iZXIgbGlua3Mg ZG9lc24ndCBtYWtlIHNlbnNlKSwgaXQgaXMgbm90IHN0cmljdGx5IHNwZWFraW5nIGEgcGh5c2lj YWwgb3IgcHJvdG9jb2wgcmVxdWlyZW1lbnQuICBQZXJoYXBzICJtaWdodCBhbGxvY2F0ZSAxMSIg aXMgYmV0dGVyIHRoYW4gIm1heSBhbGxvY2F0ZSB1cCB0byAxMSIgZm9yIHRoYXQgcmVhc29uLg0K DQpTZWN0aW9uIDQuNCwgLi4uDQoNCiAgIFdoZW4gTiByZWNlaXZlcyBhIHBhY2tldCBkZXN0aW5l ZCB0byBTIGFuZCBTIGlzIGEgbG9jYWwgRW5kLkRYNiBTSUQsDQogICBOIGRvZXMgdGhlIGZvbGxv d2luZyBwcm9jZXNzaW5nOg0KDQoobml0KSB3ZSBoYXZlIGEgbWlzbWF0Y2ggb2YgIk4gZG9lcyB0 aGUgZm9sbG93aW5nIHByb2Nlc3NpbmciIChsaWtlIGFwcGVhcnMgaGVyZSkgYW5kICJOIGRvZXMi IG9yIHNpbWlsYXI7IGl0IGlzIHByb2JhYmx5IHdvcnRoIG5vcm1hbGl6aW5nIG9uIG9uZSBwaHJh c2luZy4NCg0KICAgV2hlbiBwcm9jZXNzaW5nIHRoZSBVcHBlci1sYXllciBoZWFkZXIgb2YgYSBw YWNrZXQgbWF0Y2hpbmcgYSBGSUINCiAgIGVudHJ5IGxvY2FsbHkgaW5zdGFudGlhdGVkIGFzIGFu IFNSdjYgRW5kLkRYNiBTSUQsIHRoZSBmb2xsb3dpbmcgaXMNCiAgIGRvbmU6DQoNClNpbWlsYXJs eSBoZXJlLCB3ZSB1c2UgInRoZSBmb2xsb3dpbmcgaXMgZG9uZSIgYnV0IHRoZSAiTiBkb2VzIHRo ZSBmb2xsb3dpbmciIHBocmFzaW5nIHVzZWQgaW4gc29tZSBvdGhlciBzZWN0aW9ucyBpcyBwcm9i YWJseSBwcmVmZXJyZWQsIGFzIGl0IGF2b2lkcyB0aGUgcGFzc2l2ZSB2b2ljZS4NCg0KU2VjdGlv biA0LjEyDQoNCldlIG1pZ2h0IGdpdmUgc29tZSBtbmVtb25pYyBleHBsYW5hdGlvbiBmb3IgaG93 IHRoZSBuYW1lICJGRTIiIHdhcyBjaG9zZW4gdG8gaWRlbnRpZnkgdGhlIGFyZ3VtZW50IHZhbHVl Lg0KDQogICB0YWJsZSBUIGZsb29kaW5nLiAgVGhlIGFsbG9jYXRpb24gb2YgdGhlIGFyZ3VtZW50 IHZhbHVlcyBpcyBsb2NhbCB0bw0KICAgdGhlIFNSIEVuZHBvaW50IE5vZGUgaW5zdGFudGlhdGlu ZyB0aGlzIGJlaGF2aW9yIGFuZCB0aGUgc2lnbmFsaW5nIG9mDQogICB0aGUgYXJndW1lbnQgdG8g b3RoZXIgbm9kZXMgZm9yIHRoZSBFVlBOIGZ1bmN0aW9uYWxpdHkgdmlhIGNvbnRyb2wNCiAgIHBs YW5lLg0KDQpuaXQoPyk6IHMvdmlhIGNvbnRyb2wgcGxhbmUvb2NjdXJzIHZpYSB0aGUgY29udHJv bCBwbGFuZS8/DQoNClNlY3Rpb24gNC4xMw0KDQogIFMwNS4gICBJZiAoSVB2NiBIb3AgTGltaXQg PD0gMSkgew0KICBTMDYuICAgICAgIFNlbmQgYW4gSUNNUCBUaW1lIEV4Y2VlZGVkIG1lc3NhZ2Ug dG8gdGhlIFNvdXJjZSBBZGRyZXNzLA0KICAgICAgICAgICAgICAgQ29kZSAwIChIb3AgbGltaXQg ZXhjZWVkZWQgaW4gdHJhbnNpdCksDQoNCihuaXQpIHRoZSBpbmRlbnRhdGlvbiBzZWVtcyBvZmYg Ynkgb25lIHNwYWNlIGluIHRoZSBmaXJzdCBsaW5lIG9mIFMwNiAoaXQgZG9lc24ndCBtYXRjaCB0 aGUgb3RoZXIgdHdvIHBsYWNlcyB3aGVyZSB0aGlzIGNodW5rIG9jY3VycykuDQoNCiAgIFMxNC4g IFRoZSBTUkggTUFZIGJlIG9taXR0ZWQgd2hlbiB0aGUgU1J2NiBQb2xpY3kgQiBvbmx5IGNvbnRh aW5zIG9uZQ0KICAgU0lEIGFuZCB0aGVyZSBpcyBubyBuZWVkIHRvIHVzZSBhbnkgZmxhZywgdGFn IG9yIFRMVi4NCiAgIFMxNy4gIFRoZSBQYXlsb2FkIExlbmd0aCwgVHJhZmZpYyBDbGFzcywgSG9w IExpbWl0IGFuZCBOZXh0LUhlYWRlcg0KICAgZmllbGRzIGFyZSBzZXQgYXMgcGVyIFtSRkMyNDcz XS4gIFRoZSBGbG93IExhYmVsIGlzIGNvbXB1dGVkIGFzIHBlcg0KICAgW1JGQzY0MzddLg0KDQoo VGhlc2UgbG9vayB0byBiZSBTMTUgYW5kIFMxOCwgcmVzcGVjdGl2ZWx5LCBub3cuKQ0KDQpTZWN0 aW9uIDQuMTQNCg0KICAgVGhlIFNSSCBNQVkgYmUgb21pdHRlZCB3aGVuIHRoZSBTUnY2IFBvbGlj eSBvbmx5IGNvbnRhaW5zIG9uZSBzZWdtZW50DQogICBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byB1 c2UgYW55IGZsYWcsIHRhZyBvciBUTFYuDQoNCihuaXQpIGl0J3MgcHJvYmFibHkgd29ydGggaGFy bW9uaXppbmcgdGhlIHBocmFzaW5nIGJldHdlZW4gaGVyZSBhbmQgdGhlIG5vdGUgb24gUzE1IGlu IMKnNC4xMyAoc3BlY2lmaWNhbGx5LCAib25seSBjb250YWlucyBvbmUgU0lEIiB2cyAib25seSBj b250YWlucyBvbmUgc2VnbWVudCIpLg0KDQpTZWN0aW9uIDQuMTUNCg0KKG5pdCkgdGhlcmUncyBh IGJsYW5rIGxpbmUgYXQgdGhlIGVuZCBvZiBTMDYgdGhhdCBkb2Vzbid0IG9jY3VyIGluIHRoZSBv dGhlciB0d28gbG9jYXRpb25zIHdoZXJlIHRoaXMgcHNldWRvY29kZSBhcHBlYXJzLg0KDQogIFMx Ni4gICBTdWJtaXQgdGhlIHBhY2tldCB0byB0aGUgTVBMUyBlbmdpbmUgZm9yIHRyYW5zbWlzc2lv biB0byB0aGUNCiAgICAgICAgICAgIHRvcG1vc3QgbGFiZWwuDQoNCihuaXQpIEkgc3VnZ2VzdCBy ZXdvcmRpbmcgc2xpZ2h0bHkgc28gYXMgdG8gbm90IGltcGx5IHRoYXQgdGhlIG5vZGUgdG8gdHJh bnNtaXQgdG8gaXMgZGV0ZXJtaW5lZCBieSB0aGUgdG9wbW9zdCBsYWJlbCAtLSBJSVVDIGl0J3Mg ZGV0ZXJtaW5lZCBieSB0aGUgTVBMUyBwb2xpY3ksIHNpbmNlIHRoZSBpbnRlcnByZXRhdGlvbiBv ZiB0aGUgbGFiZWwgaXMgaW4gZ2VuZXJhbCBsb2NhbCB0byB0aGUgcmVjZWl2aW5nIG5vZGUuDQoN ClNlY3Rpb24gNC4xNi4xLjINCg0KICAgQXMgYSByZW1pbmRlciwgW1JGQzg3NTRdIGRlZmluZXMg aW4gc2VjdGlvbiA1IHRoZSBTUiBEZXBsb3ltZW50IE1vZGVsDQogICB3aXRoaW4gdGhlIFNSIERv bWFpbiBbUkZDODQwMl0uICBXaXRoaW4gdGhpcyBmcmFtZXdvcmssIHRoZQ0KICAgQXV0aGVudGlj YXRpb24gSGVhZGVyIChBSCkgaXMgbm90IHVzZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3Jp YmVkDQogICBpbiBTZWN0aW9uIDcuNSBvZiBbUkZDODc1NF0uDQoNCihyZXBlYXRpbmcgZnJvbSB0 aGUgcHJldmlvdXMgdGhyZWFkIGFzIGEgcGxhY2Vob2xkZXIpIEkgdGhpbmsgd2UgbmVlZCBhbm90 aGVyIHNlbnRlbmNlIG9yIGNsYXVzZSBoZXJlIHRvIGNsYXJpZnkgd2h5IHRoaXMgc3RhdGVtZW50 IGlzIHJlbGV2YW50LCBlLmcuLCAiVGh1cywgd2hpbGUgdGhlIEFIIGNhbiBkZXRlY3QgY2hhbmdl cyB0byB0aGUgSVB2NiBoZWFkZXIgY2hhaW4sIGl0IHdpbGwgbm90IGJlIHVzZWQgaW4gY29tYmlu YXRpb24gd2l0aCB0aGUgU1JILCBzbyB1c2Ugb2YgUFNQIHdpbGwgbm90IGNhdXNlIGRlbGl2ZXJ5 IGZhaWx1cmUgZHVlIHRvIEFIIHZhbGlkYXRpb24gY2hlY2tzLiINCg0KU2VjdGlvbiA1DQoNCihl ZGl0b3JpYWwpIFRoaXMgaXMgdGhlIGZpcnN0IHBsYWNlIGluIHRoZSBkb2N1bWVudCB0aGF0IHdl IHRhbGsgYWJvdXQgdGhlICJoZWFkZW5kIiBvciBpdHMgcG9saWN5IGF0IGFsbCwgc28gYSBiaXQg b2YgYmFja2dyb3VuZCBvbiB3aHkgaXQncyB1c2VmdWwgdG8gdGFidWxhdGUgcG90ZW50aWFsIGhl YWRlbmQgcG9saWN5L2JlaGF2aW9ycyBtaWdodCBiZSBoZWxwZnVsLg0KDQpTZWN0aW9uIDUueA0K DQpUeWluZyB0aGUgb3RoZXIgcG9saWNpZXMgbW9yZSBwcmVjaXNlbHkgdG8gdGhlIHBzZXVkb2Nv ZGUgZm9yIEguRW5jYXBzIChlLmcuLCByZXBsYWNpbmcgUzAxKSBzZWVtcyBsaWtlIGl0IHdvdWxk IGJlIHVzZWZ1bCwgdG8gYXZvaWQgdGhlIGFwcGVhcmFuY2Ugb2Ygc3BlY2lmeWluZyBiZWhhdmlv ciBieSBhcHBlYWxpbmcgdG8gZXhhbXBsZXMuDQoNClNlY3Rpb24gNS4xDQoNCiAgIE5vdGU6DQog ICBTMDM6IEFzIGRlc2NyaWJlZCBpbiBbUkZDNjQzN10gKElQdjYgRmxvdyBMYWJlbCBTcGVjaWZp Y2F0aW9uKS4NCg0KV2UgbmVlZCB0byBwdWxsIGluIFJGQyAyNDczIGZvciBwYXlsb2FkIGxlbmd0 aCwgdHJhZmZpYyBjbGFzcywgYW5kIG5leHQtaGVhZGVyLCBJSVVDLiAgKGhvcC1saW1pdCBpcyBj b3ZlcmVkIGEgZmV3IHBhcmFncmFwaHMgZG93bi4pIEFsc28gdG8gc2F5IGhvdyB0aGUgbmV4dC1o ZWFkZXIgdmFsdWUgaXMgc2VsZWN0ZWQuDQoNClNlY3Rpb24gOC4xDQoNCiAgIFRoZSBwcmVzZW5j ZSBvZiBTSURzIGluIHRoZSBJR1AgZG9lcyBub3QgaW1wbHkgYW55IHJvdXRpbmcgc2VtYW50aWNz DQogICB0byB0aGUgYWRkcmVzc2VzIHJlcHJlc2VudGVkIGJ5IHRoZXNlIFNJRHMuICBUaGUgcm91 dGluZyByZWFjaGFiaWxpdHkNCiAgIHRvIGFuIElQdjYgYWRkcmVzcyBpcyBzb2xlbHkgZ292ZXJu ZWQgYnkgdGhlIG5vbi1TSUQtcmVsYXRlZCBJR1ANCiAgIHByZWZpeCByZWFjaGFiaWxpdHkgaW5m b3JtYXRpb24gdGhhdCBpbmNsdWRlcyBsb2NhdG9ycy4gIFJvdXRpbmcgaXMNCiAgIG5laXRoZXIg Z292ZXJuZWQgbm9yIGluZmx1ZW5jZWQgaW4gYW55IHdheSBieSBhIFNJRCBhZHZlcnRpc2VtZW50 IGluDQogICB0aGUgSUdQLg0KDQpJdCBzZWVtcyBsaWtlIHRoaXMgaXMgdHJ5aW5nIHRvIHNheSAi dGhlIElHUCBtdXN0IG5vdCBhZHZlcnRpc2UgcHJlZml4ZXMgY29udGFpbmVkIHdpdGhpbiB0aGUg TE9DIHBhcnQgb2YgYW4gU0lEIiwgYnV0IGluIGEgdmVyeSByb3VuZGFib3V0IHdheS4NCg0KU2Vj dGlvbiA4LjMNCg0KICAgVGhlIEVuZC5EWDQsIEVuZC5EWDYsIEVuZC5EVDQsIEVuZC5EVDYsIEVu ZC5EVDQ2LCBFbmQuRFgyLCBFbmQuRFgyViwNCiAgIEVuZC5EVDJVIGFuZCBFbmQuRFQyTSBTSURz IGNhbiBiZSBzaWduYWxlZCBpbiBCR1AuDQoNClNpbmNlIHdlIHNhaWQgZWFybGllciB0aGF0IHRo ZSBzaWduYWxpbmcgb2YgU0lEcyBuZWVkcyB0byBpbmNsdWRlIHRoZSBiZWhhdmlvciBjb2RlcG9p bnQgZm9yIGVhY2ggZnVuY3Rpb24gYml0c3RyaW5nLCBpdCBzZWVtcyBsaWtlIHdlIHNob3VsZCBw cm92aWRlIGEgcmVmZXJlbmNlIHRvIGhvdyBCR1Agd2lsbCBlbmNvZGUgdGhlIGJlaGF2aW9yIGNv ZGVwb2ludC4NCg0KU2VjdGlvbiA5DQoNClRoZXJlIHNlZW0gdG8gYmUgc29tZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyByZWxhdGluZyB0byB0aGUgdXNlIG9mIFBTUCwgaW4gdGhhdCB0aGUgZWdy ZXNzIG5vZGUgbG9zZXMgdmlzaWJpbGl0eSBpbnRvIHdoaWNoIHBvbGljeSB3YXMgdXNlZCBmb3Ig YSBnaXZlbiBwYWNrZXQsIHNvIGFsbCBwYWNrZXRzIGZyb20gYWxsIHBvbGljaWVzIHRoYXQgZWdy ZXNzIHZpYSB0aGF0IFNJRCBhcmUgaW4gdGhlIHNhbWUgYW5vbnltaXR5IChhbmQgcG9saWN5ISkg c2V0LiAgSW4gcGFydGljdWxhciwgZXZlbiBpZiBhbiBITUFDIFRMViB3YXMgcHJlc2VudCBpbiB0 aGUgU1JILCBpdCBpcyBub3QgYXZhaWxhYmxlIGFuZCBjYW5ub3QgYmUgdmFsaWRhdGVkLiAgSSBy ZWNvZ25pemUgdGhhdCB0aGUgaGVhZGVuZCAob3Igd2hhdGV2ZXIgZW50aXR5IGlzIGFzc2lnbmlu ZyBTUiBwb2xpY3kpIHNob3VsZCBrbm93IHdoZW4gc3VjaCB2YWxpZGF0aW9uIHdvdWxkIGJlIGlu dGVuZGVkIHRvIG9jY3VyIGFuZCBub3QgYXNzaWduIGEgcG9saWN5IGluY29tcGF0aWJsZSB3aXRo IGl0LCBidXQgdGhlcmUgYXJlIHN0aWxsIG5ldyBjb25zaWRlcmF0aW9ucyBpbiB0aGUgc2Vuc2Ug dGhhdCB0aGUgaGVhZGVuZCBuZWVkcyB0byBiZSBhd2FyZSBvZiB0aGVzZSBjb25zaWRlcmF0aW9u cy4NCg0KKHJlcGVhdGluZyBhcyBhIHBsYWNlaG9sZGVyIGZyb20gdGhlIHByZXZpb3VzIHRocmVh ZCkgSSB0aGluayB3ZSBzaG91bGQgYWxzbyBzYXkgdGhhdCBpbiB0aGUgYWJzZW5jZSBvZiB0aGUg SE1BQyBUTFYsIHZhbGlkIEZVTkMgYW5kIEFSRyB2YWx1ZXMgb24gYW55IGdpdmVuIG5vZGUgbWF5 IGJlIGd1ZXNzYWJsZSBhbmQgc3Bvb2ZhYmxlLCBhbG9uZyB3aXRoIHRoZSBzdGFuZGFyZCBkaXNj bGFpbWVyIHRoYXQgcmlza3MgYXJlIG1pbmltYWwgc2luY2UgYWxsIG5vZGVzIGluIHRoZSBTUiBk b21haW4gYXJlIGFzc3VtZWQgdG8gYmUgdHJ1c3RlZC4gIFRoaXMgaXMgZGlzdGluY3QgZnJvbSB0 aGUgYWxyZWFkeS1leHRhbnQgYWJpbGl0eSB0byBzcG9vZiBhIFNJRCBpbiB0aGF0IHRoZSB1bmRl cmx5aW5nIHN0cnVjdHVyZSBpbiB0aGUgU0lEIG1heSBhbGxvdyB0aGUgYXR0YWNrZXIgdG8gaW5k dWNlIGJlaGF2aW9yIHRoYXQgd2FzIG5ldmVyIGludGVuZGVkIHRvIGJlIGEgU0lELCBmb3IgZXhh bXBsZSBpZiB0aGUgaW1wbGVtZW50YXRpb24gbG9naWNhbGx5IHNlcGFyYXRlcyBGVU5DIGFuZCBB UkcgcHJvY2Vzc2luZyBhbmQgdGhlIGF0dGFja2VyIG1ha2VzIGEgY29tYmluYXRpb24gdGhhdCB3 YXMgbmV2ZXIgYWR2ZXJ0aXNlZC4NCg0KQWxzbywgSUlVQywgdGhlICJTZWdtZW50cyBMZWZ0ID09 IDAiIGhhbmRsaW5nIGZvciwgZS5nLiwgRW5kLlggaXMgaW1wb3J0YW50IHRvIHByZXZlbnQgdHJh ZmZpYyBsb29wcyAtLSBpZiBhIG5vZGUgZmFpbHMgdG8gcGVyZm9ybSB0aGF0IGNoZWNrIGFuZCBi bGluZGx5IHNlbmRzIHRoZSBwYWNrZXQgdG8gdGhlIGludGVyY29ubmVjdCBpdCB3aWxsIGdldCBy ZXR1cm5lZCB0byB0aGF0IG5vZGUvU0lEIGFuZCBsb29wIHVudGlsIHRoZSBJUCBob3AgbGltaXQg aXMgZXhoYXVzdGVkLg0KDQoNCg0K From nobody Thu Dec 10 09:59:14 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D93DB3A116E; Thu, 10 Dec 2020 09:59:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160762314881.14926.16585146705140790631@ietfa.amsl.com> Date: Thu, 10 Dec 2020 09:59:08 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-27.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 17:59:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : SRv6 Network Programming Authors : Clarence Filsfils Pablo Camarillo Garvia John Leddy Daniel Voyer Satoru Matsushima Zhenbin Li Filename : draft-ietf-spring-srv6-network-programming-27.txt Pages : 44 Date : 2020-12-10 Abstract: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-27 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 10 10:02:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A1A3A1104; Thu, 10 Dec 2020 10:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=LMn0wHMt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=S6N+k4Fr 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 yRiH3UaLB5Qt; Thu, 10 Dec 2020 10:02:04 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91B53A0E0B; Thu, 10 Dec 2020 10:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25384; q=dns/txt; s=iport; t=1607623323; x=1608832923; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oDOZ9uQSWjxWhPAInQYCx/o2t6xftBcArbvzO3CQhIE=; b=LMn0wHMtuERlJFpfhKJPOT4CcHjxEAJrZxzkuRQF4s3Hl2WtwK0hCSs9 Mb0aFCOv2/M47S+3rVUL5qi6Ntzxlpw3iqTbEasxHeWAbkfMzIC8aeSq8 nncf3v5Siffia2MLOnkS6HXKcuzMWf5C/jskesisa45upAKbYUPiodqHM w=; IronPort-PHdr: =?us-ascii?q?9a23=3A//L6mRbVStLyqc3YMwRpUn//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD4Da97RJh/eF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGHcfiIVDevy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAABvYdJf/5hdJa1YCg4LAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBEgEBAQEBAQEBAQEBAUCBOwQBAQEBAQsBgVEjLgd1Wy8?= =?us-ascii?q?uCoQ1g0gDhFmJCAOPCol/gS4UgREDVAsBAQENAQElCAIEAQGESgIXgWgCJTQ?= =?us-ascii?q?JDgIDAQELAQEFAQEBAgEGBHGFYQyFcgEBAQQSEREMAQE3AQsEAgEIEQQBAQM?= =?us-ascii?q?CHwcCAgIwFQgIAgQBDQUIGoMFglUDLgEOol4CgTyIaXaBMoMEAQEFgTcCDkG?= =?us-ascii?q?CfRiCEAMGgQ4qAYJzg3aCRIJ3gR4bgUE/gRFDglU+gl0BAQEBAQGBJgEBBgU?= =?us-ascii?q?GAQccBTECgl0zgiyBWRAaPgcBBFoBAx0FDQIKFgIEKhcKIwwBBRIpCAINBAs?= =?us-ascii?q?UBQIECwETBQUBGAIfjxMSEoJsPodQnCiBDwqCdIkghiCFeHaFOYMlOolslG+?= =?us-ascii?q?UAIsMkSESFgQODYQwAgQCBAUCDgEBBYFWOmdYEQdwFTuCaVAXAg2OIQwXFIM?= =?us-ascii?q?6hRSFBEB0AgEBMwIGAQkBAQMJfIccAQEFIQeBBgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.78,409,1599523200"; d="scan'208";a="813153607" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2020 18:02:02 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BAI217e026521 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Dec 2020 18:02:01 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Dec 2020 12:02:01 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Dec 2020 13:02:00 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 10 Dec 2020 12:01:59 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZSU7KCOpO8XFnfX0PvTjwOnHWM+TZ52tA8DLRhk5yIilzyx8Pk7A+7AicrbdAWW2qwfApKkveQ78chcCrzQSz3Jaox8kOdxp4Wp0eDaxTWHPVvhUh6e5xwa++wI8Ia5X17fof4uKfUAEoLBBxL7GdGySkSx7gvzfXZkkGLX5xrSCCADhyEIJ3QpWw1LnQ5Hzj2tM5LUPN09plkYWmJXa2FmZRlH1BPI3dstxGjZup02YdzF6Y+v+Lw0T9ojzPlvYMsvNRW4EDqSTrF3kRitfZu/I8SiuBp873Qqhsat3rNttTdBfk7Qg3cgV/aaqRDnc2wAT2AJxyZba9fl4g7jtVA== 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=oDOZ9uQSWjxWhPAInQYCx/o2t6xftBcArbvzO3CQhIE=; b=aZ3SUVVcjHm2lXghrqG+R6cyorP8TE41szzC5wu2LxeTgQoCdzb+1u67FXWVzU43uNK9ItncDB7AkWOXWyWm9Vnqqji54JRkMUzDFerEtH9342fXambJKE8jscEksbvZkR8/OaH4Im2cDhziowNx3x8LKH2Od5CEUYt26WxkilgnB6mVvh9PtepXaXvYvOjpDLr6rA69yCnt86cPsVD9a5HYTO+3GRwIp/hq+23vvmchnWccyPbn3bb18YJig9GtSgjVEUX8T8qAESwWhij9N7lk0T9St+iX9HIa3ArmD580Q/Dlxs2eXYRjjuHMUYv2JCxkTyKnhwtjeNgUVAM90g== 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=oDOZ9uQSWjxWhPAInQYCx/o2t6xftBcArbvzO3CQhIE=; b=S6N+k4FrJU/4GH7ndP9yPLsV65C3t0aJu/E9mV5DvzilNmNB+EUzjnQIADvt7lb+6fJK8kLDX1FQ8u90Qkda+8WBAG+4o29vALkwfO2O2801pd7Fjah7MB9jsp+s62b46nFVYet9g9OVW0qZpu0/A4wsD9fwH2r++LTgk4N6828= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SA2PR11MB4971.namprd11.prod.outlook.com (2603:10b6:806:118::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.28; Thu, 10 Dec 2020 18:01:58 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d%4]) with mapi id 15.20.3654.015; Thu, 10 Dec 2020 18:01:58 +0000 From: "Pablo Camarillo (pcamaril)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) Thread-Index: AQHWzk11hJlsON8AwUKTQpqAtVRetqnweUEw Date: Thu, 10 Dec 2020 18:01:58 +0000 Message-ID: References: <160753350153.28997.1345859562639063746@ietfa.amsl.com> In-Reply-To: <160753350153.28997.1345859562639063746@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f87c669c-37de-4256-50e5-08d89d35b008 x-ms-traffictypediagnostic: SA2PR11MB4971: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IupdezLdvBent955NY5I4JPxoUqw2o4lAtnLfiiUY4mBOMdv5qXMDLCLO5pQCAs3dn+xd0vvWB3ShPKA09GHsYj29aQKt00RtKlPX2F3AFHBUX2sW/+duD3sGIVGZUwmMQ5f4WM5jS9Pq7Ix8eL9nORF3b2bm6lJaF2reM2P+YD0bQNUuQdBKIwZYWiY9/MfYybzPVNMZDSc4Xlb3QS6nWP18MZHjP0Vluqnk7NN7bbTMBWQ32/BusHyjblGkFBX40Mhov6cYWW5BhztvS7KpynnXzEbli7dlK58v0EaCIjluilmzGIBA6mPOXJYMwrGGVNdQgTibj1XNIOZX7QRNkXDSRe4B8y1stXhVgrqXEvaYgk3I+kv7VTLAGJOwnwfMYcBVyAZ1ySK9jSeiJdLtQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(136003)(376002)(55016002)(33656002)(83380400001)(86362001)(9686003)(71200400001)(8936002)(5660300002)(53546011)(110136005)(26005)(64756008)(30864003)(66446008)(66556008)(52536014)(6506007)(508600001)(7696005)(8676002)(66574015)(4326008)(54906003)(186003)(66476007)(76116006)(2906002)(966005)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?d0wzYmNJNlN5dGczd1JYVmhzSGV4UkRKSlJmTFM2M3FZSWNqUnRHZVdzWlkx?= =?utf-8?B?bHVScmZMcUhta0RaYUovWUdvUWIxd2cyS0ZXTGE5NjZjbVBVWUFhVmEwSXdv?= =?utf-8?B?VVJQOEg4dVlkdmNiTERmL2prZmlPcnJSUm9NcVFveVhsbmRXMGJGeUQ2OEFx?= =?utf-8?B?UVRqRW5oWWRpYlJnUEMrd2QyV1d5UVJyRXZFaWhPSW5BNlJpcEVCZ1pBQXhn?= =?utf-8?B?eTVaSU1qU29McEtjMVRYa241bmQ5cktTT1BYY2wraDM2K3BJYzI4cDE3cGtG?= =?utf-8?B?MWFENkJlZjUxbGl2eWRhSkVmc2E0d1M2Q25PMjNHQU5oQXlmVXd1RzNEdFNM?= =?utf-8?B?VmMxRGlDMkhhSVphaHU4UG15UFZObUdGdEVmUVZWRy9wTmpzNzlpRSs4cU5U?= =?utf-8?B?eWM0bVZhVDlxUlpVZWFtU0NvVXEwMzZ4T2U4OTVMdnVsSVRsUC9wL0EydzJ1?= =?utf-8?B?UDJhVStKSTFqNklRSFlVYWZOOEpvNG40S1oybEFxV2ZVQzlnZzdnZ3cxNGty?= =?utf-8?B?a0hBVkErbUpOZUNqNzZWWndQTjR2RTRDanJmcHZHbFA5SllkSVNDeGhKQWxm?= =?utf-8?B?UXVKMDFTWFpNdHFoa1Z6QWZjVDR1c1VpVG9lNUl5L3ZCQnBzQ1IwODRBZ0lX?= =?utf-8?B?LzRJaEtUM1RVaTVjN0xCd1dUa0FoRnR1YWsvSWovbm1sakppd1p4S29sdzEy?= =?utf-8?B?Wi9sallNTm9WSjJ3ZGxXQ0cwTTh2UjJXNTRxZjNhKzRrUXNlRG04dzBrbjFL?= =?utf-8?B?N2haUHE1UHlTaGRMVXgrYXpJN28yM3lCeExPNU1KRlZFaDJHQkZyMFF1NHcw?= =?utf-8?B?VXhJMG9SdVZVVWx2NjRlT0UzWTRTcUZyU285MDZTdlRTRGd0anJucjF4alR2?= =?utf-8?B?Y2wyYVBSNHJ4RThCS1ZXWDYrWnNSdFE3S1J1MkNHKytnNTdwUHZKNnFOT0xN?= =?utf-8?B?dFdVekpqWjJJZmFzRkdMVlZGcmNUaVloQUwwMFJobnF0T1B5Q3dmdTRXL2pr?= =?utf-8?B?bjlIeFE4YWx0SWd2VDRoOG9XWi9HTDV1TXJHY1h3YXcrTTJPUmZGQnRjV1Zp?= =?utf-8?B?T3F0bER4aHJoYml1eGlyM0Q3QVBsNU9qbG1acGthTmo4ZG5zTTN4OGV4NWxQ?= =?utf-8?B?N2Y2citqV3hiRFh4eTVBcUZsLy9uc29PQW1Qay95aU9PbDRFcVg0Z3lzV3Vv?= =?utf-8?B?QjROM2ZXLzJoVzlER1FBTC9PSGV3MmRiYWtFZC9DbGZJS1piaFFvRXViMWw1?= =?utf-8?B?S3Jpc3N0amdGSnRIWUtuWFlkU0R6UC9Zd3N3VjRvRUFKQmYyRmRCOHYzSjdt?= =?utf-8?Q?gIfLr7W6SoYsk=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f87c669c-37de-4256-50e5-08d89d35b008 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 18:01:58.4241 (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: fFbTFzNv1z7y8F+URI3K0J74QSkdZPkH2UMLwZgAxmV7LujLf5wBP9+O3T/JvMWn7tlmXdcu8FbVKVEgLn2M3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4971 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 18:02:07 -0000 SGkgQmVuLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciB0aW1lIG9uIHRoaXMgZG9jdW1lbnQuDQpX ZeKAmXZlIHB1Ymxpc2hlZCByZXYyNyBvZiB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgY2hhbmdlcy4g IERldGFpbHMgaW5saW5lIHdpdGggW1BDXS4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMjcNCg0KQ2hlZXJzLA0K UGFibG8uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW5qYW1pbiBLYWR1 ayB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IA0KU2VudDogbWnDqXJjb2xlcywg OSBkZSBkaWNpZW1icmUgZGUgMjAyMCAxODowNQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn Pg0KQ2M6IGRyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZ0BpZXRmLm9y Zzsgc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBCcnVubyBEZWNyYWVu ZSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbT47IGptaEBqb2VsaGFscGVybi5jb20NClN1YmplY3Q6IEJlbmphbWluIEthZHVrJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMjY6 ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1zcHJpbmctc3J2 Ni1uZXR3b3JrLXByb2dyYW1taW5nLTI2OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1F TlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy8NCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoYW5rcyBmb3IgdGhl IHVwZGF0ZXMgdGhyb3VnaCB0byB0aGUgLTI2OyB0aGV5IGhlbHAgYSBsb3QuDQpIb3dldmVyLCBJ IGRvIHRoaW5rIHRoZXJlIGlzIG9uZSBmaW5hbCBEaXNjdXNzLWxldmVsIHBvaW50IHRoYXQgbmVl ZHMgdG8gYmUgcmVzb2x2ZWQ6IGl0J3MgbW9zdGx5IGEgcHJvY2VzcyBwb2ludCwgdG8gbWFrZSBz dXJlIHRoYXQgd2hhdCB3ZSBzYXkgaW4gdGhpcyBkb2N1bWVudCBjb21wbGllcyB0byB0aGUgcmVx dWlyZW1lbnRzIHRoYXQgd2VyZSBsYWlkIG91dCBpbiBSRkMNCjg3NTQgZm9yIHRoZSBwcm9jZWR1 cmUgd2UncmUgdHJ5aW5nIHRvIGZvbGxvdy4gIFNwZWNpZmljYWxseSwgaW4gdGhlIHByb2Nlc3Mg b2YgdHJ5aW5nIHRvIGZpbmFsaXplIG15IHJldmlldyBjb21tZW50cywgSSBlbmRlZCB1cCBkb2lu ZyBhIGxvdCBvZiBiYWNrZ3JvdW5kIHJlYWRpbmcsIGluIHdoaWNoIEkgbm90aWNlZCB0aGF0IFJG QyA4NzU0IHNheXM6DQoNCiAgIE5ldyBTSURzIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSBNVVNUIHNw ZWNpZnkgdGhlIG11dGFiaWxpdHkgcHJvcGVydGllcw0KICAgb2YgdGhlIEZsYWdzLCBUYWcsIGFu ZCBTZWdtZW50IExpc3QgYW5kIGluZGljYXRlIGhvdyB0aGUgSGFzaGVkDQogICBNZXNzYWdlIEF1 dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpIFRMViAoU2VjdGlvbiAyLjEuMikgdmVyaWZpY2F0aW9u DQogICB3b3Jrcy4gIE5vdGUgdGhhdCwgaW4gZWZmZWN0LCB0aGVzZSBmaWVsZHMgYXJlIG11dGFi bGUuDQoNClRoaXMgaXMgYSBiaXQgY29uZnVzaW5nIHRvIG1lLCBpbiB0aGF0IHRoZSBTSURzIHRo ZW1zZWx2ZXMgYXBwZWFyIGFzIGVudHJpZXMgaW4gdGhlIFNlZ21lbnQgTGlzdCwgYW5kIGl0J3Mg bm90IHF1aXRlIGNsZWFyIHdoZW4gb3IgaG93IGEgcGVyLVNJRCBiZWhhdmlvciByZWxhdGluZyB0 byBmaWVsZHMgaW4gdGhlIGNvbnRhaW5pbmcgU1JIIG1pZ2h0IGNvbWUgaW50byBwbGF5LiAgSG93 ZXZlciwgZ2l2ZW4gdGhhdCB3ZSBhbGxvY2F0ZSBhIGJlaGF2aW9yIGNvZGVwb2ludCBmb3IgInRo ZSBTSUQgZGVmaW5lZCBpbiBSRkMgODc1NCIsIEkgYW0gZm9yY2VkIHRvIGNvbmNsdWRlIHRoYXQg dGhlIGJlaGF2aW9ycyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBtZWV0IHRoZSBkZWZpbml0 aW9uIG9mICJuZXcgU0lEcyINCnRoYXQgYXJlIGJlaW5nIGRlZmluZWQgImluIHRoZSBmdXR1cmUi IChmcm9tIHRoZSByZWZlcmVuY2UgcG9pbnQgb2YgUkZDIDg3NTQpLCBhbmQgdGhlcmVmb3JlIHRo YXQgdGhleSBtdXN0IHNwZWNpZnkgdGhlIGluZGljYXRlZCBwcm9wZXJ0aWVzLg0KSSdtIHRvbGQg b3V0IG9mIGJhbmQgdGhhdCB0aGUgaW50ZW50IGlzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHRoYXQg UkZDDQo4NzU0IGRvZXMgZm9yIHRoZSBTSUQgaXQgZGVmaW5lcywgYW5kIHNvIHRoaXMgc2hvdWxk IGJlIHRyaXZpYWwgdG8gcmVzb2x2ZSBqdXN0IGJ5IGFkZGluZyBhIGJyaWVmIG5vdGUgdGhhdCAo ZS5nLikgInRoZSBTSURzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGhhdmUgdGhlIHNhbWUg SE1BQyBUTFYgaGFuZGxpbmcgYW5kIG11dGFiaWxpdHkgcHJvcGVydGllcyBvZiB0aGUgRmxhZ3Ms IFRhZywgYW5kIFNlZ21lbnQgTGlzdCBmaWVsZCBhcyB0aGUgU0lEIHNwZWNpZmllZCBpbiBSRkMg ODc1NCIuICBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCBzdWNoIGFuIGV4cGxpY2l0IHN0YXRlbWVu dCBpcyByZXF1aXJlZCwgYW5kIHRoYXQgd2Ugd291bGQgaW50cm9kdWNlIGFuIGludGVybmFsIGlu Y29uc2lzdGVuY3kgYmV0d2VlbiB0aGlzIGRvY3VtZW50IGFuZCBSRkMgODc1NCBpZiB3ZSBzYXkg bm90aGluZyBvbiB0aGlzIHRvcGljLiAgSW4gcGFydGljdWxhciwgSSB0aGluayB0aGF0IHdlIHdv dWxkIG5vdCBpbmhlcml0IHRoYXQgYmVoYXZpb3IgYXMgc29tZSBraW5kIG9mIGRlZmF1bHQgYmVo YXZpb3IgaWYgd2UgbWFrZSBubyBzdGF0ZW1lbnQgYXQgYWxsLg0KDQpJIGFtIHNvcnJ5IHRoYXQg SSBkaWQgbm90IG5vdGljZSB0aGlzIGVhcmxpZXIsIGJ1dCBJIGZlZWwgdGhhdCBpdCBpcyBpbXBv cnRhbnQgdG8gcmVtYWluIGNvbnNpc3RlbnQgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIG9mIFJGQyA4 NzU0IGFuZCB0aHVzIHRoYXQgdGhpcyBpcyBhcHByb3ByaWF0ZSB0byByYWlzZSBhcyBhIERpc2N1 c3MtbGV2ZWwgcG9pbnQsIGV2ZW4gaWYgSSBoYXZlIHByZXZpb3VzbHkgcmV2aWV3ZWQgdGhlIHRl eHQgaW4gcXVlc3Rpb24uDQoNCltQQ10gV2UgaGF2ZSBhZGRlZCB5b3VyIHN1Z2dlc3RlZCBzZW50 ZW5jZSB0byB0aGUgU2VjdGlvbiA5LiAoSeKAmXZlIHMvU0lEcy9TSUQgQmVoYXZpb3JzLykuIFRo YW5rcy4NCjxORVc+DQpUaGUgU0lEIEJlaGF2aW9ycyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVu dCBoYXZlIHRoZSBzYW1lIEhNQUMgVExWIGhhbmRsaW5nIGFuZCBtdXRhYmlsaXR5IHByb3BlcnRp ZXMgb2YgdGhlIEZsYWdzLCBUYWcsIGFuZCBTZWdtZW50IExpc3QgZmllbGQgYXMgdGhlIFNJRCBC ZWhhdmlvciBzcGVjaWZpZWQgaW4gUkZDIDg3NTQuDQo8L05FVz4NCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Q09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KW25vdGU6IEkgb3JpZ2luYWxseSBwcmVwYXJlZCB0 aGVzZSBjb21tZW50cyB3aGVuIGxvb2tpbmcgYXQgdGhlIC0yNC4gIEkgdHJpZWQgdG8gcmVtb3Zl IGNvbW1lbnRzIGFib3V0IHRoaW5ncyBmaXhlZCBpbiB0aGUgLTI1IG9yIC0yNiwgYnV0IG1heSBo YXZlIG1pc3NlZCBhIGNvdXBsZTsgcGxlYXNlIGlnbm9yZSBhbnkgc3VjaCBhbHJlYWR5LWFkZHJl c3NlZCBjb21tZW50cy4NClRoZXJlIGFyZSBhbHNvIGEgY291cGxlIHBvaW50cyB0aGF0IHdlIGhh dmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NpbmcgaW4gdGhlIG90aGVyIHRocmVhZCBidXQgSSByZXRh aW4gYXMgYSAicGxhY2Vob2xkZXIiOyBob3BlZnVsbHkgd2UgY2FuIGtlZXAgdGhlIGFjdHVhbCBk aXNjdXNzaW9uIGFib3V0IHRoZW0gaW4ganVzdCBvbmUgcGxhY2UuXQ0KDQpBcyBtZW50aW9uZWQg aW4gdGhlIERpc2N1c3Mgc2VjdGlvbiwgSSBkaWQgYSBsb3Qgb2YgYmFja2dyb3VuZCByZWFkaW5n IHdoaWxlIHByZXBhcmluZyB0aGlzIHVwZGF0ZWQgYmFsbG90IHBvc2l0aW9uLiAgQW5vdGhlciB0 aGluZyBJIG5vdGljZWQgd2hpbGUgZG9pbmcgdGhhdCByZWFkaW5nIGlzIHRoYXQgdGhlIHBzZXVk b2NvZGUgaW4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NzU0I3NlY3Rpb24tNC4z LjEuMSBleHBsaWNpdGx5IG1lbnRpb25zICJwZXJmb3JtIFRMViBwcm9jZXNzaW5nIjsgd2UgbWln aHQgY29uc2lkZXIgcmVwZWF0aW5nIHRoYXQgc3RlcCBpbiBvdXIgcHNldWRvY29kZSBwcm9jZWR1 cmVzLCBhbmQgb3RoZXJ3aXNlIG1ha2luZyBvdXIgcHJvY2VkdXJlcyBhcyBhbmFsb2dvdXMgYXMg cG9zc2libGUgdG8gdGhlIFJGQyA4NzU0IHByb2NlZHVyZXMsIGp1c3QgZnJvbSB0aGUgcGVyc3Bl Y3RpdmUgb2Yga2VlcGluZyB0aGUgd3JpdGluZyBzdHlsZSBhcyBjb25zaXN0ZW50IGFzIHBvc3Np YmxlIGFjcm9zcyB0aGUgcmVsYXRlZCBkb2N1bWVudHMuICBIb3dldmVyLCB0aGF0J3MgZW50aXJl bHkgYW4gZWRpdG9yaWFsIG1hdHRlciBhbmQgdGh1cyBsZWZ0IHRvIHRoZSBkaXNjcmV0aW9uIG9m IHRoZSBhdXRob3JzL0FELg0KDQpbUENdIEFjaw0KDQpTZWN0aW9uIDINCg0KICAgVGhlIGZvbGxv d2luZyB0ZXJtcyB1c2VkIHdpdGhpbiB0aGlzIGRvY3VtZW50IGFyZSBkZWZpbmVkIGluDQogICBb UkZDODc1NF06IFNSSCwgU1IgU291cmNlIE5vZGUsIFRyYW5zaXQgTm9kZSwgU1IgU2VnbWVudCBF bmRwb2ludA0KICAgTm9kZSwgUmVkdWNlZCBTUkgsIFNlZ21lbnRzIExlZnQgYW5kIExhc3QgRW50 cnkuDQoNCkl0J3Mgc2xpZ2h0bHkgdW5mb3J0dW5hdGUgdGhhdCA4NzU0IGRpZG4ndCBoYXZlIGEg ZGVkaWNhdGVkIHRlcm1pbm9sb2d5IHNlY3Rpb24gY29udGFpbmluZyB0aGVzZSwgdGhvdWdoIGl0 J3MgdG9vIGxhdGUgdG8gcmVhbGx5IGRvIGFueXRoaW5nIGFib3V0IGl0IG5vdy4NCg0KW1BDXSBJ bmRlZWQsIGJ1dCBub3RoaW5nIEkgY2FuIGRvIGFib3V0IGl0Li4uDQoNClNlY3Rpb24gMw0KDQog ICBUaGUgdGVybSAiZnVuY3Rpb24iIHJlZmVycyB0byB0aGUgYml0LXN0cmluZyBpbiB0aGUgU1J2 NiBTSUQuICBUaGUNCiAgIHRlcm0gImJlaGF2aW9yIiBpZGVudGlmaWVzIHRoZSBiZWhhdmlvciBi b3VuZCB0byB0aGUgU0lELiAgVGhlDQogICBiZWhhdmlvcnMgYXJlIGRlZmluZWQgaW4gU2VjdGlv biA0IG9mIHRoaXMgZG9jdW1lbnQuDQoNCihuaXQpIHVzaW5nICJ0aGUgYmVoYXZpb3JzIiB0byBz b21lIGV4dGVudCBpbXBsaWVzIHRoYXQgdGhlc2UgYXJlIHRoZSBvbmx5IG9uZXMgYWxsb3dlZCBv ciBkZWZpbmVkLCB3aGljaCBpcyBub3QgdHJ1ZS4gIFBlcmhhcHMgInNvbWUgYmVoYXZpb3JzIiB3 b3VsZCBiZSBtb3JlIGFjY3VyYXRlIChvciBzb21lIG90aGVyIHBocmFzaW5nIHdvdWxkIGFsc28g Y292ZXIgdGhlIGV4cGVjdGVkIGV2b2x1dGlvbiBvZiB0aGUgZWNvc3lzdGVtKT8NCg0KW1BDXSBD aGFuZ2VkIHRvICJzb21lIGJlaGF2aW9ycyIgYXMgc3VnZ2VzdGVkLg0KDQpTZWN0aW9uIDMuMw0K DQogICBBIHBhY2tldCBjb3VsZCBiZSBzdGVlcmVkIHRvIGEgbm9uLXJvdXRlZCBTSUQgMjAwMTpk Yjg6YjoyOjEwMTo6IGJ5DQogICB1c2luZyBhIFNJRCBsaXN0IDwuLi4sMjAwMTpkYjg6YjoxOjEw MDo6LDIwMDE6ZGI4OmI6MjoxMDE6OiwuLi4+DQogICB3aGVyZSB0aGUgbm9uLXJvdXRlZCBTSUQg aXMgcHJlY2VkZWQgYnkgYSByb3V0ZWQgU0lEIHRvIHRoZSBzYW1lDQogICBub2RlLiAgUm91dGVk IGFuZCBub24tcm91dGVkIFNSdjYgU0lEcyBhcmUgdGhlIFNSdjYgaW5zdGFudGlhdGlvbiBvZg0K ICAgZ2xvYmFsIGFuZCBsb2NhbCBzZWdtZW50cywgcmVzcGVjdGl2ZWx5IFtSRkM4NDAyXS4NCg0K SWYgaXQncyAoYWxzbykgcG9zc2libGUgdG8gc3RlZXIgYSBwYWNrZXQgdG8gYSBub24tcm91dGVk IFNJRCB3aXRob3V0IGEgcHJlY2VkaW5nIHJvdXRlZCBTSUQgZm9yIHRoZSBzYW1lIG5vZGUgKGUu Zy4sIHZpYSBFbmQuWCksIGl0IHNlZW1zIGxpa2UgdGhhdCBtaWdodCBiZSB3b3J0aCBsaXN0aW5n IGFuIGV4YW1wbGUgb2YgYXMgd2VsbC4gIE90aGVyd2lzZSBhIHJlYWRlciBtaWdodCBhc3N1bWUg dGhhdCB0aGUgZ2xvYmFsIHNlZ21lbnQgaXMgYSBuZWNlc3NhcnkgcGFydCBvZiB1c2luZyB0aGUg bm9uLXJvdXRlZCBTSUQuDQoNCltQQ10gSW5kZWVkLiBXZSd2ZSBhZGRlZCB0aGUgZm9sbG93aW5n LiBUaGFua3MuDQo8T0xEPg0KQSBwYWNrZXQgY291bGQgYmUgc3RlZXJlZCB0byBhIG5vbi1yb3V0 ZWQgU0lEIDIwMDE6ZGI4OmI6MjoxMDE6OiBieQ0KICAgdXNpbmcgYSBTSUQgbGlzdCA8Li4uLDIw MDE6ZGI4OmI6MToxMDA6OiwyMDAxOmRiODpiOjI6MTAxOjosLi4uPg0KICAgd2hlcmUgdGhlIG5v bi1yb3V0ZWQgU0lEIGlzIHByZWNlZGVkIGJ5IGEgcm91dGVkIFNJRCB0byB0aGUgc2FtZQ0KICAg bm9kZS4gIA0KPC9PTEQ+DQo8TkVXPg0KQSBwYWNrZXQgY291bGQgYmUgc3RlZXJlZCB0aHJvdWdo IGEgbm9uLXJvdXRlZCBTSUQgMjAwMTpkYjg6YjoyOjEwMTo6IGJ5DQogICB1c2luZyBhIFNJRCBs aXN0IDwuLi4sMjAwMTpkYjg6YjoxOjEwMDo6LDIwMDE6ZGI4OmI6MjoxMDE6OiwuLi4+DQogICB3 aGVyZSB0aGUgbm9uLXJvdXRlZCBTSUQgaXMgcHJlY2VkZWQgYnkgYSByb3V0ZWQgU0lEIHRvIHRo ZSBzYW1lDQogICBub2RlLiAgQSBwYWNrZXQgY291bGQgYWxzbyBiZSBzdGVlcmVkIHRvIGEgbm9k ZSBpbnN0YW50aWF0aW5nIGEgDQogICBub24tcm91dGVkIFNJRCBieSBwcmVjZWRpbmcgaXQgaW4g dGhlIFNJRC1saXN0IHdpdGggYW4gQWRqYWNlbmN5IFNJRCB0byB0aGF0IG5vZGUuDQo8L05FVz4N Cg0KU2VjdGlvbiA0DQoNCiAgRW5kLkRUMlUgICAgICAgICAgIEVuZHBvaW50IHdpdGggZGVjYXBz IGFuZCB1bmljYXN0IE1BQyBMMnRhYmxlIGxvb2t1cA0KICAgICAgICAgICAgICAgICAgICAgZS5n LiBFVlBOIEJyaWRnaW5nIHVuaWNhc3QgdXNlLWNhc2UNCg0KKG5pdCkgd2Ugc2VlbSB0byBwdXQg YSBzcGFjZSBpbiAiTDIgdGFibGUiIHRoZSBvdGhlciB0aW1lcyBpdCBhcHBlYXJzLg0KDQpbUENd IEZpeGVkDQoNCiAgIFRoZSBsaXN0IGlzIG5vdCBleGhhdXN0aXZlLiAgSW4gcHJhY3RpY2UsIGFu eSBmdW5jdGlvbiBjYW4gYmUNCiAgIGF0dGFjaGVkIHRvIGEgbG9jYWwgU0lEOiBlLmcuIGEgbm9k ZSBOIGNhbiBiaW5kIGEgU0lEIHRvIGEgbG9jYWwgVk0NCiAgIG9yIGNvbnRhaW5lciB3aGljaCBj YW4gYXBwbHkgYW55IGNvbXBsZXggcHJvY2Vzc2luZyBvbiB0aGUgcGFja2V0Lg0KDQoobml0KSB0 aGUgcHJlY2VkaW5nIGxpc3Qgd2FzIGEgbGlzdCBvZiB3ZWxsLWtub3duIGJlaGF2aW9ycywgbm90 IGEgbGlzdCBvZiBmdW5jdGlvbnMuICBJSVVDLCBpdCBpcyBtb3JlIGFwcHJvcHJpYXRlIHRvIHVz ZSAiYmVoYXZpb3IiIGhlcmUgdGhhbiAiZnVuY3Rpb24iLCBzaW5jZSB0aGUgImZ1bmN0aW9uIiBp cyBqdXN0IHRoZSBvcGFxdWUgYml0c3RyaW5nLg0KDQpbUENdIEluZGVlZC4gRml4ZWQuDQoNClNl Y3Rpb24gNC4xLjEsIC4uLg0KDQogICBXaGVuIHByb2Nlc3NpbmcgdGhlIFVwcGVyLWxheWVyIEhl YWRlciBvZiBhIHBhY2tldCBtYXRjaGluZyBhIEZJQg0KICAgZW50cnkgbG9jYWxseSBpbnN0YW50 aWF0ZWQgYXMgYW4gU1J2NiBFbmQgU0lEIGRvIHRoZSBmb2xsb3dpbmc6DQoNCihlZGl0b3JpYWws IEkgdGhpbmspIEkgZmluZCBpdCBpbnRlcmVzdGluZyB0byBjb21wYXJlIHRoZSBwaHJhc2luZyBo ZXJlIHRvIHdoYXQgd2FzIHVzZWQgaW4gwqc0LjEgKHdoZW4gcHJvY2Vzc2luZyBhbiBTUkgpLCB3 aGVyZSB0aGUgdGV4dCBpcyAicmVjZWl2ZXMgYSBwYWNrZXQgd2hvc2UgSVB2NiBEQSBpcyBTIGFu ZCBTIGlzIGEgbG9jYWwgRW5kIFNJRCIuICBXaHkgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gIkVu ZCBTSUQiIGFuZCAnU1J2NiBFbmQgU0lEIj8gIElJVUMgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4g Y2hlY2tpbmcgIklQdjYgREEiIGFuZCAibWF0Y2hpbmcgYSBGSUIgZW50cnkgbG9jYWxseSBpbnN0 YW50aWF0ZWQiIGlzIGltcG9ydGFudCBhbmQgdGhlIGxhbmd1YWdlIHNob3VsZCBub3QgYmUgaGFy bW9uaXplZCBiZXR3ZWVuIG9jY3VycmVuY2VzLg0KVGhlICIuLi4iIGluIHRoZSBTZWN0aW9uIG51 bWJlciBsaXN0aW5nIGluZGljYXRlcyB0aGF0IHRoaXMgKG9yIHNpbWlsYXIpIHBocmFzaW5nIGFw cGVhcnMgdGhyb3VnaG91dCwgd2hlbmV2ZXIgd2UgdGFsayBhYm91dCBwcm9jZXNzaW5nIGFuIHVw cGVyLWxheWVyIGhlYWRlci4NCg0KW1BDXSBUaGUgcGhyYXNpbmcgb2YgNC4xLjEgaXMgdGhlIHNh bWUgYXMgdGhlIG9uZSB1c2VkIGluIFJGQzg3NTQuDQpbUENdIFRoZSBkaWZmIGJldHdlZW4gIlNS djYgRW5kIFNJRCIgYW5kICJFbmQgU0lEIiBpcyBhbiBlZGl0b3JpYWwgbml0LiBJIGFncmVlIHRo YXQgc2hvdWxkIGJlIGhhcm1vbml6ZWQuIEkndmUgcmVtb3ZlZCAiU1J2NiIgaW4gYWxsIGluc3Rh bmNlcy4NCg0KU2VjdGlvbiA0LjINCg0KICAgTm90ZSB0aGF0IGlmIE4gaGFzIGFuIG91dGdvaW5n IGludGVyZmFjZSBidW5kbGUgSSB0byBhIG5laWdoYm9yIFENCiAgIG1hZGUgb2YgMTAgbWVtYmVy IGxpbmtzLCBOIG1heSBhbGxvY2F0ZSB1cCB0byAxMSBFbmQuWCBsb2NhbCBTSURzOg0KICAgb25l IGZvciB0aGUgYnVuZGxlIGl0c2VsZiBhbmQgdGhlbiB1cCB0byBvbmUgZm9yIGVhY2ggTGF5ZXIt MiBtZW1iZXINCiAgIGxpbmsuICBUaGUgZmxvd3Mgc3RlZXJlZCB1c2luZyB0aGUgRW5kLlggU0lE IGNvcnJlc3BvbmRpbmcgdG8gdGhlDQoNCihuaXQpIEkgdGhpbmsgdGhhdCB3aGlsZSAidXAgdG8g MTEiIG1pZ2h0IGJlIHRoZSBzaXR1YXRpb24gdGhhdCBtYWtlcyB0aGUgbW9zdCBzZW5zZSAoaW4g dGhhdCBoYXZpbmcgbWFueSBkaXN0aW5jdCBzdWJncm91cHMgd2l0aCAxIDwgbiA8IDEwIG1lbWJl ciBsaW5rcyBkb2Vzbid0IG1ha2Ugc2Vuc2UpLCBpdCBpcyBub3Qgc3RyaWN0bHkgc3BlYWtpbmcg YSBwaHlzaWNhbCBvciBwcm90b2NvbCByZXF1aXJlbWVudC4gIFBlcmhhcHMgIm1pZ2h0IGFsbG9j YXRlIDExIiBpcyBiZXR0ZXIgdGhhbiAibWF5IGFsbG9jYXRlIHVwIHRvIDExIiBmb3IgdGhhdCBy ZWFzb24uDQoNCltQQ10gQ2hhbmdlZCB0byBtaWdodC4NCg0KU2VjdGlvbiA0LjQsIC4uLg0KDQog ICBXaGVuIE4gcmVjZWl2ZXMgYSBwYWNrZXQgZGVzdGluZWQgdG8gUyBhbmQgUyBpcyBhIGxvY2Fs IEVuZC5EWDYgU0lELA0KICAgTiBkb2VzIHRoZSBmb2xsb3dpbmcgcHJvY2Vzc2luZzoNCg0KKG5p dCkgd2UgaGF2ZSBhIG1pc21hdGNoIG9mICJOIGRvZXMgdGhlIGZvbGxvd2luZyBwcm9jZXNzaW5n IiAobGlrZSBhcHBlYXJzIGhlcmUpIGFuZCAiTiBkb2VzIiBvciBzaW1pbGFyOyBpdCBpcyBwcm9i YWJseSB3b3J0aCBub3JtYWxpemluZyBvbiBvbmUgcGhyYXNpbmcuDQoNCltQQ10gQ2hhbmdlZCB0 byAiTiBkb2VzIg0KDQogICBXaGVuIHByb2Nlc3NpbmcgdGhlIFVwcGVyLWxheWVyIGhlYWRlciBv ZiBhIHBhY2tldCBtYXRjaGluZyBhIEZJQg0KICAgZW50cnkgbG9jYWxseSBpbnN0YW50aWF0ZWQg YXMgYW4gU1J2NiBFbmQuRFg2IFNJRCwgdGhlIGZvbGxvd2luZyBpcw0KICAgZG9uZToNCg0KU2lt aWxhcmx5IGhlcmUsIHdlIHVzZSAidGhlIGZvbGxvd2luZyBpcyBkb25lIiBidXQgdGhlICJOIGRv ZXMgdGhlIGZvbGxvd2luZyIgcGhyYXNpbmcgdXNlZCBpbiBzb21lIG90aGVyIHNlY3Rpb25zIGlz IHByb2JhYmx5IHByZWZlcnJlZCwgYXMgaXQgYXZvaWRzIHRoZSBwYXNzaXZlIHZvaWNlLg0KDQpb UENdIENoYW5nZWQgdG8gIk4gZG9lcyINCg0KU2VjdGlvbiA0LjEyDQoNCldlIG1pZ2h0IGdpdmUg c29tZSBtbmVtb25pYyBleHBsYW5hdGlvbiBmb3IgaG93IHRoZSBuYW1lICJGRTIiIHdhcyBjaG9z ZW4gdG8gaWRlbnRpZnkgdGhlIGFyZ3VtZW50IHZhbHVlLg0KDQpbUENdIEluaXRpYWxseSB3ZSBy ZWZlcnJlZCB0byBpdCBhcyDigJxMMiBhcmd1bWVudCBzcGVjaWZpYyB0byBFVlBOIEVTSSBmaWx0 ZXJpbmfigJ0uIEkgZG9u4oCZdCBzZWUgYSBzdHJhaWdodGZvcndhcmQgbW5lbW9uaWMgZXhwbGFu YXRpb24uDQoNCiAgIHRhYmxlIFQgZmxvb2RpbmcuICBUaGUgYWxsb2NhdGlvbiBvZiB0aGUgYXJn dW1lbnQgdmFsdWVzIGlzIGxvY2FsIHRvDQogICB0aGUgU1IgRW5kcG9pbnQgTm9kZSBpbnN0YW50 aWF0aW5nIHRoaXMgYmVoYXZpb3IgYW5kIHRoZSBzaWduYWxpbmcgb2YNCiAgIHRoZSBhcmd1bWVu dCB0byBvdGhlciBub2RlcyBmb3IgdGhlIEVWUE4gZnVuY3Rpb25hbGl0eSB2aWEgY29udHJvbA0K ICAgcGxhbmUuDQoNCm5pdCg/KTogcy92aWEgY29udHJvbCBwbGFuZS9vY2N1cnMgdmlhIHRoZSBj b250cm9sIHBsYW5lLz8NCg0KW1BDXSBDaGFuZ2VkDQoNClNlY3Rpb24gNC4xMw0KDQogIFMwNS4g ICBJZiAoSVB2NiBIb3AgTGltaXQgPD0gMSkgew0KICBTMDYuICAgICAgIFNlbmQgYW4gSUNNUCBU aW1lIEV4Y2VlZGVkIG1lc3NhZ2UgdG8gdGhlIFNvdXJjZSBBZGRyZXNzLA0KICAgICAgICAgICAg ICAgQ29kZSAwIChIb3AgbGltaXQgZXhjZWVkZWQgaW4gdHJhbnNpdCksDQoNCihuaXQpIHRoZSBp bmRlbnRhdGlvbiBzZWVtcyBvZmYgYnkgb25lIHNwYWNlIGluIHRoZSBmaXJzdCBsaW5lIG9mIFMw NiAoaXQgZG9lc24ndCBtYXRjaCB0aGUgb3RoZXIgdHdvIHBsYWNlcyB3aGVyZSB0aGlzIGNodW5r IG9jY3VycykuDQoNCltQQ10gRml4ZWQNCg0KICAgUzE0LiAgVGhlIFNSSCBNQVkgYmUgb21pdHRl ZCB3aGVuIHRoZSBTUnY2IFBvbGljeSBCIG9ubHkgY29udGFpbnMgb25lDQogICBTSUQgYW5kIHRo ZXJlIGlzIG5vIG5lZWQgdG8gdXNlIGFueSBmbGFnLCB0YWcgb3IgVExWLg0KICAgUzE3LiAgVGhl IFBheWxvYWQgTGVuZ3RoLCBUcmFmZmljIENsYXNzLCBIb3AgTGltaXQgYW5kIE5leHQtSGVhZGVy DQogICBmaWVsZHMgYXJlIHNldCBhcyBwZXIgW1JGQzI0NzNdLiAgVGhlIEZsb3cgTGFiZWwgaXMg Y29tcHV0ZWQgYXMgcGVyDQogICBbUkZDNjQzN10uDQoNCihUaGVzZSBsb29rIHRvIGJlIFMxNSBh bmQgUzE4LCByZXNwZWN0aXZlbHksIG5vdy4pDQoNCltQQ10gRml4ZWQNCg0KU2VjdGlvbiA0LjE0 DQoNCiAgIFRoZSBTUkggTUFZIGJlIG9taXR0ZWQgd2hlbiB0aGUgU1J2NiBQb2xpY3kgb25seSBj b250YWlucyBvbmUgc2VnbWVudA0KICAgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gdXNlIGFueSBm bGFnLCB0YWcgb3IgVExWLg0KDQoobml0KSBpdCdzIHByb2JhYmx5IHdvcnRoIGhhcm1vbml6aW5n IHRoZSBwaHJhc2luZyBiZXR3ZWVuIGhlcmUgYW5kIHRoZSBub3RlIG9uIFMxNSBpbiDCpzQuMTMg KHNwZWNpZmljYWxseSwgIm9ubHkgY29udGFpbnMgb25lIFNJRCIgdnMgIm9ubHkgY29udGFpbnMg b25lIHNlZ21lbnQiKS4NCg0KW1BDXSBJbmRlZWQuIENoYW5nZWQuDQoNClNlY3Rpb24gNC4xNQ0K DQoobml0KSB0aGVyZSdzIGEgYmxhbmsgbGluZSBhdCB0aGUgZW5kIG9mIFMwNiB0aGF0IGRvZXNu J3Qgb2NjdXIgaW4gdGhlIG90aGVyIHR3byBsb2NhdGlvbnMgd2hlcmUgdGhpcyBwc2V1ZG9jb2Rl IGFwcGVhcnMuDQoNCiAgUzE2LiAgIFN1Ym1pdCB0aGUgcGFja2V0IHRvIHRoZSBNUExTIGVuZ2lu ZSBmb3IgdHJhbnNtaXNzaW9uIHRvIHRoZQ0KICAgICAgICAgICAgdG9wbW9zdCBsYWJlbC4NCg0K KG5pdCkgSSBzdWdnZXN0IHJld29yZGluZyBzbGlnaHRseSBzbyBhcyB0byBub3QgaW1wbHkgdGhh dCB0aGUgbm9kZSB0byB0cmFuc21pdCB0byBpcyBkZXRlcm1pbmVkIGJ5IHRoZSB0b3Btb3N0IGxh YmVsIC0tIElJVUMgaXQncyBkZXRlcm1pbmVkIGJ5IHRoZSBNUExTIHBvbGljeSwgc2luY2UgdGhl IGludGVycHJldGF0aW9uIG9mIHRoZSBsYWJlbCBpcyBpbiBnZW5lcmFsIGxvY2FsIHRvIHRoZSBy ZWNlaXZpbmcgbm9kZS4NCg0KW1BDXSBSZW1vdmVkICJ0byB0aGUgdG9wbW9zdCBsYWJlbCIuDQoN ClNlY3Rpb24gNC4xNi4xLjINCg0KICAgQXMgYSByZW1pbmRlciwgW1JGQzg3NTRdIGRlZmluZXMg aW4gc2VjdGlvbiA1IHRoZSBTUiBEZXBsb3ltZW50IE1vZGVsDQogICB3aXRoaW4gdGhlIFNSIERv bWFpbiBbUkZDODQwMl0uICBXaXRoaW4gdGhpcyBmcmFtZXdvcmssIHRoZQ0KICAgQXV0aGVudGlj YXRpb24gSGVhZGVyIChBSCkgaXMgbm90IHVzZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3Jp YmVkDQogICBpbiBTZWN0aW9uIDcuNSBvZiBbUkZDODc1NF0uDQoNCihyZXBlYXRpbmcgZnJvbSB0 aGUgcHJldmlvdXMgdGhyZWFkIGFzIGEgcGxhY2Vob2xkZXIpIEkgdGhpbmsgd2UgbmVlZCBhbm90 aGVyIHNlbnRlbmNlIG9yIGNsYXVzZSBoZXJlIHRvIGNsYXJpZnkgd2h5IHRoaXMgc3RhdGVtZW50 IGlzIHJlbGV2YW50LCBlLmcuLCAiVGh1cywgd2hpbGUgdGhlIEFIIGNhbiBkZXRlY3QgY2hhbmdl cyB0byB0aGUgSVB2NiBoZWFkZXIgY2hhaW4sIGl0IHdpbGwgbm90IGJlIHVzZWQgaW4gY29tYmlu YXRpb24gd2l0aCB0aGUgU1JILCBzbyB1c2Ugb2YgUFNQIHdpbGwgbm90IGNhdXNlIGRlbGl2ZXJ5 IGZhaWx1cmUgZHVlIHRvIEFIIHZhbGlkYXRpb24gY2hlY2tzLiINCg0KW1BDXSBXaGF0IGFib3V0 IHRoaXM/DQo8T0xEPg0KV2l0aGluIHRoaXMgZnJhbWV3b3JrLCB0aGUgQXV0aGVudGljYXRpb24g SGVhZGVyIChBSCkgaXMgbm90IHVzZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNy41IG9mIFtSRkM4NzU0XS4NCjwvT0xEPg0KPFBST1BPU0FMPg0KV2l0aGluIHRo aXMgZnJhbWV3b3JrLCB0aGUgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkgaXMgbm90IHVzZWQg dG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy41IG9mIFtSRkM4NzU0 XS4gSGVuY2UsIHRoZSBkaXNjdXNzaW9uIG9mIGFwcGxpY2FiaWxpdHkgb2YgUFNQIGFsb25nIHdp dGggQUggdXNhZ2UgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPC9QUk9Q T1NBTD4NCg0KU2VjdGlvbiA1DQoNCihlZGl0b3JpYWwpIFRoaXMgaXMgdGhlIGZpcnN0IHBsYWNl IGluIHRoZSBkb2N1bWVudCB0aGF0IHdlIHRhbGsgYWJvdXQgdGhlICJoZWFkZW5kIiBvciBpdHMg cG9saWN5IGF0IGFsbCwgc28gYSBiaXQgb2YgYmFja2dyb3VuZCBvbiB3aHkgaXQncyB1c2VmdWwg dG8gdGFidWxhdGUgcG90ZW50aWFsIGhlYWRlbmQgcG9saWN5L2JlaGF2aW9ycyBtaWdodCBiZSBo ZWxwZnVsLg0KDQpbUENdIEkndmUgYWRkZWQgYSByZWZlcmVuY2UgdG8gUkZDODQwMi4NCg0KU2Vj dGlvbiA1LngNCg0KVHlpbmcgdGhlIG90aGVyIHBvbGljaWVzIG1vcmUgcHJlY2lzZWx5IHRvIHRo ZSBwc2V1ZG9jb2RlIGZvciBILkVuY2FwcyAoZS5nLiwgcmVwbGFjaW5nIFMwMSkgc2VlbXMgbGlr ZSBpdCB3b3VsZCBiZSB1c2VmdWwsIHRvIGF2b2lkIHRoZSBhcHBlYXJhbmNlIG9mIHNwZWNpZnlp bmcgYmVoYXZpb3IgYnkgYXBwZWFsaW5nIHRvIGV4YW1wbGVzLg0KDQpTZWN0aW9uIDUuMQ0KDQog ICBOb3RlOg0KICAgUzAzOiBBcyBkZXNjcmliZWQgaW4gW1JGQzY0MzddIChJUHY2IEZsb3cgTGFi ZWwgU3BlY2lmaWNhdGlvbikuDQoNCldlIG5lZWQgdG8gcHVsbCBpbiBSRkMgMjQ3MyBmb3IgcGF5 bG9hZCBsZW5ndGgsIHRyYWZmaWMgY2xhc3MsIGFuZCBuZXh0LWhlYWRlciwgSUlVQy4gIChob3At bGltaXQgaXMgY292ZXJlZCBhIGZldyBwYXJhZ3JhcGhzIGRvd24uKSBBbHNvIHRvIHNheSBob3cg dGhlIG5leHQtaGVhZGVyIHZhbHVlIGlzIHNlbGVjdGVkLg0KDQpbUENdIEFkZGVkIHJlZmVyZW5j ZSB0byBSRkMyNDczLg0KDQpTZWN0aW9uIDguMQ0KDQogICBUaGUgcHJlc2VuY2Ugb2YgU0lEcyBp biB0aGUgSUdQIGRvZXMgbm90IGltcGx5IGFueSByb3V0aW5nIHNlbWFudGljcw0KICAgdG8gdGhl IGFkZHJlc3NlcyByZXByZXNlbnRlZCBieSB0aGVzZSBTSURzLiAgVGhlIHJvdXRpbmcgcmVhY2hh YmlsaXR5DQogICB0byBhbiBJUHY2IGFkZHJlc3MgaXMgc29sZWx5IGdvdmVybmVkIGJ5IHRoZSBu b24tU0lELXJlbGF0ZWQgSUdQDQogICBwcmVmaXggcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIHRo YXQgaW5jbHVkZXMgbG9jYXRvcnMuICBSb3V0aW5nIGlzDQogICBuZWl0aGVyIGdvdmVybmVkIG5v ciBpbmZsdWVuY2VkIGluIGFueSB3YXkgYnkgYSBTSUQgYWR2ZXJ0aXNlbWVudCBpbg0KICAgdGhl IElHUC4NCg0KSXQgc2VlbXMgbGlrZSB0aGlzIGlzIHRyeWluZyB0byBzYXkgInRoZSBJR1AgbXVz dCBub3QgYWR2ZXJ0aXNlIHByZWZpeGVzIGNvbnRhaW5lZCB3aXRoaW4gdGhlIExPQyBwYXJ0IG9m IGFuIFNJRCIsIGJ1dCBpbiBhIHZlcnkgcm91bmRhYm91dCB3YXkuDQoNCltQQ10gTm90IGF0IGFs bC4gVGhpcyBpcyBzYXlpbmcgdGhhdCBpbiB5b3VyIElHUCB5b3UgaGF2ZSB0d28gZGlmZmVyZW50 IHRoaW5nczogcHJlZml4IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiAtaW5jbHVkaW5nIGxvY2F0 b3JzLTsgYW5kIFNJRCBhZHZlcnRpc2VtZW50cy4gQW5kIHJvdXRpbmcgaW4geW91ciBuZXR3b3Jr IGlzIGRlcml2ZWQgZnJvbSB0aGUgZmlyc3Qgb25lLg0KDQpTZWN0aW9uIDguMw0KDQogICBUaGUg RW5kLkRYNCwgRW5kLkRYNiwgRW5kLkRUNCwgRW5kLkRUNiwgRW5kLkRUNDYsIEVuZC5EWDIsIEVu ZC5EWDJWLA0KICAgRW5kLkRUMlUgYW5kIEVuZC5EVDJNIFNJRHMgY2FuIGJlIHNpZ25hbGVkIGlu IEJHUC4NCg0KU2luY2Ugd2Ugc2FpZCBlYXJsaWVyIHRoYXQgdGhlIHNpZ25hbGluZyBvZiBTSURz IG5lZWRzIHRvIGluY2x1ZGUgdGhlIGJlaGF2aW9yIGNvZGVwb2ludCBmb3IgZWFjaCBmdW5jdGlv biBiaXRzdHJpbmcsIGl0IHNlZW1zIGxpa2Ugd2Ugc2hvdWxkIHByb3ZpZGUgYSByZWZlcmVuY2Ug dG8gaG93IEJHUCB3aWxsIGVuY29kZSB0aGUgYmVoYXZpb3IgY29kZXBvaW50Lg0KDQpbUENdIElu Zm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gdGhlc2Ugb3RoZXIgcm91dGluZyBwcm90b2NvbCBkcmFm dHMgd2VyZSByZW1vdmVkIGFzIHBhcnQgb2YgZWFybGllciByZXZpZXcgY29tbWVudHMuIFdlIGNh biBhZGQgaXQgYmFjayBpZiBNYXJ0aW4gKHJlc3BvbnNpYmxlIEFEKSB3YW50cyB1cyB0byBkbyBz by4NCg0KU2VjdGlvbiA5DQoNClRoZXJlIHNlZW0gdG8gYmUgc29tZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyByZWxhdGluZyB0byB0aGUgdXNlIG9mIFBTUCwgaW4gdGhhdCB0aGUgZWdyZXNzIG5v ZGUgbG9zZXMgdmlzaWJpbGl0eSBpbnRvIHdoaWNoIHBvbGljeSB3YXMgdXNlZCBmb3IgYSBnaXZl biBwYWNrZXQsIHNvIGFsbCBwYWNrZXRzIGZyb20gYWxsIHBvbGljaWVzIHRoYXQgZWdyZXNzIHZp YSB0aGF0IFNJRCBhcmUgaW4gdGhlIHNhbWUgYW5vbnltaXR5IChhbmQgcG9saWN5ISkgc2V0LiAg SW4gcGFydGljdWxhciwgZXZlbiBpZiBhbiBITUFDIFRMViB3YXMgcHJlc2VudCBpbiB0aGUgU1JI LCBpdCBpcyBub3QgYXZhaWxhYmxlIGFuZCBjYW5ub3QgYmUgdmFsaWRhdGVkLiAgSSByZWNvZ25p emUgdGhhdCB0aGUgaGVhZGVuZCAob3Igd2hhdGV2ZXIgZW50aXR5IGlzIGFzc2lnbmluZyBTUiBw b2xpY3kpIHNob3VsZCBrbm93IHdoZW4gc3VjaCB2YWxpZGF0aW9uIHdvdWxkIGJlIGludGVuZGVk IHRvIG9jY3VyIGFuZCBub3QgYXNzaWduIGEgcG9saWN5IGluY29tcGF0aWJsZSB3aXRoIGl0LCBi dXQgdGhlcmUgYXJlIHN0aWxsIG5ldyBjb25zaWRlcmF0aW9ucyBpbiB0aGUgc2Vuc2UgdGhhdCB0 aGUgaGVhZGVuZCBuZWVkcyB0byBiZSBhd2FyZSBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucy4NCg0K W1BDXSBBcyBwYXJ0IG9mIHRoZSBjb21tZW50cyBmcm9tIEFsdmFybyB3ZSBhZGRlZCB0aGlzIHRl eHQgd2hpY2ggSSBiZWxpZXZlIGNvdmVycyB0aGF0IHBvaW50Og0K4oCcVGhlIGhlYWRlbmQgcG9s aWN5IGRlZmluaXRpb24gc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgc3BlY2lmaWMNCiAg IGJlaGF2aW9yIHVzZWQgYW5kIGFueSBsb2NhbCBjb25maWd1cmF0aW9u4oCdDQoNCihyZXBlYXRp bmcgYXMgYSBwbGFjZWhvbGRlciBmcm9tIHRoZSBwcmV2aW91cyB0aHJlYWQpIEkgdGhpbmsgd2Ug c2hvdWxkIGFsc28gc2F5IHRoYXQgaW4gdGhlIGFic2VuY2Ugb2YgdGhlIEhNQUMgVExWLCB2YWxp ZCBGVU5DIGFuZCBBUkcgdmFsdWVzIG9uIGFueSBnaXZlbiBub2RlIG1heSBiZSBndWVzc2FibGUg YW5kIHNwb29mYWJsZSwgYWxvbmcgd2l0aCB0aGUgc3RhbmRhcmQgZGlzY2xhaW1lciB0aGF0IHJp c2tzIGFyZSBtaW5pbWFsIHNpbmNlIGFsbCBub2RlcyBpbiB0aGUgU1IgZG9tYWluIGFyZSBhc3N1 bWVkIHRvIGJlIHRydXN0ZWQuICBUaGlzIGlzIGRpc3RpbmN0IGZyb20gdGhlIGFscmVhZHktZXh0 YW50IGFiaWxpdHkgdG8gc3Bvb2YgYSBTSUQgaW4gdGhhdCB0aGUgdW5kZXJseWluZyBzdHJ1Y3R1 cmUgaW4gdGhlIFNJRCBtYXkgYWxsb3cgdGhlIGF0dGFja2VyIHRvIGluZHVjZSBiZWhhdmlvciB0 aGF0IHdhcyBuZXZlciBpbnRlbmRlZCB0byBiZSBhIFNJRCwgZm9yIGV4YW1wbGUgaWYgdGhlIGlt cGxlbWVudGF0aW9uIGxvZ2ljYWxseSBzZXBhcmF0ZXMgRlVOQyBhbmQgQVJHIHByb2Nlc3Npbmcg YW5kIHRoZSBhdHRhY2tlciBtYWtlcyBhIGNvbWJpbmF0aW9uIHRoYXQgd2FzIG5ldmVyIGFkdmVy dGlzZWQuDQoNCltQQ10gSSBiZWxpZXZlIHlvdSBhcmUgbWFraW5nIGFuIGltcGxlbWVudGF0aW9u IGFzc3VtcHRpb24gb24gaG93IFNJRHMgYXJlIG1hdGNoZWQgYXQgYSBub2RlLiBBcyBhIHJlbWlu ZGVyIFJGQzg3NTQgc3RhdGVzIHRoYXQg4oCcV2hlbiBhbiBTUnY2LWNhcGFibGUgbm9kZSByZWNl aXZlcyBhbiBJUHY2IHBhY2tldCwgaXQgcGVyZm9ybXMgYSBsb25nZXN0LXByZWZpeC1tYXRjaCBs b29rdXAgb24gdGhlIHBhY2tldCdzIGRlc3RpbmF0aW9uIGFkZHJlc3Mu4oCdLiBUaHVzLCB0aGUg YWJpbGl0eSB0byBzcG9vZiBhIHBhcnRpY3VsYXIgRlVOQ1QgaXMgdGhlIHNhbWUgYXMgdGhlIGFi aWxpdHkgdG8gc3Bvb2YgYW55IG90aGVyIElQIGFkZHJlc3Mgb24gdGhlIG5vZGUuIEluIHRoZSBj b250ZXh0IG9mIFNSdjYsIHRoaXMgaXMgbWl0aWdhdGVkIGJ5IHVzaW5nIHRoZSBTUiBEb21haW4g YXMgZGVzY3JpYmVkIGluIFJGQzg3NTQgYW5kIC1pbiBwYXJ0aWN1bGFyIFNlY3Rpb24gNy4yLS4N Cg0KQWxzbywgSUlVQywgdGhlICJTZWdtZW50cyBMZWZ0ID09IDAiIGhhbmRsaW5nIGZvciwgZS5n LiwgRW5kLlggaXMgaW1wb3J0YW50IHRvIHByZXZlbnQgdHJhZmZpYyBsb29wcyAtLSBpZiBhIG5v ZGUgZmFpbHMgdG8gcGVyZm9ybSB0aGF0IGNoZWNrIGFuZCBibGluZGx5IHNlbmRzIHRoZSBwYWNr ZXQgdG8gdGhlIGludGVyY29ubmVjdCBpdCB3aWxsIGdldCByZXR1cm5lZCB0byB0aGF0IG5vZGUv U0lEIGFuZCBsb29wIHVudGlsIHRoZSBJUCBob3AgbGltaXQgaXMgZXhoYXVzdGVkLg0KDQpbUENd IEluZGVlZCwgZm9sbG93aW5nIGFsbCB0aGUgcHNldWRvY29kZXMgYXJlIGltcG9ydGFudCBhbmQg bm90IHNraXBwaW5nIGluc3RydWN0aW9ucyBpcyBpbXBvcnRhbnQuIEJ1dCB0aGlzIGNvdWxkIGJl IHNhaWQgZm9yIG1hbnkgbGluZXMgb2YgcHNldWRvY29kZSAtbm90IG9ubHkgZm9yIHRoYXQgY2hl Y2stLiBJbiB0aGUgc2FtZSBsaW5lIHRoYXQgaXQgY291bGQgYmUgc2FpZCB0aGF0IGRlY3JlbWVu dGluZyB0aGUgSVB2NiBob3AgbGltaXQgd2hlbiBwcm9jZXNzaW5nIGFuIElQdjYgcGFja2V0IGlz IGNyaXRpY2FsLiBJbiBvdGhlciB3b3JkcywgaXQgZmVlbHMgYXdrd2FyZCB0byBhZGQgYSBwYXJ0 aWN1bGFyIHJlbWluZGVyIG9ubHkgb24gdGhhdCBsaW5lIGFuZCBub3Qgb24gYW55IG90aGVyLiBB bGwgYXJlIGltcG9ydGFudC4NCg0KDQo= From nobody Fri Dec 11 05:54:41 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 835E63A0AB1; Fri, 11 Dec 2020 05:54:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160769487547.19478.17911056328217150861@ietfa.amsl.com> Date: Fri, 11 Dec 2020 05:54:35 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-nsh-sr-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 13:54:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Integration of Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) Authors : James N Guichard Jeff Tantsura Filename : draft-ietf-spring-nsh-sr-04.txt Pages : 18 Date : 2020-12-11 Abstract: This document describes the integration of Network Service Header (NSH) [RFC8300] and Segment Routing (SR) [RFC8402], as well as encapsulation details, to support Service Function Chaining (SFC) [RFC7665] in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture. Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFF) along a given Service Function Path (SFP) while NSH has the responsibility for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. The integration described in this document demonstrates that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using NSH. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-nsh-sr-04 https://datatracker.ietf.org/doc/html/draft-ietf-spring-nsh-sr-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-nsh-sr-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 11 08:15:25 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F53A0CED for ; Fri, 11 Dec 2020 08:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=M8M+t13Y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oaMv7Lg0 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 ZjcRafbJbVsx for ; Fri, 11 Dec 2020 08:15:21 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCE13A0CEA for ; Fri, 11 Dec 2020 08:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1607703319; x=1608912919; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OY5TiDqDB0V7Dmaw5fmxp63DZBN0ToUj9ahEjsogm/c=; b=M8M+t13YCUbWwNd7jp5tBDV2TmCTa1z8hhaymex1RJDvt7JO0yoc1S5q 6jxtgTFK4uaDmxSHoh5F2TUyy7RtDJ4iNyQB4RRLHn72gyBSltooYqtVQ 0PMWV59zdoCJQAvRVlshXPPMRDEHoVyI2cmfaTtHn2AyNkIIBKTqcA4tw E=; X-IPAS-Result: =?us-ascii?q?A0ApAgCdmdNfmIcNJK1igQmBT4FSUYFXLy4Kh30DjVOZD?= =?us-ascii?q?YEuFIERA1QLAQEBDQEBLQIEAQGESgKBfwIlNAkOAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQEBAQEBAQGGNgELhgsoBgEBOBEBPkImAQQbGoMEglYDLgGjbQKBP?= =?us-ascii?q?IhpdIE0gwQBAQWFDhiCEAmBOIJ1gmlOhxsbgUE/gRFDgicuhEcBEgEjg0iCL?= =?us-ascii?q?IFZT0s4gTIwcQMzkBqnfwqCdASbZaI6lAGcUwSETwIEAgQFAg4BAQWBVjhpc?= =?us-ascii?q?HAVO4JpUBcCDY47HYM6ilh0NwIGCgEBAwl8iEoBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AQfPj3R0B/jXbP8+jsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,411,1599523200"; d="scan'208";a="613150858" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Dec 2020 16:15:19 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BBGFIbJ001696 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 11 Dec 2020 16:15:18 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Dec 2020 10:15:18 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Dec 2020 11:15:18 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 11 Dec 2020 11:15:17 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D1iRhEMmtlz879qk+1JUjAYy+edeSnXDKQBG3b2RWWO64kWWpbSUa+xhs+tD8EDEFo0cxvYNRYMbeo8RykhEWKH89BgrmeQkmvde/jsmSKwy3VC/d/HVDRMxTVZ+zwdX6wV++JWCoi5LZww6Vo3NAL1ACqqKki70H+Eqj+Vy16DGkDXkGpL79O4nxc/YviKBOpPdj5McDRk6NzvG8AdWSDla0tZU4msYBNpxTegK/ZZjiuM3ahdKS0QY/zESbIm3kdQC2F10Wrgs1Laj2RvvSCZnH5fsxKzc3eEhdGEcXNM1lQvfO9b5KNugvvvikzOEFINLGq7QIefqa9gWWeVQkg== 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=OY5TiDqDB0V7Dmaw5fmxp63DZBN0ToUj9ahEjsogm/c=; b=I21SsI5OE8stSVBmEs8W6OKyAhHfOvIZcnqLn8HPGIlZXp7BPhBfO5rkS8zhTvU8HGXV6Yt45Wx2/qggiqzZUdVmbJDHzNiAhM1vzqCICWIX7ymkMD3uL6AdbFcI9IOrn39+qvRkE3FCvtiezCFMlKNT75DLl+fa9Y1NOywDMbn2XF7eBJCWq/G6PvnHzFKYT1IZtqksks9Dt0eeYJlYmssAoLnFkP9xvYBCLxVBoUUUS2AZI5+khojC+119nvlnKuCekmCUgQXcwQGgTxPC0w/v46tim6133/CPzzcBFLEQPt+W7Dt3+XIFfn+eWfcj0Em915k4peOA6N/6ZzPb5Q== 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=OY5TiDqDB0V7Dmaw5fmxp63DZBN0ToUj9ahEjsogm/c=; b=oaMv7Lg0eRQ2uL2SeuGtNRIyld2kk+2mG2PwEvNjXduYrVHvLKDtXtf3Pu18DoYlHmARpSHPbYUZYn+9FWfdSiustJf10TMcYaieRLhQjLzQrRJo2pkBEDgm2L4b/+lhqaTgR3DqZsScNhuw9GuSW6gXrQ99x2oOX8+61cuJz8o= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB5060.namprd11.prod.outlook.com (2603:10b6:303:93::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Fri, 11 Dec 2020 16:15:16 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d1b1:838a:7ea7:539c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d1b1:838a:7ea7:539c%3]) with mapi id 15.20.3654.018; Fri, 11 Dec 2020 16:15:16 +0000 From: "Ketan Talaulikar (ketant)" To: "spring@ietf.org" Thread-Topic: Regd reserving block of colors values (draft-ietf-spring-segment-routing-policy) Thread-Index: AdbP1zkgxGdsAFfoSgqNFFILGHto+w== Date: Fri, 11 Dec 2020 16:15:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e77d86d-e32d-45e8-28b2-08d89deff2be x-ms-traffictypediagnostic: CO1PR11MB5060: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SfW7UoZXNBncVntF5BA05Hz8/ffyNIrVxpOv5aW9Fw0Wug13mgL/pgH3EHj95tBVwFTkvAhQvHiqbXK3duhtYJ1tC56aomqWYBe2mk/ub4w00jVrlKwuQ1HivP7FUzCH6ggzG44Fjtca1HDfS2rQP6UUcV4wXdH3OKouW9YYCSmTgPnrr0dmoJtaBeWgmfk18YVPQx7AwjOA19Igg+0k3rU/aNlLTU7RYAk/qLy3ET56JQuGqUpiG3j/Y8Zpcf/OX2IV/j1dXNjEM+qrXLzXRgTp3XzX76JNx912P/0Qk351jbZdZ6rebOhh2jF/0KtXRbleip4q1A9SLvO0Y9pprw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(346002)(9686003)(66446008)(508600001)(66556008)(86362001)(64756008)(76116006)(5660300002)(83380400001)(2906002)(66946007)(66476007)(8936002)(7696005)(6916009)(6506007)(33656002)(186003)(71200400001)(55016002)(8676002)(26005)(52536014)(4744005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?A97gurPbuTHuBPRFRZBc4c8x+vJ+I4l/6zSny5rV/mgN93TkXaczaCJJmbGv?= =?us-ascii?Q?1f2o3RzaKYoaV5x5EziCYJRvknUncIOnxQ/9vmLO/fKG4orbuZkpx/i7rLYe?= =?us-ascii?Q?RudNJ1MHj1NwoOICaorqtplSnztt/JNUIdW1qCMJ89NWqdLULFsjUToPeonS?= =?us-ascii?Q?0dx+gIRmPnd4NwiFz30WOOef/3wEH2WPmvBQFvQUUtw97T5vJZEjFVQg/gsC?= =?us-ascii?Q?bZAbDg6cvVh4XIiGeiX4U39qFM32oV4cEt5TxfXtclS4EP/we0HW59JR3dsT?= =?us-ascii?Q?ty0CNCfE98E9ztEqW94vaVtxjBOKQgixLX76EjYPj0v2AYD1hJ/SJe5RAlrO?= =?us-ascii?Q?qffBbFELDR2zAAuxgkhyHoINyycSZfiw/OFXfy4Thh7qAXmBAiDBydZgUlRP?= =?us-ascii?Q?W11e7sX5V2AnOa112gzzcnvZeEGiuXjlMHxztFeBgVLyAGo5vzVmLwTTG4tn?= =?us-ascii?Q?sfmeoJfLRf2/IgrLVSMgcx/9VO5Tbv+i8VjiI3tkb/Qo/P1t7nbAQ7VGUjVq?= =?us-ascii?Q?oS3V543iaHeoij1/xOaEraDXuiWGJoP9b055omlwhnPlTQsHU3vV562jtHB+?= =?us-ascii?Q?SC2S6SE1bQw3rzyKbm3yR8ZxJRWdtXOvECM6EiFcHodMsU1iMZfwCF6XvAyX?= =?us-ascii?Q?g10dnCScc+izxTzkpu8PchvIWMF5ozvfLSLwwKz+Jxj+yfiJSzCOY+Odqps2?= =?us-ascii?Q?/6dIOB9bgHnHVPnu11Lu9ptQg44p2QO0Wf4FOTOGCdzf5rpcYytAg5CUQQ1R?= =?us-ascii?Q?Ffqb13g7wJZeW3eT4XljqX9b8lIrgzvwvKp9PS7o8bTwKqvRoeIoaO2miyQ+?= =?us-ascii?Q?0xZOr4hwrkmn/5VdIIM2t7PyCpfVBhugE2rrRtfi4Mbp6LXasJ8IxZ97021L?= =?us-ascii?Q?dYmfEYQcSrSjMnJD+5ljuUmTvKNm7ogOSWLdcMDzlEfgd3HH4eEaxEzS22pl?= =?us-ascii?Q?lMFAJZhgulK10yp3nMqH/+1jj3e/LFv5wCzBiK8NkJI=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e77d86d-e32d-45e8-28b2-08d89deff2be X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 16:15:16.6794 (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: RyzITaMrBlJaDOsjLUuy1tkftlNFb3Rd2rg+/TlLiVaGpOX5z0NYBhBSbmUAhqx9JgFmn3ydWDcrkSAZ+dCnlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5060 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [spring] Regd reserving block of colors values (draft-ietf-spring-segment-routing-policy) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 16:15:23 -0000 Hello All, We had the discussion, both on the list before the IETF 109 as well as duri= ng the WG session at IETF 109, regarding some sort of an allocation or rese= rvation of a block/range of color values on the routers. This range may be = for either local use on the routers (i.e. not used for steering) or may be = dedicated for a controller to use (e.g. for SR Policies initiated/signalled= via controllers). There were different opinions expressed on this matter. Today the draft-ietf-spring-segment-routing-policy does not contain any tex= t on this aspect. It is left to the deployment design to manage the color s= pace as required. This email is to continue this discussion so we can arrive at a consensus o= n this topic. Would appreciate feedback/inputs from the WG so we can address this open co= mment and progress this important draft towards WGLC. Thanks, Ketan From nobody Sat Dec 12 13:51:32 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7133A0E3F for ; Sat, 12 Dec 2020 13:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[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, T_REMOTE_IMAGE=0.01, 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 CycG8cXFzirx for ; Sat, 12 Dec 2020 13:51:29 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 91CF93A0E3B for ; Sat, 12 Dec 2020 13:51:29 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id l23so4388826pjg.1 for ; Sat, 12 Dec 2020 13:51:29 -0800 (PST) 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=yc+QfGWOp6MWLhXWqOtYv3gl8pbHI658Wk2N3KcWCtI=; b=SCzcN1zUNUT1KxkwJqhUuCQQRrEEsE4mG87oLjaaP9ZuT38vBGJxxLS/Em9yA6DBYd 1vWy59qDF7DOCwHlSYUHIlj4IgMtO9qjWjxV+JTOAyG8a5wTA1qI/m4C5sYk3IbV0zWc VnnkNfAcE2y1u4exxSJ3RlGR5ElhJwd/bsy5mwPZb2Uq0wW0qrkdlsgb6DDWcgQ0HxuW 3Rwjwvg457TNkZGcMHIYEp/U8ozeC21UDV/AK8ryBe5DO4bFO+xFF8Y1oKhnxA78pRC4 rx1YTak0Opw8lB0zD8WtqWxixnJpbmSMdSLgVRFlsIxOYgE0Eu0Fh9oCSeda6+evfTjh D2kw== 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=yc+QfGWOp6MWLhXWqOtYv3gl8pbHI658Wk2N3KcWCtI=; b=lIJvvOCtX2LT2ITFWN7fyRk6iFUJLIGEoXLs+keO6e7Afs4iKnmDuOA5bFlBP6jsJA XJZYTc70XSiSA5eTDitJga3YAeUQ9qurFJlMU2uhzM8qWsPaOz8Hd1brgZeQ+Mu/+hFk B3KX4egUdRM2wRXei22r7qs8F53B+2X3/SIiGbdLRhWdFQORs+lodU7InQITwxX0/wHG gCqr6GkHe014CCfeIKSSxsF6hwTTLNKVmW0SRy5Za14Rbf3KeGPeZJEE47SoA5ffK/TM e7MDsHZ+k85UR6HM7mkLVjOwpNCJcKYKTszzB2BpbxiEpXft4c3bbfUSGaM1Kv0cfajp MO6A== X-Gm-Message-State: AOAM5324bwYjabqqGZuQmFtUUgn9SeYm0op2teSk82JRP8BeBaMHoxby VgA802T20z3z3L30xI5dJhGEbArdpUE4Qev36It4QuSjwsQ= X-Google-Smtp-Source: ABdhPJxB8XlZXdPJ4rfTdi868fPgH3SO1jM2YR4zldt7pG+7BUXDOmkszKLMrJ/lciwBxiDTIqV8ReWrvpEyDKnAe+Q= X-Received: by 2002:a17:90a:fb97:: with SMTP id cp23mr19058582pjb.215.1607809888884; Sat, 12 Dec 2020 13:51:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 12 Dec 2020 16:51:18 -0500 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b1ffa05b64b69df" Archived-At: Subject: Re: [spring] Regd reserving block of colors values (draft-ietf-spring-segment-routing-policy) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 21:51:31 -0000 --0000000000004b1ffa05b64b69df Content-Type: text/plain; charset="UTF-8" Hi Ketan In the draft the SR policy defined on a headend source SR node (color,endpoint) tuple, the 32 bit color which defines the steering based on the AD protocol source origin PCEP, BGP, CLI. So the 32 bit color field could be numeric or ASCII field and is locally significant and seems to be no different that the name or numeric value that specifies a RSVP TE explicit path ID which is up to the operators to define based on their design. To me this should be left to local use by operators implementation of the design. Kind Regards Gyan On Fri, Dec 11, 2020 at 11:15 AM Ketan Talaulikar (ketant) wrote: > Hello All, > > We had the discussion, both on the list before the IETF 109 as well as > during the WG session at IETF 109, regarding some sort of an allocation or > reservation of a block/range of color values on the routers. This range may > be for either local use on the routers (i.e. not used for steering) or may be dedicated > for a controller to use (e.g. for SR Policies initiated/signalled via > controllers). There were different opinions expressed on this matter. > > Today the draft-ietf-spring-segment-routing-policy does not contain any > text on this aspect. It is left to the deployment design to manage the > color space as required. > > This email is to continue this discussion so we can arrive at a consensus > on this topic. > > Would appreciate feedback/inputs from the WG so we can address this open > comment and progress this important draft towards WGLC. > > Thanks, > Ketan > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000004b1ffa05b64b69df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ketan

In the draft the SR policy defined on a headend source SR node (color,en= dpoint) tuple, the 32 bit color which defines the steering based on the AD = protocol source origin PCEP, BGP, CLI. =C2=A0

So the 32 bit color field could be numeric or ASCII f= ield and is locally significant and seems to be no different that the name = or numeric value that specifies a RSVP TE explicit path ID which is up to t= he operators to define based on their design.

To me this should be left to local use by operators i= mplementation of the design.

Kind Regards=C2=A0

= Gyan

On Fri, Dec 11, 2020 at 11:15 AM Ketan Talaulikar (ketant) <ket= ant=3D40cisco.com@dmarc.ietf.= org> wrote:
Hello All,

We had the discussion, both on the list before the IETF 109 as well as duri= ng the WG session at IETF 109, regarding some sort of an allocation or rese= rvation of a block/range of color values on the routers. This range may be = for either
local use on the rout= ers (i.e. not used for steering) or may be dedicated for a controller to us= e (e.g. for SR Policies initiated/signalled via controllers). There were di= fferent opinions expressed on this matter.

Today the draft-ietf-spring-segment-routing-policy does not contain any tex= t on this aspect. It is left to the deployment design to manage the color s= pace as required.

This email is to continue this discussion so we can arrive at a consensus o= n this topic.

Would appreciate feedback/inputs from the WG so we can address this open co= mment and progress this important draft towards WGLC.

Thanks,
Ketan

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--0000000000004b1ffa05b64b69df-- From nobody Sat Dec 12 14:30:06 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C13A0D84; Sat, 12 Dec 2020 14:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 QrDv6UxqZW6R; Sat, 12 Dec 2020 14:30:01 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 BAC293A0D77; Sat, 12 Dec 2020 14:30:00 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id c12so9516495pfo.10; Sat, 12 Dec 2020 14:30:00 -0800 (PST) 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=gn1qetWFh/sTHoZhcb9siSWkD7rx0E2/dfDIvwjzoL0=; b=O6lU8VvyLK5ror/Y2wOvx0uM6J4uCDXecNSAUuVmpQkXNBT3chOnriUw6NZDcGeci9 wXxcCrecUwGPXcikcEnQ0Zt0ySA3V82by55sDdwSk3XuEjVntawIJvTaX88AKInlVs8o Gf9Naa21iv/fgz6uApa3Q2LRBXabcPrht90sqlvjShSR1Uo83QCm2rJVP3NED/p6lVgR Y3kL9C/tbKZ4Xv2MF4flWdUnuO2xZpFySct2yCE4ELBpwbmis/rsTioXiAUoYE1AJtp3 XaPZ7gWA8RmiehgmtJTtvS/jA5rcXYEiBaaQCc5CbhBiOPREPfvdW4/UZZ9YtRYbEJfn SJtA== 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=gn1qetWFh/sTHoZhcb9siSWkD7rx0E2/dfDIvwjzoL0=; b=gFC1KHnhCY3p38yCuFPraMsZNc5MRDbeFDUxmfF3G7A4+p8Nz/2+dMep1IGyU0mxab z9yMubDJhu7NZHY/UEyti+kSFaNX+SxeN/AIH+ibk7V8jQFIjju24nP2cjz5wIX6bSk8 Cr5Ivr0beY1knO5yW5g6NEhJev2fdx7ij7mM7CcQUGuLD2ka6OKKv9msP/dLm3+/uzbE x3GXHm9yc0qsr3pXEUUbu4RLc/2B+AZRn/B1aPx62hbAwNzMNwkQThPt8vcXEVkH/S59 zoPjX8njIoANii/diWgcbSCPVh8kGbzrO1hsUTn8lQsfnzR+riUl3+TLVyJyeEwevWUu NWZw== X-Gm-Message-State: AOAM530WFR+VeZxtvGu4H2/L7lYfvYWdf5y/Fa+DA4sk6yNXk8ezw5FH r7jL/S+ndXmBw1B5jvYs0bKYxSL4RYX9+Tsv1iM= X-Google-Smtp-Source: ABdhPJwqsoBOVjj2PNtfIhbfyLxQ5nxmd3PANKs97jAaUWfhNqvgzjtTDL9bgsXrcpq1M4rI4J7E/PfiqjA+FCzbsAA= X-Received: by 2002:aa7:9698:0:b029:19d:d63f:d2d2 with SMTP id f24-20020aa796980000b029019dd63fd2d2mr17690859pfk.4.1607812199949; Sat, 12 Dec 2020 14:29:59 -0800 (PST) MIME-Version: 1.0 References: <08c001d6b8d3$010d08d0$03271a70$@com> In-Reply-To: From: Gyan Mishra Date: Sat, 12 Dec 2020 17:29:39 -0500 Message-ID: To: "Darren Dukes (ddukes)" Cc: Greg Mirsky , Weiqiang Cheng , spring , "spring-chairs@ietf.org" , srcomp Content-Type: multipart/alternative; boundary="0000000000000b280b05b64bf300" Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 22:30:05 -0000 --0000000000000b280b05b64bf300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darren I had similar concerns as Greg has as to the requirements draft. Greg- sorry to but in hope you don=E2=80=99t mind.=F0=9F=98=80 Please see in-line below On Mon, Nov 30, 2020 at 12:00 PM Darren Dukes (ddukes) wrote: > Greg, thank you for your thoughtful analysis and comments. I=E2=80=99m r= eplying > on behalf of myself and not the entire design team. > > Please see inline [D] > > ------------------------------ > *From:* spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Sent:* Thursday, November 19, 2020 9:32 PM > *To:* Weiqiang Cheng > *Cc:* srcomp ; spring ; > spring-chairs@ietf.org > *Subject:* Re: [spring] FW: New Version Notification for > draft-srcompdt-spring-compression-requirement-00.txt > > > Hi Weiqiang, members of the DT, > > thank you for volunteering your time and expertise to this important for > the further development of the SR project. Please find my notes and > questions below: > > - my first question is on the intended scope of the document. As I can > understand from the title, abstract, the scope is "the requirements fo= r > solutions to compress SRv6 SID lists". When I compare that with what w= as in > the charter of the DT in the announcement by our chairs > > : > > ... the requirements for solutions to compressing segment routing > information for use over IPv6. > > Though the difference in texts might seems as small, the scopes they > identify differ significantly. To me, it seems as the scope of the draft = is > targeted to only one possible solution to provide SR over IPv6 > functionality, the SRH. Does the DT plan to expand the scope of the draft > to match it to its charter? > > [D] I believe this was answered in the working group meeting and > presentation by Weiqiang. Moving the text in A.1 back to the introductio= n > should make the goals of the document clear. > > - It appears that in order to qualify whether a proposed > compression method complies with the requirement in 3.1.2 an agreement= by > the WG on the benchmarking method is required because metrics listed, = in my > view, are platform-dependent. > > > - Though I can appreciate your consideration and using SHOULD in > requirement 3.1.3, I don't find it particularly important to be includ= ed in > the list. After all, it is a matter of the art of implementation. > > [D] Both 3.1.2 and 3.1.3 exist to allow for comparison of proposals > forwarding and state efficiency. They are intentionally non-prescriptive > stating that a =E2=80=9Cproposal SHOULD minimize=E2=80=9D state or resour= ces during > forwarding. They give the working group the ability to identify proposal= s > that significantly reduce efficiency. For example, a solution that reduc= es > header size by distributing per flow forwarding state to all nodes may > compress well, but at the expense of efficiency. > Gyan> My thoughts are thet forwarding and efficiencies as requirements is getting too deep into the weeds of the hardware NPU or FPGA ASIC either merchant or proprietary silicon and as each vendor has its own method of accomplishing the goal it=E2=80=99s up to the vendor implementation of the = solution to ensure the efficiency to make the solution viable. I think adding this requirement puts the cart before the horse so to speak and limits the design framework to think outside the box on a solution verses being boxed in from the getgo. > > - I think I cannot agree the SID summarization is the only viable > technique for the interdomain SR. Replacing MUST with SHOULD might be > reasonable, And preferably adding an informative text to describe > alternative methods to support the interdomain SR. > > [D] Aggregation or summarization is not the only technique for interdomai= n > SR. Binding SIDs are required in A.3, and there are other methods an > operator can use. The Rationale does describe one other option that > requires additional SIDs in a SID list. > However, the design team has heard from operators that summarization is a > very important part of SRv6 and their SRv6 deployment plans. They do not > want to lose this functionality for the sake of compression. > Gyan> As SRv6 uses the IPv6 data plane it is based on LPM (Longest prefix match) routing and not MPLS style =E2=80=9Cexact match=E2=80=9D for = FEC binding. So that being said the destination egress PE SR locator for final destination would be LPM routed to PSP node. So in the context of summarization the main point is summarization does not generally happen within the closed singe area or level SR domain as all egress PE final destination prefix sid host route is flooded domain wide, however with larger domains it could be broken up into areas or levels and LPM matching can happen to summarize final destination egress PE prefix sid prefixes. As Greg pointed out as far as summarization the main use case is for inter area where summarization would occur. That is precisely Greg=E2=80=99s context of rep= lacement of MUST with SHOULD. > > > - I think I understand the intention of the requirement in Section > 4.2.1 but I may propose expressing it differently: > > A path traversed using a list of compressed SIDs MUST always be the same > as the path traversed using the list of uncompressed SIDs if no compressi= on > was applied. > > > [D] This seems like reasonable text > Gyan> Agreed with Greg=E2=80=99s comment and updated text. > > > - I think that the use of MUST in requirement 5.1 is too strong. > Firstly, such compatibility is not essential in a greenfield scenario. > Secondly, the control plane based solution might be envisioned to > coordinate the interworking between SR domains using SRv6 and not usin= g the > SRv6 technique. > > [D] 5.1 describes a =E2=80=9Cships in the night=E2=80=9D deployment scena= rio, such that it > must be possible to have non-compressed SRv6 support on a node as well as > the compression solution. > > [D] I.e. the compression solution MUST make it possible for a node to > support the uncompressed control plane and data plane, as well as the > compressed control plane and data plane. It does not state that every nod= e > MUST support both at the same time. Given this, does your objection to MU= ST > still apply? > Gyan> I believe Greg=E2=80=99s is stating and I agree as well as the st= rong requirement hinders the development for when we are in the end state which would be green field or new deployments that don=E2=80=99t need the MUST ve= rbiage. If you have to account for the interoperability or backwards compatibility their is definitely more overhead that has to be met in the design solution and limits the scope of the design solution which should not be limited. Also their maybe other interworking tunneling or translation mechanisms that already exist today that can provide the interoperability without making interoperability or backwards compatibility a requirement. I think this unnecessarily complicates the possible solution scope of which we don=E2=80=99t want. Here is rewording of the first sentence. Option #1 =E2=80=9CThe compression proposal MUST support deployment in existing Brown= field SRv6 networks only and not Greenfield network deployments=E2=80=9D Option #2 =E2=80=9CThe compression proposal SHOULD support deployment on existing SRv= 6 networks. As existing networks will eventually all support SRv6 compression as nodes are upgraded prior to conversion to SRv6, the need for all nodes to require backwards compatibility will not always be necessary. Thank you Gyan > > > > And in the conclusion, once again, many thanks to all the members of the > Design Team for the job well done. > > Regards, > Greg > > On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng < > chengweiqiang@chinamobile.com> wrote: > > Hi Group, > As you know, the SPRING Working Group set up an SR compression design tea= m > prior to IETF108. > The design team is to produce (rough) consensus (of the DT) outputs to th= e > WG on two related topics: > 1) What are the requirements for solutions to compressing segment routing > information for use over IPv6; > 2) A comparison of proposed approaches to compressing segment routing > information for use over IPv6. > > With great effort of design team members, DT have finished the version -0= 0 > of the requirements document and have submitted it to datatracker. > > Please review it and let's know your comments. > > B.R. > Weiqiang Cheng > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-dr= afts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5 = 16:32 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang Chen= g > =E4=B8=BB=E9=A2=98: New Version Notification for > draft-srcompdt-spring-compression-requirement-00.txt > > > A new version of I-D, draft-srcompdt-spring-compression-requirement-00.tx= t > has been successfully submitted by Weiqiang Cheng and posted to the > IETF repository. > > Name: draft-srcompdt-spring-compression-requirement > Revision: 00 > Title: Compressed SRv6 SID List Requirements > Document date: 2020-10-30 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-00.txt > Status: > https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requir= ement/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > Htmlized: > https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement= -00 > > > Abstract: > This document specifies requirements for solutions to compress SRv6 > SID lists. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000000b280b05b64bf300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Darren=C2=A0
I had similar concerns as Greg has as to the requi= rements draft.

Greg- sor= ry to but in hope you don=E2=80=99t mind.=F0=9F=98=80

Please see in-line below=C2=A0

=
On Mon, No= v 30, 2020 at 12:00 PM Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> wrote:
<= /div>
Greg, thank you for your thoughtful analysis and comments.=C2=A0 I=E2=80=99= m replying on behalf of myself and not the entire design team.

Please see inline [D]

From: spr= ing <spring-bounces@ietf.org> on beha= lf of Greg Mirsky <gregimirsky@gmail.com>= ;
Sent: Thursday, November 19= , 2020 9:32 PM
To: Weiqiang Cheng <chengweiqiang@chinamobile.com>
Cc: srcomp <srcomp@ietf.org>; spring <spring@ietf.o= rg>; spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: Re: [spring] FW: N= ew Version Notification for draft-srcompdt-spring-compression-requirement-0= 0.txt
=C2=A0
Hi We= iqiang, members of the DT,
thank you for volunteering your time and expertise to this important f= or the further development of the SR project. Please find my notes and ques= tions below:
  • my first question is on the intended scope of the document. As I can un= derstand from the title, abstract, the scope is "the requirements for = solutions to compress SRv6 SID lists". When I compare that with what w= as in the charter of the DT in the announcement by our chairs:
=C2=A0... the requirements for solutions to compressing segment routin= g information for use over IPv6.
Though the difference in texts might seems as small, the scopes they i= dentify differ significantly. To me, it seems as the scope of the draft is = targeted to only one possible solution to provide SR over IPv6 functionalit= y, the SRH. Does the DT plan to expand the scope of the draft to match it to its charter?
[D] I believe this was answered in the working group meeting and prese= ntation by Weiqiang.=C2=A0 Moving the text in A.1 back to the introduction = should make the goals of the document clear.
  • It appears that in order to qualify whether a proposed compression=C2= =A0method complies with the requirement in 3.1.2 an agreement by the WG on = the benchmarking method is required because metrics listed, in my view, are= platform-dependent.
  • Though I can appreciate your consideration and using SHOULD in requirem= ent 3.1.3, I don't find it particularly important to be included in the= list. After all, it is a matter of the art of implementation.
[D] Both 3.1.2 and 3.1.3 exist to allow for comparison of proposals forward= ing and state efficiency.=C2=A0 They are intentionally non-prescriptive sta= ting that a =E2=80=9Cproposal SHOULD minimize=E2=80=9D state or resources d= uring forwarding.=C2=A0 They give the working group the ability to identify proposals that significantly reduce efficiency.=C2=A0 For exam= ple, a solution that reduces header size by distributing per flow forwardin= g state to all nodes may compress well, but at the expense of efficiency.

= =C2=A0 =C2=A0Gyan> My thoughts are thet forwarding and efficiencies as r= equirements is getting too deep into the weeds of the hardware NPU or FPGA = ASIC either merchant or proprietary silicon and as each vendor has its own = method of accomplishing the goal it=E2=80=99s up to the vendor implementati= on of the solution to ensure the efficiency to make the solution viable.=C2= =A0 I think adding this requirement puts the cart before the horse so to sp= eak and limits the design framework to think outside the box on a solution = verses being boxed in from the getgo.
  • I think I cannot agree the SID summarization is the only viable techniq= ue for the interdomain SR. Replacing MUST with SHOULD might be reasonable, = And preferably adding an informative text to describe alternative methods t= o support the interdomain SR.
[D] Aggregation or summarization is not the only technique for interdo= main SR.=C2=A0 Binding SIDs are required in A.3, and there are other method= s an operator can use.=C2=A0 The Rationale does describe one other option t= hat requires additional SIDs in a SID list.
However, the design team has heard from operators that summarization i= s a very important part of SRv6 and their SRv6 deployment plans. They do no= t want to lose this functionality for the sake of compression.
<= /div>

=C2=A0 =C2=A0 Gyan> As SRv6 uses the IPv6 data plane it is based on LPM= (Longest prefix match) routing and not MPLS style =E2=80=9Cexact match=E2= =80=9D for FEC binding.=C2=A0 So that being said the destination egress PE = SR locator for final destination would be LPM routed to PSP node.=C2=A0 So = in the context of summarization the main point is summarization does not ge= nerally happen within the closed singe area or level SR domain as all =C2= =A0 egress PE final destination prefix sid host route is flooded domain wid= e, however with larger domains it could be broken up into areas or levels = =C2=A0and LPM matching can happen to summarize final destination egress PE = prefix sid prefixes.=C2=A0 As Greg pointed out as far as summarization the = main use case is for inter area where summarization would occur.=C2=A0 That= is precisely Greg=E2=80=99s context of replacement of MUST with SHOULD.=C2= =A0

  • I think I understand the intention of the requirement in Section 4.2.1 = but I may propose expressing it differently:
A pat= h traversed using a list of compressed SIDs MUST always be the same as the = path traversed using the list of uncompressed SIDs if no compression was ap= plied.

[D] This seems like reasonable text

=C2=A0 =C2=A0Gyan> Agree= d with Greg=E2=80=99s comment and updated text.

  • I think that the use of MUST in requirement 5.1 is too strong. Firstly,= such compatibility is not essential in a greenfield scenario. Secondly, th= e control plane based solution might be envisioned to coordinate the interw= orking between SR domains using SRv6 and not using the SRv6 technique.
[D] 5.1 describes a =E2=80=9Cships in the night=E2=80=9D deployment scenari= o, such that it must be possible to have non-compressed SRv6 support on a n= ode as well as the compression solution.

[D] I.e. the compression solution MUST make it possible for a node to = support the uncompressed control plane and data plane, as well as the compr= essed control plane and data plane. It does not state that every node MUST = support both at the same time. Given this, does your objection to MUST still apply?

=C2=A0 =C2=A0 Gyan> I believe Greg=E2=80=99s is stating and I agree as= well as the strong requirement hinders the development for when we are in = the end state which would be green field or new deployments that don=E2=80= =99t need the MUST verbiage.=C2=A0 If you have to account for the interoper= ability or backwards compatibility their is definitely more overhead that h= as to be met in the design solution and limits the scope of the design solu= tion which should not be limited.=C2=A0 Also their maybe other interworking= tunneling or translation mechanisms that already exist today that can prov= ide the interoperability without making interoperability or backwards compa= tibility a requirement.=C2=A0 I think this unnecessarily complicates the po= ssible solution scope of which we don=E2=80=99t want.

Here is rewording of the first sentence.

Option #1=C2=A0
=E2=80=9CThe compression proposal MUST support deployment in exi= sting Brownfield SRv6 networks only and not Greenfield network deployments= =E2=80=9D=C2=A0

Option #= 2=C2=A0
=E2=80=9CThe compression proposal SHOULD sup= port deployment on existing SRv6 networks. =C2=A0
As existing networks will eventually all support = SRv6 compression as nodes are upgraded prior to conversion to SRv6, the nee= d for all nodes to require backwards compatibility will not always be neces= sary. =C2=A0=C2=A0

Thank= you=C2=A0

Gyan



And in the conclusion, once again, many thanks to all the members of the De= sign Team for the job well done.

Regards,
Greg

On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng <chengweiqiang@c= hinamobile.com> wrote:
Hi Group,
As you know, the SPRING Working Group set up an SR compression design team = prior to IETF108.
The design team is to produce (rough) consensus (of the DT) outputs to the = WG on two related topics:
1) What are the requirements for solutions to compressing segment routing i= nformation for use over IPv6;
2) A comparison of proposed approaches to compressing segment routing infor= mation for use over IPv6.

With great effort of design team members, DT have finished the version -00 = of the requirements document and have submitted it to datatracker.

Please review it and let's know your comments.

B.R.
Weiqiang Cheng


-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B411=E6=9C=882=E6=97=A5 16= :32
=E6=94=B6=E4=BB=B6=E4=BA=BA: Sander Steffann; SJM Steffann; Weiqiang Cheng<= br> =E4=B8=BB=E9=A2=98: New Version Notification for draft-srcompdt-spring-comp= ression-requirement-00.txt


A new version of I-D, draft-srcompdt-spring-compression-requirement-00.txt<= br> has been successfully submitted by Weiqiang Cheng and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-srcompdt-spring-compres= sion-requirement
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Compressed SRv6 SID List Requireme= nts
Document date:=C2=A0 2020-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requireme= nt-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-srcompdt-spring-= compression-requirement/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-srcompdt-spr= ing-compression-requirement
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-srcompdt-spring-compression-r= equirement-00


Abstract:
=C2=A0 =C2=A0This document specifies requirements for solutions to compress= SRv6
=C2=A0 =C2=A0SID lists.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat





_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--0000000000000b280b05b64bf300-- From nobody Tue Dec 15 09:35:27 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0263A1281; Tue, 15 Dec 2020 09:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_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 G5MGDRAt86yZ; Tue, 15 Dec 2020 09:35:20 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2117.outbound.protection.outlook.com [40.107.237.117]) (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 851CD3A127E; Tue, 15 Dec 2020 09:35:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YSuI6H43rXzO6xHTk7l/2Cu3EoLOdbnv8ZpsrDFU2oeAy7LgUTrwhbSXO4pd0KQfq/Y5JRlpDDRSql02FUhBGOlZGDtqopluxLsUyABMgtm1OBO2320TuTsJSRW8l6/dxivUPoJGTM/9k0SGpACa8PtyRRM3pHWSAeo7YyFj8m0PXaHVd7/4yLaVQAD06lMev8LplSSUQ8KkgcDIpjMd3RKTikfmwDnYh7fvupaaOHbURKGQ9znRNHyyeM8HWIBkQ/VJjUQx0YGa7tYAffK0ytQ+XoLzknrLCSr0UcYQwkBWZ5dT7KWcyTt1O3E47lx5BGrS7CJD32oLj+SaVmK3dg== 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=GJmTT/osqGa5ajj9RfyPkAXN6i/zR1Xf2CHgDBAv/FY=; b=l7HfN5WoNpZ/alTAGTWkDx7FdS53lTHO5Wj1HVLmejrCxQfvPdMfAJKrCG8W5XtQs8T5KVEToSB8sfr1TkQt5G3KMDSfh1YgEfIjUDEo6LXB9pf53uLMKlkg/ewuTdZeTjZcv4+S8TJwIullcIA1s0MnMiHGp8dDfmtIC9WXDWym6yNn9Q1vykhH+IjdEgqmN6ZvI3tDfuJkKsVA8Q9Z9RWFiqbMRzDOGIK/QIcF2r1Y36RVqO9eYROZj1cGzzI9sb1YWLQA9d09QA3OtTYTpezLUlL7+CajDWttn833LzaR0DBeSWpYhQvN2tw6hb5F8QDAwXGPxlFZLl/8ggrNMw== 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=GJmTT/osqGa5ajj9RfyPkAXN6i/zR1Xf2CHgDBAv/FY=; b=LA+f5F00VQ8bSEUj9GBCoebbCG0UDsxXH2PnQPsq8HiEwdvvfvhSOtYkyWQ76V7CA9b927jzsD/H6mhLQI2v54cpggsCW1AUdBRkLUqyrk7zMyq99j6dbUhZRk/XJ4Y50faPOq/awT6wx0oLSMKpeuFIXjtd+Jg+dBaj8GD4l3c= Received: from DM6PR13MB2762.namprd13.prod.outlook.com (2603:10b6:5:13c::13) by DM6PR13MB3626.namprd13.prod.outlook.com (2603:10b6:5:24b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.18; Tue, 15 Dec 2020 17:35:17 +0000 Received: from DM6PR13MB2762.namprd13.prod.outlook.com ([fe80::5122:27c3:690f:afdf]) by DM6PR13MB2762.namprd13.prod.outlook.com ([fe80::5122:27c3:690f:afdf%3]) with mapi id 15.20.3676.015; Tue, 15 Dec 2020 17:35:17 +0000 From: Haoyu Song To: "spring@ietf.org" , 6man <6man@ietf.org> Thread-Topic: SRv6 active In-band measurement using IOAM Thread-Index: AdbTB1EhuodI7nG0QZObO1K7vuDdyA== Date: Tue, 15 Dec 2020 17:35:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2600:1700:38c4:650:d820:707:8caa:10b6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ea4b2ef-755f-4b4b-ea83-08d8a11fc9d3 x-ms-traffictypediagnostic: DM6PR13MB3626: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EsAwL5XySz0GipzOXMl4wmGA2nAB6S5mL04LnBJhkPSmyhKCsVMUYfbcBE3LWskHMv0CbU88TS94ze3MpiHrz1ELhtXJeAvKelMAesgL3dC1LbOCkirmgQ3Zd+Cpp5NwyQIjtvzk308/VzVZ1gVMVr6N9Po/6bO4be/PSyIMl5lsjngUG2o6OT4sjozADQEjeg5LjC53/WyF3/cWbS+F5bDlnorvxJFfXQuH9ciw2MP2+N4Y7nUupUWK7RP1xdVPSi4G5E0N+kDJnW+uny69JboBii6Q/9BLCnF+OJ6Y9P6ztJGEJSzNefWADpqiuFegmj4LwsMqVVV5G19zQxgl85QiNKFZRHf2X9jZ1k2GIVaCWha2/4kFQ0MTPTufGD6eMx7Bl1XtjisxDJV2FHRXRdUgBUFr7jM5hryNGhLypdOcAEk1RaImhHlGvgmXiNLL8gBzEjU9L2BNils99ASLyg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB2762.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(39840400004)(136003)(346002)(376002)(86362001)(8936002)(52536014)(66556008)(9686003)(33656002)(2906002)(71200400001)(166002)(186003)(83380400001)(8676002)(55016002)(44832011)(6506007)(5660300002)(450100002)(478600001)(7696005)(316002)(66946007)(66476007)(66446008)(966005)(110136005)(64756008)(4744005)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?UcivQbZ/bsAFQ8D8Nqd5kKuq23nO3tIDnYeT5kmHaSW4i7VVu7AoTVyh/NsX?= =?us-ascii?Q?n/XfAw4hA9C3nZ1j3LdgX/4x1uPRYxaYgutAT7H/6Dxkij0GF8dbgvZFhD4C?= =?us-ascii?Q?118/boUT1lXuzMrbY0IFDqed4WtxCpGVc1ll2RTM9D/UopgFeSAQ3zPPuRir?= =?us-ascii?Q?b9+l/rBa6g2s5r19txpqXLSrkHMxb6pXiCDvVPiiIaTJqde/XUDV0mdbE+u/?= =?us-ascii?Q?a+1u0VW6qgK/vxH7wa/7zynsNh1cYHvUgHZWFoMB1c4rHZXROXyF32yGVGKm?= =?us-ascii?Q?A20/ZuTkarNw56aernCUnfaF5lxqG06uRqwncDO6tFiTPB1jo90XhPvWlmDR?= =?us-ascii?Q?m8czApuoMhA3qKlfwYCeP/GSj+PwU6h8HmL9j8LppYmxti/+9v2Eod4hI8/t?= =?us-ascii?Q?Qo4ZgnTpU+rvLwOq6HYwGXgy+v/izp4ksY+XN4GLpqbZODLfgUkjdGQFh8tR?= =?us-ascii?Q?fpYibt8QpyNK8KwCj2POJlZF2yj40HfVXhMYkoNl20+cRm4cEVTfYj14I7v6?= =?us-ascii?Q?MA994NZyoYlvZ6LPQDeaEU4oH/sIuNkl7u3vUXlFcP35jinAKtzgEk6MnK4c?= =?us-ascii?Q?xd3b8bRwwnPFynnsn/+SA0TOrfP0I4S4XbctcVD6WbJ070xNjzh2/ygGWnlK?= =?us-ascii?Q?8YNm8h1bGUF7ZAUDvdrl2HEP/UJGrALzS0qYKJYhTNJ9xdslC6V7qhWWhfcX?= =?us-ascii?Q?RfUwo5NwqIcsk4ykMg3kugDCbtMOxltaWlAHHurrzIbJWT8OXijWk7Z4afGs?= =?us-ascii?Q?CDD6MRhZ9FiuH1H6iHo1mdKbNPASLF5mnCRazPxN6aw9rbtbWUzHZ3bQ0PuL?= =?us-ascii?Q?gPqp+Z4LUZmzFK0QCMfcqqGjkyrwKEO69NgyI5tTuuyl4Ed7tRK+FBfAh6yc?= =?us-ascii?Q?ZpMVQhqdAMu59GCVrzxhxbAswE40ENDavPqU7pQKA95vwpvo2HJDIAIj6+Uh?= =?us-ascii?Q?BpbMx/MCbfs80MZqDjpzWY38NGhVggecxZ2UWYyHhtfkVOP6tY1xBgiihErJ?= =?us-ascii?Q?Bf/en5VZCZhgcbzH7/jbnf/xCqJqt5gly5HpwfkMtL24i58=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR13MB276202B412EB94A056BDA9E39AC60DM6PR13MB2762namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB2762.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ea4b2ef-755f-4b4b-ea83-08d8a11fc9d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 17:35:17.4352 (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: IZXZZ5OU7KvFZhMo67yVPDHD1FZNO8oiWDObTJWsYyqHpcy3ReQj+5M+Aflqe/NwRY+cY5IBU3TMIkIeUQ+yEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3626 Archived-At: Subject: [spring] SRv6 active In-band measurement using IOAM X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 17:35:22 -0000 --_000_DM6PR13MB276202B412EB94A056BDA9E39AC60DM6PR13MB2762namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We just published the following draft which describes a method to support S= Rv6 in-band measurement using IOAM. draft-song-spring-siam-00 - SRv6 In-situ Active Measurement (ietf.org) It achieves the same goal as IOAM but avoid the issues concerning the encap= sulation and overhead. Moreover, it can be used for several other interesting applications as summ= arized in our draft. One of them is detailed in the following draft: https://datatracker.ietf.org/doc/draft-tian-bupt-inwt-mechanism-policy/ We believe the proposed method is simple and practical. You are welcome to = provide comments, suggestions, and questions. Thank you very much! Best, Haoyu --_000_DM6PR13MB276202B412EB94A056BDA9E39AC60DM6PR13MB2762namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_DM6PR13MB276202B412EB94A056BDA9E39AC60DM6PR13MB2762namp_-- From nobody Wed Dec 16 05:37:00 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D41FA3A0B1F; Wed, 16 Dec 2020 05:36:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160812581785.21110.7220640486925863317@ietfa.amsl.com> Date: Wed, 16 Dec 2020 05:36:57 -0800 Archived-At: Subject: [spring] The SPRING WG has placed draft-gandhi-spring-twamp-srpm in state "Waiting for WG Chair Go-Ahead" X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 13:36:58 -0000 The SPRING WG has placed draft-gandhi-spring-twamp-srpm in state Waiting for WG Chair Go-Ahead (entered by Jim Guichard) The document is available at https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/ Comment: The WG adoption calls have completed for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 and https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. Although there was enough support for adoption indicated on the mailing list, the chairs have decided not to adopt these documents into the SPRING WG at this time. This decision was driven by the current status of two companion documents in the IPPM WG that describe the necessary extensions in support of the SPRING documents. These documents are https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 and https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. Adoption into the IPPM WG was not successful at this time as the IPPM chairs believe they need to be further refined and are currently discussing further steps with the authors of those documents (see https://mailarchive.ietf.org/arch/msg/ippm/mACgnxbYy64FK9RCoq_8GhxdfPw/). Until the work by the IPPM chairs and authors has been completed, and successful adoption of the documents in that WG completed, the SPRING chairs would like to wait on adoption of the SPRING documents, and ask that the authors keep us informed of the status so that action can be taken at the appropriate time. From nobody Wed Dec 16 05:37:04 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D263A0E50; Wed, 16 Dec 2020 05:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_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 4yr7SDv6s6vb; Wed, 16 Dec 2020 05:36:57 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2095.outbound.protection.outlook.com [40.107.243.95]) (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 762A53A0DBE; Wed, 16 Dec 2020 05:36:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mplhpZh5b8B81vCDYkqPTsTKXFe0j0CD+Xy/3gIIXLYFzcFGPtWiEnzhqgtGv5NswG/rKgyJXeucm9U+N1IMC6djhGtPfKEN4TizweaEwlcjXCM7TWK+c8vvRhz2hMNTfQR/0PHCJkxEqJfMH5FnCWjhnDVwgXYLGSg/9wgrBm5u1A4su1ZRiGjDVUwHeSQdEYepyaCWFSBhJPg1wjCeFzsGxEMkknNc5WGnCGnTveqQP8dg031r7AhjGAjFh7I00iaegz5Zf0tV2VlCSuiK0WN6kTWGdTDLhYQ5opuFBj7uLidTrH1Em/JrQsxCQ+eZbXBl6Rx+uVMO34QT4oo1Dw== 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=aV2cXzaIcVlaGyxV5eyePfZQG/wiJd+jONS2a53uo5g=; b=i2iiEUPmZd4gOhrFU6OM9VC/WQD17BCuUgNJ9OlQbYuCYDQLyxzCA5On/Vzpj6Rd4kUINZBCcqlEcnSdDrYCtcHSXEOln3R3KbQgZ6wRnx4Jjvzot4Mi3Ta6z8LzTVAYp4bcB0dlGU7DSoJvii5h54y3yDBymzv0kcOmUGywZwrWgD2YfPZPeyaA6jl/fcOONGOFDmDAcYgblUnqfYzgybMtpbOJLEzh4LHLkK7mxvojrb2TmDoDDPHsOMTcsymWx3Xl9ErVDsIPDNnxwYuYKQ4FMDLAa2rPtvd8lHtFUxlU35cl6Yu2DRDldmjuGEhRDRW4k8gV9RWYXNAaQTFPXw== 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=aV2cXzaIcVlaGyxV5eyePfZQG/wiJd+jONS2a53uo5g=; b=dH2MwDZ9ZjE5qil7xgxibZFD4fIt+2C5iALBufpZyngOyq9xFs21EbbIU93m1myJz7dqVjy6YE+EOGBGRJxuqMET628qzJcfMkfzO/nCbTsEokcOnH1btVFzF0vLR14GPiuVWS1nKiF8rAeyn8FDI34u81+gbhrBnguqE5XZXPU= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by BL0PR13MB4546.namprd13.prod.outlook.com (2603:10b6:208:1c6::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.9; Wed, 16 Dec 2020 13:36:52 +0000 Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::2c12:7610:af63:f0f6]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::2c12:7610:af63:f0f6%3]) with mapi id 15.20.3676.013; Wed, 16 Dec 2020 13:36:52 +0000 From: James Guichard To: "spring@ietf.org" CC: "spring-chairs@ietf.org" , "ippm-chairs@ietf.org" Thread-Topic: WG Adoption Calls for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 and https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 Thread-Index: AdbTsCtUHcr8jmweTl66HBvbW1dYrQ== Date: Wed, 16 Dec 2020 13:36:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2600:6c64:497f:d3ca:39ca:73a:a4f3:975d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 890f865a-3a12-4435-1e32-08d8a1c7a5ce x-ms-traffictypediagnostic: BL0PR13MB4546: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5CoGJwOn4Rx5WI2HTzo9y/zXCNQHWADeY8c3YMaZUsLQUUM6OXvpsd8GJ/jE1Hv72aHWJfJT3S5RAqdf2BUssiK/mX1KPhA1asRAkt+FSpVGZCtjh1E4zw9haVfK/ywsa4Ol2d3X6YrRPSAjDZRoPmvr8+e0D88kG4e2jYApqZzdPjlvJZP1vHTStUniWcMRsE+aB6pB3o7Tu8VCHVaghEVKk4SymQ8I0F0Qgp+bW2zIWemwwFsnU5rcUy/0rlr07ZX92FWYJ7ny/CAxDPbUOGoNJ3hfzrHgMJRC4EoVySPw9gRIjEhYivFaufJoNAYTVN+b1pH61BX3Oh+4naAOUpsYviGRwoJwoDise3lRJldhYkdrZQOg9x7pzWg1A5E9Fp76SxOL+E72mvxw2gWFp/Zp9G6cjFK4nz/+ki1Qt+xyGgC0Y0HDXRWRDTc92D5Q x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4206.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39840400004)(376002)(136003)(366004)(396003)(9686003)(86362001)(76116006)(8676002)(8936002)(5660300002)(54906003)(66446008)(6506007)(64756008)(55016002)(33656002)(71200400001)(478600001)(66556008)(186003)(66946007)(66476007)(966005)(6916009)(450100002)(4326008)(7696005)(166002)(52536014)(316002)(2906002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ESAsMRRZg/zJh6wwVZVyLaFxy07a1VFysCcZ9w/3EPaRIR3cBzW8zQyJx1Jf?= =?us-ascii?Q?5aotmHrGTf2OGkwpw8xnSsSj4zOdnfEztvsA5J7rH3Zo0qkBwWyrq4GE0lJB?= =?us-ascii?Q?F7fSlMQi3LPjVrWG5X5mOwqD7EwwhECShh8IGKj3SwNnXfXL95N0zW9mEHtD?= =?us-ascii?Q?zVZE3JQgLfYyEvny4YNIXPGMRnBfBpIJxwMqt1pnBQLNmHSU/MebvujMe3Yv?= =?us-ascii?Q?L7Pm8wnNW32C/vLx9Fx92ILa1L9jXm5mg1mwCAFZnR0WBm29sB7LZ+E6NXzL?= =?us-ascii?Q?GxAhglU8FlECV5dvQptuDJnAsqTuy93JCfe9GsIEIDqNwBGBWQJpZWI+znAZ?= =?us-ascii?Q?5mOinJ39hlOjZJw6q66uhstTnz7vkId83iE6AX/7Y0FeHrzwg51SlPLCBWBO?= =?us-ascii?Q?ph1G0c/0ljjUaNA2MSctA7PEnvdSIfYL/p+yrQRya4ACwM6pWlq2NdF8xDlx?= =?us-ascii?Q?cwxAqeXhMcELdZ5neo6EHpAWrnqQFDuFfH//1a0upAp2LmbUUJLuKHmZCdU1?= =?us-ascii?Q?oLwTUhstkkNtjkc+VBDfrODak872LthTqebosPI6NY0/ASeLRaQW1vD+4cLz?= =?us-ascii?Q?XeLzshQQCN5cD/27d2CVhNLlWJJPRrp5uso98lkWjGsV9QifbVwnsAPXHppX?= =?us-ascii?Q?wALJj9zDXac5DaXCXfId2e3ADYuM1S94J30sTkX9OXPm2KQ4moq0dgCaCW+E?= =?us-ascii?Q?kE+xsLPjYnbpATvsi39JnbVRCb67bRk+fg2jI9YNxwdWeCP7SnZHWoK8mf+b?= =?us-ascii?Q?fbR9cPKVQ0LIE/flpe4btdzbNB/X1FGzDnweNmyEqsqjdyPLqgGY2ShMYMu8?= =?us-ascii?Q?EeswwPcd0ciYjQTHuN+Bnzvt6Tkbr9Pull4c0qn7RzmmCWUwOJN+lJLm9Maa?= =?us-ascii?Q?eJBnNh+LNkDg8Jzt0TUSVRSIfwXHbWhRSbQxmyaEGoVCCbGt0omPa2igFFgi?= =?us-ascii?Q?T2gPazunknRV3wrEjmWkX6a7r6a5CtKl5USLgdU9PeLq2CggdCOLhjAGBAnr?= =?us-ascii?Q?oriywTqh7ZAFB9BdqHRMkjKY5SQkGPlAZWBu1N9GuegAQKI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB4206293B8A1287211781BFCED2C50MN2PR13MB4206namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4206.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 890f865a-3a12-4435-1e32-08d8a1c7a5ce X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 13:36:52.4658 (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: 9hr7/SrNzu+guOgtWJt35o6iY+4LSeUwLqFSq5A1CqBV/XoWQfuX6aS58ei6TEMP6iOFcwG/TMEmE7nhG+yzOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR13MB4546 Archived-At: Subject: [spring] WG Adoption Calls for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 and https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 13:36:59 -0000 --_000_MN2PR13MB4206293B8A1287211781BFCED2C50MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG & Authors, The WG adoption calls have completed for https://tools.ietf.org/html/draft-= gandhi-spring-twamp-srpm-11 and https://tools.ietf.org/html/draft-gandhi-sp= ring-stamp-srpm-03. Although there was enough support for adoption indicate= d on the mailing list, the chairs have decided not to adopt these documents= into the SPRING WG at this time. This decision was driven by the current status of two companion documents i= n the IPPM WG that describe the necessary extensions in support of the SPRI= NG documents. These documents are https://tools.ietf.org/html/draft-gandhi-= ippm-stamp-srpm-00 and https://tools.ietf.org/html/draft-gandhi-ippm-twamp-= srpm-00. Adoption into the IPPM WG was not successful at this time as the = IPPM chairs believe they need to be further refined and are currently discu= ssing further steps with the authors of those documents (see https://mailar= chive.ietf.org/arch/msg/ippm/mACgnxbYy64FK9RCoq_8GhxdfPw/). Until the work = by the IPPM chairs and authors has been completed, and successful adoption = of the documents in that WG obtained, the SPRING chairs would like to wait = on adoption of the SPRING documents, and ask that the authors keep us infor= med of the status so that action can be taken at the appropriate time. Thanks! Jim, Joel & Bruno --_000_MN2PR13MB4206293B8A1287211781BFCED2C50MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG & Authors,

 

The WG adoption calls have completed for https://tools.ietf.org/html/draft-gandhi-spri= ng-twamp-srpm-11 and <= span style=3D"color:#0563C1">https://tools.ietf.org/html/draft-gandhi-sprin= g-stamp-srpm-03. Although there was enough support for adoption = indicated on the mailing list, the chairs have decided not to adopt these documents into the SPRING WG at this time.=

 

This decision was driven by the current status of tw= o companion documents in the IPPM WG that describe the necessary extensions= in support of the SPRING documents. These documents are https://tools.ietf.org/html/draft-gandhi-ippm-st= amp-srpm-00 and https://tools.ietf.org/html/draft-gandhi-ippm-tw= amp-srpm-00.  Adoption into the IPPM WG was not successful = at this time as the IPPM chairs believe they need to be further refined and are currently discussing further steps with= the authors of those documents (see https://mailarc= hive.ietf.org/arch/msg/ippm/mACgnxbYy64FK9RCoq_8GhxdfPw/). Until= the work by the IPPM chairs and authors has been completed, and successful adoption of the documents in that WG ob= tained, the SPRING chairs would like to wait on adoption of the SPRING docu= ments, and ask that the authors keep us informed of the status so that acti= on can be taken at the appropriate time.

 

Thanks!

 

Jim, Joel & Bruno

 

 

 

--_000_MN2PR13MB4206293B8A1287211781BFCED2C50MN2PR13MB4206namp_-- From nobody Wed Dec 16 05:37:33 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC313A0D65; Wed, 16 Dec 2020 05:37:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160812585162.18246.273103992432862083@ietfa.amsl.com> Date: Wed, 16 Dec 2020 05:37:31 -0800 Archived-At: Subject: [spring] The SPRING WG has placed draft-gandhi-spring-stamp-srpm in state "Waiting for WG Chair Go-Ahead" X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 13:37:32 -0000 The SPRING WG has placed draft-gandhi-spring-stamp-srpm in state Waiting for WG Chair Go-Ahead (entered by Jim Guichard) The document is available at https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/ Comment: The WG adoption calls have completed for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 and https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03. Although there was enough support for adoption indicated on the mailing list, the chairs have decided not to adopt these documents into the SPRING WG at this time. This decision was driven by the current status of two companion documents in the IPPM WG that describe the necessary extensions in support of the SPRING documents. These documents are https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 and https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00. Adoption into the IPPM WG was not successful at this time as the IPPM chairs believe they need to be further refined and are currently discussing further steps with the authors of those documents (see https://mailarchive.ietf.org/arch/msg/ippm/mACgnxbYy64FK9RCoq_8GhxdfPw/). Until the work by the IPPM chairs and authors has been completed, and successful adoption of the documents in that WG completed, the SPRING chairs would like to wait on adoption of the SPRING documents, and ask that the authors keep us informed of the status so that action can be taken at the appropriate time. From nobody Fri Dec 18 02:54:44 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61DA3A122C; Fri, 18 Dec 2020 02:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=d1d52NjB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Vkzeoijm 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 YcyG-vwFvSZK; Fri, 18 Dec 2020 02:54:38 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8803A122B; Fri, 18 Dec 2020 02:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26520; q=dns/txt; s=iport; t=1608288878; x=1609498478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BvvkYyfzBOZFwIDPKovDflOXgMm1QfQeDUHWTY1UPn4=; b=d1d52NjByruG25szCeLn8clHfCK8RWBulzOu273eXf2jlV17kLmypMvY U62fZSCKlUS8HmJ8rQXzhuYd+ocavCGCTOKMJ0Qd8GLAhnOwysxkgEahT +Ext68E5nxKbzXdnj3lXQrlEMBhaNLP5Kpc8qpf3jA2M0sfkDS9AWGmBE g=; X-IPAS-Result: =?us-ascii?q?A0A7AAAEyttfmIcNJK1YCg4MAQEBAQEBAQEBAQMBAQEBE?= =?us-ascii?q?gEBAQECAgEBAQFAgU+BUiMufFsvGBYKhDWDSAONXAOPDIoAgUKBEQNUCAMBA?= =?us-ascii?q?QENAQElCAIEAQGESgIXgVwCJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBA?= =?us-ascii?q?QEBAQGGNgyFcgEBAQQSEREMAQE3AQsEAgEIEQQBAQMCFQIIBwICAjAVCAgCB?= =?us-ascii?q?AENBQgagwQBglUDLgEOon8CgTyIEQVTdoEygwQBAQWBNwIOQYMsGIIQAwY3V?= =?us-ascii?q?yqCdYN6gkSCeHomG4FBP4ERQ4JWPoJdAQEBAQEBgSYBAQYFBgEHHAUxAiUCg?= =?us-ascii?q?jYzgiyBWRAaPgcBBFoBAx0FDQIKFgIEKhcKIwwBBRIpCAINBAsUBQIECwETB?= =?us-ascii?q?QUBGAIWCY8VEhKCbD6HUpwsgQ8KgnSJI4YhhXl2hTqDJjqJbZRxlAeLDZEmE?= =?us-ascii?q?hYEDg2EMAIEAgQFAg4BAQWBbSFpWBEHcBU7gmlQFwINjiEMDgkUgzqFFIUEQ?= =?us-ascii?q?HQCAQEzAgYBCQEBAwl8QIh5AQEFIQeBBgGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AV4+GvRbEtrGXAEzF0i7Qlor/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD47a8PlDzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX1ZkbZpTu56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,430,1599523200"; d="scan'208";a="635985627" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Dec 2020 10:54:37 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BIAsaqI022910 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Dec 2020 10:54:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Dec 2020 04:54:36 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Dec 2020 05:54:34 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 18 Dec 2020 04:54:34 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bTXTydQSrv10eMbP03dhPxYKyaI+8h8e1V8Tzoq2eBX34xmZbNUtY40nih/0PW5ee32GNlPGsf3FD9VJzc0tn5lhRLhZ+fdmHFqAi5DE+cT0xEaCtovEbxaWUd31KsGJL3wEJa3yQ+lQFZZd4S48vVphlNOdMz8jm49xUbK0M6habj/sDOz4deB4Ys9lCKbPa1JKFoLAOC5XNWHXSmgFB4I6sP9EJNqlQbW8WOsTXedjvYW7K5+hVhPS0VSXw0oJqhmuOKZ2+V1suvFct5vmJppieOdWnE4yI5N4WNYCzWq1RTWM/4wSNxZg4zvnLuAtUI0pBmzRF9KvMgy6JLwrOQ== 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=BvvkYyfzBOZFwIDPKovDflOXgMm1QfQeDUHWTY1UPn4=; b=KXMSoG6mv1/o70138nNC6MRi/BxJprURO3EJLEy8sztK3qdAFhpernZz7mZIdxxQ73yefpYuVeUGT4iMEVieSg3wJp39YDW2ZlihqtzTv1WPfAe1q1/4p6RiJCyu5FxhFfUQY3XgR65NLaD99rcMZBsmofAnRwJzFADjrpGIP6U/U927KeHfMPJ9+98I31dcVEwg4xiTMf4H0rCdnNZohTKaWP22OHAQA24GlT7ToOIezzcddEqK8zdRdJNteFoWNgrDa9hnFWl9Oqek8mhRwXePacfEA/jSdmhk0IY++Q6uYMac+qr8DlERi9a7kUJSC+ke+KIC+UMYorhMokufHw== 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=BvvkYyfzBOZFwIDPKovDflOXgMm1QfQeDUHWTY1UPn4=; b=VkzeoijmHkDiJCwMHs1TmbHXzW6A6LMNOlxWau5psajnk3rdnlvN6NYQ3opdHiBYi3ZENB10eG4Rh6hyhKBwQxkGpxkifylBV7JhDvQrEX88uuy8VLvviBbR84JCWclGxzsHORk87Yb8SOteBYHRjvG5IKc7PDWD0M3dWOIm7XE= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SA2PR11MB5017.namprd11.prod.outlook.com (2603:10b6:806:11e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.19; Fri, 18 Dec 2020 10:54:33 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d%4]) with mapi id 15.20.3676.025; Fri, 18 Dec 2020 10:54:33 +0000 From: "Pablo Camarillo (pcamaril)" To: "Pablo Camarillo (pcamaril)" , Benjamin Kaduk , The IESG CC: "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) Thread-Index: AQHWzk11hJlsON8AwUKTQpqAtVRetqnweUEwgAwpHjA= Date: Fri, 18 Dec 2020 10:54:33 +0000 Message-ID: References: <160753350153.28997.1345859562639063746@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.38] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8985a927-848e-4d04-ddb5-08d8a3434dcb x-ms-traffictypediagnostic: SA2PR11MB5017: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H+J2dx5ghJdcd2HJAhbviphrm5/CgVxQXFIaQC73xVY2uxa1+LfvFnHnu8iw/2pTsM+1ZCJRr24PjN/HlU4hGjwhJsPXVweacyHvQ8HMWf+NCoMEhrb7r6ZrdU31yVp0hXGTUwefIeDp89CoCrJBTG99GZcsZw9IpX1w7fYSIdK7AI1NeZuRpu9VoDCfiMYyX70pXjMWIMl62WpyCfAK+Ty2EpPhBEPqTwU0WEtRrjPuoBEOsDQgLlWm02JmNNf1AgwX6QZjK0lyUTu685xsAujE/SyADDq57qEoKVPKrrzm12YqJKGlSli19TDD5nTofc0sEsbmTBKEWmpglranLIbjV0H0M9ziP1DpGkcUpiET+FSypMwTgoJqtanQ8snbet2cZx+M20nuU5omHrHe1Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(396003)(376002)(136003)(346002)(110136005)(186003)(86362001)(4326008)(8676002)(83380400001)(5660300002)(76116006)(66446008)(8936002)(2906002)(52536014)(26005)(966005)(64756008)(66476007)(71200400001)(478600001)(66556008)(66946007)(30864003)(33656002)(7696005)(66574015)(54906003)(9686003)(6506007)(55016002)(316002)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?K2V3Z05TOW9jZThJcDRyandia1lMNFdmQUZwYnkzM0gzMmNTRzNLVkd3NjVt?= =?utf-8?B?b3UxallZcEIvanhETUJBdmdYR1RiRlNiaHV3bUlNcmdyL25KdnhMTGluQmNl?= =?utf-8?B?M3VJZEFPYXlCemJzVTFhNzNhTkt5MHJ2ZjdWdDQ2WW93RTRQTStWbnEvQnRz?= =?utf-8?B?dGxsL2ZuaXhSbklQRXVON1kwd1ZadENjS3lwOENhSGlBUmZ2OTlSSWJ3YU52?= =?utf-8?B?b3pGczlRdE54WGxBSHhEeHdBbnBlUVdpOUZPRnhlTFcranVBekFHbVRiM0Ir?= =?utf-8?B?UHpTWU5WSHFXSGV3UGRJVmRpaFBmZjdQR0QzVFNjTnFEYlZ4aHBobVBHa3VG?= =?utf-8?B?Q1lLc2xoaHVqeUJMN1FmQ2MyekhWYW52bGVsYlhRL25wbjMwS1A1WDYzZ2hT?= =?utf-8?B?RWpQdm45dlhmcDQ0ejZTd2F5elZSRWtPTEpwNm1jSElRakRyUE5ZY0QwMTR0?= =?utf-8?B?c3R3S0xkQmFURi9jTTRZY2RNR095SGJlMmI0cVNUODN1WFRKa0cvbm4wMU4v?= =?utf-8?B?WVczZU55QURYS1JITjBwQTZ3YURVbW9IejUxdmV4bEsrZXcwUU1oNXQ0Y2tF?= =?utf-8?B?NWNHckJ0UGRhSWxBWEFGWW1ZalhUdFoydUVxUmh1MklsWmZyeW54ejR5YkZ0?= =?utf-8?B?cDBZTEdIZnhDYU5FL0VmWkxKS25kdDE1WmNtd1o3eEhuN0hMb3Byb1d6SThx?= =?utf-8?B?ZkZBRVNKVEY2b1VZR1FvbllrNkZkbTZXT2ZVVnZneFFwVDZvZVlZeXF6bSs5?= =?utf-8?B?c3I2TVhvT2xSNVZYQ3V3NVpKaUpDZWxrWTNGTit3NkVKZXR1eUs0QmZoWnk5?= =?utf-8?B?eFoxV1ltVW90V3FaRlk1OXhTejc4SnJHaFUzT3VjUGQyTjZxY202VkpNWXg0?= =?utf-8?B?cFJGZlVsUmFqcVptSTRTcGdlVVZhZnV1ZDNxbGtkeFZOTnc1cUN1U1F6aFJG?= =?utf-8?B?NVhZc01rWjU5VStPYzJsZnNjQXZEVUpadnZtcEVVRzIvQVh2ZHY1MHF5QUpT?= =?utf-8?B?bjNoaGdWUCtWbDc2VXQzei8zK0dWMU5CQi9EdWZIUjF1Vkp0ZDlEQ3dIRzhl?= =?utf-8?B?WmRBc1ZjVm95aDRqYWZJS1RhZEN6U1ZQUGZra29McU4rUy93QzlzMUcxbHBY?= =?utf-8?B?YzlsYWN2Lzg3OWVqVUZ0cWJsV1htQ3NzQlFNYm5hYStFeGJUNU14VC83NDdX?= =?utf-8?B?K2V0dW1mampsMlltSnlBNkkyUVBRRElOME5IQ2I2QlFGTi9nVGxPVHQzU0VH?= =?utf-8?B?ZkhWVUp6bmdvSnlQNktUREhvWStTTTJYVll3d3NLZHRoMTZiMXJWOGtVaVlH?= =?utf-8?Q?iMfa7WAJ153K8=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8985a927-848e-4d04-ddb5-08d8a3434dcb X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2020 10:54:33.5321 (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: +EPf1BAxSlRcaQKFyK4ZaiD7nyLAqpKHz7s14lXq2xmLO3Kkf6tIMxzuE8ZyevECWQMwS+szkPylCLXa/tu+KA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB5017 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 10:54:42 -0000 SGkgQmVuLA0KDQpJIGtub3cgaXTigJlzIGEgYnVzeSB0aW1lIG9mIHRoZSB5ZWFyLCBidXQgSSdt IGhvcGVmdWwgZm9yIGFuIGVhcmx5IENocmlzdG1hcyBwcmVzZW50IHJlcGx5LiA7LSkNCldoZW5l dmVyIHlvdSBoYXZlIHNvbWUgdGltZSwgY2FuIHlvdSBwbGVhc2UgdmVyaWZ5IHdoZXRoZXIgdGhl IHJldjI3IChwb3N0ZWQgb25lIHdlZWsgYWdvKSBhZGRyZXNzZXMgeW91ciBsYXN0IERJU0NVU1Mg cG9pbnQ/IEkgYmVsaWV2ZSBpdCBzaG91bGQgYmUgYWRkcmVzc2VkIGFzIHdlIGFkZGVkIHlvdXIg cHJvcG9zZWQgdGV4dCB0byB0aGUgZG9jdW1lbnQuIA0KDQpNYW55IHRoYW5rcywNClBhYmxvLg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGFibG8gQ2FtYXJpbGxvIChwY2Ft YXJpbCkgPHBjYW1hcmlsQGNpc2NvLmNvbT4gDQpTZW50OiBqdWV2ZXMsIDEwIGRlIGRpY2llbWJy ZSBkZSAyMDIwIDE5OjAyDQpUbzogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+OyBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmst cHJvZ3JhbW1pbmdAaWV0Zi5vcmc7IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRm Lm9yZzsgQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+OyBKb2VsIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQpTdWJqZWN0OiBSRTogQmVuamFtaW4gS2FkdWsn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy0y NjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSGkgQmVuLA0KDQpNYW55IHRoYW5rcyBm b3IgeW91ciB0aW1lIG9uIHRoaXMgZG9jdW1lbnQuDQpXZeKAmXZlIHB1Ymxpc2hlZCByZXYyNyBv ZiB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgY2hhbmdlcy4gIERldGFpbHMgaW5saW5lIHdpdGggW1BD XS4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5l dHdvcmstcHJvZ3JhbW1pbmctMjcNCg0KQ2hlZXJzLA0KUGFibG8uDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgPG5vcmVw bHlAaWV0Zi5vcmc+IA0KU2VudDogbWnDqXJjb2xlcywgOSBkZSBkaWNpZW1icmUgZGUgMjAyMCAx ODowNQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtc3ByaW5n LXNydjYtbmV0d29yay1wcm9ncmFtbWluZ0BpZXRmLm9yZzsgc3ByaW5nLWNoYWlyc0BpZXRmLm9y Zzsgc3ByaW5nQGlldGYub3JnOyBCcnVubyBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3Jhbmdl LmNvbT47IEpvZWwgSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT47IGptaEBqb2VsaGFscGVy bi5jb20NClN1YmplY3Q6IEJlbmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNw cmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMjY6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQoNCkJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nLTI2 OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5n LXNydjYtbmV0d29yay1wcm9ncmFtbWluZy8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZXMgdGhyb3VnaCB0byB0aGUg LTI2OyB0aGV5IGhlbHAgYSBsb3QuDQpIb3dldmVyLCBJIGRvIHRoaW5rIHRoZXJlIGlzIG9uZSBm aW5hbCBEaXNjdXNzLWxldmVsIHBvaW50IHRoYXQgbmVlZHMgdG8gYmUgcmVzb2x2ZWQ6IGl0J3Mg bW9zdGx5IGEgcHJvY2VzcyBwb2ludCwgdG8gbWFrZSBzdXJlIHRoYXQgd2hhdCB3ZSBzYXkgaW4g dGhpcyBkb2N1bWVudCBjb21wbGllcyB0byB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgd2VyZSBsYWlk IG91dCBpbiBSRkMNCjg3NTQgZm9yIHRoZSBwcm9jZWR1cmUgd2UncmUgdHJ5aW5nIHRvIGZvbGxv dy4gIFNwZWNpZmljYWxseSwgaW4gdGhlIHByb2Nlc3Mgb2YgdHJ5aW5nIHRvIGZpbmFsaXplIG15 IHJldmlldyBjb21tZW50cywgSSBlbmRlZCB1cCBkb2luZyBhIGxvdCBvZiBiYWNrZ3JvdW5kIHJl YWRpbmcsIGluIHdoaWNoIEkgbm90aWNlZCB0aGF0IFJGQyA4NzU0IHNheXM6DQoNCiAgIE5ldyBT SURzIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSBNVVNUIHNwZWNpZnkgdGhlIG11dGFiaWxpdHkgcHJv cGVydGllcw0KICAgb2YgdGhlIEZsYWdzLCBUYWcsIGFuZCBTZWdtZW50IExpc3QgYW5kIGluZGlj YXRlIGhvdyB0aGUgSGFzaGVkDQogICBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMp IFRMViAoU2VjdGlvbiAyLjEuMikgdmVyaWZpY2F0aW9uDQogICB3b3Jrcy4gIE5vdGUgdGhhdCwg aW4gZWZmZWN0LCB0aGVzZSBmaWVsZHMgYXJlIG11dGFibGUuDQoNClRoaXMgaXMgYSBiaXQgY29u ZnVzaW5nIHRvIG1lLCBpbiB0aGF0IHRoZSBTSURzIHRoZW1zZWx2ZXMgYXBwZWFyIGFzIGVudHJp ZXMgaW4gdGhlIFNlZ21lbnQgTGlzdCwgYW5kIGl0J3Mgbm90IHF1aXRlIGNsZWFyIHdoZW4gb3Ig aG93IGEgcGVyLVNJRCBiZWhhdmlvciByZWxhdGluZyB0byBmaWVsZHMgaW4gdGhlIGNvbnRhaW5p bmcgU1JIIG1pZ2h0IGNvbWUgaW50byBwbGF5LiAgSG93ZXZlciwgZ2l2ZW4gdGhhdCB3ZSBhbGxv Y2F0ZSBhIGJlaGF2aW9yIGNvZGVwb2ludCBmb3IgInRoZSBTSUQgZGVmaW5lZCBpbiBSRkMgODc1 NCIsIEkgYW0gZm9yY2VkIHRvIGNvbmNsdWRlIHRoYXQgdGhlIGJlaGF2aW9ycyBzcGVjaWZpZWQg aW4gdGhpcyBkb2N1bWVudCBtZWV0IHRoZSBkZWZpbml0aW9uIG9mICJuZXcgU0lEcyINCnRoYXQg YXJlIGJlaW5nIGRlZmluZWQgImluIHRoZSBmdXR1cmUiIChmcm9tIHRoZSByZWZlcmVuY2UgcG9p bnQgb2YgUkZDIDg3NTQpLCBhbmQgdGhlcmVmb3JlIHRoYXQgdGhleSBtdXN0IHNwZWNpZnkgdGhl IGluZGljYXRlZCBwcm9wZXJ0aWVzLg0KSSdtIHRvbGQgb3V0IG9mIGJhbmQgdGhhdCB0aGUgaW50 ZW50IGlzIHRvIGRvIHRoZSBzYW1lIHRoaW5nIHRoYXQgUkZDDQo4NzU0IGRvZXMgZm9yIHRoZSBT SUQgaXQgZGVmaW5lcywgYW5kIHNvIHRoaXMgc2hvdWxkIGJlIHRyaXZpYWwgdG8gcmVzb2x2ZSBq dXN0IGJ5IGFkZGluZyBhIGJyaWVmIG5vdGUgdGhhdCAoZS5nLikgInRoZSBTSURzIHNwZWNpZmll ZCBpbiB0aGlzIGRvY3VtZW50IGhhdmUgdGhlIHNhbWUgSE1BQyBUTFYgaGFuZGxpbmcgYW5kIG11 dGFiaWxpdHkgcHJvcGVydGllcyBvZiB0aGUgRmxhZ3MsIFRhZywgYW5kIFNlZ21lbnQgTGlzdCBm aWVsZCBhcyB0aGUgU0lEIHNwZWNpZmllZCBpbiBSRkMgODc1NCIuICBIb3dldmVyLCBJIGJlbGll dmUgdGhhdCBzdWNoIGFuIGV4cGxpY2l0IHN0YXRlbWVudCBpcyByZXF1aXJlZCwgYW5kIHRoYXQg d2Ugd291bGQgaW50cm9kdWNlIGFuIGludGVybmFsIGluY29uc2lzdGVuY3kgYmV0d2VlbiB0aGlz IGRvY3VtZW50IGFuZCBSRkMgODc1NCBpZiB3ZSBzYXkgbm90aGluZyBvbiB0aGlzIHRvcGljLiAg SW4gcGFydGljdWxhciwgSSB0aGluayB0aGF0IHdlIHdvdWxkIG5vdCBpbmhlcml0IHRoYXQgYmVo YXZpb3IgYXMgc29tZSBraW5kIG9mIGRlZmF1bHQgYmVoYXZpb3IgaWYgd2UgbWFrZSBubyBzdGF0 ZW1lbnQgYXQgYWxsLg0KDQpJIGFtIHNvcnJ5IHRoYXQgSSBkaWQgbm90IG5vdGljZSB0aGlzIGVh cmxpZXIsIGJ1dCBJIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gcmVtYWluIGNvbnNpc3Rl bnQgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIG9mIFJGQyA4NzU0IGFuZCB0aHVzIHRoYXQgdGhpcyBp cyBhcHByb3ByaWF0ZSB0byByYWlzZSBhcyBhIERpc2N1c3MtbGV2ZWwgcG9pbnQsIGV2ZW4gaWYg SSBoYXZlIHByZXZpb3VzbHkgcmV2aWV3ZWQgdGhlIHRleHQgaW4gcXVlc3Rpb24uDQoNCltQQ10g V2UgaGF2ZSBhZGRlZCB5b3VyIHN1Z2dlc3RlZCBzZW50ZW5jZSB0byB0aGUgU2VjdGlvbiA5LiAo SeKAmXZlIHMvU0lEcy9TSUQgQmVoYXZpb3JzLykuIFRoYW5rcy4NCjxORVc+DQpUaGUgU0lEIEJl aGF2aW9ycyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBoYXZlIHRoZSBzYW1lIEhNQUMgVExW IGhhbmRsaW5nIGFuZCBtdXRhYmlsaXR5IHByb3BlcnRpZXMgb2YgdGhlIEZsYWdzLCBUYWcsIGFu ZCBTZWdtZW50IExpc3QgZmllbGQgYXMgdGhlIFNJRCBCZWhhdmlvciBzcGVjaWZpZWQgaW4gUkZD IDg3NTQuDQo8L05FVz4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KW25vdGU6IEkgb3JpZ2luYWxseSBwcmVwYXJlZCB0aGVzZSBjb21tZW50cyB3aGVuIGxvb2tp bmcgYXQgdGhlIC0yNC4gIEkgdHJpZWQgdG8gcmVtb3ZlIGNvbW1lbnRzIGFib3V0IHRoaW5ncyBm aXhlZCBpbiB0aGUgLTI1IG9yIC0yNiwgYnV0IG1heSBoYXZlIG1pc3NlZCBhIGNvdXBsZTsgcGxl YXNlIGlnbm9yZSBhbnkgc3VjaCBhbHJlYWR5LWFkZHJlc3NlZCBjb21tZW50cy4NClRoZXJlIGFy ZSBhbHNvIGEgY291cGxlIHBvaW50cyB0aGF0IHdlIGhhdmUgYWxyZWFkeSBiZWVuIGRpc2N1c3Np bmcgaW4gdGhlIG90aGVyIHRocmVhZCBidXQgSSByZXRhaW4gYXMgYSAicGxhY2Vob2xkZXIiOyBo b3BlZnVsbHkgd2UgY2FuIGtlZXAgdGhlIGFjdHVhbCBkaXNjdXNzaW9uIGFib3V0IHRoZW0gaW4g anVzdCBvbmUgcGxhY2UuXQ0KDQpBcyBtZW50aW9uZWQgaW4gdGhlIERpc2N1c3Mgc2VjdGlvbiwg SSBkaWQgYSBsb3Qgb2YgYmFja2dyb3VuZCByZWFkaW5nIHdoaWxlIHByZXBhcmluZyB0aGlzIHVw ZGF0ZWQgYmFsbG90IHBvc2l0aW9uLiAgQW5vdGhlciB0aGluZyBJIG5vdGljZWQgd2hpbGUgZG9p bmcgdGhhdCByZWFkaW5nIGlzIHRoYXQgdGhlIHBzZXVkb2NvZGUgaW4NCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4NzU0I3NlY3Rpb24tNC4zLjEuMSBleHBsaWNpdGx5IG1lbnRpb25z ICJwZXJmb3JtIFRMViBwcm9jZXNzaW5nIjsgd2UgbWlnaHQgY29uc2lkZXIgcmVwZWF0aW5nIHRo YXQgc3RlcCBpbiBvdXIgcHNldWRvY29kZSBwcm9jZWR1cmVzLCBhbmQgb3RoZXJ3aXNlIG1ha2lu ZyBvdXIgcHJvY2VkdXJlcyBhcyBhbmFsb2dvdXMgYXMgcG9zc2libGUgdG8gdGhlIFJGQyA4NzU0 IHByb2NlZHVyZXMsIGp1c3QgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Yga2VlcGluZyB0aGUgd3Jp dGluZyBzdHlsZSBhcyBjb25zaXN0ZW50IGFzIHBvc3NpYmxlIGFjcm9zcyB0aGUgcmVsYXRlZCBk b2N1bWVudHMuICBIb3dldmVyLCB0aGF0J3MgZW50aXJlbHkgYW4gZWRpdG9yaWFsIG1hdHRlciBh bmQgdGh1cyBsZWZ0IHRvIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBhdXRob3JzL0FELg0KDQpbUENd IEFjaw0KDQpTZWN0aW9uIDINCg0KICAgVGhlIGZvbGxvd2luZyB0ZXJtcyB1c2VkIHdpdGhpbiB0 aGlzIGRvY3VtZW50IGFyZSBkZWZpbmVkIGluDQogICBbUkZDODc1NF06IFNSSCwgU1IgU291cmNl IE5vZGUsIFRyYW5zaXQgTm9kZSwgU1IgU2VnbWVudCBFbmRwb2ludA0KICAgTm9kZSwgUmVkdWNl ZCBTUkgsIFNlZ21lbnRzIExlZnQgYW5kIExhc3QgRW50cnkuDQoNCkl0J3Mgc2xpZ2h0bHkgdW5m b3J0dW5hdGUgdGhhdCA4NzU0IGRpZG4ndCBoYXZlIGEgZGVkaWNhdGVkIHRlcm1pbm9sb2d5IHNl Y3Rpb24gY29udGFpbmluZyB0aGVzZSwgdGhvdWdoIGl0J3MgdG9vIGxhdGUgdG8gcmVhbGx5IGRv IGFueXRoaW5nIGFib3V0IGl0IG5vdy4NCg0KW1BDXSBJbmRlZWQsIGJ1dCBub3RoaW5nIEkgY2Fu IGRvIGFib3V0IGl0Li4uDQoNClNlY3Rpb24gMw0KDQogICBUaGUgdGVybSAiZnVuY3Rpb24iIHJl ZmVycyB0byB0aGUgYml0LXN0cmluZyBpbiB0aGUgU1J2NiBTSUQuICBUaGUNCiAgIHRlcm0gImJl aGF2aW9yIiBpZGVudGlmaWVzIHRoZSBiZWhhdmlvciBib3VuZCB0byB0aGUgU0lELiAgVGhlDQog ICBiZWhhdmlvcnMgYXJlIGRlZmluZWQgaW4gU2VjdGlvbiA0IG9mIHRoaXMgZG9jdW1lbnQuDQoN CihuaXQpIHVzaW5nICJ0aGUgYmVoYXZpb3JzIiB0byBzb21lIGV4dGVudCBpbXBsaWVzIHRoYXQg dGhlc2UgYXJlIHRoZSBvbmx5IG9uZXMgYWxsb3dlZCBvciBkZWZpbmVkLCB3aGljaCBpcyBub3Qg dHJ1ZS4gIFBlcmhhcHMgInNvbWUgYmVoYXZpb3JzIiB3b3VsZCBiZSBtb3JlIGFjY3VyYXRlIChv ciBzb21lIG90aGVyIHBocmFzaW5nIHdvdWxkIGFsc28gY292ZXIgdGhlIGV4cGVjdGVkIGV2b2x1 dGlvbiBvZiB0aGUgZWNvc3lzdGVtKT8NCg0KW1BDXSBDaGFuZ2VkIHRvICJzb21lIGJlaGF2aW9y cyIgYXMgc3VnZ2VzdGVkLg0KDQpTZWN0aW9uIDMuMw0KDQogICBBIHBhY2tldCBjb3VsZCBiZSBz dGVlcmVkIHRvIGEgbm9uLXJvdXRlZCBTSUQgMjAwMTpkYjg6YjoyOjEwMTo6IGJ5DQogICB1c2lu ZyBhIFNJRCBsaXN0IDwuLi4sMjAwMTpkYjg6YjoxOjEwMDo6LDIwMDE6ZGI4OmI6MjoxMDE6Oiwu Li4+DQogICB3aGVyZSB0aGUgbm9uLXJvdXRlZCBTSUQgaXMgcHJlY2VkZWQgYnkgYSByb3V0ZWQg U0lEIHRvIHRoZSBzYW1lDQogICBub2RlLiAgUm91dGVkIGFuZCBub24tcm91dGVkIFNSdjYgU0lE cyBhcmUgdGhlIFNSdjYgaW5zdGFudGlhdGlvbiBvZg0KICAgZ2xvYmFsIGFuZCBsb2NhbCBzZWdt ZW50cywgcmVzcGVjdGl2ZWx5IFtSRkM4NDAyXS4NCg0KSWYgaXQncyAoYWxzbykgcG9zc2libGUg dG8gc3RlZXIgYSBwYWNrZXQgdG8gYSBub24tcm91dGVkIFNJRCB3aXRob3V0IGEgcHJlY2VkaW5n IHJvdXRlZCBTSUQgZm9yIHRoZSBzYW1lIG5vZGUgKGUuZy4sIHZpYSBFbmQuWCksIGl0IHNlZW1z IGxpa2UgdGhhdCBtaWdodCBiZSB3b3J0aCBsaXN0aW5nIGFuIGV4YW1wbGUgb2YgYXMgd2VsbC4g IE90aGVyd2lzZSBhIHJlYWRlciBtaWdodCBhc3N1bWUgdGhhdCB0aGUgZ2xvYmFsIHNlZ21lbnQg aXMgYSBuZWNlc3NhcnkgcGFydCBvZiB1c2luZyB0aGUgbm9uLXJvdXRlZCBTSUQuDQoNCltQQ10g SW5kZWVkLiBXZSd2ZSBhZGRlZCB0aGUgZm9sbG93aW5nLiBUaGFua3MuDQo8T0xEPg0KQSBwYWNr ZXQgY291bGQgYmUgc3RlZXJlZCB0byBhIG5vbi1yb3V0ZWQgU0lEIDIwMDE6ZGI4OmI6MjoxMDE6 OiBieQ0KICAgdXNpbmcgYSBTSUQgbGlzdCA8Li4uLDIwMDE6ZGI4OmI6MToxMDA6OiwyMDAxOmRi ODpiOjI6MTAxOjosLi4uPg0KICAgd2hlcmUgdGhlIG5vbi1yb3V0ZWQgU0lEIGlzIHByZWNlZGVk IGJ5IGEgcm91dGVkIFNJRCB0byB0aGUgc2FtZQ0KICAgbm9kZS4gIA0KPC9PTEQ+DQo8TkVXPg0K QSBwYWNrZXQgY291bGQgYmUgc3RlZXJlZCB0aHJvdWdoIGEgbm9uLXJvdXRlZCBTSUQgMjAwMTpk Yjg6YjoyOjEwMTo6IGJ5DQogICB1c2luZyBhIFNJRCBsaXN0IDwuLi4sMjAwMTpkYjg6YjoxOjEw MDo6LDIwMDE6ZGI4OmI6MjoxMDE6OiwuLi4+DQogICB3aGVyZSB0aGUgbm9uLXJvdXRlZCBTSUQg aXMgcHJlY2VkZWQgYnkgYSByb3V0ZWQgU0lEIHRvIHRoZSBzYW1lDQogICBub2RlLiAgQSBwYWNr ZXQgY291bGQgYWxzbyBiZSBzdGVlcmVkIHRvIGEgbm9kZSBpbnN0YW50aWF0aW5nIGEgDQogICBu b24tcm91dGVkIFNJRCBieSBwcmVjZWRpbmcgaXQgaW4gdGhlIFNJRC1saXN0IHdpdGggYW4gQWRq YWNlbmN5IFNJRCB0byB0aGF0IG5vZGUuDQo8L05FVz4NCg0KU2VjdGlvbiA0DQoNCiAgRW5kLkRU MlUgICAgICAgICAgIEVuZHBvaW50IHdpdGggZGVjYXBzIGFuZCB1bmljYXN0IE1BQyBMMnRhYmxl IGxvb2t1cA0KICAgICAgICAgICAgICAgICAgICAgZS5nLiBFVlBOIEJyaWRnaW5nIHVuaWNhc3Qg dXNlLWNhc2UNCg0KKG5pdCkgd2Ugc2VlbSB0byBwdXQgYSBzcGFjZSBpbiAiTDIgdGFibGUiIHRo ZSBvdGhlciB0aW1lcyBpdCBhcHBlYXJzLg0KDQpbUENdIEZpeGVkDQoNCiAgIFRoZSBsaXN0IGlz IG5vdCBleGhhdXN0aXZlLiAgSW4gcHJhY3RpY2UsIGFueSBmdW5jdGlvbiBjYW4gYmUNCiAgIGF0 dGFjaGVkIHRvIGEgbG9jYWwgU0lEOiBlLmcuIGEgbm9kZSBOIGNhbiBiaW5kIGEgU0lEIHRvIGEg bG9jYWwgVk0NCiAgIG9yIGNvbnRhaW5lciB3aGljaCBjYW4gYXBwbHkgYW55IGNvbXBsZXggcHJv Y2Vzc2luZyBvbiB0aGUgcGFja2V0Lg0KDQoobml0KSB0aGUgcHJlY2VkaW5nIGxpc3Qgd2FzIGEg bGlzdCBvZiB3ZWxsLWtub3duIGJlaGF2aW9ycywgbm90IGEgbGlzdCBvZiBmdW5jdGlvbnMuICBJ SVVDLCBpdCBpcyBtb3JlIGFwcHJvcHJpYXRlIHRvIHVzZSAiYmVoYXZpb3IiIGhlcmUgdGhhbiAi ZnVuY3Rpb24iLCBzaW5jZSB0aGUgImZ1bmN0aW9uIiBpcyBqdXN0IHRoZSBvcGFxdWUgYml0c3Ry aW5nLg0KDQpbUENdIEluZGVlZC4gRml4ZWQuDQoNClNlY3Rpb24gNC4xLjEsIC4uLg0KDQogICBX aGVuIHByb2Nlc3NpbmcgdGhlIFVwcGVyLWxheWVyIEhlYWRlciBvZiBhIHBhY2tldCBtYXRjaGlu ZyBhIEZJQg0KICAgZW50cnkgbG9jYWxseSBpbnN0YW50aWF0ZWQgYXMgYW4gU1J2NiBFbmQgU0lE IGRvIHRoZSBmb2xsb3dpbmc6DQoNCihlZGl0b3JpYWwsIEkgdGhpbmspIEkgZmluZCBpdCBpbnRl cmVzdGluZyB0byBjb21wYXJlIHRoZSBwaHJhc2luZyBoZXJlIHRvIHdoYXQgd2FzIHVzZWQgaW4g wqc0LjEgKHdoZW4gcHJvY2Vzc2luZyBhbiBTUkgpLCB3aGVyZSB0aGUgdGV4dCBpcyAicmVjZWl2 ZXMgYSBwYWNrZXQgd2hvc2UgSVB2NiBEQSBpcyBTIGFuZCBTIGlzIGEgbG9jYWwgRW5kIFNJRCIu ICBXaHkgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gIkVuZCBTSUQiIGFuZCAnU1J2NiBFbmQgU0lE Ij8gIElJVUMgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gY2hlY2tpbmcgIklQdjYgREEiIGFuZCAi bWF0Y2hpbmcgYSBGSUIgZW50cnkgbG9jYWxseSBpbnN0YW50aWF0ZWQiIGlzIGltcG9ydGFudCBh bmQgdGhlIGxhbmd1YWdlIHNob3VsZCBub3QgYmUgaGFybW9uaXplZCBiZXR3ZWVuIG9jY3VycmVu Y2VzLg0KVGhlICIuLi4iIGluIHRoZSBTZWN0aW9uIG51bWJlciBsaXN0aW5nIGluZGljYXRlcyB0 aGF0IHRoaXMgKG9yIHNpbWlsYXIpIHBocmFzaW5nIGFwcGVhcnMgdGhyb3VnaG91dCwgd2hlbmV2 ZXIgd2UgdGFsayBhYm91dCBwcm9jZXNzaW5nIGFuIHVwcGVyLWxheWVyIGhlYWRlci4NCg0KW1BD XSBUaGUgcGhyYXNpbmcgb2YgNC4xLjEgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSB1c2VkIGluIFJG Qzg3NTQuDQpbUENdIFRoZSBkaWZmIGJldHdlZW4gIlNSdjYgRW5kIFNJRCIgYW5kICJFbmQgU0lE IiBpcyBhbiBlZGl0b3JpYWwgbml0LiBJIGFncmVlIHRoYXQgc2hvdWxkIGJlIGhhcm1vbml6ZWQu IEkndmUgcmVtb3ZlZCAiU1J2NiIgaW4gYWxsIGluc3RhbmNlcy4NCg0KU2VjdGlvbiA0LjINCg0K ICAgTm90ZSB0aGF0IGlmIE4gaGFzIGFuIG91dGdvaW5nIGludGVyZmFjZSBidW5kbGUgSSB0byBh IG5laWdoYm9yIFENCiAgIG1hZGUgb2YgMTAgbWVtYmVyIGxpbmtzLCBOIG1heSBhbGxvY2F0ZSB1 cCB0byAxMSBFbmQuWCBsb2NhbCBTSURzOg0KICAgb25lIGZvciB0aGUgYnVuZGxlIGl0c2VsZiBh bmQgdGhlbiB1cCB0byBvbmUgZm9yIGVhY2ggTGF5ZXItMiBtZW1iZXINCiAgIGxpbmsuICBUaGUg Zmxvd3Mgc3RlZXJlZCB1c2luZyB0aGUgRW5kLlggU0lEIGNvcnJlc3BvbmRpbmcgdG8gdGhlDQoN CihuaXQpIEkgdGhpbmsgdGhhdCB3aGlsZSAidXAgdG8gMTEiIG1pZ2h0IGJlIHRoZSBzaXR1YXRp b24gdGhhdCBtYWtlcyB0aGUgbW9zdCBzZW5zZSAoaW4gdGhhdCBoYXZpbmcgbWFueSBkaXN0aW5j dCBzdWJncm91cHMgd2l0aCAxIDwgbiA8IDEwIG1lbWJlciBsaW5rcyBkb2Vzbid0IG1ha2Ugc2Vu c2UpLCBpdCBpcyBub3Qgc3RyaWN0bHkgc3BlYWtpbmcgYSBwaHlzaWNhbCBvciBwcm90b2NvbCBy ZXF1aXJlbWVudC4gIFBlcmhhcHMgIm1pZ2h0IGFsbG9jYXRlIDExIiBpcyBiZXR0ZXIgdGhhbiAi bWF5IGFsbG9jYXRlIHVwIHRvIDExIiBmb3IgdGhhdCByZWFzb24uDQoNCltQQ10gQ2hhbmdlZCB0 byBtaWdodC4NCg0KU2VjdGlvbiA0LjQsIC4uLg0KDQogICBXaGVuIE4gcmVjZWl2ZXMgYSBwYWNr ZXQgZGVzdGluZWQgdG8gUyBhbmQgUyBpcyBhIGxvY2FsIEVuZC5EWDYgU0lELA0KICAgTiBkb2Vz IHRoZSBmb2xsb3dpbmcgcHJvY2Vzc2luZzoNCg0KKG5pdCkgd2UgaGF2ZSBhIG1pc21hdGNoIG9m ICJOIGRvZXMgdGhlIGZvbGxvd2luZyBwcm9jZXNzaW5nIiAobGlrZSBhcHBlYXJzIGhlcmUpIGFu ZCAiTiBkb2VzIiBvciBzaW1pbGFyOyBpdCBpcyBwcm9iYWJseSB3b3J0aCBub3JtYWxpemluZyBv biBvbmUgcGhyYXNpbmcuDQoNCltQQ10gQ2hhbmdlZCB0byAiTiBkb2VzIg0KDQogICBXaGVuIHBy b2Nlc3NpbmcgdGhlIFVwcGVyLWxheWVyIGhlYWRlciBvZiBhIHBhY2tldCBtYXRjaGluZyBhIEZJ Qg0KICAgZW50cnkgbG9jYWxseSBpbnN0YW50aWF0ZWQgYXMgYW4gU1J2NiBFbmQuRFg2IFNJRCwg dGhlIGZvbGxvd2luZyBpcw0KICAgZG9uZToNCg0KU2ltaWxhcmx5IGhlcmUsIHdlIHVzZSAidGhl IGZvbGxvd2luZyBpcyBkb25lIiBidXQgdGhlICJOIGRvZXMgdGhlIGZvbGxvd2luZyIgcGhyYXNp bmcgdXNlZCBpbiBzb21lIG90aGVyIHNlY3Rpb25zIGlzIHByb2JhYmx5IHByZWZlcnJlZCwgYXMg aXQgYXZvaWRzIHRoZSBwYXNzaXZlIHZvaWNlLg0KDQpbUENdIENoYW5nZWQgdG8gIk4gZG9lcyIN Cg0KU2VjdGlvbiA0LjEyDQoNCldlIG1pZ2h0IGdpdmUgc29tZSBtbmVtb25pYyBleHBsYW5hdGlv biBmb3IgaG93IHRoZSBuYW1lICJGRTIiIHdhcyBjaG9zZW4gdG8gaWRlbnRpZnkgdGhlIGFyZ3Vt ZW50IHZhbHVlLg0KDQpbUENdIEluaXRpYWxseSB3ZSByZWZlcnJlZCB0byBpdCBhcyDigJxMMiBh cmd1bWVudCBzcGVjaWZpYyB0byBFVlBOIEVTSSBmaWx0ZXJpbmfigJ0uIEkgZG9u4oCZdCBzZWUg YSBzdHJhaWdodGZvcndhcmQgbW5lbW9uaWMgZXhwbGFuYXRpb24uDQoNCiAgIHRhYmxlIFQgZmxv b2RpbmcuICBUaGUgYWxsb2NhdGlvbiBvZiB0aGUgYXJndW1lbnQgdmFsdWVzIGlzIGxvY2FsIHRv DQogICB0aGUgU1IgRW5kcG9pbnQgTm9kZSBpbnN0YW50aWF0aW5nIHRoaXMgYmVoYXZpb3IgYW5k IHRoZSBzaWduYWxpbmcgb2YNCiAgIHRoZSBhcmd1bWVudCB0byBvdGhlciBub2RlcyBmb3IgdGhl IEVWUE4gZnVuY3Rpb25hbGl0eSB2aWEgY29udHJvbA0KICAgcGxhbmUuDQoNCm5pdCg/KTogcy92 aWEgY29udHJvbCBwbGFuZS9vY2N1cnMgdmlhIHRoZSBjb250cm9sIHBsYW5lLz8NCg0KW1BDXSBD aGFuZ2VkDQoNClNlY3Rpb24gNC4xMw0KDQogIFMwNS4gICBJZiAoSVB2NiBIb3AgTGltaXQgPD0g MSkgew0KICBTMDYuICAgICAgIFNlbmQgYW4gSUNNUCBUaW1lIEV4Y2VlZGVkIG1lc3NhZ2UgdG8g dGhlIFNvdXJjZSBBZGRyZXNzLA0KICAgICAgICAgICAgICAgQ29kZSAwIChIb3AgbGltaXQgZXhj ZWVkZWQgaW4gdHJhbnNpdCksDQoNCihuaXQpIHRoZSBpbmRlbnRhdGlvbiBzZWVtcyBvZmYgYnkg b25lIHNwYWNlIGluIHRoZSBmaXJzdCBsaW5lIG9mIFMwNiAoaXQgZG9lc24ndCBtYXRjaCB0aGUg b3RoZXIgdHdvIHBsYWNlcyB3aGVyZSB0aGlzIGNodW5rIG9jY3VycykuDQoNCltQQ10gRml4ZWQN Cg0KICAgUzE0LiAgVGhlIFNSSCBNQVkgYmUgb21pdHRlZCB3aGVuIHRoZSBTUnY2IFBvbGljeSBC IG9ubHkgY29udGFpbnMgb25lDQogICBTSUQgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gdXNlIGFu eSBmbGFnLCB0YWcgb3IgVExWLg0KICAgUzE3LiAgVGhlIFBheWxvYWQgTGVuZ3RoLCBUcmFmZmlj IENsYXNzLCBIb3AgTGltaXQgYW5kIE5leHQtSGVhZGVyDQogICBmaWVsZHMgYXJlIHNldCBhcyBw ZXIgW1JGQzI0NzNdLiAgVGhlIEZsb3cgTGFiZWwgaXMgY29tcHV0ZWQgYXMgcGVyDQogICBbUkZD NjQzN10uDQoNCihUaGVzZSBsb29rIHRvIGJlIFMxNSBhbmQgUzE4LCByZXNwZWN0aXZlbHksIG5v dy4pDQoNCltQQ10gRml4ZWQNCg0KU2VjdGlvbiA0LjE0DQoNCiAgIFRoZSBTUkggTUFZIGJlIG9t aXR0ZWQgd2hlbiB0aGUgU1J2NiBQb2xpY3kgb25seSBjb250YWlucyBvbmUgc2VnbWVudA0KICAg YW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gdXNlIGFueSBmbGFnLCB0YWcgb3IgVExWLg0KDQoobml0 KSBpdCdzIHByb2JhYmx5IHdvcnRoIGhhcm1vbml6aW5nIHRoZSBwaHJhc2luZyBiZXR3ZWVuIGhl cmUgYW5kIHRoZSBub3RlIG9uIFMxNSBpbiDCpzQuMTMgKHNwZWNpZmljYWxseSwgIm9ubHkgY29u dGFpbnMgb25lIFNJRCIgdnMgIm9ubHkgY29udGFpbnMgb25lIHNlZ21lbnQiKS4NCg0KW1BDXSBJ bmRlZWQuIENoYW5nZWQuDQoNClNlY3Rpb24gNC4xNQ0KDQoobml0KSB0aGVyZSdzIGEgYmxhbmsg bGluZSBhdCB0aGUgZW5kIG9mIFMwNiB0aGF0IGRvZXNuJ3Qgb2NjdXIgaW4gdGhlIG90aGVyIHR3 byBsb2NhdGlvbnMgd2hlcmUgdGhpcyBwc2V1ZG9jb2RlIGFwcGVhcnMuDQoNCiAgUzE2LiAgIFN1 Ym1pdCB0aGUgcGFja2V0IHRvIHRoZSBNUExTIGVuZ2luZSBmb3IgdHJhbnNtaXNzaW9uIHRvIHRo ZQ0KICAgICAgICAgICAgdG9wbW9zdCBsYWJlbC4NCg0KKG5pdCkgSSBzdWdnZXN0IHJld29yZGlu ZyBzbGlnaHRseSBzbyBhcyB0byBub3QgaW1wbHkgdGhhdCB0aGUgbm9kZSB0byB0cmFuc21pdCB0 byBpcyBkZXRlcm1pbmVkIGJ5IHRoZSB0b3Btb3N0IGxhYmVsIC0tIElJVUMgaXQncyBkZXRlcm1p bmVkIGJ5IHRoZSBNUExTIHBvbGljeSwgc2luY2UgdGhlIGludGVycHJldGF0aW9uIG9mIHRoZSBs YWJlbCBpcyBpbiBnZW5lcmFsIGxvY2FsIHRvIHRoZSByZWNlaXZpbmcgbm9kZS4NCg0KW1BDXSBS ZW1vdmVkICJ0byB0aGUgdG9wbW9zdCBsYWJlbCIuDQoNClNlY3Rpb24gNC4xNi4xLjINCg0KICAg QXMgYSByZW1pbmRlciwgW1JGQzg3NTRdIGRlZmluZXMgaW4gc2VjdGlvbiA1IHRoZSBTUiBEZXBs b3ltZW50IE1vZGVsDQogICB3aXRoaW4gdGhlIFNSIERvbWFpbiBbUkZDODQwMl0uICBXaXRoaW4g dGhpcyBmcmFtZXdvcmssIHRoZQ0KICAgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkgaXMgbm90 IHVzZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3JpYmVkDQogICBpbiBTZWN0aW9uIDcuNSBv ZiBbUkZDODc1NF0uDQoNCihyZXBlYXRpbmcgZnJvbSB0aGUgcHJldmlvdXMgdGhyZWFkIGFzIGEg cGxhY2Vob2xkZXIpIEkgdGhpbmsgd2UgbmVlZCBhbm90aGVyIHNlbnRlbmNlIG9yIGNsYXVzZSBo ZXJlIHRvIGNsYXJpZnkgd2h5IHRoaXMgc3RhdGVtZW50IGlzIHJlbGV2YW50LCBlLmcuLCAiVGh1 cywgd2hpbGUgdGhlIEFIIGNhbiBkZXRlY3QgY2hhbmdlcyB0byB0aGUgSVB2NiBoZWFkZXIgY2hh aW4sIGl0IHdpbGwgbm90IGJlIHVzZWQgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgU1JILCBzbyB1 c2Ugb2YgUFNQIHdpbGwgbm90IGNhdXNlIGRlbGl2ZXJ5IGZhaWx1cmUgZHVlIHRvIEFIIHZhbGlk YXRpb24gY2hlY2tzLiINCg0KW1BDXSBXaGF0IGFib3V0IHRoaXM/DQo8T0xEPg0KV2l0aGluIHRo aXMgZnJhbWV3b3JrLCB0aGUgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkgaXMgbm90IHVzZWQg dG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy41IG9mIFtSRkM4NzU0 XS4NCjwvT0xEPg0KPFBST1BPU0FMPg0KV2l0aGluIHRoaXMgZnJhbWV3b3JrLCB0aGUgQXV0aGVu dGljYXRpb24gSGVhZGVyIChBSCkgaXMgbm90IHVzZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNy41IG9mIFtSRkM4NzU0XS4gSGVuY2UsIHRoZSBkaXNjdXNzaW9u IG9mIGFwcGxpY2FiaWxpdHkgb2YgUFNQIGFsb25nIHdpdGggQUggdXNhZ2UgaXMgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPC9QUk9QT1NBTD4NCg0KU2VjdGlvbiA1DQoNCihl ZGl0b3JpYWwpIFRoaXMgaXMgdGhlIGZpcnN0IHBsYWNlIGluIHRoZSBkb2N1bWVudCB0aGF0IHdl IHRhbGsgYWJvdXQgdGhlICJoZWFkZW5kIiBvciBpdHMgcG9saWN5IGF0IGFsbCwgc28gYSBiaXQg b2YgYmFja2dyb3VuZCBvbiB3aHkgaXQncyB1c2VmdWwgdG8gdGFidWxhdGUgcG90ZW50aWFsIGhl YWRlbmQgcG9saWN5L2JlaGF2aW9ycyBtaWdodCBiZSBoZWxwZnVsLg0KDQpbUENdIEkndmUgYWRk ZWQgYSByZWZlcmVuY2UgdG8gUkZDODQwMi4NCg0KU2VjdGlvbiA1LngNCg0KVHlpbmcgdGhlIG90 aGVyIHBvbGljaWVzIG1vcmUgcHJlY2lzZWx5IHRvIHRoZSBwc2V1ZG9jb2RlIGZvciBILkVuY2Fw cyAoZS5nLiwgcmVwbGFjaW5nIFMwMSkgc2VlbXMgbGlrZSBpdCB3b3VsZCBiZSB1c2VmdWwsIHRv IGF2b2lkIHRoZSBhcHBlYXJhbmNlIG9mIHNwZWNpZnlpbmcgYmVoYXZpb3IgYnkgYXBwZWFsaW5n IHRvIGV4YW1wbGVzLg0KDQpTZWN0aW9uIDUuMQ0KDQogICBOb3RlOg0KICAgUzAzOiBBcyBkZXNj cmliZWQgaW4gW1JGQzY0MzddIChJUHY2IEZsb3cgTGFiZWwgU3BlY2lmaWNhdGlvbikuDQoNCldl IG5lZWQgdG8gcHVsbCBpbiBSRkMgMjQ3MyBmb3IgcGF5bG9hZCBsZW5ndGgsIHRyYWZmaWMgY2xh c3MsIGFuZCBuZXh0LWhlYWRlciwgSUlVQy4gIChob3AtbGltaXQgaXMgY292ZXJlZCBhIGZldyBw YXJhZ3JhcGhzIGRvd24uKSBBbHNvIHRvIHNheSBob3cgdGhlIG5leHQtaGVhZGVyIHZhbHVlIGlz IHNlbGVjdGVkLg0KDQpbUENdIEFkZGVkIHJlZmVyZW5jZSB0byBSRkMyNDczLg0KDQpTZWN0aW9u IDguMQ0KDQogICBUaGUgcHJlc2VuY2Ugb2YgU0lEcyBpbiB0aGUgSUdQIGRvZXMgbm90IGltcGx5 IGFueSByb3V0aW5nIHNlbWFudGljcw0KICAgdG8gdGhlIGFkZHJlc3NlcyByZXByZXNlbnRlZCBi eSB0aGVzZSBTSURzLiAgVGhlIHJvdXRpbmcgcmVhY2hhYmlsaXR5DQogICB0byBhbiBJUHY2IGFk ZHJlc3MgaXMgc29sZWx5IGdvdmVybmVkIGJ5IHRoZSBub24tU0lELXJlbGF0ZWQgSUdQDQogICBw cmVmaXggcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uIHRoYXQgaW5jbHVkZXMgbG9jYXRvcnMuICBS b3V0aW5nIGlzDQogICBuZWl0aGVyIGdvdmVybmVkIG5vciBpbmZsdWVuY2VkIGluIGFueSB3YXkg YnkgYSBTSUQgYWR2ZXJ0aXNlbWVudCBpbg0KICAgdGhlIElHUC4NCg0KSXQgc2VlbXMgbGlrZSB0 aGlzIGlzIHRyeWluZyB0byBzYXkgInRoZSBJR1AgbXVzdCBub3QgYWR2ZXJ0aXNlIHByZWZpeGVz IGNvbnRhaW5lZCB3aXRoaW4gdGhlIExPQyBwYXJ0IG9mIGFuIFNJRCIsIGJ1dCBpbiBhIHZlcnkg cm91bmRhYm91dCB3YXkuDQoNCltQQ10gTm90IGF0IGFsbC4gVGhpcyBpcyBzYXlpbmcgdGhhdCBp biB5b3VyIElHUCB5b3UgaGF2ZSB0d28gZGlmZmVyZW50IHRoaW5nczogcHJlZml4IHJlYWNoYWJp bGl0eSBpbmZvcm1hdGlvbiAtaW5jbHVkaW5nIGxvY2F0b3JzLTsgYW5kIFNJRCBhZHZlcnRpc2Vt ZW50cy4gQW5kIHJvdXRpbmcgaW4geW91ciBuZXR3b3JrIGlzIGRlcml2ZWQgZnJvbSB0aGUgZmly c3Qgb25lLg0KDQpTZWN0aW9uIDguMw0KDQogICBUaGUgRW5kLkRYNCwgRW5kLkRYNiwgRW5kLkRU NCwgRW5kLkRUNiwgRW5kLkRUNDYsIEVuZC5EWDIsIEVuZC5EWDJWLA0KICAgRW5kLkRUMlUgYW5k IEVuZC5EVDJNIFNJRHMgY2FuIGJlIHNpZ25hbGVkIGluIEJHUC4NCg0KU2luY2Ugd2Ugc2FpZCBl YXJsaWVyIHRoYXQgdGhlIHNpZ25hbGluZyBvZiBTSURzIG5lZWRzIHRvIGluY2x1ZGUgdGhlIGJl aGF2aW9yIGNvZGVwb2ludCBmb3IgZWFjaCBmdW5jdGlvbiBiaXRzdHJpbmcsIGl0IHNlZW1zIGxp a2Ugd2Ugc2hvdWxkIHByb3ZpZGUgYSByZWZlcmVuY2UgdG8gaG93IEJHUCB3aWxsIGVuY29kZSB0 aGUgYmVoYXZpb3IgY29kZXBvaW50Lg0KDQpbUENdIEluZm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8g dGhlc2Ugb3RoZXIgcm91dGluZyBwcm90b2NvbCBkcmFmdHMgd2VyZSByZW1vdmVkIGFzIHBhcnQg b2YgZWFybGllciByZXZpZXcgY29tbWVudHMuIFdlIGNhbiBhZGQgaXQgYmFjayBpZiBNYXJ0aW4g KHJlc3BvbnNpYmxlIEFEKSB3YW50cyB1cyB0byBkbyBzby4NCg0KU2VjdGlvbiA5DQoNClRoZXJl IHNlZW0gdG8gYmUgc29tZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWxhdGluZyB0byB0aGUg dXNlIG9mIFBTUCwgaW4gdGhhdCB0aGUgZWdyZXNzIG5vZGUgbG9zZXMgdmlzaWJpbGl0eSBpbnRv IHdoaWNoIHBvbGljeSB3YXMgdXNlZCBmb3IgYSBnaXZlbiBwYWNrZXQsIHNvIGFsbCBwYWNrZXRz IGZyb20gYWxsIHBvbGljaWVzIHRoYXQgZWdyZXNzIHZpYSB0aGF0IFNJRCBhcmUgaW4gdGhlIHNh bWUgYW5vbnltaXR5IChhbmQgcG9saWN5ISkgc2V0LiAgSW4gcGFydGljdWxhciwgZXZlbiBpZiBh biBITUFDIFRMViB3YXMgcHJlc2VudCBpbiB0aGUgU1JILCBpdCBpcyBub3QgYXZhaWxhYmxlIGFu ZCBjYW5ub3QgYmUgdmFsaWRhdGVkLiAgSSByZWNvZ25pemUgdGhhdCB0aGUgaGVhZGVuZCAob3Ig d2hhdGV2ZXIgZW50aXR5IGlzIGFzc2lnbmluZyBTUiBwb2xpY3kpIHNob3VsZCBrbm93IHdoZW4g c3VjaCB2YWxpZGF0aW9uIHdvdWxkIGJlIGludGVuZGVkIHRvIG9jY3VyIGFuZCBub3QgYXNzaWdu IGEgcG9saWN5IGluY29tcGF0aWJsZSB3aXRoIGl0LCBidXQgdGhlcmUgYXJlIHN0aWxsIG5ldyBj b25zaWRlcmF0aW9ucyBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgaGVhZGVuZCBuZWVkcyB0byBiZSBh d2FyZSBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucy4NCg0KW1BDXSBBcyBwYXJ0IG9mIHRoZSBjb21t ZW50cyBmcm9tIEFsdmFybyB3ZSBhZGRlZCB0aGlzIHRleHQgd2hpY2ggSSBiZWxpZXZlIGNvdmVy cyB0aGF0IHBvaW50Og0K4oCcVGhlIGhlYWRlbmQgcG9saWN5IGRlZmluaXRpb24gc2hvdWxkIGJl IGNvbnNpc3RlbnQgd2l0aCB0aGUgc3BlY2lmaWMNCiAgIGJlaGF2aW9yIHVzZWQgYW5kIGFueSBs b2NhbCBjb25maWd1cmF0aW9u4oCdDQoNCihyZXBlYXRpbmcgYXMgYSBwbGFjZWhvbGRlciBmcm9t IHRoZSBwcmV2aW91cyB0aHJlYWQpIEkgdGhpbmsgd2Ugc2hvdWxkIGFsc28gc2F5IHRoYXQgaW4g dGhlIGFic2VuY2Ugb2YgdGhlIEhNQUMgVExWLCB2YWxpZCBGVU5DIGFuZCBBUkcgdmFsdWVzIG9u IGFueSBnaXZlbiBub2RlIG1heSBiZSBndWVzc2FibGUgYW5kIHNwb29mYWJsZSwgYWxvbmcgd2l0 aCB0aGUgc3RhbmRhcmQgZGlzY2xhaW1lciB0aGF0IHJpc2tzIGFyZSBtaW5pbWFsIHNpbmNlIGFs bCBub2RlcyBpbiB0aGUgU1IgZG9tYWluIGFyZSBhc3N1bWVkIHRvIGJlIHRydXN0ZWQuICBUaGlz IGlzIGRpc3RpbmN0IGZyb20gdGhlIGFscmVhZHktZXh0YW50IGFiaWxpdHkgdG8gc3Bvb2YgYSBT SUQgaW4gdGhhdCB0aGUgdW5kZXJseWluZyBzdHJ1Y3R1cmUgaW4gdGhlIFNJRCBtYXkgYWxsb3cg dGhlIGF0dGFja2VyIHRvIGluZHVjZSBiZWhhdmlvciB0aGF0IHdhcyBuZXZlciBpbnRlbmRlZCB0 byBiZSBhIFNJRCwgZm9yIGV4YW1wbGUgaWYgdGhlIGltcGxlbWVudGF0aW9uIGxvZ2ljYWxseSBz ZXBhcmF0ZXMgRlVOQyBhbmQgQVJHIHByb2Nlc3NpbmcgYW5kIHRoZSBhdHRhY2tlciBtYWtlcyBh IGNvbWJpbmF0aW9uIHRoYXQgd2FzIG5ldmVyIGFkdmVydGlzZWQuDQoNCltQQ10gSSBiZWxpZXZl IHlvdSBhcmUgbWFraW5nIGFuIGltcGxlbWVudGF0aW9uIGFzc3VtcHRpb24gb24gaG93IFNJRHMg YXJlIG1hdGNoZWQgYXQgYSBub2RlLiBBcyBhIHJlbWluZGVyIFJGQzg3NTQgc3RhdGVzIHRoYXQg 4oCcV2hlbiBhbiBTUnY2LWNhcGFibGUgbm9kZSByZWNlaXZlcyBhbiBJUHY2IHBhY2tldCwgaXQg cGVyZm9ybXMgYSBsb25nZXN0LXByZWZpeC1tYXRjaCBsb29rdXAgb24gdGhlIHBhY2tldCdzIGRl c3RpbmF0aW9uIGFkZHJlc3Mu4oCdLiBUaHVzLCB0aGUgYWJpbGl0eSB0byBzcG9vZiBhIHBhcnRp Y3VsYXIgRlVOQ1QgaXMgdGhlIHNhbWUgYXMgdGhlIGFiaWxpdHkgdG8gc3Bvb2YgYW55IG90aGVy IElQIGFkZHJlc3Mgb24gdGhlIG5vZGUuIEluIHRoZSBjb250ZXh0IG9mIFNSdjYsIHRoaXMgaXMg bWl0aWdhdGVkIGJ5IHVzaW5nIHRoZSBTUiBEb21haW4gYXMgZGVzY3JpYmVkIGluIFJGQzg3NTQg YW5kIC1pbiBwYXJ0aWN1bGFyIFNlY3Rpb24gNy4yLS4NCg0KQWxzbywgSUlVQywgdGhlICJTZWdt ZW50cyBMZWZ0ID09IDAiIGhhbmRsaW5nIGZvciwgZS5nLiwgRW5kLlggaXMgaW1wb3J0YW50IHRv IHByZXZlbnQgdHJhZmZpYyBsb29wcyAtLSBpZiBhIG5vZGUgZmFpbHMgdG8gcGVyZm9ybSB0aGF0 IGNoZWNrIGFuZCBibGluZGx5IHNlbmRzIHRoZSBwYWNrZXQgdG8gdGhlIGludGVyY29ubmVjdCBp dCB3aWxsIGdldCByZXR1cm5lZCB0byB0aGF0IG5vZGUvU0lEIGFuZCBsb29wIHVudGlsIHRoZSBJ UCBob3AgbGltaXQgaXMgZXhoYXVzdGVkLg0KDQpbUENdIEluZGVlZCwgZm9sbG93aW5nIGFsbCB0 aGUgcHNldWRvY29kZXMgYXJlIGltcG9ydGFudCBhbmQgbm90IHNraXBwaW5nIGluc3RydWN0aW9u cyBpcyBpbXBvcnRhbnQuIEJ1dCB0aGlzIGNvdWxkIGJlIHNhaWQgZm9yIG1hbnkgbGluZXMgb2Yg cHNldWRvY29kZSAtbm90IG9ubHkgZm9yIHRoYXQgY2hlY2stLiBJbiB0aGUgc2FtZSBsaW5lIHRo YXQgaXQgY291bGQgYmUgc2FpZCB0aGF0IGRlY3JlbWVudGluZyB0aGUgSVB2NiBob3AgbGltaXQg d2hlbiBwcm9jZXNzaW5nIGFuIElQdjYgcGFja2V0IGlzIGNyaXRpY2FsLiBJbiBvdGhlciB3b3Jk cywgaXQgZmVlbHMgYXdrd2FyZCB0byBhZGQgYSBwYXJ0aWN1bGFyIHJlbWluZGVyIG9ubHkgb24g dGhhdCBsaW5lIGFuZCBub3Qgb24gYW55IG90aGVyLiBBbGwgYXJlIGltcG9ydGFudC4NCg0KDQo= From nobody Mon Dec 21 09:39:49 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA5C3A1104; Mon, 21 Dec 2020 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, 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 1mIfiLeELkxG; Mon, 21 Dec 2020 09:39:37 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2131.outbound.protection.outlook.com [40.107.243.131]) (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 930763A10F2; Mon, 21 Dec 2020 09:39:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HshJGdg2csoOK0S3NnqLcIc20uSeSeXiv+4PD3Szi3Ke+M6M4ptKS69wFVvJBnOgup3+E+g5kcfCRStOY7OpRYkxcjJSc0IGg8uJkriMxQhwq9dzYAfuDKHjm+tgU3SBM3cxLX8cWjaPvvpiAnrztbpzhV7ZGvp0BTeQ5JSIprxlJdUWb5jZxmNWvsiXSib3D95AuSQMPm5AybYnMvuUMRw0Y6KHwi6vLCn5Mpb4/Y6o1mfSO3xTeaiaRt6KNDeQAVcnexJmbe9wbZLDuACq0VsFdrxDU98LuAs73xuuGd5hw8w418r7MOpxOqmfCgdC01KHGGiTHbDBSXNfb4KIlA== 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=EYB7bfhaS1Mui65oeYVFRd8GDTdnFxJeDluZF6Pcmqo=; b=Ydh7Y+LowwzLnd0V1mObY+fU4yzTo57aGQ+Lrtqw36WU/uUoSZEhBLhuWqsuG24niZHmjr7AfgEQGZ3Pvsk4opluc1OddejSvWNQsvB6JdZNkO1Dze2CnXdJb0/POblL7YPZuOAbBbTi31UEoIBZQQQxALIOPCLasc3PpR2L2LL7/w/yS3E1sdwdcIQsHSMQri3KKwI4kIoquNVJKaH3cHJzzOl+I7v4DHdy+QUz2fnfYC5Xw9W4GG6LQkLKQ4XbjxDv1RDi6cJdjcwqs4CzbssG2KXpnMoqiOxgnXFuadVIFIqn4B0OZ82C2qrqO7ZX1uh547RSxfouIFkBCvTtpg== 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=EYB7bfhaS1Mui65oeYVFRd8GDTdnFxJeDluZF6Pcmqo=; b=Ozp38XuYUPQHAslbOx4cfX1xMtQogU6LwDYmlqAGi1JVS7Kb5rLz+EQWEZ7UUHuFxHiH0kQnvjHUGsoKST6bo47zgM6KCpgvwiWGMCKqLjAAldwVbNQI9L+eda59RwHj3RGFJgMxTUJzjHi7DMYCwIZgj3zVCR5SCvMlVCcO17w= Received: from BY5PR13MB3048.namprd13.prod.outlook.com (2603:10b6:a03:188::21) by BY5PR13MB3666.namprd13.prod.outlook.com (2603:10b6:a03:22a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.10; Mon, 21 Dec 2020 17:39:33 +0000 Received: from BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::e062:2fe5:a426:5b6c]) by BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::e062:2fe5:a426:5b6c%7]) with mapi id 15.20.3700.026; Mon, 21 Dec 2020 17:39:33 +0000 From: Yingzhen Qu To: Tal Mizrahi , Yingzhen Qu CC: "rtg-ads@ietf.org" , "draft-ietf-spring-sr-yang@ietf.org" , "rtg-dir@ietf.org" , "spring@ietf.org" , "last-call@ietf.org" Thread-Topic: [RTG-DIR] RtgDir Review: draft-ietf-spring-sr-yang-28 Thread-Index: AQHWzViaG4Hb4FSo4k+7/LsRGMCDzantooqAgACkjwCAExiUAA== Date: Mon, 21 Dec 2020 17:39:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:646:9500:4d:1820:a46e:710d:93fc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82775129-1b2a-4109-f1ec-08d8a5d76119 x-ms-traffictypediagnostic: BY5PR13MB3666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4DRDnOybx4AwMMnuKuEJ1vTDCZ0/kBPi82OjHwWslMOZhpvvWAlc0wO5K+/JhMxUbpFZQCGTzGhJetP++t6Fao/FjMbT+loYWnVqSu1mHBVZmGI2q5Pos71eWHx5D29jP/vOycoY4scIz4tMt5mNbJI67/FqiAVnwnvwj0vKpX79J7Eh6F7RFlProgl4gh/oW3OmPHHmVCv9rWWWPbdsjoCWd7h9UCS7mJJfOOj92aGScTXSg5axl2cBdmOTcRI4bOPuaPJ815JpR90Gq8lU2DIvO/xInVV2wJKRUUhOiDg2PAVwlac2X4ZiBn0DIQd/Qs5+lSNLIFyDQkaNZ2q+cDwW1af9lrzZf8lW2IPpIgYN8iXbprh6Su21AI7XMInAF6k0PbVR0WjpMOP1b/v9kfqFFxNFUn/hy+d6EfEUG3qc40S/R9qZucb75gYj1NFTZ2zSYyLwR+AZDD4WQHyamV6axOIF+aICroBc2LixiMRIaaD2HokCsOL02uTqb58C68YP4WBEmC5x34A3j7uDoA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3048.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39840400004)(376002)(396003)(366004)(66946007)(44832011)(76116006)(2616005)(6512007)(66446008)(66476007)(64756008)(53546011)(316002)(71200400001)(66556008)(45080400002)(4326008)(478600001)(86362001)(33656002)(5660300002)(8936002)(8676002)(186003)(6506007)(966005)(6486002)(54906003)(36756003)(110136005)(2906002)(83380400001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?ZUNHempTVDBWS2hkTVZnaXNacVM2N0MzNnExUTFHUVNONDFwc3JiYUUxLzNr?= =?utf-8?B?VzJJZHBvMkFqZmtQMXZOSktaL1F5Y2dWYndFYXlxekgxeU92ZG0wTFZ6dWNy?= =?utf-8?B?SUg0QW5OZmwwTDJlUW9nTTRFTm81UktRYks2OU1HTEZkRWdmTVBSNzZVQVha?= =?utf-8?B?UkRURnlRb29TMndwVk9Kd0tXaHpVZDBNM1RkVmJ1eUxzUXFndzIyS1hRSjVE?= =?utf-8?B?QU84NWVDMjBuRTZOb2xnMDNGUzNOcnM3OUNOUW1wSTJhcURFSnJYbnJVMUti?= =?utf-8?B?Ynh0eEh1TmQ1Zi9hRlBsTzl2WTVvZkJzWFFlTFp0OWIxdXBJa1pmTUhCVFJH?= =?utf-8?B?NjVDbWoyS2hjRkhkUm95MEFnT3B4ckV6VFVIS3ZJbFJjRlFnRG03MGwrenZl?= =?utf-8?B?US94SHc0R1l3V0gyRjY3bDl1K2xFQmR0T29jdlZWZGJvSmlsajBMSm9vR2Fs?= =?utf-8?B?emN6VzlLUFhXaGpTK3hicmc0OTg4dXdqUENKOUU1cHRjT0c1UE5FYnp1ZDBS?= =?utf-8?B?aHc5bEpJUEwxS3RkL0NJVWk3Z1IvWHhSdGt2cSt4czM4cm9DOUh3ZlcxYXcz?= =?utf-8?B?clJZOFJoN3dHWWVFd0lkMUxiMDdBZ1NQOVN2RHNRRzB6SnMzTFZlUG9KeUN0?= =?utf-8?B?VE05UGM3UjRDRDVYa0pDZ2Q0K3hzdEJxVy9vOGIxdU5nM3R4b0YrL3VOR1F5?= =?utf-8?B?VytKMkpQNTB6ekl4dEdJU25yM3JqZ2JoVkpJd25aNHNmN2p5Z2VoM0hhcER2?= =?utf-8?B?REc1TEVld25RYVFFQTlwSXd0aVRXbG44VTRQakVYSzBYaVJuTGFlWUFsYXJn?= =?utf-8?B?UGZzMGM0Y01HVENUMitSRE1hejk1aWxOK1Iwa2E1WFBkVFBEVFExa3VSTW1V?= =?utf-8?B?bGU2MWhCQUYzTXNOTFVoMHl1bzBvZ1Bya3U2OER0RnJoYzJIaVlicVRpaTF1?= =?utf-8?B?Vzl3Sm9hQU1vRVBsSytBQW5aQnZMTTBzU3pEL3NyckVPUFgxYnh0NXo2ZjNJ?= =?utf-8?B?UjZUWmpMQlVTcVR5ckJjZWNwWnExVEpWcmhpUnVjQlU2ajFxbFJjWEFXYWJS?= =?utf-8?B?a0ZySkhVWXpPMWc4SkxJclJld2IyaWVYd3p6ZW01cEp2VENYdFZidHlPakFF?= =?utf-8?B?Qjl0ZDMyV3JKenJlSVNmbUVGdlRtZG9JTWF4QjNlUndSeWZSRkRHWUMvL01y?= =?utf-8?B?UEd1RXpsZmNPUUJjanFORThTUFRIL1pjMS8wZC85NUhMV0VwbUVReDR3SmJ3?= =?utf-8?B?Si82ZCttZDR6MzhIUWRDUmwrODRMN2R4OHQzZlBlYjRTQjBLSXRLYWJuY1lJ?= =?utf-8?B?TUxNMy9oYTJ0ZTh0ZWQ5Y0NoUVV4amVtbFBjb2czVkZaam9Pc2Rwdmc0NUNk?= =?utf-8?B?czh4LzBsUkswaFh6cExrTzVOazE3bER5SDNyeW9Md2gwUGhVMjlhb3pkQkVF?= =?utf-8?Q?fVea8fIh?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3048.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82775129-1b2a-4109-f1ec-08d8a5d76119 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2020 17:39:33.7207 (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: 3AHBh8dJ4CsYEgo0Ae/whhrE0bIdXFTJ7NITaD7r4v96LTRgLzzl7Sq+mhXhRxW20YKS1Serp9dvneUtsPQM2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3666 Archived-At: Subject: Re: [spring] [RTG-DIR] RtgDir Review: draft-ietf-spring-sr-yang-28 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 17:39:40 -0000 SGkgVGFsLA0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UuIFdlIGhhZCBhIGRpc2N1c3Np b24gYW1vbmcgdGhlIGF1dGhvcnMsIGFuZCB3ZSBhZ3JlZSB0aGF0IHdlJ2xsIGFkZCBhIGNsYWlt IHRoYXQgU1J2NiBpcyBub3Qgc3VwcG9ydGVkIGluIHRoaXMgZG9jdW1lbnQsIGJ1dCB3ZSBkb24n dCB3YW50IHRvIGFkZCBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZXMgdG8gb3RoZXIgZHJhZnRzIHRo YXQncyBhdWdtZW50aW5nIHRoZSBiYXNlIFNSIG1vZHVsZSBzaW5jZSB0aGlzIGlzIG5vdCBjb250 cm9sbGVkIGJ5IHRoZSBiYXNlIG1vZHVsZS4gDQoNCklmIHlvdSBkb24ndCBtaW5kLCB3ZSdsbCBh ZGQgdGhlIGNsYWltIGluIHRoZSBuZXh0IHZlcnNpb24gdG9nZXRoZXIgd2l0aCBvdGhlciByZXZp ZXcgY29tbWVudHMuIFBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgb3RoZXIgY29t bWVudHMuDQoNClRoYW5rcywNCllpbmd6aGVuDQoNCu+7v09uIDEyLzgvMjAsIDEwOjAyIFBNLCAi VGFsIE1penJhaGkiIDx0YWwubWl6cmFoaS5waGRAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEhp IFlpbmd6aGVuLA0KDQogICAgVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuDQoNCiAgICBQ bGVhc2Ugc2VlIGJlbG93Lg0KDQoNCiAgICA+ICBbWWluZ3poZW5dOiB5ZXMsIHRoaXMgZG9jdW1l bnQgZm9jdXNlcyBvbiB0aGUgU1ItTVBMUyBkYXRhIHBsYW5lLiBIb3dldmVyIHRoZXJlIGlzIGll dGYtc2VnbWVudC1yb3V0aW5nLnlhbmcgbW9kdWxlIGRlZmluZWQgYXMgdGhlIGdlbmVyaWMgZnJh bWUsIHdoaWNoIGlzIG1lYW50IHRvIGJlIGF1Z21lbnRlZCBieSBkaWZmZXJlbnQgZGF0YSBwbGFu ZXMsIGluY2x1ZGluZyBib3RoIFNSLU1QTFMgYW5kIFNSdjYuIFRoaXMgd2FzIHRoZSBjb25zZW5z dXMgYmV0d2VlbiB0aGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IGFuZCBhdXRob3JzIG9mIFNSdjYg WUFORyBtb2RlbC4gSWYgeW91IHRoaW5rIHRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIGlz IG5vdCBjbGVhciwgcGxlYXNlIGxldCB1cyBrbm93Lg0KDQogICAgUmlnaHQuIEkgYmVsaWV2ZSB0 aGlzIHBvaW50IHNob3VsZCBiZSBjbGFyaWZpZWQgaW4gdGhlIGludHJvZHVjdGlvbg0KICAgIHdp dGggYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoZSBTUnY2IFlBTkcgZHJhZnQuDQoNCg0K ICAgID4gW1lpbmd6aGVuXTogIGZvciBpbmdyZXNzL2VncmVzcyBub2RlcywgZG8geW91IG1lYW4g U1IgcG9saWN5PyB3aGljaCBpcyBkZWZpbmVkIGluIGEgc2VwYXJhdGUgZHJhZnQ6IGh0dHBzOi8v bmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LXJhemEtc3ByaW5nLXNyLXBvbGljeS15YW5n LTAzJmFtcDtkYXRhPTA0JTdDMDElN0N5aW5nemhlbi5xdSU0MGZ1dHVyZXdlaS5jb20lN0MxYTk3 NTYzMGVhNzQ0NDE3NDA0YzA4ZDg5YzA4MTJhMCU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1 OTFmZWRjJTdDMSU3QzElN0M2Mzc0MzA5MDU3NzQxMDkwNDMlN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9WVdBU05ianFRY0FvZjUlMkJPVGJ3dzI5NkRK ZDJaJTJCN2pGeUg0NFpRUTlHR2MlM0QmYW1wO3Jlc2VydmVkPTANCg0KICAgIFJpZ2h0LCBhZ2Fp biBJIHN1Z2dlc3QgdG8gY2xhcmlmeSB0aGlzIHBvaW50IGluIHRoZSBkcmFmdC4NCg0KDQogICAg Q2hlZXJzLA0KICAgIFRhbC4NCg0KDQoNCiAgICBPbiBUdWUsIERlYyA4LCAyMDIwIGF0IDEwOjEz IFBNIFlpbmd6aGVuIFF1IDx5aW5nemhlbi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPg0K ICAgID4gSGkgVGFsLA0KICAgID4NCiAgICA+IFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5k IGNvbW1lbnRzLCB3ZSBoYXZlIHB1Ymxpc2hlZCB2ZXJzaW9uIC0yOSB0byBhZGRyZXNzIHlvdXIg Y29tbWVudHMuIFBsZWFzZSBzZWUgbXkgZGV0YWlsZWQgYW5zd2VycyBiZWxvdyBpbmxpbmUuDQog ICAgPg0KICAgID4gVGhhbmtzLA0KICAgID4gWWluZ3poZW4NCiAgICA+DQogICAgPiBPbiBUdWUs IERlYyA4LCAyMDIwIGF0IDM6NTIgQU0gVGFsIE1penJhaGkgPHRhbC5taXpyYWhpLnBoZEBnbWFp bC5jb20+IHdyb3RlOg0KICAgID4+DQogICAgPj4gSGVsbG8sDQogICAgPj4NCiAgICA+PiBJIGhh dmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3Ig dGhpcw0KICAgID4+IGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZp ZXcgYWxsIHJvdXRpbmcgb3INCiAgICA+PiByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHDQogICAgPj4gcmV2aWV3LCBhbmQg c29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBp cw0KICAgID4+IHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0DQogICAgPj4gdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUNCiAgICA+PiBodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnRyYWMudG9vbHMuaWV0Zi5vcmclMkZhcmVhJTJGcnRn JTJGdHJhYyUyRndpa2klMkZSdGdEaXImYW1wO2RhdGE9MDQlN0MwMSU3Q3lpbmd6aGVuLnF1JTQw ZnV0dXJld2VpLmNvbSU3QzFhOTc1NjMwZWE3NDQ0MTc0MDRjMDhkODljMDgxMmEwJTdDMGZlZThm ZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzQzMDkwNTc3NDEwOTA0MyU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1yMUxQMHo4 ZjN1dm03alJWWGtrMjBhbk54T1kyazE1bnkzJTJGbmk1YUVqMWclM0QmYW1wO3Jlc2VydmVkPTAN CiAgICA+Pg0KICAgID4+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLA0KICAgID4+IGl0IHdvdWxkIGJlIGhlbHBmdWwg aWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXINCiAgICA+PiBJ RVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbQ0KICAgID4+IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUg ZHJhZnQuDQogICAgPj4NCiAgICA+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFu Zy0yOA0KICAgID4+IFJldmlld2VyOiBUYWwgTWl6cmFoaQ0KICAgID4+IFJldmlldyBEYXRlOiAw OC1EZWMtMjAyMA0KICAgID4+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQogICAg Pj4NCiAgICA+Pg0KICAgID4+IFN1bW1hcnk6DQogICAgPj4gSSBoYXZlIHNvbWUgbWlub3IgY29u Y2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlDQogICAgPj4g cmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KICAgID4+DQogICAgPj4NCiAgICA+PiBDb21t ZW50czoNCiAgICA+PiBUaGUgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3Ig TVBMUyBzZWdtZW50IHJvdXRpbmcuIFRoZQ0KICAgID4+IGRvY3VtZW50IGlzIGluIGdvb2Qgc2hh cGUsIGFuZCBJIGJlbGlldmUgaXQgaXMgYWxtb3N0IHJlYWR5IGZvcg0KICAgID4+IHB1YmxpY2F0 aW9uLg0KICAgID4+DQogICAgPj4gTXkgY29tbWVudHMgYXJlIG1haW5seSBhYm91dCB0aGUgbmVl ZCBmb3IgYSBjbGVhciBkZWZpbml0aW9uIG9mIHRoZQ0KICAgID4+IHNjb3BlIG9mIHRoZSBkb2N1 bWVudC4gV2hpbGUgdGhlc2UgY29tbWVudHMgZG8gbm90IHJlcXVpcmUgbWFqb3INCiAgICA+PiBj aGFuZ2VzIGluIHRoZSBkb2N1bWVudCwgYSBiaXQgb2YgcmVwaHJhc2luZyBhbmQgY2xhcmlmeWlu ZyB0ZXh0IHdpbGwNCiAgICA+PiBnbyBhIGxvbmcgd2F5IGhlcmUuDQogICAgPj4NCiAgICA+Pg0K ICAgID4+IElzc3VlczoNCiAgICA+PiAtIFRoZSBkb2N1bWVudCBpcyBmb2N1c2VkIG9uIFNSLU1Q TFMsIHdoaWxlIFJGQzg0MDIgZGlzY3Vzc2VzIGJvdGgNCiAgICA+PiBTUi1NUExTIGFuZCBTUnY2 LiBJIGFtIHN1cmUgdGhlcmUgaXMgYSBnb29kIHJlYXNvbiBmb3IgdGhpcywgYnV0IGl0IGlzDQog ICAgPj4gaW1wb3J0YW50IHRvIHBvaW50IG91dCBhdCB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhl IGRvY3VtZW50IHRoYXQgaXQNCiAgICA+PiBkb2VzIG5vdCBjb3ZlciBTUnY2IGFuZCBwcmVmZXJh Ymx5IGFsc28gdGhlIHJlYXNvbiBmb3IgdGhpcy4NCiAgICA+DQogICAgPg0KICAgID4gIFtZaW5n emhlbl06IHllcywgdGhpcyBkb2N1bWVudCBmb2N1c2VzIG9uIHRoZSBTUi1NUExTIGRhdGEgcGxh bmUuIEhvd2V2ZXIgdGhlcmUgaXMgaWV0Zi1zZWdtZW50LXJvdXRpbmcueWFuZyBtb2R1bGUgZGVm aW5lZCBhcyB0aGUgZ2VuZXJpYyBmcmFtZSwgd2hpY2ggaXMgbWVhbnQgdG8gYmUgYXVnbWVudGVk IGJ5IGRpZmZlcmVudCBkYXRhIHBsYW5lcywgaW5jbHVkaW5nIGJvdGggU1ItTVBMUyBhbmQgU1J2 Ni4gVGhpcyB3YXMgdGhlIGNvbnNlbnN1cyBiZXR3ZWVuIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJh ZnQgYW5kIGF1dGhvcnMgb2YgU1J2NiBZQU5HIG1vZGVsLiBJZiB5b3UgdGhpbmsgdGhlIGFic3Ry YWN0IGFuZCBpbnRyb2R1Y3Rpb24gaXMgbm90IGNsZWFyLCBwbGVhc2UgbGV0IHVzIGtub3cuDQog ICAgPg0KICAgID4+DQogICAgPj4gLSBJdCBpcyBpbXBvcnRhbnQgdG8gY2xhcmlmeSB0aGUgc2Nv cGUgb2YgdGhlIFlBTkcgbW9kZWxzIGluIHRoZQ0KICAgID4+IGludHJvZHVjdGlvbjogZG8gdGhl eSByZWZlciBvbmx5IHRvIFNSIHJvdXRlcnMsIG9yIGFsc28gdG8gU1INCiAgICA+PiBpbmdyZXNz L2VncmVzcyBub2Rlcz8NCiAgICA+DQogICAgPg0KICAgID4gW1lpbmd6aGVuXTogIGZvciBpbmdy ZXNzL2VncmVzcyBub2RlcywgZG8geW91IG1lYW4gU1IgcG9saWN5PyB3aGljaCBpcyBkZWZpbmVk IGluIGEgc2VwYXJhdGUgZHJhZnQ6IGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRy YWZ0LXJhemEtc3ByaW5nLXNyLXBvbGljeS15YW5nLTAzJmFtcDtkYXRhPTA0JTdDMDElN0N5aW5n emhlbi5xdSU0MGZ1dHVyZXdlaS5jb20lN0MxYTk3NTYzMGVhNzQ0NDE3NDA0YzA4ZDg5YzA4MTJh MCU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzElN0M2Mzc0MzA5MDU3 NzQxMDkwNDMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pR SWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2Rh dGE9WVdBU05ianFRY0FvZjUlMkJPVGJ3dzI5NkRKZDJaJTJCN2pGeUg0NFpRUTlHR2MlM0QmYW1w O3Jlc2VydmVkPTANCiAgICA+DQogICAgPj4NCiAgICA+PiAtIFRoZSBDb21tb24gVHlwZXMgbW9k dWxlIGlzIG1lbnRpb25lZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gU2VjdGlvbg0KICAgID4+IDgu IEl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIG1lbnRpb24gaXQgYW5kIGRlc2NyaWJlIGl0cyBw dXJwb3NlIGluDQogICAgPj4gU2VjdGlvbiAzLg0KICAgID4NCiAgICA+DQogICAgPiBbWWluZ3po ZW5dOiBHb29kIHN1Z2dlc3Rpb24uIEkgYWRkZWQgYSBzbWFsbCBwYXJhZ3JhcGggZm9yIHRoZSBj b21tb24geWFuZyBtb2R1bGUuDQogICAgPg0KICAgID4+DQogICAgPj4gLSBJbiB0aGUgZm9sbG93 aW5nIHRleHQgaXQgd291bGQgYmUgbW9yZSBhY2N1cmF0ZSB0byByZXBsYWNlOiAid2l0aA0KICAg ID4+IFNlZ21lbnQgUm91dGluZyAoU1IpLiIgPT0+ICJ3aXRoIE1QTFMgU2VnbWVudCBSb3V0aW5n IChTUikuIg0KICAgID4+DQogICAgPj4gICAgICAgICAgIlRoaXMgYXVnbWVudHMgcm91dGluZyBk YXRhIG1vZGVsIChSRkMgODM0OSkNCiAgICA+PiAgICAgICAgICAgd2l0aCBTZWdtZW50IFJvdXRp bmcgKFNSKS4iOw0KICAgID4+DQogICAgPiBbWWluZ3poZW5dOiBmaXhlZC4NCiAgICA+DQoNCg== From nobody Tue Dec 22 11:22:12 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0253A1228; Tue, 22 Dec 2020 11:22:10 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=eDousKSQ; dkim=pass (1024-bit key) header.d=juniper.net header.b=bKuKHLTe 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 WXsoZkYo58Mt; Tue, 22 Dec 2020 11:22:08 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 3F06D3A1182; Tue, 22 Dec 2020 11:22:07 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BMJJAT5030910; Tue, 22 Dec 2020 11:22:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=eW3idy8LpPckQ8b9Wjoup0pEi+5nGm2E4v02hyi1pYg=; b=eDousKSQSUU3f11msrht3TlCsmD6gybl5Fqllt4GEIK4nZP4k9U/KMJvo7veNGaiel9L oh0OP577YEma3OATsm1PziIC2mEFEaWEhJQFOuX5LMERkyu0W09MkplRU0NgfnlCL3WV h059ia7i49odpu9RTOlMHmjtsWa2sMU3hGO8xkoJ18G3TE+/mLFjJDJptc4UMyzQck4M znRNiptfu7AwozbHId3PqGNQk8ktUEu7V4p5DIY7TafDQtLi82Bi6F8Qh6jvxehg9QCs zCo5mlTL5SZsvNET2Htl9im2TCdDGf+hvR/7v2hnLziYd4O3l/+7xX85t4j+E4DQr9Ua Kw== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2046.outbound.protection.outlook.com [104.47.74.46]) by mx0a-00273201.pphosted.com with ESMTP id 35k0fe21hs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Dec 2020 11:22:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nPPtOblZgI98bE48/aItJxcxSmCVD+8758jZ26DmBFIfNz1NFIm1XVutSw9Coz0k0+qHEXmcFuIVU+EAFy/0JfK2QMKeijebP4BV0tYA7gNIZX6Nw23Mq2m0zH9UhHcsqCjewr/eqWruW08hYCsyez6Es49SVIJS/uC1fWte33lD5hp6xioeAbJHr24SXXBnhqDmtRx2fh3CqXJuDeLx6cJWkD25zmGBLiAqO4FLQkgydPrDjGlPJKulbJWiAIBjejmHvXF7xZf/TNix/GQF3OXzAiYsDtoY4MSpEMvjUy/bT99F17TkasR/+3cSHAyVmbSZU1RCPXXtTHl3KOMHSg== 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=eW3idy8LpPckQ8b9Wjoup0pEi+5nGm2E4v02hyi1pYg=; b=PYV2uaTXXpnzZBfKEQEMHPuHNlllufAP655XehmbmIfkRdnyNyU9X5bzPzLPtoqdSodaygPFcOg+6ubGAIhi64yYtC5fmDW1dF932Xvh6LBwjMeXKzelUk/A+gfUvvbrOYD/Eu2d0G5zy/39GFSh0lwEN2/gGweyBm+uqizaPHcj8weA/hFm4KvyW5fnkZM7nt+yzDOuI2Yo1Pf3sStmIMXN+IJ/OWcVFJxlvyw46dNPK8Aa5J8yR3T58os3aFWtKFtIIsGIm02IjBGP8onv1dx+I5/xe5UyCF7ScDkE0yKE3xnvUPkZWwPvjYQ9U7wukynco3HZBbV9XDu5imXvWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eW3idy8LpPckQ8b9Wjoup0pEi+5nGm2E4v02hyi1pYg=; b=bKuKHLTeW4eStS3U3e8SR/qb+WGLkyjsNcvX6QrEmra8jPgIdkbwkPuNUTvVNDLrUi1Wf4imYn91Wb6veU7SOtgVv+3FQczZ8Zr1hHwavVShKrGCZHTAjaiU/qqhiMXYUjOBsnmhY99tiRLNSxgt4aut+j90VlHBdnq3RQeET2I= Received: from BYAPR05MB4136.namprd05.prod.outlook.com (2603:10b6:a02:85::18) by BYAPR05MB6120.namprd05.prod.outlook.com (2603:10b6:a03:df::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.21; Tue, 22 Dec 2020 19:22:04 +0000 Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::1ee:5d65:c857:e2a2]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::1ee:5d65:c857:e2a2%3]) with mapi id 15.20.3700.026; Tue, 22 Dec 2020 19:22:04 +0000 From: Tarek Saad To: "spring@ietf.org" CC: "draft-bestbar-spring-scalable-ns@ietf.org" Thread-Topic: New Version Notification for draft-bestbar-spring-scalable-ns-00.txt Thread-Index: AQHW0+i7Eh6OCiyU2UigDylUXH48xKoDM86A Date: Tue, 22 Dec 2020 19:22:04 +0000 Message-ID: References: <160814995342.30546.18446043186607190952@ietfa.amsl.com> In-Reply-To: <160814995342.30546.18446043186607190952@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=2961bc9c-5e09-4668-9469-978ddb16246c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-12-22T19:21:23Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c3ae2eab-1877-4781-5e6d-08d8a6aedd79 x-ms-traffictypediagnostic: BYAPR05MB6120: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qRnfg5Y7ugNtLRb2gYjkldssxVem7/Q+ImEdbjFhlPnd2xGMBMWRs9MxgxZDhCUU1yEZSh1uTrukieUZSfX9bVaxa0P7imRVut/O0QOd5euyWIiiWehd0E3YzHzIq8+ipzlGg2VPHxLMaGtyvDLV7hMFgNhc5X4WqU88xMKXdLlCxQP1pyWtL8oqUWcGjl4HUd9EBsntBpDkrdx+v4KPQ5neiQBOT2HSAMUklD3xiAK3wh9ZZMDBkvg2yD0Co+9HxdyPpz8W5X6QzafbAN2D8JXL21DOa66YlPOk1aYCjEbmSJHgzZaL+Gjd+LNwYspa7u6pNeDFDHrCvywDuuaT5uroiSZn0fgOZ2AqMEIBvQJB+xLfwXYd4yFoUeo3oLWjvGxDvY7rG2vCIqBNAuUgF6Ff0VxMO2P0SV2n5iC2S6z7OvlC62BNQgpZOWTqXYRFdV8qnoPLAx3Tgt8Eb8SSInMI1XeGgM+N8qPlpNdvPdmD+oi/qBotP3Ox380n1FRIsidCv7i5RQekoezy855U4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(83380400001)(4001150100001)(450100002)(66574015)(6506007)(478600001)(6916009)(71200400001)(36756003)(8936002)(966005)(33656002)(8676002)(6512007)(6486002)(316002)(86362001)(66946007)(64756008)(66446008)(66556008)(91956017)(66476007)(2616005)(5660300002)(26005)(4326008)(186003)(2906002)(76116006)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?TzNRZjdhazhyRlUvK3VYMGN6QVkzR0lRZ3RVbHZKSDd1bm9iSE5YVmVDMDZo?= =?utf-8?B?dHFXWThZT1lDQjlJYjhxR3ZLWFI4aE1XTjkyWVBkMVAwOXdRa2NvNkdULzhl?= =?utf-8?B?VkhxeXZQMkhDY2tYZGlZVHQrb2hEd2NRY3R2VXcrYkJ0VzR0TlJndkRaS01y?= =?utf-8?B?UmNWNXNNRTBnbmNkVUQwbVBnL1lzaHA4dlZvWkU4TXRQUFFRUmlxMVVyVUxJ?= =?utf-8?B?bUg1T0R6dkwrcWNpZEIyWUV5eHZobjc5ZGh5Q2UrRTlna1RIOGVrYWVRMEJ5?= =?utf-8?B?WitJOHFmSDQzZC9adUg2bDhXNzBUZDc0cG92MVYwZ2N0NTRBUjhoeU1ZRDdZ?= =?utf-8?B?a1VDK1ora3B4c3RZeEJXcEhlL2RQeVEvMGFHQlpDWXB5OHF4MjJFcElUdW5H?= =?utf-8?B?VjMrUm1iMkYydUFxYXoyMHE2cWlvL3pGbkRlNWtZaVk0TlAvM0RjbGhybHBQ?= =?utf-8?B?OHV1empLSWtpYkZFcDJLT201R0lvNVgrdVBqWXBHY3VNbjQwZGxsZ3puNksy?= =?utf-8?B?UTkyQzhWc21wQlZmdjM1SXA5bTdyakRQS2FUdkxQR1Z3UVJBcEdCMEIxSGNH?= =?utf-8?B?cUZxSEZqOXVhQ3gzQU9IRXZoM2VCa3dwM0xud0xQZzY5ZmtzaGd0NXVxVDNL?= =?utf-8?B?QnNVNnV5MytMaWc5dVVGOEdZMXZwVnNMWU1OMkwvU2tmNEtnUWZyY2dNQ3hz?= =?utf-8?B?b0FnbG9jUS9mVVUyaGpvRGxJWU9YR3Nsd0FCZXdTTXZwT3hrWjJ4RmhORkJs?= =?utf-8?B?em1ER2VYcnYvVWtGYjlwRC9kbDFqVEpDK3p1VVhaVFY2Q2FRdTF0NGJtQWtH?= =?utf-8?B?Uld6aGNLREgvOTQwUTR5dGtJMEhUdkdxZStEYytRSjMxQ2tOMU1jdE5IVHpI?= =?utf-8?B?cHNOWXd3bFFaVTlZVUVVMXdITkEyNGtmNU9hNlZnMlpHaFlKeWVnVTdQQXFx?= =?utf-8?B?cjRlN2NmSW5iekZ1TWpuTVJCdFlYbHZSNmo4WVRSZEZkRUlZc3U5U1hBVDRN?= =?utf-8?B?eThDaTgvU3RtTU92M3NscGRoZzIrd2h0ZXBJbmJxUENuZ013REx0WitDeG5G?= =?utf-8?B?SzFiN2Y3OTVVREV0MlJnOFk5djFNY0MxSzh6NG82WUg0WGN5elZRdHAwcGwz?= =?utf-8?B?ZWR0NEhMNzFtUnlpcWNiM21wMk03VS9ONUk3NHNtN3VTU0xsT2JXZEROZXF1?= =?utf-8?B?K2lNbmhxQ3lETzdtakRwUm5zOFNwejVGbmxPNDVoVEI3dUxDWEFmWGNSVVp5?= =?utf-8?B?a3IyN1JXU3VXb2VsSTR5aWJUcDY4Wk9ZY3JZV3R0S3BKK3BqYnV2d3hvaE9Q?= =?utf-8?Q?k07lN3MH1BwkCJMM0z2ELWZTXXCg75cT8u?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A3D8AAA4096B4B6B9BAD914D708D80BEjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3ae2eab-1877-4781-5e6d-08d8a6aedd79 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 19:22:04.1865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IOtlDNlDU+RLAsIHC2hmdf0atmUENZnZMj3vhn3frj1HkkDrL0cgd94hjqnuuV6Dz548CXgX+xM4jXNZA8VazA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6120 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-22_10:2020-12-21, 2020-12-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 impostorscore=0 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012220140 Archived-At: Subject: Re: [spring] New Version Notification for draft-bestbar-spring-scalable-ns-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 19:22:10 -0000 --_000_A3D8AAA4096B4B6B9BAD914D708D80BEjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0csDQoNClRoaXMgZHJhZnQgZGlzY3Vzc2VzIHNjYWxhYmxlIG1lY2hhbmlzbXMgdG8gcmVh bGl6ZSBuZXR3b3JrIHNsaWNpbmcgaW4gU1IgbmV0d29ya3MuDQpJdCBpbnRyb2R1Y2VzIHR3byBt ZWNoYW5pc21zIHRvIGFjaGlldmUgdGhpczoNCg0KICAqICAgQWJpbGl0eSB0byBhbGxvY2F0ZSBt dWx0aXBsZSBzbGljZSBTSURzIGZvciB0aGUgc2FtZSBwcmVmaXggdGhhdCBzaGFyZSB0aGUgc2Ft ZSB1bmRlcmx5aW5nIHRvcG9sb2d5Lg0KICAqICAgUmVseWluZyBvbiBhIGdsb2JhbCBuZXR3b3Jr IHNsaWNlIGlkZW50aWZpZXIgdGhhdCBjYW4gYmUgY2FycmllZCBpbiBwYWNrZXRzIGZvcndhcmRl ZCBvdmVyIGEgbmV0d29yayBzbGljZSBpbiBhbiBJUC9NUExTIFNSIG5ldHdvcmsuDQoNClBsZWFz ZSByZXZpZXcgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGNvbW1lbnRzLg0KDQpSZWdhcmRz LA0KVGFyZWsvUGF2YW4NCg0KDQoNCg0KDQrvu79PbiAxMi8xNi8yMCwgMzoxOSBQTSwgImludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoN Cg0KDQogICAgW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQoNCg0K DQoNCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVzdGJhci1zcHJpbmctc2NhbGFi bGUtbnMtMDAudHh0DQoNCiAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRh cmVrIFNhYWQgYW5kIHBvc3RlZCB0byB0aGUNCg0KICAgIElFVEYgcmVwb3NpdG9yeS4NCg0KDQoN CiAgICBOYW1lOiAgICAgICAgICAgZHJhZnQtYmVzdGJhci1zcHJpbmctc2NhbGFibGUtbnMNCg0K ICAgIFJldmlzaW9uOiAgICAgICAwMA0KDQogICAgVGl0bGU6ICAgICAgICAgIFNjYWxhYmxlIE5l dHdvcmsgU2xpY2luZyBvdmVyIFNSIE5ldHdvcmtzDQoNCiAgICBEb2N1bWVudCBkYXRlOiAgMjAy MC0xMi0xNg0KDQogICAgR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQog ICAgUGFnZXM6ICAgICAgICAgIDEwDQoNCiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVz dGJhci1zcHJpbmctc2NhbGFibGUtbnMtMDAudHh0X187ISFORXQ2eU1hTy1nayFUY1lSdU5DcWpH N1VNN3p4ZDRPaDUxTTdjTVRDZzNKV1REc1RQTko0ejAxYVhwdllwTXVHaks3UDlkeVNDZyQNCg0K ICAgIFN0YXR1czogICAgICAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVzdGJhci1zcHJpbmctc2NhbGFibGUtbnMv X187ISFORXQ2eU1hTy1nayFUY1lSdU5DcWpHN1VNN3p4ZDRPaDUxTTdjTVRDZzNKV1REc1RQTko0 ejAxYVhwdllwTXVHaks3WEJnejQ4QSQNCg0KICAgIEh0bWxpemVkOiAgICAgICBodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1iZXN0YmFyLXNwcmluZy1zY2FsYWJsZS1uc19fOyEhTkV0NnlNYU8tZ2shVGNZUnVOQ3Fq RzdVTTd6eGQ0T2g1MU03Y01UQ2czSldURHNUUE5KNHowMWFYcHZZcE11R2pLNDhHbDVEMnckDQoN CiAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXN0YmFyLXNwcmluZy1zY2FsYWJsZS1ucy0wMF9f OyEhTkV0NnlNYU8tZ2shVGNZUnVOQ3FqRzdVTTd6eGQ0T2g1MU03Y01UQ2czSldURHNUUE5KNHow MWFYcHZZcE11R2pLNHRDUmJwTWckDQoNCg0KDQoNCg0KICAgIEFic3RyYWN0Og0KDQogICAgICAg TXVsdGlwbGUgbmV0d29yayBzbGljZXMgY2FuIGJlIHJlYWxpemVkIG9uIHRvcCBvZiBhIHNpbmds ZSBzaGFyZWQNCg0KICAgICAgIG5ldHdvcmsuICBBIHJvdXRlciB0aGF0IHJlcXVpcmVzIGZvcndh cmRpbmcgb2YgYSBwYWNrZXQgdGhhdCBiZWxvbmdzDQoNCiAgICAgICB0byBhIG5ldHdvcmsgc2xp Y2UgbWF5IGhhdmUgdG8gZGVjaWRlIG9uIHRoZSBmb3J3YXJkaW5nIGFjdGlvbiB0bw0KDQogICAg ICAgdGFrZSBiYXNlZCBvbiBzZWxlY3RlZCBuZXh0LWhvcChzKSwgYW5kIHRoZSBmb3J3YXJkaW5n IHRyZWF0bWVudA0KDQogICAgICAgKGUuZy4gc2NoZWR1bGluZyBhbmQgZHJvcCBwb2xpY3kpIHRv IGVuZm9yY2UgYmFzZWQgb24gdGhlIHNsaWNlDQoNCiAgICAgICBhZ2dyZWdhdGUgcGVyLWhvcCBi ZWhhdmlvci4gIFNlZ21lbnQgUm91dGluZyBpcyBhIHRlY2hub2xvZ3kgdGhhdA0KDQogICAgICAg ZW5hYmxlcyB0aGUgc3RlZXJpbmcgb2YgcGFja2V0cyBpbiBhIG5ldHdvcmsgYnkgZW5jb2Rpbmcg cHJlLQ0KDQogICAgICAgZXN0YWJsaXNoZWQgc2VnbWVudHMgd2l0aGluIHRoZSBuZXR3b3JrIGlu dG8gdGhlIHBhY2tldCBoZWFkZXIuICBUaGlzDQoNCiAgICAgICBkb2N1bWVudCBpbnRyb2R1Y2Vz IG1lY2hhbmlzbXMgdG8gZW5hYmxlIGZvcndhcmRpbmcgb2YgcGFja2V0cyBvdmVyIGENCg0KICAg ICAgIHNwZWNpZmljIG5ldHdvcmsgc2xpY2UgYWxvbmcgYSBTZWdtZW50IFJvdXRpbmcgKFNSKSBw YXRoLg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCg0KICAgIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNCg0KDQogICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQoNCkp1 bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg== --_000_A3D8AAA4096B4B6B9BAD914D708D80BEjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6MTMxNDk0NTM3NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMzY3Nzc1NzQ7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+SGkgV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMg ZHJhZnQgZGlzY3Vzc2VzIHNjYWxhYmxlIG1lY2hhbmlzbXMgdG8gcmVhbGl6ZSBuZXR3b3JrIHNs aWNpbmcgaW4gU1IgbmV0d29ya3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JdCBpbnRyb2R1Y2VzIHR3byBtZWNo YW5pc21zIHRvIGFjaGlldmUgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkFiaWxpdHkgdG8gYWxsb2Nh dGUgbXVsdGlwbGUgc2xpY2UgU0lEcyBmb3IgdGhlIHNhbWUgcHJlZml4IHRoYXQgc2hhcmUgdGhl IHNhbWUgdW5kZXJseWluZyB0b3BvbG9neS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UmVseWlu ZyBvbiBhIGdsb2JhbCBuZXR3b3JrIHNsaWNlIGlkZW50aWZpZXIgdGhhdCBjYW4gYmUgY2Fycmll ZCBpbiBwYWNrZXRzIGZvcndhcmRlZCBvdmVyIGEgbmV0d29yayBzbGljZSBpbiBhbiBJUC9NUExT IFNSIG5ldHdvcmsuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGxlYXNlIHJldmll dyBhbmQgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UYXJlay9QYXZhbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij7vu79PbiAxMi8xNi8yMCwgMzoxOSBQTSwgJnF1b3Q7aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnJnF1b3Q7ICZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVzdGJh ci1zcHJpbmctc2NhbGFibGUtbnMtMDAudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBUYXJlayBTYWFkIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSUVURiByZXBvc2l0b3J5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTmFtZTombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZHJhZnQtYmVzdGJhci1zcHJpbmctc2NhbGFibGUtbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBSZXZpc2lvbjombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2NhbGFibGUgTmV0d29yayBTbGljaW5n IG92ZXIgU1IgTmV0d29ya3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyBEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDIwLTEyLTE2PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgR3Jv dXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVSTDombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt YmVzdGJhci1zcHJpbmctc2NhbGFibGUtbnMtMDAudHh0X187ISFORXQ2eU1hTy1nayFUY1lSdU5D cWpHN1VNN3p4ZDRPaDUxTTdjTVRDZzNKV1REc1RQTko0ejAxYVhwdllwTXVHaks3UDlkeVNDZyQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyBTdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1iZXN0YmFyLXNwcmluZy1zY2FsYWJsZS1ucy9fXzshIU5FdDZ5TWFPLWdrIVRj WVJ1TkNxakc3VU03enhkNE9oNTFNN2NNVENnM0pXVERzVFBOSjR6MDFhWHB2WXBNdUdqSzdYQmd6 NDhBJDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1iZXN0YmFyLXNwcmluZy1zY2FsYWJsZS1uc19fOyEhTkV0NnlNYU8tZ2shVGNZ UnVOQ3FqRzdVTTd6eGQ0T2g1MU03Y01UQ2czSldURHNUUE5KNHowMWFYcHZZcE11R2pLNDhHbDVE MnckPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgSHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YmVzdGJhci1zcHJpbmctc2NhbGFibGUtbnMtMDBfXzshIU5FdDZ5TWFPLWdrIVRjWVJ1TkNxakc3 VU03enhkNE9oNTFNN2NNVENnM0pXVERzVFBOSjR6MDFhWHB2WXBNdUdqSzR0Q1JicE1nJDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBBYnN0cmFjdDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBNdWx0aXBsZSBuZXR3b3JrIHNsaWNlcyBjYW4gYmUgcmVhbGl6ZWQgb24gdG9wIG9m IGEgc2luZ2xlIHNoYXJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldHdvcmsuJm5ic3A7IEEgcm91 dGVyIHRoYXQgcmVxdWlyZXMgZm9yd2FyZGluZyBvZiBhIHBhY2tldCB0aGF0IGJlbG9uZ3M8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0byBhIG5ldHdvcmsgc2xpY2UgbWF5IGhhdmUgdG8gZGVjaWRlIG9u IHRoZSBmb3J3YXJkaW5nIGFjdGlvbiB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRha2UgYmFzZWQg b24gc2VsZWN0ZWQgbmV4dC1ob3AocyksIGFuZCB0aGUgZm9yd2FyZGluZyB0cmVhdG1lbnQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAoZS5nLiBzY2hlZHVsaW5nIGFuZCBkcm9wIHBvbGljeSkgdG8gZW5m b3JjZSBiYXNlZCBvbiB0aGUgc2xpY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZ2dyZWdhdGUgcGVy LWhvcCBiZWhhdmlvci4mbmJzcDsgU2VnbWVudCBSb3V0aW5nIGlzIGEgdGVjaG5vbG9neSB0aGF0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5hYmxlcyB0aGUgc3RlZXJpbmcgb2YgcGFja2V0cyBpbiBh IG5ldHdvcmsgYnkgZW5jb2RpbmcgcHJlLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVzdGFibGlzaGVk IHNlZ21lbnRzIHdpdGhpbiB0aGUgbmV0d29yayBpbnRvIHRoZSBwYWNrZXQgaGVhZGVyLiZuYnNw OyBUaGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9jdW1lbnQgaW50cm9kdWNlcyBtZWNoYW5pc21z IHRvIGVuYWJsZSBmb3J3YXJkaW5nIG9mIHBhY2tldHMgb3ZlciBhPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc3BlY2lmaWMgbmV0d29yayBzbGljZSBhbG9uZyBhIFNlZ21lbnQgUm91dGluZyAoU1IpIHBh dGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBJRVRG IFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8YnI+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250 LXNpemU6N3B0O2NvbG9yOiMwMDAwMDA7bWFyZ2luOjE1cHQ7IiBhbGlnbj0iQ2VudGVyIj4NCkp1 bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHk8YnI+DQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A3D8AAA4096B4B6B9BAD914D708D80BEjunipernet_-- From nobody Tue Dec 22 20:04:43 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846903A0978; Tue, 22 Dec 2020 20:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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=A9HHnzbr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t6K66tmq 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 WDo6F4RvZFEA; Tue, 22 Dec 2020 20:04:38 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D684F3A0977; Tue, 22 Dec 2020 20:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44394; q=dns/txt; s=iport; t=1608696277; x=1609905877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ms+sW65hvTNmtV0rgprPpHUQ/QLCLWil5WiWfSAZsZ8=; b=A9HHnzbrthnSIcfVa2Rnezig3NPbzwsgs1kb32lVSmhMlWmY9lTCuOIl 0URHmxXahfGsZbL6zAr1tX0mEozYZl6E60494TXbE7QBsiRJxPk9SLao5 GyPOCG2hvkRvnQS0jF6ZM+rB2el+etFfoC2v0GgyESeFOty0EjW2+iga4 A=; IronPort-PHdr: =?us-ascii?q?9a23=3AbyiN3RIheFEovP1gQNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/g1rAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdQEcf6IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAAAnweJf/5ldJa1YBwMaAQEBAQE?= =?us-ascii?q?BAQEBAQMBAQEBEgEBAQECAgEBAQGCD4EjAS4jLgd2Wy8uCoQ1g0gDjVoDgQW?= =?us-ascii?q?JFY5ygUKBEQNPBQsBAQENAQEYAQwIAgQBAYQGRAIXgVsCJTgTAgMBAQsBAQU?= =?us-ascii?q?BAQECAQYEcYVhDIVzAQEBBAEBEAgJHQEBKQMJAgEPAgEGAgcHAwQBARYLBwM?= =?us-ascii?q?CAgIfBgsUCQgCBA4FCBMHgwWBflIFAy4BDpRgkGsCgTyIaXaBMoMEAQEGgTM?= =?us-ascii?q?BAwIOQYMPDQuCEAmBIReCdYN8gQaFMiYbgUE/gRFDgiE1PoIbQgEBAgEBgRQ?= =?us-ascii?q?SAQcEBwESEQYPCAIGBgkIAQiCURcdgiyBWBEBWBRSBA0LOQEBBQ87DAsLClw?= =?us-ascii?q?EASQBAQ4rJQGPdQIDgjYBPocsKZwxOVgKgnSJJ4Z2hhmFPoMngS6Ie4VcjGO?= =?us-ascii?q?COJ8agneOWROEPQIEAgQFAg4BAQaBQyojZ3BwFRohgjUBATIJRxcCDY4hDBc?= =?us-ascii?q?UgzqFFIVEdAI1AgYBCQEBAwl8iCMCJoENAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.78,441,1599523200"; d="scan'208,217";a="574463681" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Dec 2020 04:04:35 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BN44Zle006517 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Dec 2020 04:04:36 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 22:04:35 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 22:04:35 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 22 Dec 2020 23:04:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7byXJ6DQJKbkSo+P0MJaC8yxNvw4I4zUStrv8oN+L2o1UcyJJihSBds1IXXYTPf8fleB8b0oM80+ora/5p8Vx5mujnoNb5SIjN6eaPVxayYaSEpSPoDqtoYrgl7jbMbsqDZ8j9Dx0FixMVTedaA8xuDJ7iDl/GBbU+EjjAuUYbGLvSizho56JwwYR9T5sZ0EJy1N/i2iFQ3WA9LOCpAoe5QOr/qPjEf0AluK6NDkScN5jYqur1/WrWio3NmpQmqJMiJaxUFFy24spiUSAZBupnRePXXeMX2MoRgiEQ1Ov+4tQmQ4m0aigKWmrJhJFwOHyEJVjJhXFE1B0TXPErwvw== 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=Ms+sW65hvTNmtV0rgprPpHUQ/QLCLWil5WiWfSAZsZ8=; b=RLaaIY+thuKHmm0pHG0dw6yGkoQ/JvhWOIiRbfT9f/bIqbS9Zra/4xJiozXqwDvCiccN5dKXnhKbPj8OwClmAgVP0vY3TOYhzRVMsvNfREp879WxWakEbZTJv9z+W3kuyhkBEU74WLpliykArPwavypZOMdKV3XODR2dfnqhynL5w7o1+fQsZum9pHwocKYYke2YnNXG4OOT/QOwQGUL3Saz5zPXgEkvlzJ1nytPICchAYHvUhJYvOplbDR4bf6EAkR3mmnp76BnEsUmw3TP63oA+NXNV2hIW5ljVDRFRz5XiZX23F1+BXjW6Rm/8JfHWZ0JmHuSsNktMm72Bjjn0w== 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=Ms+sW65hvTNmtV0rgprPpHUQ/QLCLWil5WiWfSAZsZ8=; b=t6K66tmqCdS+WgfxS9tjJN71CX+7Mn+jo+xacvEF9PE7LEzGUuoDtiUwENco8Boypx2vQmE3H5lRDZdUnGkLOmUrEYMvQsCVPWD4I+sflDzjUNrKCp0rmngI/yleYlx+xJ8g30w1A7vFECuQo2y+BNHAAItv3nbFR+6rra7B4oQ= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB1476.namprd11.prod.outlook.com (2603:10b6:405:b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29; Wed, 23 Dec 2020 04:04:30 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::3ceb:c137:d13f:b30a]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::3ceb:c137:d13f:b30a%5]) with mapi id 15.20.3676.031; Wed, 23 Dec 2020 04:04:30 +0000 From: "Darren Dukes (ddukes)" To: Gyan Mishra CC: Greg Mirsky , Weiqiang Cheng , spring , "spring-chairs@ietf.org" , srcomp Thread-Topic: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt Thread-Index: AQHWvuV8FltRqyE21UeaMjRY+2Qp/anYy4A6gBtjQ4CAEAj2cA== Date: Wed, 23 Dec 2020 04:04:30 +0000 Message-ID: References: <08c001d6b8d3$010d08d0$03271a70$@com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: [198.84.181.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f215e683-0ef7-4082-0ebd-08d8a6f7d96a x-ms-traffictypediagnostic: BN6PR11MB1476: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nMtDL/bxHRuHWs4wZXSLksi7guZrKisxVN4LYtkSMlkgH1A+Ujw8foYJ2h3ZUVhqQa7Gu3eram97POyQvTHU4XacFClRPTdGoJ7uhBcmtJLBNNg9gbGZ978hn3vi8ffeD+1Bqf87gVPCvwfld3Cngk3iEqQdpsQo2eQw0t+rGE7lCers7pjGeqBHCmToAdY5QdoSm8rvHWDDNsfcuJwzzmLOcNJJe8+PFlCdo0NoneLJ0vRcLMMYqcm48h+w/1fjk40yWev287UqeNBnNxs7nSE3l4claabHrXeWogVVHWvjAip/wXwudC+Ud4JK2rqz+HAK0zipjuv7xZndhwD5AR/4AXl4q2Q2R8f2kb3WQyoC18sJpw5SZu0R8WBLmcEvgHGf5Xh+AoUDqWUOTSsLHIA32+NjfIz4eTJV89ycP9kqPpdysnd4eTtRpkUi5xWgNUMmoS07FFFa4irEi2YU/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39860400002)(136003)(346002)(376002)(316002)(54906003)(86362001)(6506007)(7696005)(2906002)(6916009)(4001150100001)(26005)(83380400001)(53546011)(186003)(66574015)(166002)(33656002)(30864003)(55016002)(71200400001)(9686003)(4326008)(66946007)(15650500001)(76116006)(8676002)(19627405001)(8936002)(91956017)(66476007)(66446008)(66556008)(64756008)(478600001)(52536014)(5660300002)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: y1ei8YswSmHk8CtuLBoOcl10MU4O7wTcY7PMC//gYQODWDALca+XKIYW/GNq50+iZkXSXflSdk5moEtci+hpNF7XmxbZHqybWngAX1xXzVBYtrAw0QJF2qR2XqhLk8IrtaHJbOB0GvQQ6nBRzDTifJPxgqbc1n77h/7gv3F2nqrah8YVpwMXkS/gWCdHPSFbPUwWC3GBpuAhw2utIkhoTUxpDyJ+HT0BwkOnBQkACwYSUDM6IclnjWFogu2GOc2xZKAH2oXgnxo87HE9iUAjPasfbdNvMsMKhrPNfXgVzzsRex4h8PaszhwM8qXqy7Z/0j9LBDdd4Z/6siS8lgyvBzcVcEZNM8kvupPHvwb1tXTjypBaJ/Q9Kto0wJRtIFFf6cei03uqkIjlkKUcbwtnL+7M9zCHLgTe5uL8IO5R35bNYjoMZhXEKxQetPZrUR8thpY+6fCHYJsjIwdvNXbgUYL+SQ3HNePcKlHCavpp69npj3xK1Zt4FE8Ni2Q0lF19Xteu1e19VH9zen1DqrgXVAu4B34XcQrZRiMwlF+D5/137aqbf38iL521hsS1F4kuXJpKOlJxvpLm9mCFxYTlBv2mckgDlsHypC+P8LB43r/Ary+JNm+O4CGu/t8s7st8yumm5fnlxxWiR/A+5NMIBD09PPFFCAAexhAxc3dWX2zqzd1fCN3zingyM7Km1wT11mOiQMK7Q7aamqzB9Jjz/WGcElYzYUOxEk/jfMruaaM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081DBCEC0CE4D035C60CA90C8DE0BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f215e683-0ef7-4082-0ebd-08d8a6f7d96a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2020 04:04:30.6954 (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: Um0+Fx5PSbGbhjkS8VMi5dv/R7R1jsq6a6/uQEUdzdYgPkWRH8PuvwQgzRymaHDg7nCDFz1g+yazsU8t3i7dUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1476 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 04:04:42 -0000 --_000_BN6PR11MB4081DBCEC0CE4D035C60CA90C8DE0BN6PR11MB4081namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFBsZWFzZSBzZWUgaW5saW5lIFtERDJdDQoNClRoYW5rcw0KICAgRGFycmVuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fn c21AZ21haWwuY29tPg0KDQpIaSBEYXJyZW4NCg0KSSBoYWQgc2ltaWxhciBjb25jZXJucyBhcyBH cmVnIGhhcyBhcyB0byB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0Lg0KDQpHcmVnLSBzb3JyeSB0byBi dXQgaW4gaG9wZSB5b3UgZG9u4oCZdCBtaW5kLvCfmIANCg0KUGxlYXNlIHNlZSBpbi1saW5lIGJl bG93DQoNCk9uIE1vbiwgTm92IDMwLCAyMDIwIGF0IDEyOjAwIFBNIERhcnJlbiBEdWtlcyAoZGR1 a2VzKSA8ZGR1a2VzPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNpc2NvLmNv bUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KR3JlZywgdGhhbmsgeW91IGZvciB5b3VyIHRob3Vn aHRmdWwgYW5hbHlzaXMgYW5kIGNvbW1lbnRzLiAgSeKAmW0gcmVwbHlpbmcgb24gYmVoYWxmIG9m IG15c2VsZiBhbmQgbm90IHRoZSBlbnRpcmUgZGVzaWduIHRlYW0uDQoNClBsZWFzZSBzZWUgaW5s aW5lIFtEXQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc3ByaW5n IDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYgb2YgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86 Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAy MCA5OjMyIFBNDQpUbzogV2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUu Y29tPG1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbT4+DQpDYzogc3Jjb21wIDxz cmNvbXBAaWV0Zi5vcmc8bWFpbHRvOnNyY29tcEBpZXRmLm9yZz4+OyBzcHJpbmcgPHNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj47IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+IDxzcHJpbmctY2hhaXJzQGlldGYub3JnPG1h aWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJl c3Npb24tcmVxdWlyZW1lbnQtMDAudHh0DQoNCkhpIFdlaXFpYW5nLCBtZW1iZXJzIG9mIHRoZSBE VCwNCnRoYW5rIHlvdSBmb3Igdm9sdW50ZWVyaW5nIHlvdXIgdGltZSBhbmQgZXhwZXJ0aXNlIHRv IHRoaXMgaW1wb3J0YW50IGZvciB0aGUgZnVydGhlciBkZXZlbG9wbWVudCBvZiB0aGUgU1IgcHJv amVjdC4gUGxlYXNlIGZpbmQgbXkgbm90ZXMgYW5kIHF1ZXN0aW9ucyBiZWxvdzoNCg0KICAqICAg bXkgZmlyc3QgcXVlc3Rpb24gaXMgb24gdGhlIGludGVuZGVkIHNjb3BlIG9mIHRoZSBkb2N1bWVu dC4gQXMgSSBjYW4gdW5kZXJzdGFuZCBmcm9tIHRoZSB0aXRsZSwgYWJzdHJhY3QsIHRoZSBzY29w ZSBpcyAidGhlIHJlcXVpcmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNzIFNSdjYgU0lE IGxpc3RzIi4gV2hlbiBJIGNvbXBhcmUgdGhhdCB3aXRoIHdoYXQgd2FzIGluIHRoZSBjaGFydGVy IG9mIHRoZSBEVCBpbiB0aGUgYW5ub3VuY2VtZW50IGJ5IG91ciBjaGFpcnM8aHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvdUw1Y0xFdWZpcG1sUVFfdzNWWnZiLXB6 bmQ0Lz46DQoNCiAuLi4gdGhlIHJlcXVpcmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNz aW5nIHNlZ21lbnQgcm91dGluZyBpbmZvcm1hdGlvbiBmb3IgdXNlIG92ZXIgSVB2Ni4NClRob3Vn aCB0aGUgZGlmZmVyZW5jZSBpbiB0ZXh0cyBtaWdodCBzZWVtcyBhcyBzbWFsbCwgdGhlIHNjb3Bl cyB0aGV5IGlkZW50aWZ5IGRpZmZlciBzaWduaWZpY2FudGx5LiBUbyBtZSwgaXQgc2VlbXMgYXMg dGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBpcyB0YXJnZXRlZCB0byBvbmx5IG9uZSBwb3NzaWJsZSBz b2x1dGlvbiB0byBwcm92aWRlIFNSIG92ZXIgSVB2NiBmdW5jdGlvbmFsaXR5LCB0aGUgU1JILiBE b2VzIHRoZSBEVCBwbGFuIHRvIGV4cGFuZCB0aGUgc2NvcGUgb2YgdGhlIGRyYWZ0IHRvIG1hdGNo IGl0IHRvIGl0cyBjaGFydGVyPw0KW0RdIEkgYmVsaWV2ZSB0aGlzIHdhcyBhbnN3ZXJlZCBpbiB0 aGUgd29ya2luZyBncm91cCBtZWV0aW5nIGFuZCBwcmVzZW50YXRpb24gYnkgV2VpcWlhbmcuICBN b3ZpbmcgdGhlIHRleHQgaW4gQS4xIGJhY2sgdG8gdGhlIGludHJvZHVjdGlvbiBzaG91bGQgbWFr ZSB0aGUgZ29hbHMgb2YgdGhlIGRvY3VtZW50IGNsZWFyLg0KDQogICogICBJdCBhcHBlYXJzIHRo YXQgaW4gb3JkZXIgdG8gcXVhbGlmeSB3aGV0aGVyIGEgcHJvcG9zZWQgY29tcHJlc3Npb24gbWV0 aG9kIGNvbXBsaWVzIHdpdGggdGhlIHJlcXVpcmVtZW50IGluIDMuMS4yIGFuIGFncmVlbWVudCBi eSB0aGUgV0cgb24gdGhlIGJlbmNobWFya2luZyBtZXRob2QgaXMgcmVxdWlyZWQgYmVjYXVzZSBt ZXRyaWNzIGxpc3RlZCwgaW4gbXkgdmlldywgYXJlIHBsYXRmb3JtLWRlcGVuZGVudC4NCg0KICAq ICAgVGhvdWdoIEkgY2FuIGFwcHJlY2lhdGUgeW91ciBjb25zaWRlcmF0aW9uIGFuZCB1c2luZyBT SE9VTEQgaW4gcmVxdWlyZW1lbnQgMy4xLjMsIEkgZG9uJ3QgZmluZCBpdCBwYXJ0aWN1bGFybHkg aW1wb3J0YW50IHRvIGJlIGluY2x1ZGVkIGluIHRoZSBsaXN0LiBBZnRlciBhbGwsIGl0IGlzIGEg bWF0dGVyIG9mIHRoZSBhcnQgb2YgaW1wbGVtZW50YXRpb24uDQoNCltEXSBCb3RoIDMuMS4yIGFu ZCAzLjEuMyBleGlzdCB0byBhbGxvdyBmb3IgY29tcGFyaXNvbiBvZiBwcm9wb3NhbHMgZm9yd2Fy ZGluZyBhbmQgc3RhdGUgZWZmaWNpZW5jeS4gIFRoZXkgYXJlIGludGVudGlvbmFsbHkgbm9uLXBy ZXNjcmlwdGl2ZSBzdGF0aW5nIHRoYXQgYSDigJxwcm9wb3NhbCBTSE9VTEQgbWluaW1pemXigJ0g c3RhdGUgb3IgcmVzb3VyY2VzIGR1cmluZyBmb3J3YXJkaW5nLiAgVGhleSBnaXZlIHRoZSB3b3Jr aW5nIGdyb3VwIHRoZSBhYmlsaXR5IHRvIGlkZW50aWZ5IHByb3Bvc2FscyB0aGF0IHNpZ25pZmlj YW50bHkgcmVkdWNlIGVmZmljaWVuY3kuICBGb3IgZXhhbXBsZSwgYSBzb2x1dGlvbiB0aGF0IHJl ZHVjZXMgaGVhZGVyIHNpemUgYnkgZGlzdHJpYnV0aW5nIHBlciBmbG93IGZvcndhcmRpbmcgc3Rh dGUgdG8gYWxsIG5vZGVzIG1heSBjb21wcmVzcyB3ZWxsLCBidXQgYXQgdGhlIGV4cGVuc2Ugb2Yg ZWZmaWNpZW5jeS4NCg0KICAgR3lhbj4gTXkgdGhvdWdodHMgYXJlIHRoZXQgZm9yd2FyZGluZyBh bmQgZWZmaWNpZW5jaWVzIGFzIHJlcXVpcmVtZW50cyBpcyBnZXR0aW5nIHRvbyBkZWVwIGludG8g dGhlIHdlZWRzIG9mIHRoZSBoYXJkd2FyZSBOUFUgb3IgRlBHQSBBU0lDIGVpdGhlciBtZXJjaGFu dCBvciBwcm9wcmlldGFyeSBzaWxpY29uIGFuZCBhcyBlYWNoIHZlbmRvciBoYXMgaXRzIG93biBt ZXRob2Qgb2YgYWNjb21wbGlzaGluZyB0aGUgZ29hbCBpdOKAmXMgdXAgdG8gdGhlIHZlbmRvciBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgc29sdXRpb24gdG8gZW5zdXJlIHRoZSBlZmZpY2llbmN5IHRv IG1ha2UgdGhlIHNvbHV0aW9uIHZpYWJsZS4gIEkgdGhpbmsgYWRkaW5nIHRoaXMgcmVxdWlyZW1l bnQgcHV0cyB0aGUgY2FydCBiZWZvcmUgdGhlIGhvcnNlIHNvIHRvIHNwZWFrIGFuZCBsaW1pdHMg dGhlIGRlc2lnbiBmcmFtZXdvcmsgdG8gdGhpbmsgb3V0c2lkZSB0aGUgYm94IG9uIGEgc29sdXRp b24gdmVyc2VzIGJlaW5nIGJveGVkIGluIGZyb20gdGhlIGdldGdvLg0KDQpbREQyXSBUaGUgcmVx dWlyZW1lbnRzIGV4aXN0IHRvIGFsbG93IGZvciBjb21wYXJpc29uIGJldHdlZW4gcHJvdG9jb2wg cHJvcG9zYWxzLiBQcm9wb3NhbCBhdXRob3JzIGNhbiB0aGluayAib3V0c2lkZSB0aGUgYm94IiBh bGwgdGhleSB3YW50IHRvIGNvbXByZXNzIGFuIFNSdjYgU0lEIGxpc3QuICBUaGV5IFNIT1VMRCBh bHNvIGNvbnNpZGVyIHRoZXNlIHJlcXVpcmVtZW50cy4gIEFzIEkgc3RhdGVkIGJlZm9yZSB3ZSBu ZWVkIHRoZSBhYmlsaXR5IHRvIGNvbXBhcmUgcHJvcG9zYWxzIHRoYXQgY29tcHJlc3MgdGhlIFNS djYgU0lEIGxpc3QgYnkgaW5jcmVhc2luZyBjb21wbGV4aXR5IGFuZCBzdGF0ZSwgU1BSSU5HIGNh biB0aGVuIGRldGVybWluZSBpZiBpdCdzIGEgdmFsdWFibGUgdHJhZGUgdG8gbWFrZS4NCg0KICAq ICAgSSB0aGluayBJIGNhbm5vdCBhZ3JlZSB0aGUgU0lEIHN1bW1hcml6YXRpb24gaXMgdGhlIG9u bHkgdmlhYmxlIHRlY2huaXF1ZSBmb3IgdGhlIGludGVyZG9tYWluIFNSLiBSZXBsYWNpbmcgTVVT VCB3aXRoIFNIT1VMRCBtaWdodCBiZSByZWFzb25hYmxlLCBBbmQgcHJlZmVyYWJseSBhZGRpbmcg YW4gaW5mb3JtYXRpdmUgdGV4dCB0byBkZXNjcmliZSBhbHRlcm5hdGl2ZSBtZXRob2RzIHRvIHN1 cHBvcnQgdGhlIGludGVyZG9tYWluIFNSLg0KDQpbRF0gQWdncmVnYXRpb24gb3Igc3VtbWFyaXph dGlvbiBpcyBub3QgdGhlIG9ubHkgdGVjaG5pcXVlIGZvciBpbnRlcmRvbWFpbiBTUi4gIEJpbmRp bmcgU0lEcyBhcmUgcmVxdWlyZWQgaW4gQS4zLCBhbmQgdGhlcmUgYXJlIG90aGVyIG1ldGhvZHMg YW4gb3BlcmF0b3IgY2FuIHVzZS4gIFRoZSBSYXRpb25hbGUgZG9lcyBkZXNjcmliZSBvbmUgb3Ro ZXIgb3B0aW9uIHRoYXQgcmVxdWlyZXMgYWRkaXRpb25hbCBTSURzIGluIGEgU0lEIGxpc3QuDQpI b3dldmVyLCB0aGUgZGVzaWduIHRlYW0gaGFzIGhlYXJkIGZyb20gb3BlcmF0b3JzIHRoYXQgc3Vt bWFyaXphdGlvbiBpcyBhIHZlcnkgaW1wb3J0YW50IHBhcnQgb2YgU1J2NiBhbmQgdGhlaXIgU1J2 NiBkZXBsb3ltZW50IHBsYW5zLiBUaGV5IGRvIG5vdCB3YW50IHRvIGxvc2UgdGhpcyBmdW5jdGlv bmFsaXR5IGZvciB0aGUgc2FrZSBvZiBjb21wcmVzc2lvbi4NCg0KICAgIEd5YW4+IEFzIFNSdjYg dXNlcyB0aGUgSVB2NiBkYXRhIHBsYW5lIGl0IGlzIGJhc2VkIG9uIExQTSAoTG9uZ2VzdCBwcmVm aXggbWF0Y2gpIHJvdXRpbmcgYW5kIG5vdCBNUExTIHN0eWxlIOKAnGV4YWN0IG1hdGNo4oCdIGZv ciBGRUMgYmluZGluZy4gIFNvIHRoYXQgYmVpbmcgc2FpZCB0aGUgZGVzdGluYXRpb24gZWdyZXNz IFBFIFNSIGxvY2F0b3IgZm9yIGZpbmFsIGRlc3RpbmF0aW9uIHdvdWxkIGJlIExQTSByb3V0ZWQg dG8gUFNQIG5vZGUuICBTbyBpbiB0aGUgY29udGV4dCBvZiBzdW1tYXJpemF0aW9uIHRoZSBtYWlu IHBvaW50IGlzIHN1bW1hcml6YXRpb24gZG9lcyBub3QgZ2VuZXJhbGx5IGhhcHBlbiB3aXRoaW4g dGhlIGNsb3NlZCBzaW5nZSBhcmVhIG9yIGxldmVsIFNSIGRvbWFpbiBhcyBhbGwgICBlZ3Jlc3Mg UEUgZmluYWwgZGVzdGluYXRpb24gcHJlZml4IHNpZCBob3N0IHJvdXRlIGlzIGZsb29kZWQgZG9t YWluIHdpZGUsIGhvd2V2ZXIgd2l0aCBsYXJnZXIgZG9tYWlucyBpdCBjb3VsZCBiZSBicm9rZW4g dXAgaW50byBhcmVhcyBvciBsZXZlbHMgIGFuZCBMUE0gbWF0Y2hpbmcgY2FuIGhhcHBlbiB0byBz dW1tYXJpemUgZmluYWwgZGVzdGluYXRpb24gZWdyZXNzIFBFIHByZWZpeCBzaWQgcHJlZml4ZXMu ICBBcyBHcmVnIHBvaW50ZWQgb3V0IGFzIGZhciBhcyBzdW1tYXJpemF0aW9uIHRoZSBtYWluIHVz ZSBjYXNlIGlzIGZvciBpbnRlciBhcmVhIHdoZXJlIHN1bW1hcml6YXRpb24gd291bGQgb2NjdXIu ICBUaGF0IGlzIHByZWNpc2VseSBHcmVn4oCZcyBjb250ZXh0IG9mIHJlcGxhY2VtZW50IG9mIE1V U1Qgd2l0aCBTSE9VTEQuDQoNCltERDJdIE15IHJlYWQgaXMgdGhhdCB5b3UncmUgY29uZnVzaW5n IGRlcGxveW1lbnQgcmVxdWlyZW1lbnRzIHdpdGggcHJvdG9jb2wgcmVxdWlyZW1lbnRzLiAgVGhl IHJlcXVpcmVtZW50IGlzIHRoYXQgYSBwcm9wb3NhbCBNVVNUIHN1cHBvcnQgc3VtbWFyaXphdGlv bi4gIFdoZXRoZXIgb3Igbm90IGEgcGFydGljdWxhciBkZXBsb3ltZW50IHVzZXMgbXVsdGlwbGUg ZG9tYWlucyBhbmQgdGFrZXMgYWR2YW50YWdlIG9mIGl0IGlzIG5vdCByZWxldmFudCB0byB0aGUg cmVxdWlyZW1lbnQgbm9yIHRoZSBwcm9wb3NhbC4NCg0KDQoNCiAgKiAgIEkgdGhpbmsgSSB1bmRl cnN0YW5kIHRoZSBpbnRlbnRpb24gb2YgdGhlIHJlcXVpcmVtZW50IGluIFNlY3Rpb24gNC4yLjEg YnV0IEkgbWF5IHByb3Bvc2UgZXhwcmVzc2luZyBpdCBkaWZmZXJlbnRseToNCg0KQSBwYXRoIHRy YXZlcnNlZCB1c2luZyBhIGxpc3Qgb2YgY29tcHJlc3NlZCBTSURzIE1VU1QgYWx3YXlzIGJlIHRo ZSBzYW1lIGFzIHRoZSBwYXRoIHRyYXZlcnNlZCB1c2luZyB0aGUgbGlzdCBvZiB1bmNvbXByZXNz ZWQgU0lEcyBpZiBubyBjb21wcmVzc2lvbiB3YXMgYXBwbGllZC4NCg0KW0RdIFRoaXMgc2VlbXMg bGlrZSByZWFzb25hYmxlIHRleHQNCg0KICAgR3lhbj4gQWdyZWVkIHdpdGggR3JlZ+KAmXMgY29t bWVudCBhbmQgdXBkYXRlZCB0ZXh0Lg0KDQoNCiAgKiAgIEkgdGhpbmsgdGhhdCB0aGUgdXNlIG9m IE1VU1QgaW4gcmVxdWlyZW1lbnQgNS4xIGlzIHRvbyBzdHJvbmcuIEZpcnN0bHksIHN1Y2ggY29t cGF0aWJpbGl0eSBpcyBub3QgZXNzZW50aWFsIGluIGEgZ3JlZW5maWVsZCBzY2VuYXJpby4gU2Vj b25kbHksIHRoZSBjb250cm9sIHBsYW5lIGJhc2VkIHNvbHV0aW9uIG1pZ2h0IGJlIGVudmlzaW9u ZWQgdG8gY29vcmRpbmF0ZSB0aGUgaW50ZXJ3b3JraW5nIGJldHdlZW4gU1IgZG9tYWlucyB1c2lu ZyBTUnY2IGFuZCBub3QgdXNpbmcgdGhlIFNSdjYgdGVjaG5pcXVlLg0KDQpbRF0gNS4xIGRlc2Ny aWJlcyBhIOKAnHNoaXBzIGluIHRoZSBuaWdodOKAnSBkZXBsb3ltZW50IHNjZW5hcmlvLCBzdWNo IHRoYXQgaXQgbXVzdCBiZSBwb3NzaWJsZSB0byBoYXZlIG5vbi1jb21wcmVzc2VkIFNSdjYgc3Vw cG9ydCBvbiBhIG5vZGUgYXMgd2VsbCBhcyB0aGUgY29tcHJlc3Npb24gc29sdXRpb24uDQoNCltE XSBJLmUuIHRoZSBjb21wcmVzc2lvbiBzb2x1dGlvbiBNVVNUIG1ha2UgaXQgcG9zc2libGUgZm9y IGEgbm9kZSB0byBzdXBwb3J0IHRoZSB1bmNvbXByZXNzZWQgY29udHJvbCBwbGFuZSBhbmQgZGF0 YSBwbGFuZSwgYXMgd2VsbCBhcyB0aGUgY29tcHJlc3NlZCBjb250cm9sIHBsYW5lIGFuZCBkYXRh IHBsYW5lLiBJdCBkb2VzIG5vdCBzdGF0ZSB0aGF0IGV2ZXJ5IG5vZGUgTVVTVCBzdXBwb3J0IGJv dGggYXQgdGhlIHNhbWUgdGltZS4gR2l2ZW4gdGhpcywgZG9lcyB5b3VyIG9iamVjdGlvbiB0byBN VVNUIHN0aWxsIGFwcGx5Pw0KDQogICAgR3lhbj4gSSBiZWxpZXZlIEdyZWfigJlzIGlzIHN0YXRp bmcgYW5kIEkgYWdyZWUgYXMgd2VsbCBhcyB0aGUgc3Ryb25nIHJlcXVpcmVtZW50IGhpbmRlcnMg dGhlIGRldmVsb3BtZW50IGZvciB3aGVuIHdlIGFyZSBpbiB0aGUgZW5kIHN0YXRlIHdoaWNoIHdv dWxkIGJlIGdyZWVuIGZpZWxkIG9yIG5ldyBkZXBsb3ltZW50cyB0aGF0IGRvbuKAmXQgbmVlZCB0 aGUgTVVTVCB2ZXJiaWFnZS4gIElmIHlvdSBoYXZlIHRvIGFjY291bnQgZm9yIHRoZSBpbnRlcm9w ZXJhYmlsaXR5IG9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHRoZWlyIGlzIGRlZmluaXRlbHkg bW9yZSBvdmVyaGVhZCB0aGF0IGhhcyB0byBiZSBtZXQgaW4gdGhlIGRlc2lnbiBzb2x1dGlvbiBh bmQgbGltaXRzIHRoZSBzY29wZSBvZiB0aGUgZGVzaWduIHNvbHV0aW9uIHdoaWNoIHNob3VsZCBu b3QgYmUgbGltaXRlZC4NCg0KW0REMl0gcmV2aXNpb24gMDIgc2VjdGlvbiA1LjEgZG9lcyBub3Qg cmVxdWlyZSAiaW50ZXJvcGVyYWJpbGl0eSIgbm9yICJiYWNrd2FyZCBjb21wYXRpYmlsaXR5Ii4g IEl0IGRlc2NyaWJlcyBhIHNoaXBzLWluLXRoZS1uaWdodCBjYXBhYmlsaXR5IHdoZXJlIHRoZSBj b21wcmVzc2lvbiBwcm9wb3NhbCBjYW4gZXhpc3QgaW4gdGhlIHNhbWUgbmV0d29yayBhdCB0aGUg c2FtZSB0aW1lIGFzIHRoZSBjdXJyZW50IFNSdjYgcHJvdG9jb2wgd2l0aG91dCBicmVha2luZyB0 aGUgY3VycmVudCBwcm90b2NvbC4gIFRoaXMgaXMgbm90IGEgaGlnaCBiYXIgdG8gbWVldC4NCg0K DQoNCkFsc28gdGhlaXIgbWF5YmUgb3RoZXIgaW50ZXJ3b3JraW5nIHR1bm5lbGluZyBvciB0cmFu c2xhdGlvbiBtZWNoYW5pc21zIHRoYXQgYWxyZWFkeSBleGlzdCB0b2RheSB0aGF0IGNhbiBwcm92 aWRlIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGhvdXQgbWFraW5nIGludGVyb3BlcmFiaWxpdHkg b3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYSByZXF1aXJlbWVudC4gIEkgdGhpbmsgdGhpcyB1 bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVzIHRoZSBwb3NzaWJsZSBzb2x1dGlvbiBzY29wZSBvZiB3 aGljaCB3ZSBkb27igJl0IHdhbnQuDQoNCkhlcmUgaXMgcmV3b3JkaW5nIG9mIHRoZSBmaXJzdCBz ZW50ZW5jZS4NCg0KT3B0aW9uICMxDQrigJxUaGUgY29tcHJlc3Npb24gcHJvcG9zYWwgTVVTVCBz dXBwb3J0IGRlcGxveW1lbnQgaW4gZXhpc3RpbmcgQnJvd25maWVsZCBTUnY2IG5ldHdvcmtzIG9u bHkgYW5kIG5vdCBHcmVlbmZpZWxkIG5ldHdvcmsgZGVwbG95bWVudHPigJ0NCg0KT3B0aW9uICMy DQrigJxUaGUgY29tcHJlc3Npb24gcHJvcG9zYWwgU0hPVUxEIHN1cHBvcnQgZGVwbG95bWVudCBv biBleGlzdGluZyBTUnY2IG5ldHdvcmtzLg0KDQpBcyBleGlzdGluZyBuZXR3b3JrcyB3aWxsIGV2 ZW50dWFsbHkgYWxsIHN1cHBvcnQgU1J2NiBjb21wcmVzc2lvbiBhcyBub2RlcyBhcmUgdXBncmFk ZWQgcHJpb3IgdG8gY29udmVyc2lvbiB0byBTUnY2LCB0aGUgbmVlZCBmb3IgYWxsIG5vZGVzIHRv IHJlcXVpcmUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2lsbCBub3QgYWx3YXlzIGJlIG5lY2Vz c2FyeS4NCg0KVGhhbmsgeW91DQoNCkd5YW4NCg0KDQoNCkFuZCBpbiB0aGUgY29uY2x1c2lvbiwg b25jZSBhZ2FpbiwgbWFueSB0aGFua3MgdG8gYWxsIHRoZSBtZW1iZXJzIG9mIHRoZSBEZXNpZ24g VGVhbSBmb3IgdGhlIGpvYiB3ZWxsIGRvbmUuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFRodSwg Tm92IDEyLCAyMDIwIGF0IDE6MDYgQU0gV2VpcWlhbmcgQ2hlbmcgPGNoZW5nd2VpcWlhbmdAY2hp bmFtb2JpbGUuY29tPG1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbT4+IHdyb3Rl Og0KSGkgR3JvdXAsDQpBcyB5b3Uga25vdywgdGhlIFNQUklORyBXb3JraW5nIEdyb3VwIHNldCB1 cCBhbiBTUiBjb21wcmVzc2lvbiBkZXNpZ24gdGVhbSBwcmlvciB0byBJRVRGMTA4Lg0KVGhlIGRl c2lnbiB0ZWFtIGlzIHRvIHByb2R1Y2UgKHJvdWdoKSBjb25zZW5zdXMgKG9mIHRoZSBEVCkgb3V0 cHV0cyB0byB0aGUgV0cgb24gdHdvIHJlbGF0ZWQgdG9waWNzOg0KMSkgV2hhdCBhcmUgdGhlIHJl cXVpcmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNzaW5nIHNlZ21lbnQgcm91dGluZyBp bmZvcm1hdGlvbiBmb3IgdXNlIG92ZXIgSVB2NjsNCjIpIEEgY29tcGFyaXNvbiBvZiBwcm9wb3Nl ZCBhcHByb2FjaGVzIHRvIGNvbXByZXNzaW5nIHNlZ21lbnQgcm91dGluZyBpbmZvcm1hdGlvbiBm b3IgdXNlIG92ZXIgSVB2Ni4NCg0KV2l0aCBncmVhdCBlZmZvcnQgb2YgZGVzaWduIHRlYW0gbWVt YmVycywgRFQgaGF2ZSBmaW5pc2hlZCB0aGUgdmVyc2lvbiAtMDAgb2YgdGhlIHJlcXVpcmVtZW50 cyBkb2N1bWVudCBhbmQgaGF2ZSBzdWJtaXR0ZWQgaXQgdG8gZGF0YXRyYWNrZXIuDQoNClBsZWFz ZSByZXZpZXcgaXQgYW5kIGxldCdzIGtub3cgeW91ciBjb21tZW50cy4NCg0KQi5SLg0KV2VpcWlh bmcgQ2hlbmcNCg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pl0NCuWPkemAgeaXtumXtDogMjAyMOW5tDEx5pyIMuaXpSAxNjozMg0K5pS25Lu25Lq6OiBTYW5k ZXIgU3RlZmZhbm47IFNKTSBTdGVmZmFubjsgV2VpcWlhbmcgQ2hlbmcNCuS4u+mimDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24t cmVxdWlyZW1lbnQtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNyY29t cGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VpcWlhbmcgQ2hlbmcgYW5kIHBvc3RlZCB0byB0aGUNCklF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1j b21wcmVzc2lvbi1yZXF1aXJlbWVudA0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAg ICAgQ29tcHJlc3NlZCBTUnY2IFNJRCBMaXN0IFJlcXVpcmVtZW50cw0KRG9jdW1lbnQgZGF0ZTog IDIwMjAtMTAtMzANCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OiAgICAgICAgICAxMA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hp dmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNw cmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWly ZW1lbnQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJlcXVp cmVtZW50cyBmb3Igc29sdXRpb25zIHRvIGNvbXByZXNzIFNSdjYNCiAgIFNJRCBsaXN0cy4NCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5v cmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJp bmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwcmluZw0KLS0NCg0KW2h0dHA6Ly9zczcudnp3LmNvbS9pcy9pbWFnZS9WZXJpem9uV2ly ZWxlc3MvdnotbG9nby1lbWFpbF08aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+DQoNCkd5YW4gTWlz aHJhDQoNCk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdA0KDQpNIDMwMSA1MDItMTM0Nw0KMTMx MDEgQ29sdW1iaWEgUGlrZQ0KU2lsdmVyIFNwcmluZywgTUQNCg0K --_000_BN6PR11MB4081DBCEC0CE4D035C60CA90C8DE0BN6PR11MB4081namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhpLCBQbGVhc2Ugc2VlIGlubGluZSBbREQyXTwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpUaGFu a3M8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4N CiZuYnNwOyAmbmJzcDtEYXJyZW48L2Rpdj4NCjxkaXYgaWQ9ImFwcGVuZG9uc2VuZCI+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4NCjxo ciB0YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4N CjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBz YW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9t OjwvYj4gR3lhbiBNaXNocmEgJmx0O2hheWFidXNhZ3NtQGdtYWlsLmNvbSZndDs8YnI+DQo8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0i Q2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6MTFw dCI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJhdXRvIj5IaSBEYXJyZW4m bmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRv Ij5JIGhhZCBzaW1pbGFyIGNvbmNlcm5zIGFzIEdyZWcgaGFzIGFzIHRvIHRoZSByZXF1aXJlbWVu dHMgZHJhZnQuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i YXV0byI+R3JlZy0gc29ycnkgdG8gYnV0IGluIGhvcGUgeW91IGRvbuKAmXQgbWluZC7wn5iAPC9k aXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+UGxlYXNl IHNlZSBpbi1saW5lIGJlbG93Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXYgY2xhc3M9Inhf Z21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9InhfZ21haWxfYXR0ciI+T24gTW9u LCBOb3YgMzAsIDIwMjAgYXQgMTI6MDAgUE0gRGFycmVuIER1a2VzIChkZHVrZXMpICZsdDtkZHVr ZXM9PGEgaHJlZj0ibWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnIj40MGNpc2NvLmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg Y2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJv cmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVm dDoxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpHcmVnLCB0aGFuayB5 b3UgZm9yIHlvdXIgdGhvdWdodGZ1bCBhbmFseXNpcyBhbmQgY29tbWVudHMuJm5ic3A7IEnigJlt IHJlcGx5aW5nIG9uIGJlaGFsZiBvZiBteXNlbGYgYW5kIG5vdCB0aGUgZW50aXJlIGRlc2lnbiB0 ZWFtLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRp Y2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQpQbGVhc2Ugc2Vl IGlubGluZSBbRF08YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9InhfbV8tNjMzMzIwMTkwODkzOTA4Njk5 OGFwcGVuZG9uc2VuZCI+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFy aWFsLEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCww KSI+DQo8YnI+DQo8L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRo Ojk4JSI+DQo8ZGl2IGlkPSJ4X21fLTYzMzMyMDE5MDg5MzkwODY5OThkaXZScGx5RndkTXNnIiBk aXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6 ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigwLDAsMCki PjxiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPkZyb206PC9iPiBzcHJp bmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgR3JlZyBNaXJza3kgJmx0OzxhIGhy ZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+ Jmd0Ozxicj4NCjxiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgMTksIDIwMjAgOTozMiBQTTxicj4NCjxiIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPlRvOjwvYj4gV2VpcWlhbmcgQ2hlbmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPmNoZW5nd2VpcWlh bmdAY2hpbmFtb2JpbGUuY29tPC9hPiZndDs8YnI+DQo8YiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmIj5DYzo8L2I+IHNyY29tcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNyY29t cEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWYiPnNyY29tcEBpZXRmLm9yZzwvYT4mZ3Q7OyBzcHJpbmcgJmx0OzxhIGhyZWY9Im1h aWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQpzcHJpbmctY2hhaXJzQGlldGYub3JnPC9hPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5zcHJpbmctY2hhaXJzQGll dGYub3JnPC9hPiZndDs8YnI+DQo8YiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmIj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMC50 eHQ8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDQwcHg7IGJvcmRlcjpu b25lOyBwYWRkaW5nOjBweCI+SGkgV2VpcWlhbmcsIG1lbWJlcnMgb2YgdGhlIERULDwvYmxvY2tx dW90ZT4NCjxkaXY+dGhhbmsgeW91IGZvciB2b2x1bnRlZXJpbmcgeW91ciB0aW1lIGFuZCBleHBl cnRpc2UgdG8gdGhpcyBpbXBvcnRhbnQgZm9yIHRoZSBmdXJ0aGVyIGRldmVsb3BtZW50IG9mIHRo ZSBTUiBwcm9qZWN0LiBQbGVhc2UgZmluZCBteSBub3RlcyBhbmQgcXVlc3Rpb25zIGJlbG93Ojxi cj4NCjwvZGl2Pg0KPGRpdj4NCjx1bD4NCjxsaT5teSBmaXJzdCBxdWVzdGlvbiBpcyBvbiB0aGUg aW50ZW5kZWQgc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBBcyBJIGNhbiB1bmRlcnN0YW5kIGZyb20g dGhlIHRpdGxlLCBhYnN0cmFjdCwgdGhlIHNjb3BlIGlzICZxdW90O3RoZSByZXF1aXJlbWVudHMg Zm9yIHNvbHV0aW9ucyB0byBjb21wcmVzcyBTUnY2IFNJRCBsaXN0cyZxdW90Oy4gV2hlbiBJIGNv bXBhcmUgdGhhdCB3aXRoIHdoYXQgd2FzIGluIHRoZSBjaGFydGVyIG9mIHRoZSBEVCBpbg0KPGEg aHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvdUw1Y0xF dWZpcG1sUVFfdzNWWnZiLXB6bmQ0LyIgdGFyZ2V0PSJfYmxhbmsiPg0KdGhlIGFubm91bmNlbWVu dCBieSBvdXIgY2hhaXJzPC9hPjo8L2xpPjwvdWw+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggNDBweDsgYm9yZGVyOm5vbmU7IHBhZGRpbmc6MHB4Ij4NCjxk aXY+Jm5ic3A7Li4uIHRoZSByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0byBjb21wcmVzc2lu ZyBzZWdtZW50IHJvdXRpbmcgaW5mb3JtYXRpb24gZm9yIHVzZSBvdmVyIElQdjYuPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDQwcHg7 IGJvcmRlcjpub25lOyBwYWRkaW5nOjBweCI+DQo8ZGl2PlRob3VnaCB0aGUgZGlmZmVyZW5jZSBp biB0ZXh0cyBtaWdodCBzZWVtcyBhcyBzbWFsbCwgdGhlIHNjb3BlcyB0aGV5IGlkZW50aWZ5IGRp ZmZlciBzaWduaWZpY2FudGx5LiBUbyBtZSwgaXQgc2VlbXMgYXMgdGhlIHNjb3BlIG9mIHRoZSBk cmFmdCBpcyB0YXJnZXRlZCB0byBvbmx5IG9uZSBwb3NzaWJsZSBzb2x1dGlvbiB0byBwcm92aWRl IFNSIG92ZXIgSVB2NiBmdW5jdGlvbmFsaXR5LCB0aGUgU1JILiBEb2VzIHRoZSBEVCBwbGFuIHRv DQogZXhwYW5kIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgdG8gbWF0Y2ggaXQgdG8gaXRzIGNoYXJ0 ZXI/PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PltEXSBJIGJlbGlldmUgdGhpcyB3YXMgYW5z d2VyZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgbWVldGluZyBhbmQgcHJlc2VudGF0aW9uIGJ5IFdl aXFpYW5nLiZuYnNwOyBNb3ZpbmcgdGhlIHRleHQgaW4gQS4xIGJhY2sgdG8gdGhlIGludHJvZHVj dGlvbiBzaG91bGQgbWFrZSB0aGUgZ29hbHMgb2YgdGhlIGRvY3VtZW50IGNsZWFyLjwvZGl2Pg0K PHVsPg0KPGxpPkl0IGFwcGVhcnMgdGhhdCBpbiBvcmRlciB0byBxdWFsaWZ5IHdoZXRoZXIgYSBw cm9wb3NlZCBjb21wcmVzc2lvbiZuYnNwO21ldGhvZCBjb21wbGllcyB3aXRoIHRoZSByZXF1aXJl bWVudCBpbiAzLjEuMiBhbiBhZ3JlZW1lbnQgYnkgdGhlIFdHIG9uIHRoZSBiZW5jaG1hcmtpbmcg bWV0aG9kIGlzIHJlcXVpcmVkIGJlY2F1c2UgbWV0cmljcyBsaXN0ZWQsIGluIG15IHZpZXcsIGFy ZSBwbGF0Zm9ybS1kZXBlbmRlbnQuPC9saT48L3VsPg0KPHVsPg0KPGxpPlRob3VnaCBJIGNhbiBh cHByZWNpYXRlIHlvdXIgY29uc2lkZXJhdGlvbiBhbmQgdXNpbmcgU0hPVUxEIGluIHJlcXVpcmVt ZW50IDMuMS4zLCBJIGRvbid0IGZpbmQgaXQgcGFydGljdWxhcmx5IGltcG9ydGFudCB0byBiZSBp bmNsdWRlZCBpbiB0aGUgbGlzdC4gQWZ0ZXIgYWxsLCBpdCBpcyBhIG1hdHRlciBvZiB0aGUgYXJ0 IG9mIGltcGxlbWVudGF0aW9uLjwvbGk+PC91bD4NCjxkaXY+PC9kaXY+DQpbRF0gQm90aCAzLjEu MiBhbmQgMy4xLjMgZXhpc3QgdG8gYWxsb3cgZm9yIGNvbXBhcmlzb24gb2YgcHJvcG9zYWxzIGZv cndhcmRpbmcgYW5kIHN0YXRlIGVmZmljaWVuY3kuJm5ic3A7IFRoZXkgYXJlIGludGVudGlvbmFs bHkgbm9uLXByZXNjcmlwdGl2ZSBzdGF0aW5nIHRoYXQgYSDigJxwcm9wb3NhbCBTSE9VTEQgbWlu aW1pemXigJ0gc3RhdGUgb3IgcmVzb3VyY2VzIGR1cmluZyBmb3J3YXJkaW5nLiZuYnNwOyBUaGV5 IGdpdmUgdGhlIHdvcmtpbmcgZ3JvdXAgdGhlIGFiaWxpdHkNCiB0byBpZGVudGlmeSBwcm9wb3Nh bHMgdGhhdCBzaWduaWZpY2FudGx5IHJlZHVjZSBlZmZpY2llbmN5LiZuYnNwOyBGb3IgZXhhbXBs ZSwgYSBzb2x1dGlvbiB0aGF0IHJlZHVjZXMgaGVhZGVyIHNpemUgYnkgZGlzdHJpYnV0aW5nIHBl ciBmbG93IGZvcndhcmRpbmcgc3RhdGUgdG8gYWxsIG5vZGVzIG1heSBjb21wcmVzcyB3ZWxsLCBi dXQgYXQgdGhlIGV4cGVuc2Ugb2YgZWZmaWNpZW5jeS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0 byI+Jm5ic3A7ICZuYnNwO0d5YW4mZ3Q7IE15IHRob3VnaHRzIGFyZSB0aGV0IGZvcndhcmRpbmcg YW5kIGVmZmljaWVuY2llcyBhcyByZXF1aXJlbWVudHMgaXMgZ2V0dGluZyB0b28gZGVlcCBpbnRv IHRoZSB3ZWVkcyBvZiB0aGUgaGFyZHdhcmUgTlBVIG9yIEZQR0EgQVNJQyBlaXRoZXIgbWVyY2hh bnQgb3IgcHJvcHJpZXRhcnkgc2lsaWNvbiBhbmQgYXMgZWFjaCB2ZW5kb3IgaGFzIGl0cyBvd24g bWV0aG9kIG9mIGFjY29tcGxpc2hpbmcgdGhlIGdvYWwNCiBpdOKAmXMgdXAgdG8gdGhlIHZlbmRv ciBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc29sdXRpb24gdG8gZW5zdXJlIHRoZSBlZmZpY2llbmN5 IHRvIG1ha2UgdGhlIHNvbHV0aW9uIHZpYWJsZS4mbmJzcDsgSSB0aGluayBhZGRpbmcgdGhpcyBy ZXF1aXJlbWVudCBwdXRzIHRoZSBjYXJ0IGJlZm9yZSB0aGUgaG9yc2Ugc28gdG8gc3BlYWsgYW5k IGxpbWl0cyB0aGUgZGVzaWduIGZyYW1ld29yayB0byB0aGluayBvdXRzaWRlIHRoZSBib3ggb24g YSBzb2x1dGlvbiB2ZXJzZXMNCiBiZWluZyBib3hlZCBpbiBmcm9tIHRoZSBnZXRnby48L2Rpdj4N CjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5bREQyXSBUaGUg cmVxdWlyZW1lbnRzIGV4aXN0IHRvIGFsbG93IGZvciBjb21wYXJpc29uIGJldHdlZW4gcHJvdG9j b2wgcHJvcG9zYWxzLiBQcm9wb3NhbCBhdXRob3JzIGNhbiB0aGluayAmcXVvdDtvdXRzaWRlIHRo ZSBib3gmcXVvdDsgYWxsIHRoZXkgd2FudCB0byBjb21wcmVzcyBhbiBTUnY2IFNJRCBsaXN0LiAm bmJzcDtUaGV5IFNIT1VMRCBhbHNvIGNvbnNpZGVyIHRoZXNlIHJlcXVpcmVtZW50cy4gJm5ic3A7 QXMgSSBzdGF0ZWQgYmVmb3JlIHdlIG5lZWQNCiB0aGUgYWJpbGl0eSB0byBjb21wYXJlIHByb3Bv c2FscyB0aGF0IGNvbXByZXNzIHRoZSBTUnY2IFNJRCBsaXN0IGJ5IGluY3JlYXNpbmcgY29tcGxl eGl0eSBhbmQgc3RhdGUsIFNQUklORyBjYW4gdGhlbiBkZXRlcm1pbmUgaWYgaXQncyBhIHZhbHVh YmxlIHRyYWRlIHRvIG1ha2UuPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4 OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleDsgYm9yZGVyLWxlZnQt Y29sb3I6cmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjx1bD4NCjxsaT5JIHRoaW5rIEkgY2Fubm90IGFncmVlIHRoZSBTSUQgc3VtbWFy aXphdGlvbiBpcyB0aGUgb25seSB2aWFibGUgdGVjaG5pcXVlIGZvciB0aGUgaW50ZXJkb21haW4g U1IuIFJlcGxhY2luZyBNVVNUIHdpdGggU0hPVUxEIG1pZ2h0IGJlIHJlYXNvbmFibGUsIEFuZCBw cmVmZXJhYmx5IGFkZGluZyBhbiBpbmZvcm1hdGl2ZSB0ZXh0IHRvIGRlc2NyaWJlIGFsdGVybmF0 aXZlIG1ldGhvZHMgdG8gc3VwcG9ydCB0aGUgaW50ZXJkb21haW4gU1IuPC9saT48L3VsPg0KPGRp dj5bRF0gQWdncmVnYXRpb24gb3Igc3VtbWFyaXphdGlvbiBpcyBub3QgdGhlIG9ubHkgdGVjaG5p cXVlIGZvciBpbnRlcmRvbWFpbiBTUi4mbmJzcDsgQmluZGluZyBTSURzIGFyZSByZXF1aXJlZCBp biBBLjMsIGFuZCB0aGVyZSBhcmUgb3RoZXIgbWV0aG9kcyBhbiBvcGVyYXRvciBjYW4gdXNlLiZu YnNwOyBUaGUgUmF0aW9uYWxlIGRvZXMgZGVzY3JpYmUgb25lIG90aGVyIG9wdGlvbiB0aGF0IHJl cXVpcmVzIGFkZGl0aW9uYWwgU0lEcyBpbiBhIFNJRCBsaXN0Lg0KPGRpdj5Ib3dldmVyLCB0aGUg ZGVzaWduIHRlYW0gaGFzIGhlYXJkIGZyb20gb3BlcmF0b3JzIHRoYXQgc3VtbWFyaXphdGlvbiBp cyBhIHZlcnkgaW1wb3J0YW50IHBhcnQgb2YgU1J2NiBhbmQgdGhlaXIgU1J2NiBkZXBsb3ltZW50 IHBsYW5zLiBUaGV5IGRvIG5vdCB3YW50IHRvIGxvc2UgdGhpcyBmdW5jdGlvbmFsaXR5IGZvciB0 aGUgc2FrZSBvZiBjb21wcmVzc2lvbi48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBk aXI9ImF1dG8iPiZuYnNwOyAmbmJzcDsgR3lhbiZndDsgQXMgU1J2NiB1c2VzIHRoZSBJUHY2IGRh dGEgcGxhbmUgaXQgaXMgYmFzZWQgb24gTFBNIChMb25nZXN0IHByZWZpeCBtYXRjaCkgcm91dGlu ZyBhbmQgbm90IE1QTFMgc3R5bGUg4oCcZXhhY3QgbWF0Y2jigJ0gZm9yIEZFQyBiaW5kaW5nLiZu YnNwOyBTbyB0aGF0IGJlaW5nIHNhaWQgdGhlIGRlc3RpbmF0aW9uIGVncmVzcyBQRSBTUiBsb2Nh dG9yIGZvciBmaW5hbCBkZXN0aW5hdGlvbiB3b3VsZCBiZSBMUE0gcm91dGVkDQogdG8gUFNQIG5v ZGUuJm5ic3A7IFNvIGluIHRoZSBjb250ZXh0IG9mIHN1bW1hcml6YXRpb24gdGhlIG1haW4gcG9p bnQgaXMgc3VtbWFyaXphdGlvbiBkb2VzIG5vdCBnZW5lcmFsbHkgaGFwcGVuIHdpdGhpbiB0aGUg Y2xvc2VkIHNpbmdlIGFyZWEgb3IgbGV2ZWwgU1IgZG9tYWluIGFzIGFsbCAmbmJzcDsgZWdyZXNz IFBFIGZpbmFsIGRlc3RpbmF0aW9uIHByZWZpeCBzaWQgaG9zdCByb3V0ZSBpcyBmbG9vZGVkIGRv bWFpbiB3aWRlLCBob3dldmVyIHdpdGggbGFyZ2VyDQogZG9tYWlucyBpdCBjb3VsZCBiZSBicm9r ZW4gdXAgaW50byBhcmVhcyBvciBsZXZlbHMgJm5ic3A7YW5kIExQTSBtYXRjaGluZyBjYW4gaGFw cGVuIHRvIHN1bW1hcml6ZSBmaW5hbCBkZXN0aW5hdGlvbiBlZ3Jlc3MgUEUgcHJlZml4IHNpZCBw cmVmaXhlcy4mbmJzcDsgQXMgR3JlZyBwb2ludGVkIG91dCBhcyBmYXIgYXMgc3VtbWFyaXphdGlv biB0aGUgbWFpbiB1c2UgY2FzZSBpcyBmb3IgaW50ZXIgYXJlYSB3aGVyZSBzdW1tYXJpemF0aW9u IHdvdWxkIG9jY3VyLiZuYnNwOw0KIFRoYXQgaXMgcHJlY2lzZWx5IEdyZWfigJlzIGNvbnRleHQg b2YgcmVwbGFjZW1lbnQgb2YgTVVTVCB3aXRoIFNIT1VMRC4mbmJzcDs8L2Rpdj4NCjxkaXYgZGly PSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5bREQyXSBNeSByZWFkIGlzIHRo YXQgeW91J3JlIGNvbmZ1c2luZyBkZXBsb3ltZW50IHJlcXVpcmVtZW50cyB3aXRoIHByb3RvY29s IHJlcXVpcmVtZW50cy4gJm5ic3A7VGhlIHJlcXVpcmVtZW50IGlzIHRoYXQgYSBwcm9wb3NhbCBN VVNUIHN1cHBvcnQgc3VtbWFyaXphdGlvbi4gJm5ic3A7V2hldGhlciBvciBub3QgYSBwYXJ0aWN1 bGFyIGRlcGxveW1lbnQgdXNlcyBtdWx0aXBsZSBkb21haW5zIGFuZCB0YWtlcyBhZHZhbnRhZ2Ug b2YgaXQNCiBpcyBub3QgcmVsZXZhbnQgdG8gdGhlIHJlcXVpcmVtZW50IG5vciB0aGUgcHJvcG9z YWwuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz cz0ieF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVy LWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFl eDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2IGRpcj0ibHRyIj4N CjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2IGRpcj0iYXV0byI+PC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjx1bD4NCjxsaT5JIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUgaW50ZW50aW9u IG9mIHRoZSByZXF1aXJlbWVudCBpbiBTZWN0aW9uIDQuMi4xIGJ1dCBJIG1heSBwcm9wb3NlIGV4 cHJlc3NpbmcgaXQgZGlmZmVyZW50bHk6PC9saT48L3VsPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweCA0MHB4OyBib3JkZXI6bm9uZTsgcGFkZGluZzowcHgiPkEgcGF0aCB0 cmF2ZXJzZWQgdXNpbmcgYSBsaXN0IG9mIGNvbXByZXNzZWQgU0lEcyBNVVNUIGFsd2F5cyBiZSB0 aGUgc2FtZSBhcyB0aGUgcGF0aCB0cmF2ZXJzZWQgdXNpbmcgdGhlIGxpc3Qgb2YgdW5jb21wcmVz c2VkIFNJRHMgaWYgbm8gY29tcHJlc3Npb24gd2FzIGFwcGxpZWQuPGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0RdIFRoaXMgc2VlbXMgbGlrZSByZWFzb25hYmxl IHRleHQ8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg ZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj4mbmJzcDsgJm5ic3A7R3lh biZndDsgQWdyZWVkIHdpdGggR3JlZ+KAmXMgY29tbWVudCBhbmQgdXBkYXRlZCB0ZXh0LjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9InhfZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBw eCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtc3R5bGU6c29s aWQ7IHBhZGRpbmctbGVmdDoxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCki Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0iYXV0 byI+PGJyPg0KPC9kaXY+DQo8dWw+DQo8bGk+SSB0aGluayB0aGF0IHRoZSB1c2Ugb2YgTVVTVCBp biByZXF1aXJlbWVudCA1LjEgaXMgdG9vIHN0cm9uZy4gRmlyc3RseSwgc3VjaCBjb21wYXRpYmls aXR5IGlzIG5vdCBlc3NlbnRpYWwgaW4gYSBncmVlbmZpZWxkIHNjZW5hcmlvLiBTZWNvbmRseSwg dGhlIGNvbnRyb2wgcGxhbmUgYmFzZWQgc29sdXRpb24gbWlnaHQgYmUgZW52aXNpb25lZCB0byBj b29yZGluYXRlIHRoZSBpbnRlcndvcmtpbmcgYmV0d2VlbiBTUiBkb21haW5zIHVzaW5nDQogU1J2 NiBhbmQgbm90IHVzaW5nIHRoZSBTUnY2IHRlY2huaXF1ZS48L2xpPjwvdWw+DQo8ZGl2PjwvZGl2 Pg0KW0RdIDUuMSBkZXNjcmliZXMgYSDigJxzaGlwcyBpbiB0aGUgbmlnaHTigJ0gZGVwbG95bWVu dCBzY2VuYXJpbywgc3VjaCB0aGF0IGl0IG11c3QgYmUgcG9zc2libGUgdG8gaGF2ZSBub24tY29t cHJlc3NlZCBTUnY2IHN1cHBvcnQgb24gYSBub2RlIGFzIHdlbGwgYXMgdGhlIGNvbXByZXNzaW9u IHNvbHV0aW9uLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0RdIEkuZS4gdGhlIGNvbXByZXNz aW9uIHNvbHV0aW9uIE1VU1QgbWFrZSBpdCBwb3NzaWJsZSBmb3IgYSBub2RlIHRvIHN1cHBvcnQg dGhlIHVuY29tcHJlc3NlZCBjb250cm9sIHBsYW5lIGFuZCBkYXRhIHBsYW5lLCBhcyB3ZWxsIGFz IHRoZSBjb21wcmVzc2VkIGNvbnRyb2wgcGxhbmUgYW5kIGRhdGEgcGxhbmUuIEl0IGRvZXMgbm90 IHN0YXRlIHRoYXQgZXZlcnkgbm9kZSBNVVNUIHN1cHBvcnQgYm90aCBhdCB0aGUgc2FtZSB0aW1l LiBHaXZlbg0KIHRoaXMsIGRvZXMgeW91ciBvYmplY3Rpb24gdG8gTVVTVCBzdGlsbCBhcHBseT88 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg ZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj4mbmJzcDsgJm5ic3A7IEd5 YW4mZ3Q7IEkgYmVsaWV2ZSBHcmVn4oCZcyBpcyBzdGF0aW5nIGFuZCBJIGFncmVlIGFzIHdlbGwg YXMgdGhlIHN0cm9uZyByZXF1aXJlbWVudCBoaW5kZXJzIHRoZSBkZXZlbG9wbWVudCBmb3Igd2hl biB3ZSBhcmUgaW4gdGhlIGVuZCBzdGF0ZSB3aGljaCB3b3VsZCBiZSBncmVlbiBmaWVsZCBvciBu ZXcgZGVwbG95bWVudHMgdGhhdCBkb27igJl0IG5lZWQgdGhlIE1VU1QgdmVyYmlhZ2UuJm5ic3A7 IElmIHlvdSBoYXZlIHRvIGFjY291bnQNCiBmb3IgdGhlIGludGVyb3BlcmFiaWxpdHkgb3IgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgdGhlaXIgaXMgZGVmaW5pdGVseSBtb3JlIG92ZXJoZWFkIHRo YXQgaGFzIHRvIGJlIG1ldCBpbiB0aGUgZGVzaWduIHNvbHV0aW9uIGFuZCBsaW1pdHMgdGhlIHNj b3BlIG9mIHRoZSBkZXNpZ24gc29sdXRpb24gd2hpY2ggc2hvdWxkIG5vdCBiZSBsaW1pdGVkLiZu YnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPltERDJdIHJldmlzaW9uIDAyIHNlY3Rpb24gNS4xIGRvZXMgbm90IHJlcXVpcmUgJnF1 b3Q7aW50ZXJvcGVyYWJpbGl0eSZxdW90OyBub3IgJnF1b3Q7YmFja3dhcmQgY29tcGF0aWJpbGl0 eSZxdW90Oy4gJm5ic3A7SXQgZGVzY3JpYmVzIGEgc2hpcHMtaW4tdGhlLW5pZ2h0IGNhcGFiaWxp dHkgd2hlcmUgdGhlIGNvbXByZXNzaW9uIHByb3Bvc2FsIGNhbiBleGlzdCBpbiB0aGUgc2FtZSBu ZXR3b3JrIGF0IHRoZSBzYW1lIHRpbWUgYXMgdGhlIGN1cnJlbnQgU1J2NiBwcm90b2NvbA0KIHdp dGhvdXQgYnJlYWtpbmcgdGhlIGN1cnJlbnQgcHJvdG9jb2wuICZuYnNwO1RoaXMgaXMgbm90IGEg aGlnaCBiYXIgdG8gbWVldC48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxk aXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4N CjxkaXYgZGlyPSJhdXRvIj5BbHNvIHRoZWlyIG1heWJlIG90aGVyIGludGVyd29ya2luZyB0dW5u ZWxpbmcgb3IgdHJhbnNsYXRpb24gbWVjaGFuaXNtcyB0aGF0IGFscmVhZHkgZXhpc3QgdG9kYXkg dGhhdCBjYW4gcHJvdmlkZSB0aGUgaW50ZXJvcGVyYWJpbGl0eSB3aXRob3V0IG1ha2luZyBpbnRl cm9wZXJhYmlsaXR5IG9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGEgcmVxdWlyZW1lbnQuJm5i c3A7IEkgdGhpbmsgdGhpcyB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVzDQogdGhlIHBvc3NpYmxl IHNvbHV0aW9uIHNjb3BlIG9mIHdoaWNoIHdlIGRvbuKAmXQgd2FudC48L2Rpdj4NCjxkaXYgZGly PSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5IZXJlIGlzIHJld29yZGluZyBv ZiB0aGUgZmlyc3Qgc2VudGVuY2UuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+ DQo8ZGl2IGRpcj0iYXV0byI+T3B0aW9uICMxJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+ 4oCcVGhlIGNvbXByZXNzaW9uIHByb3Bvc2FsIE1VU1Qgc3VwcG9ydCBkZXBsb3ltZW50IGluIGV4 aXN0aW5nIEJyb3duZmllbGQgU1J2NiBuZXR3b3JrcyBvbmx5IGFuZCBub3QgR3JlZW5maWVsZCBu ZXR3b3JrIGRlcGxveW1lbnRz4oCdJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0K PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+T3B0aW9uICMyJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0i YXV0byI+4oCcVGhlIGNvbXByZXNzaW9uIHByb3Bvc2FsIFNIT1VMRCBzdXBwb3J0IGRlcGxveW1l bnQgb24gZXhpc3RpbmcgU1J2NiBuZXR3b3Jrcy4gJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0iYXV0 byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+QXMgZXhpc3RpbmcgbmV0d29ya3Mgd2ls bCBldmVudHVhbGx5IGFsbCBzdXBwb3J0IFNSdjYgY29tcHJlc3Npb24gYXMgbm9kZXMgYXJlIHVw Z3JhZGVkIHByaW9yIHRvIGNvbnZlcnNpb24gdG8gU1J2NiwgdGhlIG5lZWQgZm9yIGFsbCBub2Rl cyB0byByZXF1aXJlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpbGwgbm90IGFsd2F5cyBiZSBu ZWNlc3NhcnkuICZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iPlRoYW5rIHlvdSZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8i Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPkd5YW48L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3Jk ZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6 MWV4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpIj4NCjxkaXYgZGlyPSJsdHIi Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KQW5kIGluIHRoZSBjb25jbHVzaW9uLCBvbmNlIGFnYWluLCBtYW55IHRoYW5r cyB0byBhbGwgdGhlIG1lbWJlcnMgb2YgdGhlIERlc2lnbiBUZWFtIGZvciB0aGUgam9iIHdlbGwg ZG9uZS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PkdyZWc8 L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPk9uIFRodSwgTm92IDEy LCAyMDIwIGF0IDE6MDYgQU0gV2VpcWlhbmcgQ2hlbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGVu Z3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNoZW5nd2VpcWlhbmdA Y2hpbmFtb2JpbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJv cmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4OyBib3JkZXItbGVmdC1jb2xv cjpyZ2IoMjA0LDIwNCwyMDQpIj4NCkhpIEdyb3VwLDxicj4NCkFzIHlvdSBrbm93LCB0aGUgU1BS SU5HIFdvcmtpbmcgR3JvdXAgc2V0IHVwIGFuIFNSIGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIHBy aW9yIHRvIElFVEYxMDguPGJyPg0KVGhlIGRlc2lnbiB0ZWFtIGlzIHRvIHByb2R1Y2UgKHJvdWdo KSBjb25zZW5zdXMgKG9mIHRoZSBEVCkgb3V0cHV0cyB0byB0aGUgV0cgb24gdHdvIHJlbGF0ZWQg dG9waWNzOjxicj4NCjEpIFdoYXQgYXJlIHRoZSByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0 byBjb21wcmVzc2luZyBzZWdtZW50IHJvdXRpbmcgaW5mb3JtYXRpb24gZm9yIHVzZSBvdmVyIElQ djY7PGJyPg0KMikgQSBjb21wYXJpc29uIG9mIHByb3Bvc2VkIGFwcHJvYWNoZXMgdG8gY29tcHJl c3Npbmcgc2VnbWVudCByb3V0aW5nIGluZm9ybWF0aW9uIGZvciB1c2Ugb3ZlciBJUHY2Ljxicj4N Cjxicj4NCldpdGggZ3JlYXQgZWZmb3J0IG9mIGRlc2lnbiB0ZWFtIG1lbWJlcnMsIERUIGhhdmUg ZmluaXNoZWQgdGhlIHZlcnNpb24gLTAwIG9mIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQgYW5k IGhhdmUgc3VibWl0dGVkIGl0IHRvIGRhdGF0cmFja2VyLjxicj4NCjxicj4NClBsZWFzZSByZXZp ZXcgaXQgYW5kIGxldCdzIGtub3cgeW91ciBjb21tZW50cy48YnI+DQo8YnI+DQpCLlIuPGJyPg0K V2VpcWlhbmcgQ2hlbmc8YnI+DQo8YnI+DQo8YnI+DQotLS0tLemCruS7tuWOn+S7ti0tLS0tPGJy Pg0K5Y+R5Lu25Lq6OiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XQ0KPGJyPg0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0MTHm nIgy5pelIDE2OjMyPGJyPg0K5pS25Lu25Lq6OiBTYW5kZXIgU3RlZmZhbm47IFNKTSBTdGVmZmFu bjsgV2VpcWlhbmcgQ2hlbmc8YnI+DQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwLnR4dDxi cj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcmNvbXBkdC1zcHJp bmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQtMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBXZWlxaWFuZyBDaGVuZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVt ZW50PGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRs ZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbXByZXNzZWQgU1J2NiBTSUQg TGlzdCBSZXF1aXJlbWVudHM8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDIwLTEwLTMwPGJy Pg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1 Ym1pc3Npb248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDEw PGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc3Jjb21wZHQtc3ByaW5n LWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwLnR4dCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNyY29tcGR0 LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudC0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWly ZW1lbnQvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWly ZW1lbnQvPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jjb21wZHQt c3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29t cGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudDwvYT48YnI+DQpIdG1saXplZDombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc3Jjb21wZHQtc3ByaW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50LTAwPC9hPjxicj4N Cjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyByZXF1aXJlbWVudHMgZm9yIHNvbHV0aW9ucyB0byBjb21wcmVzcyBTUnY2PGJyPg0K Jm5ic3A7ICZuYnNwO1NJRCBsaXN0cy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4N ClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJp bmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCi0tIDxicj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJ4X2dtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIi Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8cCBzdHlsZT0iY29sb3I6cmdi KDM0LDM0LDM0KSI+PGEgaHJlZj0iaHR0cDovL3d3dy52ZXJpem9uLmNvbS8iIHRhcmdldD0iX2Js YW5rIiBzdHlsZT0iY29sb3I6cmdiKDE3LDg1LDIwNCk7IHBhZGRpbmctYm90dG9tOjFlbTsgZGlz cGxheTppbmxpbmUtYmxvY2siPjxpbWcgd2lkdGg9IjgxIiBoZWlnaHQ9IjE4IiBzdHlsZT0iaGVp Z2h0OjE4cHg7IHdpZHRoOjgxcHgiIHNyYz0iaHR0cDovL3NzNy52encuY29tL2lzL2ltYWdlL1Zl cml6b25XaXJlbGVzcy92ei1sb2dvLWVtYWlsIj48L2E+PGJyPg0KPC9wPg0KPHAgc3R5bGU9ImZv bnQtc2l6ZToxZW07IG1hcmdpbjowcHg7IGZvbnQtZmFtaWx5OiZxdW90O1Zlcml6b24gTkhHIERT JnF1b3Q7LEFyaWFsLHNhbnMtc2VyaWY7IGxpbmUtaGVpZ2h0OjEzcHg7IGNvbG9yOmJsYWNrIj4N CjxiPkd5YW4gTWlzaHJhPC9iPjwvcD4NCjxwIHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpOyBt YXJnaW46MHB4OyBsaW5lLWhlaWdodDoxM3B4Ij48Zm9udCBmYWNlPSJnZW9yZ2lhLCBzZXJpZiIg c3R5bGU9ImNvbG9yOmJsYWNrOyBmb250LXNpemU6MWVtIj48aT5OZXR3b3JrIFNvbHV0aW9ucyBB PC9pPjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iZ2VvcmdpYSwgc2VyaWYiPjxp PnJjaGl0ZWN0Jm5ic3A7PC9pPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iZm9udC1zaXplOjFlbTsg bWFyZ2luOjBweDsgbGluZS1oZWlnaHQ6MTNweDsgY29sb3I6YmxhY2siPjxpPjxmb250IGZhY2U9 Imdlb3JnaWEsIHNlcmlmIj5NIDMwMSA1MDItMTM0Nzxicj4NCjEzMTAxIENvbHVtYmlhIFBpa2Um bmJzcDs8YnI+DQo8L2ZvbnQ+PC9pPlNpbHZlciBTcHJpbmcsIE1EPC9wPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR11MB4081DBCEC0CE4D035C60CA90C8DE0BN6PR11MB4081namp_-- From nobody Mon Dec 28 15:29:11 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1E3A0EC4; Mon, 28 Dec 2020 15:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gY-0ZZ1vYQ1s; Mon, 28 Dec 2020 15:29:06 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E285D3A0EBF; Mon, 28 Dec 2020 15:29:05 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BSNSt2A015753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Dec 2020 18:28:59 -0500 Date: Mon, 28 Dec 2020 15:28:54 -0800 From: Benjamin Kaduk To: "Pablo Camarillo (pcamaril)" Cc: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Message-ID: <20201228232854.GJ89068@kduck.mit.edu> References: <160753350153.28997.1345859562639063746@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 23:29:09 -0000 Hi Pablo, On Thu, Dec 10, 2020 at 06:01:58PM +0000, Pablo Camarillo (pcamaril) wrote: > Hi Ben, > > Many thanks for your time on this document. > We’ve published rev27 of the document with the changes. Details inline with [PC]. > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-27 Thanks for the updates; I've cleared my discuss in the datatracker. I'll trim the resolved stuff and just reply on a couple remaining points inline... > > -----Original Message----- > From: Benjamin Kaduk via Datatracker > Sent: miércoles, 9 de diciembre de 2020 18:05 > To: The IESG > Cc: draft-ietf-spring-srv6-network-programming@ietf.org; spring-chairs@ietf.org; spring@ietf.org; Bruno Decraene ; Joel Halpern ; jmh@joelhalpern.com > Subject: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) > > Section 4.16.1.2 > > As a reminder, [RFC8754] defines in section 5 the SR Deployment Model > within the SR Domain [RFC8402]. Within this framework, the > Authentication Header (AH) is not used to secure the SRH as described > in Section 7.5 of [RFC8754]. > > (repeating from the previous thread as a placeholder) I think we need another sentence or clause here to clarify why this statement is relevant, e.g., "Thus, while the AH can detect changes to the IPv6 header chain, it will not be used in combination with the SRH, so use of PSP will not cause delivery failure due to AH validation checks." > > [PC] What about this? > > Within this framework, the Authentication Header (AH) is not used to secure the SRH as described in Section 7.5 of [RFC8754]. > > > Within this framework, the Authentication Header (AH) is not used to secure the SRH as described in Section 7.5 of [RFC8754]. Hence, the discussion of applicability of PSP along with AH usage is beyond the scope of this document. > That seems okay, thanks. > Section 9 > > There seem to be some security considerations relating to the use of PSP, in that the egress node loses visibility into which policy was used for a given packet, so all packets from all policies that egress via that SID are in the same anonymity (and policy!) set. In particular, even if an HMAC TLV was present in the SRH, it is not available and cannot be validated. I recognize that the headend (or whatever entity is assigning SR policy) should know when such validation would be intended to occur and not assign a policy incompatible with it, but there are still new considerations in the sense that the headend needs to be aware of these considerations. > > [PC] As part of the comments from Alvaro we added this text which I believe covers that point: > “The headend policy definition should be consistent with the specific > behavior used and any local configuration” > > (repeating as a placeholder from the previous thread) I think we should also say that in the absence of the HMAC TLV, valid FUNC and ARG values on any given node may be guessable and spoofable, along with the standard disclaimer that risks are minimal since all nodes in the SR domain are assumed to be trusted. This is distinct from the already-extant ability to spoof a SID in that the underlying structure in the SID may allow the attacker to induce behavior that was never intended to be a SID, for example if the implementation logically separates FUNC and ARG processing and the attacker makes a combination that was never advertised. > > [PC] I believe you are making an implementation assumption on how SIDs are matched at a node. As a reminder RFC8754 states that “When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packet's destination address.”. Thus, the ability to spoof a particular FUNCT is the same as the ability to spoof any other IP address on the node. In the context of SRv6, this is mitigated by using the SR Domain as described in RFC8754 and -in particular Section 7.2-. I'm definitely making implementation assumptions, yes. It is possible to implement it in a way that does not suffer the potential issue, though there is a perhaps-tempting way to implement it that does suffer from the issue. In particular, I'm less concerned about spoofing FUNCT (as you note, it's similar to spoofing other things, including other SIDs) than about spoofing ARG. The ability to encode semantic information (even when the semantics are only known to the one node) in a part of the IP address in this manner seems like a fairly novel construction, and I was hoping to emphasize that care should be taken when implementing the parser. Thanks, Ben From nobody Tue Dec 29 10:04:39 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881FF3A03F5; Tue, 29 Dec 2020 10:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.901 X-Spam-Level: X-Spam-Status: No, score=-11.901 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=cOGHrJpJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iHA85A0Y 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 ZfY67_ke8zk2; Tue, 29 Dec 2020 10:04:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA5D3A03F4; Tue, 29 Dec 2020 10:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7558; q=dns/txt; s=iport; t=1609265070; x=1610474670; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eYR3VvSiCxgjSpwj9URzu3u8JcoEDwEFregziKqXRl0=; b=cOGHrJpJz0hlXIc06hotA+QcC5aULXAr8cQiVYEFuqdb7lqkUUy5KeOx MEcp9h+6RB24rTRgkuK0klfJuASzRn+Ov00flxHcQmcyM258Iya3iy3S4 +jlb5UXZkLn1l9HKWwLGT2xx+4/6dlZ398eQk6owEwZePzs85gr1xIVPn A=; X-IPAS-Result: =?us-ascii?q?A0D9AADNbetfkIwNJK1iDg8BAQEBCQESAQUFAUCBPgUBC?= =?us-ascii?q?wGBUiMufVsvLgqENYNIA41gA5kNglMDVAsBAQENAQEjCgIEAQGESgIXgVgCJ?= =?us-ascii?q?TcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAYY4DIVzAQEBAwESEREMA?= =?us-ascii?q?QE3AQQHBAIBCBEEAQEBAgIfBwICAjAVCAgCBA4FCBqDBAGCVQMOIAEDC6R2A?= =?us-ascii?q?oE8iGl2gTKDBAEBBoUTGIIQAwaBDioBgnSDfIU+eiYbgUE/gRFDglY+gl0BA?= =?us-ascii?q?QOBXgUxAoJeNIIsgVmBD0AEHTQCIF8YG00RFAUeAo9Ngn4/pAqBEQqCdokqj?= =?us-ascii?q?RWFO6JQnxuRKxKEZgIEAgQFAg4BAQaBJUcigVlwFYMkUBcCDY4hDA4JFIM6h?= =?us-ascii?q?RSFBEB0NwIGAQkBAQMJfIphLYEGAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AjDWubxcLpkNlbRp+tsvOL9fJlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQBdfe6u4ChubL4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8P/exvfrmDhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,458,1599523200"; d="scan'208";a="659061443" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Dec 2020 18:04:26 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BTI4QQP010715 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Dec 2020 18:04:26 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 29 Dec 2020 12:04:26 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 29 Dec 2020 12:04:25 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 29 Dec 2020 12:04:25 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lbeaEQZ33id7K9OEGl06n1Nf/bGEYXWXMZJ2TdZ30NqlcbiRkQ99x1pNYLFj0mRgwLKZF8DDJoNBHaVUqlv8prpep4kaRGrhIjsmbThlYjVKBJa5um+hxuDBfWMGnbPozYOpGGOu9ExjT8ktEoB3B1H4yQOV7Vs2xLKOrlvsUalpeES0vb+cdd5g91I0VZogNwebuIYYsLROOQnVg76cvJ0cSEjQ3rnHJEt/fIdt0D7ppjmhsxJzeH99PXTOjT4EIRY4enFFvpK8q2/lcnFkm8iYGoKpauFJOJpAhJwSgImBOBDZdT4PlVG0EeTdhkvslbwspYDJwd4cVcJbxGYWjw== 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=eYR3VvSiCxgjSpwj9URzu3u8JcoEDwEFregziKqXRl0=; b=j2yoNkAYtk9FiF2D0s8RgvkNHdVj1iVYMxBDn/z7WGpfi+DXM0FsrREbydQKWgqivdyYwUSkTETsOtn9hD6UoCmk0KB6hH7caYYCujEJeirel0d1KPSOHDmj5UeqW0TuULbNEbm1Weu7h0PRwOgRIed1byepgpbyY47bptA1KtFVGB3phFGWJgu7qSa2qTKusERm9J1zXDohxCzbD+ZM1uVQ0mcUhOjnwzWqnMddyAHQO1cXZ1jntbwgP5r12J32u9rjDFaLE1wZJMpRcgmOlNxvvWpd/KstujuxSwO/LpN8V4IVw6MrKqFP7JuX1tt7CYz3ek82Rz6QULSXIhjt2w== 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=eYR3VvSiCxgjSpwj9URzu3u8JcoEDwEFregziKqXRl0=; b=iHA85A0YfGigK9+keKGffVbt3yTgyxUwcgV1pwXoe+qLrzS/eAxNozkhGVj4J17sSkXLkeIJmTrSxDO0Gk0opdP219EOfc94xRSgZ3SMzn0tTv2FQ0FYJ2lFz4AhBGjMZw/jTU8YPSLOSJ0HFq+K8rKFAhbRM2TD+JoKZQoDjug= Received: from SA2PR11MB5082.namprd11.prod.outlook.com (2603:10b6:806:115::5) by SN6PR11MB2703.namprd11.prod.outlook.com (2603:10b6:805:59::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.31; Tue, 29 Dec 2020 18:04:24 +0000 Received: from SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d]) by SA2PR11MB5082.namprd11.prod.outlook.com ([fe80::d8db:82ac:c47c:ad0d%4]) with mapi id 15.20.3721.019; Tue, 29 Dec 2020 18:04:24 +0000 From: "Pablo Camarillo (pcamaril)" To: Benjamin Kaduk CC: The IESG , "draft-ietf-spring-srv6-network-programming@ietf.org" , "spring-chairs@ietf.org" , "spring@ietf.org" , Bruno Decraene , Joel Halpern Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) Thread-Index: AQHWzk11hJlsON8AwUKTQpqAtVRetqnweUEwgBzMjQCAATGmoA== Date: Tue, 29 Dec 2020 18:04:24 +0000 Message-ID: References: <160753350153.28997.1345859562639063746@ietfa.amsl.com> <20201228232854.GJ89068@kduck.mit.edu> In-Reply-To: <20201228232854.GJ89068@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [83.43.91.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 082759c4-5b22-4765-03c0-08d8ac242ccd x-ms-traffictypediagnostic: SN6PR11MB2703: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xFrpt+Bc3oruhNKSjzAc8YoOJvTmt9JJKCiBPQZ6LmIR+WTURrQ5bBwB9p2sBZNGjLr7lpACr6k9gqpSs692jM3YlX0bFMCj6RxdGqcOXnWQHGTkgch349wt/Dg6sWc897aMOfYsj+B8rG9U32STTScDMS4XqswhCylPcAM+Wqj/ugbOTOSxcuk8z6qvDzqYCq2Pydi4wfgc4XAeFWr0mQCCI4x2f2IMbfdyIZbRcW/TEw2iFiLmkE28W1srrDl3hWnU3LHEDalTdXz3yYpM4HmWOd4duGSI6U3AQ8/62rzWVuPKCdYIF/HjAt3zVhtW/tdxeZWDx+81im2pUcG2iuk+7hHTjsjUIYgSvOTC/eGMnBl3zTzJ2QErenvhu94MfDyRjuFpA6WYqRR335xJy3m5vR28Bdu9KvSaDR2mDu+c1aYvstl0NUQYApPiXs2cHxU/LRdD/6WmGYXeZoMo7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5082.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(396003)(39860400002)(136003)(64756008)(6916009)(9686003)(8936002)(5660300002)(2906002)(66446008)(8676002)(76116006)(66556008)(478600001)(55016002)(316002)(52536014)(54906003)(71200400001)(26005)(53546011)(6506007)(966005)(83380400001)(66574015)(4326008)(86362001)(33656002)(66946007)(66476007)(7696005)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?ajdJMHNIYnY0VGtRc05CeitNTDcwcXRxUjBBeis0ODlCcHRQQXNQZW01L0Vo?= =?utf-8?B?OFV3Ulltam8vUXMyaDNDY1lZYWxYRU1rVG5XQ2ljZVNBNmdqVFhmZlJwenl3?= =?utf-8?B?ZDVJRWNVVEcxeWtmamkvN0t0SmI0azRBZ0JYU2dHejdWTWFMN3VvUk9jcGtz?= =?utf-8?B?ZTQxT2E1anA3RWJMNlpuMVp0NSs0ckRQeitTdThLcmkva1V5T0FRNnNUTm1X?= =?utf-8?B?azBicWRENVRSa0hUanc1RWRqbEVhOXRnZ2RkMm5sQ01VbHhDa0ZqUmFZZ3RS?= =?utf-8?B?b1BXTllJSWd5V2gxaFl5eGk1YVRNZWZYQUZMZ0t4Y3hZSG9lT0R2TjhnbmVz?= =?utf-8?B?cWh0bllmM2kxY0UxZFJTWkpIT0RZcFVIcWxsQ0JvK1dRcHBlWmNQa1hhWDlp?= =?utf-8?B?UFNyL04rb1N1aVl4WWlTUnNCM3NHRTFOYmh5WkgzOEt5eWtqaGtXWFEraXlB?= =?utf-8?B?OE41aWRNcEFNUWpjUE44ZUFBM2dNd1lBeTdKSjNKc2hCcUJpMFZkUnRNR2ow?= =?utf-8?B?cE5ISTFvRzFNb1lISThuMTBPbHh0T05CZWVsd1pEbC9YdngvSEp5QU9JZlBs?= =?utf-8?B?TWU0Mlh5ZDZXNmZCQSsza3FxbWdiR2loRm1wV2VsSVhYZjc5dnE2QkdTWEc3?= =?utf-8?B?VC82L3JpV1FsVE5HVjR0OVdrM2Q1ZnBTNWcwanowd0VCQmdVbUo0VnZLQlVh?= =?utf-8?B?Y1RNU2lWZmlTWXhxYm9hRzQzQW9MTE56USswdE1aeHRTenl5MUYrdGhvK3c1?= =?utf-8?B?YWt3bTl4Mkhpb0c0czc2ZERYQ0JiWS9TTnhLRGlDeEVtWHpSY0ozSlQrWDNX?= =?utf-8?B?Y0pzSE1aSWxCaXlRcTJSNDJaVTdSSVFtNUZUS3NMVHFRYkhWWU5ISzFNRHht?= =?utf-8?B?ZGxSY25DN1FEWVpKaDdYVXV3ejdZeEJ3NWlxZ0VoWWJ0UG5GSDd5SHdoUGpw?= =?utf-8?B?Tm5uWUpTWHVqWG1NS3JIdmh1TXRRNUFEaXpQWjNOWERTWHdJdFp0d0NDcXM0?= =?utf-8?B?K0xXZURoUTFnTHhIODJpN0k5TmtqcWNDbnZUd2NnbFZtRFl6SHBGUXFCT1Yz?= =?utf-8?B?MXhWSEwxQyt3b2VqU3M4WUJYSjdRcDdZOWRqNjYyRUFrdEZ4M043dEpYQ290?= =?utf-8?B?bWt6QkE3MlBNSW04T1F6VW5HZkZreUlCaXlWOTZUTThzWVZQTTdJMVBOa3F3?= =?utf-8?B?SEN0RGZrQUVrdEErb2FaeDdLd0JBd2wrekdlQkZHektodEx6RElxalM4SmhE?= =?utf-8?B?OXFSUDc0ZHNleEpEbGVmeVZSNURYazBwYTl5aTk3SnFZcVJBZVBJYTFUTjc3?= =?utf-8?Q?3HB26OzdOyblg=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5082.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 082759c4-5b22-4765-03c0-08d8ac242ccd X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2020 18:04:24.2143 (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: jDIs50tn9MamzGt5FNz9HDxNa08oa7+rRG7TAbbPEbkksvFL6+k5U+LI2Xs7qGfmhENCcDfcwU4YfD8l3UGeSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2703 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-26: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:04:33 -0000 QmVuLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciB0aW1lIHRvIHJldmlldyB0aGUgZG9jdW1lbnQg YW5kIGNvbmZpcm1pbmcgdGhlIERJU0NVU1MgcG9pbnQgaXMgcmVzb2x2ZWQgbm93Lg0KV2UnbGwg cG9zdCBhIHJldjI4IGFkZGluZyB0aGUgcHJvcG9zZWQgdGV4dCBmb3IgeW91ciBjb21tZW50IHBv aW50IGJlbG93Lg0KDQpUaGFua3MsDQpQYWJsby4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PiANClNlbnQ6IG1hcnRlcywg MjkgZGUgZGljaWVtYnJlIGRlIDIwMjAgMDoyOQ0KVG86IFBhYmxvIENhbWFyaWxsbyAocGNhbWFy aWwpIDxwY2FtYXJpbEBjaXNjby5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBk cmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmdAaWV0Zi5vcmc7IHNwcmlu Zy1jaGFpcnNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgQnJ1bm8gRGVjcmFlbmUgPGJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20+OyBKb2VsIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+ DQpTdWJqZWN0OiBSZTogQmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc3By aW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZy0yNjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCg0KSGkgUGFibG8sDQoNCk9uIFRodSwgRGVjIDEwLCAyMDIwIGF0IDA2OjAxOjU4UE0gKzAw MDAsIFBhYmxvIENhbWFyaWxsbyAocGNhbWFyaWwpIHdyb3RlOg0KPiBIaSBCZW4sDQo+IA0KPiBN YW55IHRoYW5rcyBmb3IgeW91ciB0aW1lIG9uIHRoaXMgZG9jdW1lbnQuDQo+IFdl4oCZdmUgcHVi bGlzaGVkIHJldjI3IG9mIHRoZSBkb2N1bWVudCB3aXRoIHRoZSBjaGFuZ2VzLiAgRGV0YWlscyBp bmxpbmUgd2l0aCBbUENdLg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nDQo+IC0yNw0KDQpUaGFua3MgZm9yIHRo ZSB1cGRhdGVzOyBJJ3ZlIGNsZWFyZWQgbXkgZGlzY3VzcyBpbiB0aGUgZGF0YXRyYWNrZXIuDQoN CkknbGwgdHJpbSB0aGUgcmVzb2x2ZWQgc3R1ZmYgYW5kIGp1c3QgcmVwbHkgb24gYSBjb3VwbGUg cmVtYWluaW5nIHBvaW50cyBpbmxpbmUuLi4NCg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGll dGYub3JnPg0KPiBTZW50OiBtacOpcmNvbGVzLCA5IGRlIGRpY2llbWJyZSBkZSAyMDIwIDE4OjA1 DQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtc3ByaW5n LXNydjYtbmV0d29yay1wcm9ncmFtbWluZ0BpZXRmLm9yZzsgDQo+IHNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgQnJ1bm8gRGVjcmFlbmUgDQo+IDxicnVuby5kZWNyYWVu ZUBvcmFuZ2UuY29tPjsgSm9lbCBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgDQo+IGpt aEBqb2VsaGFscGVybi5jb20NCj4gU3ViamVjdDogQmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9u IA0KPiBkcmFmdC1pZXRmLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmctMjY6ICh3aXRo IERJU0NVU1MgYW5kIA0KPiBDT01NRU5UKQ0KPiANCj4gU2VjdGlvbiA0LjE2LjEuMg0KPiANCj4g ICAgQXMgYSByZW1pbmRlciwgW1JGQzg3NTRdIGRlZmluZXMgaW4gc2VjdGlvbiA1IHRoZSBTUiBE ZXBsb3ltZW50IE1vZGVsDQo+ICAgIHdpdGhpbiB0aGUgU1IgRG9tYWluIFtSRkM4NDAyXS4gIFdp dGhpbiB0aGlzIGZyYW1ld29yaywgdGhlDQo+ICAgIEF1dGhlbnRpY2F0aW9uIEhlYWRlciAoQUgp IGlzIG5vdCB1c2VkIHRvIHNlY3VyZSB0aGUgU1JIIGFzIGRlc2NyaWJlZA0KPiAgICBpbiBTZWN0 aW9uIDcuNSBvZiBbUkZDODc1NF0uDQo+IA0KPiAocmVwZWF0aW5nIGZyb20gdGhlIHByZXZpb3Vz IHRocmVhZCBhcyBhIHBsYWNlaG9sZGVyKSBJIHRoaW5rIHdlIG5lZWQgYW5vdGhlciBzZW50ZW5j ZSBvciBjbGF1c2UgaGVyZSB0byBjbGFyaWZ5IHdoeSB0aGlzIHN0YXRlbWVudCBpcyByZWxldmFu dCwgZS5nLiwgIlRodXMsIHdoaWxlIHRoZSBBSCBjYW4gZGV0ZWN0IGNoYW5nZXMgdG8gdGhlIElQ djYgaGVhZGVyIGNoYWluLCBpdCB3aWxsIG5vdCBiZSB1c2VkIGluIGNvbWJpbmF0aW9uIHdpdGgg dGhlIFNSSCwgc28gdXNlIG9mIFBTUCB3aWxsIG5vdCBjYXVzZSBkZWxpdmVyeSBmYWlsdXJlIGR1 ZSB0byBBSCB2YWxpZGF0aW9uIGNoZWNrcy4iDQo+IA0KPiBbUENdIFdoYXQgYWJvdXQgdGhpcz8N Cj4gPE9MRD4NCj4gV2l0aGluIHRoaXMgZnJhbWV3b3JrLCB0aGUgQXV0aGVudGljYXRpb24gSGVh ZGVyIChBSCkgaXMgbm90IHVzZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gNy41IG9mIFtSRkM4NzU0XS4NCj4gPC9PTEQ+DQo+IDxQUk9QT1NBTD4NCj4gV2l0aGlu IHRoaXMgZnJhbWV3b3JrLCB0aGUgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkgaXMgbm90IHVz ZWQgdG8gc2VjdXJlIHRoZSBTUkggYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy41IG9mIFtSRkM4 NzU0XS4gSGVuY2UsIHRoZSBkaXNjdXNzaW9uIG9mIGFwcGxpY2FiaWxpdHkgb2YgUFNQIGFsb25n IHdpdGggQUggdXNhZ2UgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiA8 L1BST1BPU0FMPg0KDQpUaGF0IHNlZW1zIG9rYXksIHRoYW5rcy4NCg0KPiBTZWN0aW9uIDkNCj4g DQo+IFRoZXJlIHNlZW0gdG8gYmUgc29tZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWxhdGlu ZyB0byB0aGUgdXNlIG9mIFBTUCwgaW4gdGhhdCB0aGUgZWdyZXNzIG5vZGUgbG9zZXMgdmlzaWJp bGl0eSBpbnRvIHdoaWNoIHBvbGljeSB3YXMgdXNlZCBmb3IgYSBnaXZlbiBwYWNrZXQsIHNvIGFs bCBwYWNrZXRzIGZyb20gYWxsIHBvbGljaWVzIHRoYXQgZWdyZXNzIHZpYSB0aGF0IFNJRCBhcmUg aW4gdGhlIHNhbWUgYW5vbnltaXR5IChhbmQgcG9saWN5ISkgc2V0LiAgSW4gcGFydGljdWxhciwg ZXZlbiBpZiBhbiBITUFDIFRMViB3YXMgcHJlc2VudCBpbiB0aGUgU1JILCBpdCBpcyBub3QgYXZh aWxhYmxlIGFuZCBjYW5ub3QgYmUgdmFsaWRhdGVkLiAgSSByZWNvZ25pemUgdGhhdCB0aGUgaGVh ZGVuZCAob3Igd2hhdGV2ZXIgZW50aXR5IGlzIGFzc2lnbmluZyBTUiBwb2xpY3kpIHNob3VsZCBr bm93IHdoZW4gc3VjaCB2YWxpZGF0aW9uIHdvdWxkIGJlIGludGVuZGVkIHRvIG9jY3VyIGFuZCBu b3QgYXNzaWduIGEgcG9saWN5IGluY29tcGF0aWJsZSB3aXRoIGl0LCBidXQgdGhlcmUgYXJlIHN0 aWxsIG5ldyBjb25zaWRlcmF0aW9ucyBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgaGVhZGVuZCBuZWVk cyB0byBiZSBhd2FyZSBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucy4NCj4gDQo+IFtQQ10gQXMgcGFy dCBvZiB0aGUgY29tbWVudHMgZnJvbSBBbHZhcm8gd2UgYWRkZWQgdGhpcyB0ZXh0IHdoaWNoIEkg YmVsaWV2ZSBjb3ZlcnMgdGhhdCBwb2ludDoNCj4g4oCcVGhlIGhlYWRlbmQgcG9saWN5IGRlZmlu aXRpb24gc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgc3BlY2lmaWMNCj4gICAgYmVoYXZp b3IgdXNlZCBhbmQgYW55IGxvY2FsIGNvbmZpZ3VyYXRpb27igJ0NCj4gDQo+IChyZXBlYXRpbmcg YXMgYSBwbGFjZWhvbGRlciBmcm9tIHRoZSBwcmV2aW91cyB0aHJlYWQpIEkgdGhpbmsgd2Ugc2hv dWxkIGFsc28gc2F5IHRoYXQgaW4gdGhlIGFic2VuY2Ugb2YgdGhlIEhNQUMgVExWLCB2YWxpZCBG VU5DIGFuZCBBUkcgdmFsdWVzIG9uIGFueSBnaXZlbiBub2RlIG1heSBiZSBndWVzc2FibGUgYW5k IHNwb29mYWJsZSwgYWxvbmcgd2l0aCB0aGUgc3RhbmRhcmQgZGlzY2xhaW1lciB0aGF0IHJpc2tz IGFyZSBtaW5pbWFsIHNpbmNlIGFsbCBub2RlcyBpbiB0aGUgU1IgZG9tYWluIGFyZSBhc3N1bWVk IHRvIGJlIHRydXN0ZWQuICBUaGlzIGlzIGRpc3RpbmN0IGZyb20gdGhlIGFscmVhZHktZXh0YW50 IGFiaWxpdHkgdG8gc3Bvb2YgYSBTSUQgaW4gdGhhdCB0aGUgdW5kZXJseWluZyBzdHJ1Y3R1cmUg aW4gdGhlIFNJRCBtYXkgYWxsb3cgdGhlIGF0dGFja2VyIHRvIGluZHVjZSBiZWhhdmlvciB0aGF0 IHdhcyBuZXZlciBpbnRlbmRlZCB0byBiZSBhIFNJRCwgZm9yIGV4YW1wbGUgaWYgdGhlIGltcGxl bWVudGF0aW9uIGxvZ2ljYWxseSBzZXBhcmF0ZXMgRlVOQyBhbmQgQVJHIHByb2Nlc3NpbmcgYW5k IHRoZSBhdHRhY2tlciBtYWtlcyBhIGNvbWJpbmF0aW9uIHRoYXQgd2FzIG5ldmVyIGFkdmVydGlz ZWQuDQo+IA0KPiBbUENdIEkgYmVsaWV2ZSB5b3UgYXJlIG1ha2luZyBhbiBpbXBsZW1lbnRhdGlv biBhc3N1bXB0aW9uIG9uIGhvdyBTSURzIGFyZSBtYXRjaGVkIGF0IGEgbm9kZS4gQXMgYSByZW1p bmRlciBSRkM4NzU0IHN0YXRlcyB0aGF0IOKAnFdoZW4gYW4gU1J2Ni1jYXBhYmxlIG5vZGUgcmVj ZWl2ZXMgYW4gSVB2NiBwYWNrZXQsIGl0IHBlcmZvcm1zIGEgbG9uZ2VzdC1wcmVmaXgtbWF0Y2gg bG9va3VwIG9uIHRoZSBwYWNrZXQncyBkZXN0aW5hdGlvbiBhZGRyZXNzLuKAnS4gVGh1cywgdGhl IGFiaWxpdHkgdG8gc3Bvb2YgYSBwYXJ0aWN1bGFyIEZVTkNUIGlzIHRoZSBzYW1lIGFzIHRoZSBh YmlsaXR5IHRvIHNwb29mIGFueSBvdGhlciBJUCBhZGRyZXNzIG9uIHRoZSBub2RlLiBJbiB0aGUg Y29udGV4dCBvZiBTUnY2LCB0aGlzIGlzIG1pdGlnYXRlZCBieSB1c2luZyB0aGUgU1IgRG9tYWlu IGFzIGRlc2NyaWJlZCBpbiBSRkM4NzU0IGFuZCAtaW4gcGFydGljdWxhciBTZWN0aW9uIDcuMi0u DQoNCkknbSBkZWZpbml0ZWx5IG1ha2luZyBpbXBsZW1lbnRhdGlvbiBhc3N1bXB0aW9ucywgeWVz LiAgSXQgaXMgcG9zc2libGUgdG8gaW1wbGVtZW50IGl0IGluIGEgd2F5IHRoYXQgZG9lcyBub3Qg c3VmZmVyIHRoZSBwb3RlbnRpYWwgaXNzdWUsIHRob3VnaCB0aGVyZSBpcyBhIHBlcmhhcHMtdGVt cHRpbmcgd2F5IHRvIGltcGxlbWVudCBpdCB0aGF0IGRvZXMgc3VmZmVyIGZyb20gdGhlIGlzc3Vl Lg0KDQpJbiBwYXJ0aWN1bGFyLCBJJ20gbGVzcyBjb25jZXJuZWQgYWJvdXQgc3Bvb2ZpbmcgRlVO Q1QgKGFzIHlvdSBub3RlLCBpdCdzIHNpbWlsYXIgdG8gc3Bvb2Zpbmcgb3RoZXIgdGhpbmdzLCBp bmNsdWRpbmcgb3RoZXIgU0lEcykgdGhhbiBhYm91dCBzcG9vZmluZyBBUkcuICBUaGUgYWJpbGl0 eSB0byBlbmNvZGUgc2VtYW50aWMgaW5mb3JtYXRpb24gKGV2ZW4gd2hlbiB0aGUgc2VtYW50aWNz IGFyZSBvbmx5IGtub3duIHRvIHRoZSBvbmUgbm9kZSkgaW4gYSBwYXJ0IG9mIHRoZSBJUCBhZGRy ZXNzIGluIHRoaXMgbWFubmVyIHNlZW1zIGxpa2UgYSBmYWlybHkgbm92ZWwgY29uc3RydWN0aW9u LCBhbmQgSSB3YXMgaG9waW5nIHRvIGVtcGhhc2l6ZSB0aGF0IGNhcmUgc2hvdWxkIGJlIHRha2Vu IHdoZW4gaW1wbGVtZW50aW5nIHRoZSBwYXJzZXIuDQoNClRoYW5rcywNCg0KQmVuDQo= From nobody Tue Dec 29 10:13:30 2020 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF713A0489; Tue, 29 Dec 2020 10:13:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <160926560431.10681.8485064286504544476@ietfa.amsl.com> Date: Tue, 29 Dec 2020 10:13:24 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-28.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 18:13:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : SRv6 Network Programming Authors : Clarence Filsfils Pablo Camarillo Garvia John Leddy Daniel Voyer Satoru Matsushima Zhenbin Li Filename : draft-ietf-spring-srv6-network-programming-28.txt Pages : 44 Date : 2020-12-29 Abstract: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-28 https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/

Dear all,

 

We just published the following draft which describe= s a method to support SRv6 in-band measurement using IOAM.

draft-song-spring-siam-00 - SRv= 6 In-situ Active Measurement (ietf.org)

It achieves the same goal as IOAM but avoid the issu= es concerning the encapsulation and overhead.

Moreover, it can be used for several other interesti= ng applications as summarized in our draft.

One of them is detailed in the following draft: &nbs= p;

https://datatracker.ietf.org/doc/draft-tian= -bupt-inwt-mechanism-policy/

 

 

We believe the proposed method is simple and practic= al. You are welcome to provide comments, suggestions, and questions.

Thank you very much!

 

Best,

Haoyu