From nobody Thu Mar 3 03:59:03 2022 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 2E0E63A040B; Thu, 3 Mar 2022 03:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=nokia.onmicrosoft.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 Pjd3VASuhzt5; Thu, 3 Mar 2022 03:58:49 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1a::70e]) (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 0BAD43A0490; Thu, 3 Mar 2022 03:58:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/hmvtnLncaUg/XgsoTxVZZAfor2hHWDTQuS+iUzdbD13mu7h5gOhtjAjif7YLRDQ2/XLM4Lo4zFpSkJgSA29ZCffxgsZJh3cGO9kZYsWQP0gvtBeub7Cd2pz1VAozW5w5bztdfViv0O28hXy/o+/K4eYIv4oU3ORPziEdfBDCB3+S0IdA0t39wDcgWkvV1FVEgF7SBsWmWAL7LPLQf4kHmH5sDcDnDe4tD8rIVbpojM3XGdywAkT+pKcw0T6VJv11mOKWBTNs+lxvHsMt7mttxYV5jaber3Dm+wvyHqxAcDHoiFJDiVfXNBxmlq4N13o4ep+vI0Enq6b5iaW2QCzA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AgTmV6nJXCQPSmMRU7Xm7EU23o4FxOQubgVhwVC5Otg=; b=HMRfGGroon474fgnEex+Ynd0DoEu0VkGr8EPtJjPpUud9kEatkPgnGXkEmPizpHvQWtc3X1rNgL+GD6ze/VIc9T02XygAQjvZUITlcSrvbt+AjLPQYFay/4Cmhm4ohozALaiBFGSORnbj5KFG5FHhcSoprXz3uNLtf8F6WreO1EvOxsqpqyLffyqTKL6V/QwEXweYLqX24MkJwWZATHbgfC2byGS3qY7Xbxl+wB25hL8rOKEtTBXiS/pUTxZ+aXa/HlCbHpWRLrZSMRtoihzRcUvbZSy0PCumYkOEvCS8N9M612UOQG8yMoa6GW6NWAyZ1RPxW5uJRBdoC8dAhsFMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AgTmV6nJXCQPSmMRU7Xm7EU23o4FxOQubgVhwVC5Otg=; b=ySylb9RNgm/9T9dY9LHXMJkXef4c/enh97NTjboDu4UiOc1QAiekBf4VY1aOtHewTUufPMFEL9fpqfcxyJqHtD9CZZZLbB91LHTWuY4oeTkXLDkRJuNXZvLdI+nvk2DfvuDeXV/iZL2oeix6BfjBdXXbnXFBDqtzmmWjlnoNJqY= Received: from VI1PR0701MB6991.eurprd07.prod.outlook.com (2603:10a6:800:17d::22) by VI1PR07MB6366.eurprd07.prod.outlook.com (2603:10a6:800:133::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.12; Thu, 3 Mar 2022 11:58:43 +0000 Received: from VI1PR0701MB6991.eurprd07.prod.outlook.com ([fe80::e18c:fde2:812c:41ce]) by VI1PR0701MB6991.eurprd07.prod.outlook.com ([fe80::e18c:fde2:812c:41ce%8]) with mapi id 15.20.5061.006; Thu, 3 Mar 2022 11:58:43 +0000 From: "Bocci, Matthew (Nokia - GB)" To: Greg Mirsky , "draft-bocci-mpls-miad-adi-requirements@ietf.org" CC: mpls , spring , DetNet WG Thread-Topic: Comments on draft-bocci-mpls-miad-adi-requirements Thread-Index: AQHYIqk8gOmnKoTdPEyiUCuVdATGn6ytpY/t Date: Thu, 3 Mar 2022 11:58:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32d75bc6-05aa-44ef-1090-08d9fd0d2a46 x-ms-traffictypediagnostic: VI1PR07MB6366:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jUp39hOJWKy6U0LIQcvxJesBg4tsVbP4RtnDa7KmoMWk0lbHqloR13qt4CAT0Is6HLVchzSTjnPwqGQ/c82pAdklmDTZ2W4CU+ET+I1FxJaj+nhsFhjnjt9aMrxIlELGIVCwCjMh0zFx4FEIm8LgdiuC7fCavpzbw8ES/+dZHU/NwgHjFxm3G/cgSvu3HncfUOOA5o2H/78N/xMnE07OX3CiMRdEbu4svB3z+t0lJFAvbLlJlnenEYJgwH344UN+DFO6ZRgO7GSNRBvAafaZLBeZ6YzMnkS7C6ljhMlgRI6LdEoW19GNXcPDg/uhT+A5mT1El7gJdRVuIdbZ8rQS5vl0XWQ9D6qgS/bIeo7dqDwrsUvxF923MHWfCLHOATsop2HoBGnbIY6Yy8t9ZEsw3EhaLUelzEivY1rU3KPlw2eWEJYF2DvCC7T8MUZMusUKAa4aZc4fCojRLTLXfYJ7neaYf9JfjgQ+3/xBO1yFTTKaIgNkZxW520QtfNDPsajGG6sguLw8TJbfme/jkgq0RPP9ZeRDG2NJWeSy3XWdyHv+TYbyJOxz4TKu7xfBCuWQwbscUur42xB8MEISFxtUi9w+9YXRWzewV3MNN1obiV8i2+2bb0iB2snjLFp8d9QP5X4DVTJpRImHaTc0tY3GRe19m+PG07f668Fusy/b17bcbL3jPBDiGPLKwmlc5frD71GEvv8acgEpQ6Wbwf2vRg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB6991.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66556008)(71200400001)(7696005)(5660300002)(33656002)(53546011)(8936002)(6506007)(52536014)(8676002)(122000001)(55016003)(91956017)(66446008)(82960400001)(83380400001)(66946007)(76116006)(66476007)(64756008)(38100700002)(4326008)(38070700005)(186003)(26005)(86362001)(9686003)(4744005)(2906002)(316002)(54906003)(508600001)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Kn+L25QH/IUeeMdzjdfw/RcqO54uIiu1nsQBTxbQCSXLxGkgwe3u4ziIcK9u?= =?us-ascii?Q?Hb+dDFNXtg5ZwW6mO4qOpOlj8MHBwU18SRqNCzuNOjLNbm66rDv75D+nlfZk?= =?us-ascii?Q?ZloMRdMR1NO+BMX2jka5cirKjCQZs9+hoB6BT17gQ+GOV6bBCglieak/InSL?= =?us-ascii?Q?IUgco4kxMXgvPe2K6weu5FmBCc+VDJQKet6Z56UfCQxukwwmGqLlVPmSR4fl?= =?us-ascii?Q?/vK/nc83qBNR/en7JnI7badv9LbDbEyyf0KMd1gQmZ0MAe8SzJLkAsxZwIz2?= =?us-ascii?Q?UmVN4RleCz3b52EtoQArZhOhNuLj/4+w3W4uO5EBwjKd4oPjoO12oOLUZRjf?= =?us-ascii?Q?zoQfAb9/qYJR5TS5ccauvxFdnqdY5+AqWr59rYdOZDZghXs1nw2sKH0TewOQ?= =?us-ascii?Q?TTCpaRgQ7AYfMyaOS/sKZw1f6WPIg8HbwTiCMcZ4YTKK2myvXXiVB3xiRJw2?= =?us-ascii?Q?8T0QrmFgI7woa82cTm/kPCtc/1BVyAjt34+yftQCLqHlw/AyuN5+bGV5Nv1Q?= =?us-ascii?Q?smpv+GKXZI8FekehG7ozv7i5XOmm8M3Lub4VeY8UEE1PAzErWyFC2TDdMTYD?= =?us-ascii?Q?QkzYDqoDVnjPOqpNIf720Ncqt7nrYyE4gJowR4tMZhoVoizzqJh+Z2ORbav9?= =?us-ascii?Q?ZjueLVRZw/k9JaVhYCrqZMmX+MtUF2Q+Z7BoS1iDvjfpFhoT0o2xdk8FtW5g?= =?us-ascii?Q?H7hz5uxbWGszUz/znqlH4CAGscQqOZfAwbVZHrcWA4ekM5eFnJCKeok+RVAT?= =?us-ascii?Q?qOIbmXsqtmp+rTx/Gb+KiSYoRiXpB4raO6G8uYfZZU39Y5bvvzhIEr3s9CbX?= =?us-ascii?Q?w2U/L8rDz5TJrbLBsijBRTyR7vfKhD80kwQgwYrGkssIq4ScMEHg6bHHjc/C?= =?us-ascii?Q?pZeqeYDEPiukaj79waFnWPh/nh/rF7z/nvDCbMSkRDoLfYPvAmr/KLQ+IhR8?= =?us-ascii?Q?Aaj0Dogml76ck+gYUVaVr2S9qYP+OTQeO8rgKOmIdghdQbKuE8G+Vn6CTGtE?= =?us-ascii?Q?NI+vGQ33ZK2Yjh4xfGDXSuWbZcLe08yoQlD5dhzq3NeMoc9Tapur+xYcEU/h?= =?us-ascii?Q?/nMYmO/ke9PjYyffVgOm1zYNIcNQSoAEyKkBj9e3m5oMOOJiexXKdDCkiwSu?= =?us-ascii?Q?VKFySw3+8fLtrRVMCJAOHSc2rmG8bFGFGMcNy8qijmbKIuzicMhYVHoOScfv?= =?us-ascii?Q?rCiKWASzvv3zMag6RgXP1gRQm8s4j6/AnYDXvHckHDVS3JFFe8NhmrIXPIAS?= =?us-ascii?Q?fGrSVFo0N3t6N001L3ppdJlxAMxJy6hGVO6b6HuRvGF/673ywb+oajHde3hx?= =?us-ascii?Q?X9F8B6o/k7siuo6WKsy5To3MkB8YTo5sk4TYHuZDK90AVKlKPu8bt4Aitmty?= =?us-ascii?Q?O57eNkFzHARHvQaA6RPGoVxCs7e7mnZZ5TA0CA1G9Wt/UFzH2E/ne4xoTR0l?= =?us-ascii?Q?4kvIHh6p8ETVUJnNpczSmMbrsZQDzjon1IGUJ9s3wZpg2kiqRnyj2RZ5tVcF?= =?us-ascii?Q?s/gHgbT8xKNpSs3ERRSnAJCCPCWTbu0byPC2/m+8csnjC8HhC3vfggjaIUsZ?= =?us-ascii?Q?LVfNxZGNMJywJ1+x2xW3tH6b/SVZrBk0sMxpzwCWM+kTJBsuEBPbltg/Agv6?= =?us-ascii?Q?Wytbpoxm8QC1LZyucbWEyjc=3D?= Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB6991DE8DCAE47DEFDA462F52EB049VI1PR0701MB6991_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR0701MB6991.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32d75bc6-05aa-44ef-1090-08d9fd0d2a46 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2022 11:58:43.4179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CLQKho4gp61GHPgV+hPqAI/F1wKZ9SWYD2hXXrzpRMbMeltso15VINfI18+5tSxh5cV32fpskRaZgmDzWvisXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6366 Archived-At: Subject: Re: [spring] Comments on draft-bocci-mpls-miad-adi-requirements 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 Mar 2022 11:58:54 -0000 --_000_VI1PR0701MB6991DE8DCAE47DEFDA462F52EB049VI1PR0701MB6991_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg Thank you for your detailed review and comments. We have tried to address t= hese in the updated draft that we just posted. In answer to your question below about whether the ancillary data needs a c= ommon format, I agree that it at least needs a common header format. Regards Matthew From: Greg Mirsky Date: Tuesday, 15 February 2022 at 20:18 To: draft-bocci-mpls-miad-adi-requirements@ietf.org Cc: mpls , spring , DetNet WG Subject: Comments on draft-bocci-mpls-miad-adi-requirements Hi Stewart and Matthew, thank you for organizing this document in a very clear and concise manner. = I enjoyed reading it. Attached, please find a copy of the draft with my notes, comments, and sugg= estions. The most important, in my view, the question I have Should we add = the requirement to have a common format for ancillary data defined? Looking forward to your feedback. Regards, Greg --_000_VI1PR0701MB6991DE8DCAE47DEFDA462F52EB049VI1PR0701MB6991_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg

 

Thank you for your detailed review and comments. We have tried to a= ddress these in the updated draft that we just posted.

 

In answer to your question below about whether the ancillary data n= eeds a common format, I agree that it at least needs a common header format= .

 

Regards

 

Matthew

 

 

From: Greg Mirsky <gre= gimirsky@gmail.com>
Date: Tuesday, 15 February 2022 at 20:18
To: draft-bocci-mpls-miad-adi-requirements@ietf.org <draft-bocci-= mpls-miad-adi-requirements@ietf.org>
Cc: mpls <mpls@ietf.org>, spring <spring@ietf.org>, DetN= et WG <detnet@ietf.org>
Subject: Comments on draft-bocci-mpls-miad-adi-requirements

Hi Stewart and Matt= hew,

thank you for organ= izing this document in a very clear and concise manner. I enjoyed read= ing it.

Attached, please fi= nd a copy of the draft with my notes, comments, and suggestions. The most i= mportant, in my view, the question I have Should we add the requirement to = have a common format for ancillary data defined?

 

Looking forward to = your feedback.

 

Regards,=

Greg

--_000_VI1PR0701MB6991DE8DCAE47DEFDA462F52EB049VI1PR0701MB6991_-- From nobody Thu Mar 3 08:08:24 2022 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 00EC23A0D9E; Thu, 3 Mar 2022 08:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 CPXFmu1TbcbH; Thu, 3 Mar 2022 08:08:18 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 93D183A0D62; Thu, 3 Mar 2022 08:08:18 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id qa43so11616520ejc.12; Thu, 03 Mar 2022 08:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8cH0LHCDgwy4QOJqdc58OTvRhjFoA+uKAGRUGiJMEFk=; b=Yo5Uq8VegcBtZ135gJ1vxAl2dJNGGbR17HwfUqslsZJHPfqBWYzmkGvJ5Dee39VOub 6VpTp5nlb6EmOEkaOYEkVYPrs86yTlHr6oQASQBt8WfTlBc5Cu+v/5votnMcXFcqhA50 JJYRYE3td6AlTW9kRhJC0Vw9F4ruGGLtzWgRGWK1Xzg/IBeWh7quxVA3dlDVZpgVh1KY 24wMfaqNIcbZKO2f5b9PWfCgrxfT6Rzi7xQLzdTFuGulBr9ZHnP/dAdyUwkcSk3nDBDu IfwvgyNYLWfCVZcolTYZbtbHD04BSTDsWbJ3SVK76pIHR3aACzgNRX3RydJq4Pvkpnzl yOMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8cH0LHCDgwy4QOJqdc58OTvRhjFoA+uKAGRUGiJMEFk=; b=H0c8WaIUMp65lkOvmuoK0Z8b0op8NZv6AZCJh8bIQQfakAB+tcQGL363Za9GQvZ1XS CV8VdsPAwU95pZDEh3SK3laQ60nLAKAHg6XhLwlBpQlU2+nVzhSEBnlpVSRaEBIZ2xmf aftPGUZGTm4rlwLgUvrufgmSSEnACVk5auTRluJzyy8ZsPbPO5G+e/4nbHRYNHjGWL7h Ev87OjpqS1/GcMKNiIkWXMx2hPlnXQQGOuMDvYVja6qtFkLh8pXuuuyNu15nJ/XvhN7+ OKRd00ef55LSqhB4v42fuy/ZZXLlkEdBJMOh7z40jgDVQX7Q7FVk0e8lgtS67OGV/6oi u0Ew== X-Gm-Message-State: AOAM530Z2ocQKt6xE5fjLvISj/ICDJnODzHFCRHvME6hpPl0jaKC0i+9 MMwlcUgO7FtVo7k8DRAOmz2dFp4xhx2EVRoXVLOQ9I0l X-Google-Smtp-Source: ABdhPJyErSytiLNYsxdlu5+fgrttj9rebRi26YzRI3EKHf6T6+Qwzt2ME6eI/H+aHp40Gxbys93fBNrEIkEs0JDmRs0= X-Received: by 2002:a17:906:bf1:b0:6cd:186:9ffa with SMTP id z17-20020a1709060bf100b006cd01869ffamr27247749ejg.506.1646323696202; Thu, 03 Mar 2022 08:08:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 3 Mar 2022 08:08:04 -0800 Message-ID: To: "Bocci, Matthew (Nokia - GB)" Cc: "draft-bocci-mpls-miad-adi-requirements@ietf.org" , mpls , spring , DetNet WG Content-Type: multipart/alternative; boundary="00000000000018f7bb05d9529b3e" Archived-At: Subject: Re: [spring] Comments on draft-bocci-mpls-miad-adi-requirements 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 Mar 2022 16:08:23 -0000 --00000000000018f7bb05d9529b3e Content-Type: text/plain; charset="UTF-8" Hi Matthew, thank you for the heads-up. I'll review the updated draft and be back with my notes. Regards, Greg On Thu, Mar 3, 2022 at 3:58 AM Bocci, Matthew (Nokia - GB) < matthew.bocci@nokia.com> wrote: > Hi Greg > > > > Thank you for your detailed review and comments. We have tried to address > these in the updated draft that we just posted. > > > > In answer to your question below about whether the ancillary data needs a > common format, I agree that it at least needs a common header format. > > > > Regards > > > > Matthew > > > > > > *From: *Greg Mirsky > *Date: *Tuesday, 15 February 2022 at 20:18 > *To: *draft-bocci-mpls-miad-adi-requirements@ietf.org < > draft-bocci-mpls-miad-adi-requirements@ietf.org> > *Cc: *mpls , spring , DetNet WG < > detnet@ietf.org> > *Subject: *Comments on draft-bocci-mpls-miad-adi-requirements > > Hi Stewart and Matthew, > > thank you for organizing this document in a very clear and concise manner. > I enjoyed reading it. > > Attached, please find a copy of the draft with my notes, comments, and > suggestions. The most important, in my view, the question I have Should we > add the requirement to have a common format for ancillary data defined? > > > > Looking forward to your feedback. > > > > Regards, > > Greg > --00000000000018f7bb05d9529b3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matthew,
thank you for the heads-up. I'll revie= w the updated draft and be back with my notes.

Reg= ards,
Greg

On Thu, Mar 3, 2022 at 3:58 AM Bocci, Matthew (No= kia - GB) <matthew.bocci@noki= a.com> wrote:

Hi Greg=

=C2=A0<= /span>

Thank you for your de= tailed review and comments. We have tried to address these in the updated d= raft that we just posted.

=C2=A0<= /span>

In answer to your que= stion below about whether the ancillary data needs a common format, I agree= that it at least needs a common header format.

=C2=A0<= /span>

Regards=

=C2=A0<= /span>

Matthew=

=C2=A0<= /span>

=C2=A0<= /span>

From: Greg Mirsky <gregimirsky@gmail.com= >
Date: Tuesday, 15 February 2022 at 20:18
To: draft-bocci-mpls-miad-adi-requirements@ietf.org &l= t;draft-bocci-mpls-miad-adi-requirements@ietf.org>
Cc: mpls <mpls= @ietf.org>, spring <spring@ietf.org>, DetNet WG <detnet@ietf.org>
Subject: Comments on draft-bocci-mpls-miad-adi-requirements

Hi Stewart and Matthe= w,

thank you for organiz= ing this document in a very clear and=C2=A0concise manner. I enjoyed readin= g it.

Attached, please find= a copy of the draft with my notes, comments, and suggestions. The most imp= ortant, in my view, the question I have Should we add the requirement to ha= ve a common format for ancillary data defined?

=C2=A0<= /span>

Looking forward to yo= ur feedback.

=C2=A0<= /span>

Regards,

Greg

--00000000000018f7bb05d9529b3e-- From nobody Thu Mar 3 16:16:16 2022 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 BF5E33A0A82; Thu, 3 Mar 2022 16:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 dDBXJyI_0Tsk; Thu, 3 Mar 2022 16:15:45 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 85C123A0894; Thu, 3 Mar 2022 16:15:27 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id p4so8742899edi.1; Thu, 03 Mar 2022 16:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hz4RT6Au4fVvtj2jP8a1jh6n6SnGUsEDqm43PAdz+K4=; b=e1ESw6pQQgf/odyw9lIRan/1rmYcpK0tl/uicywIOyCx/dcXSexs/CLsdkOoA6+G9I BZwn3gt9LkOIkuQg4w3RaskyeEQ0blt83uG2yjA6ovCEamsIL4d+lPxmA/VznViv8vUQ FigIHKHOkDnM84BeEEPRvyzVspcuCdnveYIKeBJagdc6Haa+kWnCXf7a3BFRDaa/Ow7s V6WwQo4VJIAI+wL0md0GCZKQ9IQXCd0IK0itZimjOmbFaU94ojnO4oxS8yJ/wBhXcSYq yqMI1FFRdPrao3YnfV7SA3kzZ5ZL8Yx4KDRJimOZQGEJpnP0ZUMlVhGWknEZ1BiMIJI2 FGVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hz4RT6Au4fVvtj2jP8a1jh6n6SnGUsEDqm43PAdz+K4=; b=0ZfHxovdfoSr4Tx72JA1ujUZLK5m40eBOmzvokg/THGX2hK8X7PiOxEj9sEkVRkf73 Uh/5YScSFGMPUqJisir1iXUAmZyNJfdzhOTPbF5ZDtyajtLxFY+Ylt4Gg6OClxippmVv 0Hv2TXgFbVB+k4NZxVG4XFE5mCh7qFDaREfdQRL5+p4tJYxH660liIW6YXrFzbgbvpw8 FbtOFhLCiEKMBKB5X/LCNmuO5FxRxgATh/Re/ryrTKZJeol98OHKTjFHVoscWmDozbKN 13HMNtX6auUshsXUmuQ2rDGOjPK3Z83iUomsmamDz6M6gzAP9YIKkD6zW/U2qOpMOaME Z7wA== X-Gm-Message-State: AOAM533D8VVuD6xyyZAAr9a3ox1f3bW4ApErF3RN7yVx/9IgAcAVIH/U hd+xTt7uUItAuQBs35GkUahFVFRRelJ1fdaJOugsfje3oP8= X-Google-Smtp-Source: ABdhPJxGsc3wLF+wMjYs2dk7SPcamFgDv2RdYVjtxEFgdAzF1yyEX/jkL6XCOSkb4NgAWEtr0ji+Dh8o+acoZBsh9Hk= X-Received: by 2002:a05:6402:440d:b0:412:9e8a:5e51 with SMTP id y13-20020a056402440d00b004129e8a5e51mr37250118eda.362.1646352925414; Thu, 03 Mar 2022 16:15:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 3 Mar 2022 16:15:14 -0800 Message-ID: To: "Bocci, Matthew (Nokia - GB)" Cc: "draft-bocci-mpls-miad-adi-requirements@ietf.org" , mpls , spring , DetNet WG Content-Type: multipart/alternative; boundary="0000000000004b589a05d9596947" Archived-At: Subject: Re: [spring] Comments on draft-bocci-mpls-miad-adi-requirements 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, 04 Mar 2022 00:15:57 -0000 --0000000000004b589a05d9596947 Content-Type: text/plain; charset="UTF-8" Hi Matthew and Stewart, thank you for your work addressing my comments; much appreciated. I have several follow-up questions and comments to the new version of the draft, mostly to the new Section 3.1.2 : - I may suggest an editorial update to bullet 2 OLD TEXT: 2. A common mechanism for ancillary data MUST be defined so that a node receiving the ancillary data can determine whether to process, ignore or discard it. NEW TEXT: 2. A common mechanism for ancillary data MUST be defined so that a node receiving the ancillary data can act according to the local policies. - bullet 4 receives two notes: - I think it should be a requirement, not a recommendation - I think that an LSR must not be able to insert any ancillary data. Only ingress LER inserts data. - it would be good if bullet 6 can be split into two - RE: bullet 7, I don't think that MPLS is the appropriate layer to guarantee in-order delivery. Should that be left to an application? - it appears that bullet 8 is specific to the PSD case. If that is the case, should it refer to the BoS instead of "as close to the label stack as possible"? - I think that having a requirement for the use of a common ancillary data header will help the discussion. Couple nits: - "an/or" -> "and/or" - s/lath/path/ Regards, Greg On Thu, Mar 3, 2022 at 3:58 AM Bocci, Matthew (Nokia - GB) < matthew.bocci@nokia.com> wrote: > Hi Greg > > > > Thank you for your detailed review and comments. We have tried to address > these in the updated draft that we just posted. > > > > In answer to your question below about whether the ancillary data needs a > common format, I agree that it at least needs a common header format. > > > > Regards > > > > Matthew > > > > > > *From: *Greg Mirsky > *Date: *Tuesday, 15 February 2022 at 20:18 > *To: *draft-bocci-mpls-miad-adi-requirements@ietf.org < > draft-bocci-mpls-miad-adi-requirements@ietf.org> > *Cc: *mpls , spring , DetNet WG < > detnet@ietf.org> > *Subject: *Comments on draft-bocci-mpls-miad-adi-requirements > > Hi Stewart and Matthew, > > thank you for organizing this document in a very clear and concise manner. > I enjoyed reading it. > > Attached, please find a copy of the draft with my notes, comments, and > suggestions. The most important, in my view, the question I have Should we > add the requirement to have a common format for ancillary data defined? > > > > Looking forward to your feedback. > > > > Regards, > > Greg > --0000000000004b589a05d9596947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matt= hew and Stewart,
thank you for your work addressing my comments; much= =C2=A0appreciated. I have several follow-up questions and comments to the n= ew version of the draft, mostly to the new Sect= ion 3.1.2:
  • I may suggest an editorial update to bulle= t 2
OLD TEXT:
=C2=A0 =C2=A02.=C2=A0 =C2=A0A common = mechanism for ancillary data MUST be defined so that a
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 node receiving the ancillary data can determine whether t= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 process, ignore or discard it.
NEW TEXT:
=C2=A0 =C2=A02.=C2=A0 =C2=A0A common m= echanism for ancillary data MUST be defined so that a
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 node receiving the ancillary data can act according=C2=A0= to the local policies.
  • bullet 4 receives two notes:=
    • I think it should be a requirement, not a recommendation
      • <= li>I think that an LSR must not be able to insert any ancillary data. Only = ingress LER inserts data.
  • it would be good if bullet 6 can be = split into two
  • RE: bullet=C2=A07, I don't think that MPLS is th= e appropriate layer to guarantee in-order delivery. Should that be left to = an application?
  • it appears that bullet 8 is specific to the PSD cas= e. If that is the case, should it refer to the BoS instead of "as clos= e to the label stack as possible"?=C2=A0
  • I think that having a= requirement for the use of a common ancillary data header will help the di= scussion.
Couple nits:
  • "an/or&qu= ot; -> "and/or"
  • s/lath/path/
Regards,
Greg

On Thu, Mar 3, 2022 at 3:58 AM Bo= cci, Matthew (Nokia - GB) <ma= tthew.bocci@nokia.com> wrote:

Hi Greg=

=C2=A0<= /span>

Thank you for your de= tailed review and comments. We have tried to address these in the updated d= raft that we just posted.

=C2=A0<= /span>

In answer to your que= stion below about whether the ancillary data needs a common format, I agree= that it at least needs a common header format.

=C2=A0<= /span>

Regards=

=C2=A0<= /span>

Matthew=

=C2=A0<= /span>

=C2=A0<= /span>

From: Greg Mirsky <gregimirsky@gmail.com= >
Date: Tuesday, 15 February 2022 at 20:18
To: draft-bocci-mpls-miad-adi-requirements@ietf.org &l= t;draft-bocci-mpls-miad-adi-requirements@ietf.org>
Cc: mpls <mpls= @ietf.org>, spring <spring@ietf.org>, DetNet WG <detnet@ietf.org>
Subject: Comments on draft-bocci-mpls-miad-adi-requirements

Hi Stewart and Matthe= w,

thank you for organiz= ing this document in a very clear and=C2=A0concise manner. I enjoyed readin= g it.

Attached, please find= a copy of the draft with my notes, comments, and suggestions. The most imp= ortant, in my view, the question I have Should we add the requirement to ha= ve a common format for ancillary data defined?

=C2=A0<= /span>

Looking forward to yo= ur feedback.

=C2=A0<= /span>

Regards,

Greg

--0000000000004b589a05d9596947-- From nobody Sat Mar 5 02:20:18 2022 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 558B53A1679; Sat, 5 Mar 2022 02:20:15 -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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164647561528.28345.11306331208100016043@ietfa.amsl.com> Date: Sat, 05 Mar 2022 02:20:15 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-19.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: Sat, 05 Mar 2022 10:20:16 -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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-19.txt Pages : 40 Date : 2022-03-05 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into a SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC8402 as it details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-19 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Mar 5 02:29:56 2022 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 3A6543A11D6; Sat, 5 Mar 2022 02:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 dHyjjheYN9fP; Sat, 5 Mar 2022 02:29:37 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 3F23E3A11BC; Sat, 5 Mar 2022 02:29:37 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id v62so6767681vsv.1; Sat, 05 Mar 2022 02:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BtBCxtSkoZ2iSq+MUILzoWdG1u/CGmJS/OEJe2PFGVw=; b=G0AK2VWdsEYL4E2J/Hw9efoxeCE9rKgNaehOX1Obg2RGo4HxYSo4gii1Wm9Ymp5YDt 0SRj95fVvKl1f9Qn6OscnSYprYJZ6YViYBI7eAew2uV0GFAu8GPsTenbw/X/NqrGkzWP 0JYyMMitVQzTfOs7lJj65zOlweoEjqiwNVyJSBOFJ4HXXJKr0pL56+eJ/R7WCUtdi++w E/zGGo4i4cKFipCifyxjQmCbFQaK/rA6z1rzdRC7VycDlSxA+fWtVrSnDYzsuC2bXGvZ zOqYrPK1S/KbnZ1UgF2NhbuVqYrknP2a88tybX+GUWLk6SMd3hZeBTX/Ir33ys4qyzTU EO4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BtBCxtSkoZ2iSq+MUILzoWdG1u/CGmJS/OEJe2PFGVw=; b=dxTUo/3Fx2wCUorK6csV9Vqq1czbFm3rJNKoShePLpr9eFMBtafg9agnphE6caGS4B WswEYh0lDMH/SxrW5Ggrrg+4SOqywkwJ8aAD7TeQ3VHTb0N9lVzCifUaoHlmnS5o/Isi bOShRGtYJLfJMzMzxdYm3nGkTrYC6I9oiITfiZYsP2grOi6S/fZJRtNLsn6n0hH97dK3 X59NcXT/uZ2ifEMiB3BA4ITP6b+kgiOanUv0PVs6EMaaSQxCEnrT32qOKU7oHYi6R+ZC mcG3MouJCzofkzf6Oh5/P6A4/l2KY+cSipInmtGNB1zKygX+XiJAk47f/MEdmCI75FEs YFvA== X-Gm-Message-State: AOAM530QsrPKk1Gk9AMCnOpT75s5YxVEpnef0ZjebAdlIaFNpRUdMtYp 9+QpaQYpQS43NhpRpRVoFgNX+MPIGaMWlgrV604= X-Google-Smtp-Source: ABdhPJwCkW7KmziGNGlzPzB2/DcKQtI8cUO9lEJPWzwjePD84h7D/VxECle6u3xOFFYSPeBnkqBpvFiTZjP/+M8ossc= X-Received: by 2002:a05:6102:3e95:b0:30f:9865:e97e with SMTP id m21-20020a0561023e9500b0030f9865e97emr967540vsv.15.1646476175921; Sat, 05 Mar 2022 02:29:35 -0800 (PST) MIME-Version: 1.0 References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Sat, 5 Mar 2022 15:59:24 +0530 Message-ID: To: Alvaro Retana Cc: james.n.guichard@futurewei.com, spring-chairs@ietf.org, The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, SPRING WG Content-Type: multipart/alternative; boundary="00000000000098d5ea05d9761bcc" Archived-At: Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sat, 05 Mar 2022 10:29:44 -0000 --00000000000098d5ea05d9761bcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thanks for your response and please check inline below. We have also just posted an update to address some of the comments below and from other ADs. https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-19 On Tue, Feb 22, 2022 at 3:14 AM Alvaro Retana wrote: > On February 17, 2022 at 10:06:39 AM, Ketan Talaulikar wrote: > > > Ketan: > > Hi! > > I am looking at -18. Thanks for adding the Updates tag -- you need to > also add text to the Introduction about the update. > KT> Ack. Fixed. > > Comments inline... > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > ... > > > Besides the general topic of clarifying and updating what an SR Polic= y > is, > > > this document also includes other items that were not present in > rfc8402; > > > the list includes: > > > > > > =C2=A72.1: "SR Policy MUST be identified through the tuple > > endpoint>." There's not even a mention of "color" in rfc8402. > > > > > > =C2=A72.1: "The headend is specified as an IPv4 or IPv6 address and i= s > expected > > > to be unique in the domain." Neither the mechanism to identify a node > nor > > > the expectation is present in rfc8402. > > > > > > =C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 address and = is > expected > > > to be unique in the domain." Same as above. > > > > KT> Yes, these are the constructs of SR Policy that are specified by th= is > > document. > > > > > > > > > > > The SR Database is a new element not in the base architecture. The > text in > > > =C2=A73 says that "use of the SR-DB for computation and validation of= SR > > > Policies is outside the scope of this document", but it is then > mentioned > > > and used in =C2=A75.1/=C2=A75.2. > > > > KT> The computation algorithm and related discussions about the use of > SR-DB > > were asked to be moved out of this standards track document during the = WG > > process. Those informational sections were moved into > > draft-filsfils-spring-sr-policy-considerations and kept as a reference = in > > this document. The reference in 5.1 and 5.2 is about validation of > segments > > and as a result the segment-list and candidate path. The validation of > the > > "objective" and constraints of the SR Policy was deemed to be outside t= he > > scope of the document. There were several discussions on and off-list a= t > the > > IETF meetings in this regard. Perhaps this thread gives a good summary: > > > https://mailarchive.ietf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/ > > It's ok if the SR-DB is out of scope. > > =C2=A73 does say that "use of the SR-DB for computation and validation of > SR Policies is outside the scope of this document." But that (using > the DB for validation) is different than leaving validation completely > out of scope. In fact, the text in =C2=A75.1 doesn't leave segment-list > validation (for example) out of scope when it says this: > > The SR Policy headend does not compute the Segment-List. The SR Polic= y > headend only confirms its validity. > > Or when it requires the validation explicitly: "A Segment-List of an > explicit candidate path MUST be declared invalid..." > > > Leaving the validation out of scope may have been what was intended, > but it is not what the document says. It is also not clear to me > whether the intent was to leave out of scope how to use the DB (as the > text in =C2=A73 says), or to completely leave it out. > KT> The SRDB is not out of scope. The path computation algorithm and the verification of the path constraints is out of scope. The SID validation and resolution are within the scope of the document and that requires the SRDB. We've clarified this in the text. > > The thread was not that easy to follow, with most message being about > support. Can you point me to where the out-of-scope decision was > reached? Alternatively, the Chairs can confirm. > > > > > > Accordingly, the added details require additional Security and > Manageability > > > considerations. > > > > KT> Could you please clarify/explain a bit further what you feel is > missing? > > For example, for this construct of the SR Policy specified in this > document: "The headend is specified as an IPv4 or IPv6 address and is > expected to be unique in the domain." (=C2=A72.1) > > What new security and/or manageability considerations does it > introduce? Can there be a mixture of IPv4 and IPv6 addresses > identifying headends/endpoints? What happens if there are duplicate > identifiers? How can it be detected? Can a rogue node intercept (or > perhaps attract) the traffic of an SR Policy if it advertises one of > these addresses? ... > KT> We have added some text in this regard in the draft. The detection mechanism for duplicate prefix advertisements though is out of the scope of this document. > > Some of the answers may be "nothing", or the issues may be carried > over from rfc8402 -- in those cases, please at least point that out. > > > > ... > > > (2) =C2=A75.1: > > > > > > Types A or B MUST be used for the SIDs for which the reachability > > > cannot be verified. Note that the first SID MUST always be reachable > > > regardless of its type. > > > > > > These two requirements and the text in the description of these types > > > ("...does not require the headend to perform SID resolution.") result= s > in a > > > contradiction: Types A and B are not to be resolved, but if they are > the > > > first SID then they MUST. If it's not a contradiction, then Types A > and B > > > would not be allowed to be the first SID, which is not correct becaus= e > the > > > most straightforward mechanism to define a path is to list SR-MPLS > Labels > > > or SRv6 SIDs. > > > > KT> I don't see a contradiction here. "Types A or B MUST be used for th= e > SIDs > > for which the reachability cannot be verified." is not the same as sayi= ng > > "Type A or B are not to be resolved". > > True. However, the description of both types say that "This type does > not require the headend to perform SID resolution." > KT> We will remove that sentence from both types since it is not necessary. The other segment types describe the resolution to be performed from the different contexts provided to the MPLS label or SRv6 SID. > > This is one of those cases where a (non) requirement is mentioned > without Normative language that can lead to a potentially wrong > interpretation. :-( > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > ... > > > (1) Is the specification of a headend/endpoint mandatory? IOW, should > the > > > text in =C2=A72.1 about the headend/endpoint being identified by a un= ique > IPv4 > > > or IPv6 address be normative? > > > > KT> It is not normative since we have the case of an unspecified addres= s > as > > an endpoint. We could use SHOULD though, if that clarifies. > > The unspecified address is an IPv4 or IPv6 address. > > If you use SHOULD, when would it be ok for the identification to not > be an IPv4 or IPv6 address? Why recommend and not require? > KT> I think I understand the point. The uniqueness is about the ability to resolve the IP address to a unique node in the SR domain to be able to identify a headend and a tailend. We've clarified this in the text. > > > > > > > (2) =C2=A72.1: "An implementation MAY allow the assignment of a symbo= lic > name > > > comprising of printable ASCII [RFC0020] [RFC5234] characters" > > > > > > Why are you normatively limiting the name to be represented in ASCII? > Please > > > internationalize it - use UTF-8. > > > > > > =C2=A72.6 also has similar text. > > > > KT> My understanding is that there is no compulsion to use UTF-8 for su= ch > > purposes. This was discussed in the WG. Please check: > > > https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/ > > I wouldn't say that this thread (it only includes the message you sent > to the list) qualifies as a discussion. But, yes, there is no > requirement to use UTF-8 -- it is just the nice (and maybe correct) > thing to do knowing that non-English-speaking people may also use this > specification. > > [See rfc9003 for an an example of an extension what also considered > the Cyrillic alphabet.] > KT> There are existing implementations and deployments of this draft as well as the same being signaled via corresponding protocol extensions in BGP and PCEP. If this is not a requirement, then we would like to avoid change at this stage. > > > > ... > > > (4) =C2=A72.1: "An SR Policy MAY have multiple names...in the scenari= o > where the > > > headend receives different SR Policy names" Describing multiple names > as the > > > case where multiple names are received is not helpful. > > > > KT> When CPs for the same SR Policy are provisioned via different > sources, > > then such a scenario may occur. > > It would be nice if the text included that clarification then: ...via > different sources. > KT> Ack. Clarified. > > Can multiple names be received from the same source? > KT> Yes. Since the unit of signaling in the protocols is the CP. Theoretically, the same source could send different CPs of the same Policy with different Policy names. > > > > ... > > > (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD be = set to > 0 by > > > default when not available or known." > > > > > > When is it ok for the ASN to not be set to 0 (when not available or > known)? > > > If that possibility exists, the PCE can use any value (including the > real > > > number or a random one). What issues exist with uncoordinated (or > rogue) > > > PCEs using potentially arbitrary ASNs? > > > > > > Why is this action recommended and not required? > > > > KT> AFAIR PCEP signaling does not carry AS number. So this is a > > recommendation, though a local policy or a future PCEP extension could > change > > that and we don't want to preclude it. > > First of all, the architecture shouldn't be defined as a function of > what the protocols can do today, it should be defined as a function of > what is needed. > KT> True. That would be the case in an ideal world. Practically, the WGs have ended up with the desire and requirement for having multiple protocols to signal the same construct and there is the need for some normalization. > > If the ASN can be signaled, when is it ok for it to not be set to 0 > (when not available or known)? If that possibility exists, the PCE > can use any value (including the real number or a random one). What > issues exist with uncoordinated (or rogue) PCEs using potentially > arbitrary ASNs? > KT> I will leave this question for the PCEP WG if and when they decide to add support for ASN to be signaled. It does not make any impact from this specification perspective since it is only used to identify the originator. > > > > ... > > > (9) Given the description, it seems possible for a PCE (for example) = to > > > advertise multiple candidate paths with the same Preference, > Originator, and > > > Discriminator. If that occurs, what is the result of the selection in > =C2=A72.9? > > > Would this situation result in multiple active candidate paths? > > > > KT> The ability to signal multiple CPs via PCEP is being introduced via > > draft-ietf-pce-segment-routing-policy-cp. The default is for use when n= ot > > using that draft and in that case, there would be only a single CP. > > > Let me try again: if the PCE can advertise multiple paths > (draft-ietf-pce-segment-routing-policy-cp) with the same Preference, > Originator, and Discriminator, how should the selection in =C2=A72.9 be > evaluated? > KT> Then it would be the same CP. The second update would overwrite the first one. > > > > > > > (10) =C2=A72.11: "Only the active candidate path SHOULD be used for > forwarding > > > traffic that is being steered onto that policy." When is it ok to use > > > non-active paths? Why is this action recommended and not required? > > > > KT> The condition was for path protection as described in section 9.3. > The > > "backup" path is programmed and hence may be used for forwarding while > FRR is > > active. > > By definition, the backup is only used when the main path is being > repaired and not used (because it failed). KT> This is not accurate. At the time FRR is triggered, one does not know whether what was the active path can be repaired or not. So, depending on what has been provisioned as backup, it may be that the next best path is used as the backup (so it will be considered active after control plane convergence) OR it may be an entirely different path that may not become active because the original active path was repaired or a 3rd path now becomes the active path after control plane convergence. Please also see the next comment. > IOW, in this case only one > path is used at a time. > > The text above implies that more than one path can be used at a time. > KT> That is not the intention and we've clarified in the text while using MUST. > > > > ... > > > (15) =C2=A75.2: > > > > > > When the local computation is not possible (e.g., a policy's tail-end > > > is outside the topology known to the headend) or not desired, the > > > headend MAY send path computation request to a PCE supporting PCEP > > > extension specified in [RFC8664]. > > > > > > This action (ask the PCE) is a solution, not an architectural > description. > > > Are there other external mechanisms that can find a "solution Segment= - > > > List"? It seems to me that one such mechanism would be in the form of= a > > > configured Segment-List. If that is correct, please generalize the > > > normative statement above -- where using PCEP can be an example. > > > > KT> Agree and will change that to an example. > > The updated text says: > > When the local computation is not possible (e.g., a policy's tail-end > is outside the topology known to the headend) or not desired, the > headend MAY send path computation request to a centralized > computation entity (e.g., to a PCE supporting PCEP extensions > specified in [RFC8664]). > > In the case of manual configuration, the request is not sent anywhere > (as in using a protocol)... How about this: > > When the local computation is not possible (e.g., a policy's tail-end > is outside the topology known to the headend) or not desired, the > headend may rely on an external entity. For example, a request may > be sent to a PCE supporting PCEP extensions specified in [RFC8664]. > > KT> Ack. Fixed. > > > > > (16) =C2=A77: Which are valid states? Active is one, the text mention= s an > > > "administrative state", what else? Interoperability is a good reason = to > > > specify the states and not assume that implementations might do the > right > > > thing. > > > > KT> The state here does not mean a single one like up/down. It is > referring > > to the operational state. Those aspects are covered in the > > draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP whe= n > > those protocols are in use. We'll add a reference to > > draft-ietf-spring-sr-policy-yang. > > draft-ietf-spring-sr-policy-yang says that it provides a data-model > for the SR Policy framework defined in this document. But this > document points there for the states...circular reference. > > Even if nor circular, the reference to > draft-ietf-spring-sr-policy-yang should be Normative because it > specifies the sates for the architecture. > KT> Making a normative reference to the YANG model draft would result in a circular reference. The intention of this document is to provide a high-level requirement - e.g. whether instantiated or not, which CP is active, reason for not being active, etc. The YANG model is then expected to specify the more detailed operational state. > > You mentioned above that the "state here does not mean a single one > like up/down. It is referring to the operational state." This is from > draft-ietf-spring-sr-policy-yang: > > typedef policy-oper-state { > type enumeration { > enum UP { > value 1; > description "SR policy is operationally up"; > } > enum DOWN { > value 2; > description "SR policy is operationally down"; > } > } > description "SR policy oper state"; > } > > Am I looking in the wrong place? > KT> The work on the YANG model is by no means complete (IMHO). But there are more operation states - e.g., sr-policy-types:policy-oper-state, sr-policy-types:binding-sid-oper-state, is-best-candidate-path, non-selection-reason, is-valid, etc. > > > > > > > > (17) =C2=A77: "The SR Policy state MUST also reflect the reason when = a > policy > > > and/or its candidate path is not active due to validation errors or n= ot > > > being preferred." > > > > > > Given that this is a requirement, please provide a list of reasons. > The need > > > for interoperability (by using rfc2119 language) can only be achieved > if the > > > reasons are standardized. > > > > KT> The reason is for debugging and troubleshooting. If something is > down or > > invalid, then it helps to know why. > > Yes, I understand it helps to know the reason, that's why I'm asking. :-) > > Again, please make draft-ietf-spring-sr-policy-yang a Normative reference= . > > I found a couple of identities in draft-ietf-spring-sr-policy-yang > that fit the bill for the requirement: > candidate-path-not-selected-reason and policy-down-reason. However, > what I couldn't find is the specification of the conditions when each > of the reasons is to be used. Most of reasons seem straight forward, > but it would be ideal if the specification was complete. > KT> As mentioned in my response to the comment above, the work on the YANG model seems like taking longer in the WG. The model is perhaps the best way to capture these states' information and the model can (rather should) reference the appropriate sections of this specification to clarify the intent. IMHO that would perhaps be the right way to progress this work towards publication. Thanks, Ketan > > > > Thanks! > > Alvaro. > --00000000000098d5ea05d9761bcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

Thanks for = your response and please check inline below.

We ha= ve also just posted an update to address some of the comments below and fro= m other ADs.


On Tue, Feb 22, 2022 at 3= :14 AM Alvaro Retana <aretana.ietf@gmail.com> wrote:
On February 17, 2022 at 10:06:39 AM, Keta= n Talaulikar wrote:


Ketan:

Hi!

I am looking at -18.=C2=A0 Thanks for adding the Updates tag -- you need to=
also add text to the Introduction about the update.
KT> Ack. Fixed.
=C2=A0

Comments inline...


> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
...
> > Besides the general topic of clarifying and updating what an SR P= olicy is,
> > this document also includes other items that were not present in = rfc8402;
> > the list includes:
> >
> > =C2=A72.1: "SR Policy MUST be identified through the tuple &= lt;headend, color,
> > endpoint>." =C2=A0 There's not even a mention of &quo= t;color" in rfc8402.
> >
> > =C2=A72.1: "The headend is specified as an IPv4 or IPv6 addr= ess and is expected
> > to be unique in the domain." Neither the mechanism to identi= fy a node nor
> > the expectation is present in rfc8402.
> >
> > =C2=A72.1: "The endpoint is specified as an IPv4 or IPv6 add= ress and is expected
> > to be unique in the domain." Same as above.
>
> KT> Yes, these are the constructs of SR Policy that are specified b= y this
> document.
>
> >
> >
> > The SR Database is a new element not in the base architecture. Th= e text in
> > =C2=A73 says that "use of the SR-DB for computation and vali= dation of SR
> > Policies is outside the scope of this document", but it is t= hen mentioned
> > and used in =C2=A75.1/=C2=A75.2.
>
> KT> The computation algorithm and related discussions about the use= of SR-DB
> were asked to be moved out of this standards track document during the= WG
> process. Those informational sections were moved into
> draft-filsfils-spring-sr-policy-considerations and kept as a reference= in
> this document. The reference in 5.1 and 5.2 is about validation of seg= ments
> and as a result the segment-list and candidate path. The validation of= the
> "objective" and constraints of the SR Policy was deemed to b= e outside the
> scope of the document. There were several discussions on and off-list = at the
> IETF meetings in this regard. Perhaps this thread gives a good summary= :
> https://mailarchive.ie= tf.org/arch/msg/spring/W8q3wW0damd4XgG-2cH_qzDeA6E/

It's ok if the SR-DB is out of scope.

=C2=A73 does say that "use of the SR-DB for computation and validation= of
SR Policies is outside the scope of this document." =C2=A0But that (us= ing
the DB for validation) is different than leaving validation completely
out of scope.=C2=A0 In fact, the text in =C2=A75.1 doesn't leave segmen= t-list
validation (for example) out of scope when it says this:

=C2=A0 =C2=A0The SR Policy headend does not compute the Segment-List.=C2=A0= The SR Policy
=C2=A0 =C2=A0headend only confirms its validity.

Or when it requires the validation explicitly: "A Segment-List of an explicit candidate path MUST be declared invalid..."


Leaving the validation out of scope may have been what was intended,
but it is not what the document says.=C2=A0 It is also not clear to me
whether the intent was to leave out of scope how to use the DB (as the
text in =C2=A73 says), or to completely leave it out.
=
KT> The SRDB is not out of scope. The path computation al= gorithm and the verification of the path constraints is out of scope. The S= ID validation and resolution are within the scope of the document and that = requires the SRDB. We've clarified this in the text.
=C2=A0

The thread was not that easy to follow, with most message being about
support.=C2=A0 Can you point me to where the out-of-scope decision was
reached?=C2=A0 Alternatively, the Chairs can confirm.



> > Accordingly, the added details require additional Security and Ma= nageability
> > considerations.
>
> KT> Could you please clarify/explain a bit further what you feel is= missing?

For example, for this construct of the SR Policy specified in this
document: "The headend is specified as an IPv4 or IPv6 address and is<= br> expected to be unique in the domain." (=C2=A72.1)

What new security and/or manageability considerations does it
introduce?=C2=A0 Can there be a mixture of IPv4 and IPv6 addresses
identifying headends/endpoints?=C2=A0 What happens if there are duplicate identifiers?=C2=A0 How can it be detected?=C2=A0 Can a rogue node intercept= (or
perhaps attract) the traffic of an SR Policy if it advertises one of
these addresses? =C2=A0...

KT> We ha= ve added some text in this regard in the draft. The detection mechanism for= duplicate prefix advertisements though is out of the scope of this documen= t.
=C2=A0

Some of the answers may be "nothing", or the issues may be carrie= d
over from rfc8402 -- in those cases, please at least point that out.



...
> > (2) =C2=A75.1:
> >
> > Types A or B MUST be used for the SIDs for which the reachability=
> > cannot be verified. Note that the first SID MUST always be reacha= ble
> > regardless of its type.
> >
> > These two requirements and the text in the description of these t= ypes
> > ("...does not require the headend to perform SID resolution.= ") results in a
> > contradiction: Types A and B are not to be resolved, but if they = are the
> > first SID then they MUST. If it's not a contradiction, then T= ypes A and B
> > would not be allowed to be the first SID, which is not correct be= cause the
> > most straightforward mechanism to define a path is to list SR-MPL= S Labels
> > or SRv6 SIDs.
>
> KT> I don't see a contradiction here. "Types A or B MUST b= e used for the SIDs
> for which the reachability cannot be verified." is not the same a= s saying
> "Type A or B are not to be resolved".

True.=C2=A0 However, the description of both types say that "This type= does
not require the headend to perform SID resolution."

KT> We will remove that sentence from both types since= it is not necessary. The other segment types describe the resolution to be= performed from the different contexts provided to the MPLS label or SRv6 S= ID.
=C2=A0

This is one of those cases where a (non) requirement is mentioned
without Normative language that can lead to a potentially wrong
interpretation. :-(



> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
...
> > (1) Is the specification of a headend/endpoint mandatory? IOW, sh= ould the
> > text in =C2=A72.1 about the headend/endpoint being identified by = a unique IPv4
> > or IPv6 address be normative?
>
> KT> It is not normative since we have the case of an unspecified ad= dress as
> an endpoint. We could use SHOULD though, if that clarifies.

The unspecified address is an IPv4 or IPv6 address.

If you use SHOULD, when would it be ok for the identification to not
be an IPv4 or IPv6 address?=C2=A0 Why recommend and not require?

KT> I think I understand the point. The unique= ness is about the ability to resolve the IP address to a unique node in the= SR domain to be able to identify a headend and a tailend. We've clarif= ied this in the text.
=C2=A0




> > (2) =C2=A72.1: "An implementation MAY allow the assignment o= f a symbolic name
> > comprising of printable ASCII [RFC0020] [RFC5234] characters"= ;
> >
> > Why are you normatively limiting the name to be represented in AS= CII? Please
> > internationalize it - use UTF-8.
> >
> > =C2=A72.6 also has similar text.
>
> KT> My understanding is that there is no compulsion to use UTF-8 fo= r such
> purposes. This was discussed in the WG. Please check:
> https://mailarchive.ie= tf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/

I wouldn't say that this thread (it only includes the message you sent<= br> to the list) qualifies as a discussion. =C2=A0 But, yes, there is no
requirement to use UTF-8 -- it is just the nice (and maybe correct)
thing to do knowing that non-English-speaking people may also use this
specification.

[See rfc9003 for an an example of an extension what also considered
the Cyrillic alphabet.]

KT> There ar= e existing implementations and deployments of this draft as well as the sam= e being signaled via corresponding protocol extensions in BGP and PCEP. If = this is not a requirement, then we would like to avoid change at this stage= .
=C2=A0



...
> > (4) =C2=A72.1: "An SR Policy MAY have multiple names...in th= e scenario where the
> > headend receives different SR Policy names" Describing multi= ple names as the
> > case where multiple names are received is not helpful.
>
> KT> When CPs for the same SR Policy are provisioned via different s= ources,
> then such a scenario may occur.

It would be nice if the text included that clarification then: ...via
different sources.

KT> Ack. Clarifie= d.
=C2=A0

Can multiple names be received from the same source?
<= br>
KT> Yes. Since the unit of signaling in the protocols is t= he CP. Theoretically, the same source could send different CPs of the same = Policy with different Policy names.
=C2=A0



...
> > (7) =C2=A72.4: "When signaling is via PCEP...the AS number S= HOULD be set to 0 by
> > default when not available or known."
> >
> > When is it ok for the ASN to not be set to 0 (when not available = or known)?
> > If that possibility exists, the PCE can use any value (including = the real
> > number or a random one). What issues exist with uncoordinated (or= rogue)
> > PCEs using potentially arbitrary ASNs?
> >
> > Why is this action recommended and not required?
>
> KT> AFAIR PCEP signaling does not carry AS number. So this is a
> recommendation, though a local policy or a future PCEP extension could= change
> that and we don't want to preclude it.

First of all, the architecture shouldn't be defined as a function of what the protocols can do today, it should be defined as a function of
what is needed.

KT> True. That would= be the case in an ideal world. Practically, the=C2=A0WGs have ended up wit= h the desire and requirement for having multiple protocols to signal the sa= me construct and there is the need for some normalization.
=C2=A0=

If the ASN can be signaled, when is it ok for it to not be set to 0
(when not available or known)?=C2=A0 If that possibility exists, the PCE can use any value (including the real number or a random one). What
issues exist with uncoordinated (or rogue) PCEs using potentially
arbitrary ASNs?

KT> I will leave thi= s question for the PCEP WG if and when they decide to add support for ASN t= o be signaled. It does not make any impact from this specification perspect= ive since it is only used to identify the originator.
=C2=A0



...
> > (9) Given the description, it seems possible for a PCE (for examp= le) to
> > advertise multiple candidate paths with the same Preference, Orig= inator, and
> > Discriminator. If that occurs, what is the result of the selectio= n in =C2=A72.9?
> > Would this situation result in multiple active candidate paths? >
> KT> The ability to signal multiple CPs via PCEP is being introduced= via
> draft-ietf-pce-segment-routing-policy-cp. The default is for use when = not
> using that draft and in that case, there would be only a single CP.

Let me try again: if the PCE can advertise multiple paths
(draft-ietf-pce-segment-routing-policy-cp) with the same Preference,
Originator, and Discriminator, how should the selection in =C2=A72.9 be
evaluated?

KT> Then it would be the = same CP. The second update would overwrite the first one.
=C2=A0<= /div>




> > (10) =C2=A72.11: "Only the active candidate path SHOULD be u= sed for forwarding
> > traffic that is being steered onto that policy." When is it = ok to use
> > non-active paths? Why is this action recommended and not required= ?
>
> KT> The condition was for path protection as described in section 9= .3. The
> "backup" path is programmed and hence may be used for forwar= ding while FRR is
> active.

By definition, the backup is only used when the main path is being
repaired and not used (because it failed).=C2=A0

KT> This is not accurate. At the time FRR is triggered, one does n= ot know whether what was the active path can be repaired or not. So, depend= ing on what has been provisioned as backup, it may be that the next best pa= th is used as the backup (so it will be considered active after control pla= ne convergence) OR it may be an entirely different path that may not become= active because the original active path was repaired or a 3rd path now bec= omes the active path after control plane convergence. Please also see the n= ext comment.
=C2=A0
IOW, in this case only one
path is used at a time.

The text above implies that more than one path can be used at a time.

KT> That is not the intention and we'= ve clarified in the text while using MUST.
=C2=A0



...
> > (15) =C2=A75.2:
> >
> > When the local computation is not possible (e.g., a policy's = tail-end
> > is outside the topology known to the headend) or not desired, the=
> > headend MAY send path computation request to a PCE supporting PCE= P
> > extension specified in [RFC8664].
> >
> > This action (ask the PCE) is a solution, not an architectural des= cription.
> > Are there other external mechanisms that can find a "solutio= n Segment-
> > List"? It seems to me that one such mechanism would be in th= e form of a
> > configured Segment-List. If that is correct, please generalize th= e
> > normative statement above -- where using PCEP can be an example.<= br> >
> KT> Agree and will change that to an example.

The updated text says:

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy'= ;s tail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, = the
=C2=A0 =C2=A0headend MAY send path computation request to a centralized
=C2=A0 =C2=A0computation entity (e.g., to a PCE supporting PCEP extensions<= br> =C2=A0 =C2=A0specified in [RFC8664]).

In the case of manual configuration, the request is not sent anywhere
(as in using a protocol)... =C2=A0 How about this:

=C2=A0 =C2=A0When the local computation is not possible (e.g., a policy'= ;s tail-end
=C2=A0 =C2=A0is outside the topology known to the headend) or not desired, = the
=C2=A0 =C2=A0headend may rely on an external entity.=C2=A0 For example, a r= equest may
=C2=A0 =C2=A0be sent to a PCE supporting PCEP extensions specified in [RFC8= 664].

KT> Ack. Fixed.
=C2=A0


> > (16) =C2=A77: Which are valid states? Active is one, the text men= tions an
> > "administrative state", what else? Interoperability is = a good reason to
> > specify the states and not assume that implementations might do t= he right
> > thing.
>
> KT> The state here does not mean a single one like up/down. It is r= eferring
> to the operational state. Those aspects are covered in the
> draft-ietf-spring-sr-policy-yang but also reported via BGP and PCEP wh= en
> those protocols are in use. We'll add a reference to
> draft-ietf-spring-sr-policy-yang.

draft-ietf-spring-sr-policy-yang says that it provides a data-model
for the SR Policy framework defined in this document.=C2=A0 But this
document points there for the states...circular reference.

Even if nor circular, the reference to
draft-ietf-spring-sr-policy-yang should be Normative because it
specifies the sates for the architecture.

KT> Making a normative reference to the YANG model draft would result= in a circular reference. The intention of this document is to provide a hi= gh-level requirement - e.g. whether instantiated or not, which CP is active= , reason for not being active, etc.=C2=A0 The YANG model is then expected t= o specify the more detailed operational state.
=C2=A0

You mentioned above that the "state here does not mean a single one like up/down. It is referring to the operational state." =C2=A0This is= from
draft-ietf-spring-sr-policy-yang:

=C2=A0 typedef policy-oper-state {
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 enum UP {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description "SR policy is operationally up= ";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 enum DOWN {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description "SR policy is operationally do= wn";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 description "SR policy oper state";
=C2=A0 }

Am I looking in the wrong place?

KT>= The work on the YANG model is by no means complete (IMHO). But there are m= ore operation states - e.g.,=C2=A0sr-policy-types:policy-oper-state,=C2=A0sr-policy-types:binding-sid-oper-state= ,=C2=A0is-best-= candidate-path,=C2=A0non-selection-reason,=C2=A0is-valid, etc.
=C2=A0





> > (17) =C2=A77: "The SR Policy state MUST also reflect the rea= son when a policy
> > and/or its candidate path is not active due to validation errors = or not
> > being preferred."
> >
> > Given that this is a requirement, please provide a list of reason= s. The need
> > for interoperability (by using rfc2119 language) can only be achi= eved if the
> > reasons are standardized.
>
> KT> The reason is for debugging and troubleshooting. If something i= s down or
> invalid, then it helps to know why.

Yes, I understand it helps to know the reason, that's why I'm askin= g. :-)

Again, please make draft-ietf-spring-sr-policy-yang a Normative reference.<= br>
I found a couple of identities in draft-ietf-spring-sr-policy-yang
that fit the bill for the requirement:
candidate-path-not-selected-reason and policy-down-reason.=C2=A0 However, what I couldn't find is the specification of the conditions when each of the reasons is to be used.=C2=A0 Most of reasons seem straight forward,<= br> but it would be ideal if the specification was complete.

KT> As mentioned in my response to the comment above, = the work on the YANG model seems like taking longer in the WG. The model is= perhaps the best way to capture these states' information and the mode= l can (rather should) reference the appropriate sections of this specificat= ion to clarify the intent. IMHO that would perhaps be the right way to prog= ress this work towards publication.

Thanks,
<= div>Ketan

=C2=A0



Thanks!

Alvaro.
--00000000000098d5ea05d9761bcc-- From nobody Sat Mar 5 02:37:16 2022 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 C493E3A11F0; Sat, 5 Mar 2022 02:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 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, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 0bBiJJfVSmiV; Sat, 5 Mar 2022 02:37:07 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 ADDB03A11F3; Sat, 5 Mar 2022 02:37:06 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id u124so4702085vsb.10; Sat, 05 Mar 2022 02:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UxJ5ADq1iZRxUU65QBzA1WaNHmKKNBppm8Gf/ZdeNz8=; b=TzV0WAQlqMXEpPns6RSKLzYFKlYfPGeT7ewYCv7CrF5ivFJW5fk6ShVx9lRmzbctEQ 74ifRINlQVBa6KI3GknIou9a2UOcrySdGu014vgHRpIEu18z240mV4CGWNPt7GDPoj4v RwHIcwmaoJLoDjec2cv5qOCa2usZS3fF8lWrTvAiXckB/EWR46HrYx0Xn1qWa/UYaI/e QxWb5aFJFYPTojWRHHpWZncDxjuLxE6q/iEbheksoJiJkUx9WbLtWhhbWD/AYEK7jqU+ h2AWsZ8fn2QVhm2Tta32QBOJERUgX79uQnbX2JtoY0U3novEj6ko7Rca+l2PfJsPUE1M tGqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UxJ5ADq1iZRxUU65QBzA1WaNHmKKNBppm8Gf/ZdeNz8=; b=4zUuXZAD59tODp/6ijr4+IG5Uq0YT2zp4A6i8YKJZrbC9/7eTq2qfzaBL25CH3Hgnx ULCiRqgMkRtXNTAHIbaOQ/47vThpCOWSIYQUJWhNnwHWlFKNGlUANseonYq3xQwm8Hvt KOKpPxRqivVotHEnkJVqJQ/hINSUsUxhAEtYuoUFb97+Hwn0fjmtUjJTJtkX+F5SlxpH UbyVznL4xstM+ifzmWuGvkyNbnmDd2S6g6pHvOHIW78mAMYWx62sLtTmIPtJY/fJpPOb 3yT/Bsmut5ouybCYv/nX8vqbC0ZkDnv4v2FoKg1DziLsxMtO4Cjbnx4n+4PbRXWhVKM2 ZKIA== X-Gm-Message-State: AOAM533NWZX5yMd5UVKw7z8ySOYRn1r8fiuTG95sfjkwxrruY4ha0gLN wQnCDFKqxy3Jx0zuWGZENG5XdrqVa3u9GASXqmM= X-Google-Smtp-Source: ABdhPJxtWcyUiwkn40xYyLQF5yv6CnlFSXoZoHHNiV7/MZpqmQxin6cmATUTgvvmuf2CZSmwawkNEiOZ8TnYzhxh1fM= X-Received: by 2002:a05:6102:32d1:b0:30e:5a67:8b7 with SMTP id o17-20020a05610232d100b0030e5a6708b7mr1052091vss.33.1646476624996; Sat, 05 Mar 2022 02:37:04 -0800 (PST) MIME-Version: 1.0 References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> <20220225020227.GM12881@kduck.mit.edu> In-Reply-To: <20220225020227.GM12881@kduck.mit.edu> From: Ketan Talaulikar Date: Sat, 5 Mar 2022 16:06:53 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="0000000000005d2db605d97636a9" Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sat, 05 Mar 2022 10:37:15 -0000 --0000000000005d2db605d97636a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Thanks for your response and please check inline below with KT2 We've also just posted another update to address some of your comments and those from other ADs. https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-19 On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk wrote: > Hi Ketan, > > Thanks for the replies here and the updates in the -18. > I think there are still some open topics, though; more inline. > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote: > > Hi Ben, > > > > Thanks for your detailed review and your comments/inputs. Please check > > inline for responses. > > > > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-spring-segment-routing-policy-17: 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 th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > > for more information about how to handle DISCUSS and COMMENT position= s. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > (1) I may just be misunderstanding things, but I'd like to pull on a > thread > > > in =C2=A78.4 a bit more. We say that the headend H learns a BGP rout= e that > has > > > a > > > VPN label V, but then the following procedures seem to say that we > install > > > a > > > route on the appropriate SR Policy P and that when we receive a packe= t > that > > > matches the route in question, push a label stack including the VPN > label, > > > and send the resulting packet out. > > > > > > KT> Note that we are sending the packet to the selected BGP NH (i.e. > egress > > PE) that advertised the route. The SR Policy is enabling the packets to > > traverse a path that is different from (perhaps) the best-effort IGP > > routing. > > > > > > > Nowhere do we say to check the VPN > > > status of the incoming packet, > > > > > > KT> That is the ingress part of the forwarding entry which maps the > > incoming traffic over a customer interface to their specific VPN contex= t > > and then performs a lookup in their VPN specific table. This all is > > unchanged. > > > > > > > so this seems like it would open a hole in > > > the VPN by allowing "arbitrary" incoming traffic (not marked as > specific to > > > V) to enter that VPN. Is the label V filling some other role than > > > identifying a specific VPN of many VPNs that could run along the rout= e > R/r? > > > (This is the only instance of the phrase "VPN label" in the document, > and > > > no > > > reference is given, so I'm relying heavily on instinct to ascertain t= he > > > intent here.) > > > > > > > KT> I hope my responses clarified that the only thing that is changed > here > > by the steering over the SR Policy is the path taken through the networ= k > to > > get to the egress PE. Rest is as today. And yes, of course, we have the > > ability to indicate the need for such steering via the matching Color > > Extended community to the BGP route. > > Yes, these help clarify that the part we're focusing on in this document = is > conceptually "after" the determination of the incoming VPN, and so there > isn't any new processing needed for it. Thanks for the explanation. > > > > > > > > (2) The security considerations says that this document does not > define any > > > new protocol extensions and (accordingly) does not introduce any > further > > > security considerations. The first part of this seems false, not lea= st > > > since we define the meaning of the "CO" bits in the Color Extended > > > Community. I'm pretty sure that makes the second part also false, an= d > we > > > need to discuss the security considerations relating to imposing SR > > > Policies > > > based only on color and not next-hop. Alvaro has also noted addition= al > > > aspects where security considerations are missing. > > > > > > > KT> Ack. We will add text in the security consideration sections for th= e > CO > > steering modes. > > What about the SR-DB concept and other new concepts that Alvaro identifie= d? > Aren't there security and manageability considerations there as well? > KT2> We've just added text for the endpoint uniqueness and steering aspects. The SRDB is internal to the computation node and the information within it is derived from existing routing protocols and their extensions - we are not adding anything new to it. Do let me know, however, if you feel we are missing something. > > > > > > > > (3) The Discriminator as defined in =C2=A72.5 does not seem wide enou= gh to > be > > > able to provide the needed properties. Some later clarification in > =C2=A72.6 > > > implies that the definition in =C2=A72.5 is incomplete and the width = is > actually > > > appropriate, but in either case =C2=A72.5 seems inadequate in its cur= rent > form. > > > (Details in the COMMENT.) > > > > > > > KT> 32 bit is wide enough and please see further response below. > > I think I'm still failing to understand exactly why; more below. > > > > > > > (4) Section 2.11 contains the statement, "A valid SR Policy is > instantiated > > > in the forwarding plane." > > > > > > Is this a statement of fact (i.e., a consequence of the definition of > > > "valid") or a mandate for something (e.g., the headend) to take actio= n > to > > > make it so? Given that the point of SR is to be stateless on nodes > other > > > than the headend, I suspect the former, but if we are relying on the > > > headend > > > (or some other entity) to take action to ensure this is the case, tha= t > > > needs > > > to be a clearly stated normative requirement. > > > > > > > KT> The validity of a candidate path and as an extension, the SR Policy > is > > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its > > constructs are instantiated in the forwarding plane. > > Would it make sense to say something like "In order to be considered vali= d, > an SR policy needs to be instantiated in the forwarding plane (Section 5)= "? > KT2> The SR Policy may be valid, but could not be instantiated into the forwarding due to a resource issue. We are simply stating here that generally only a valid SR Policy is instantiated in the forwarding plane. We don't have the "only" here since we have use-cases as in section 8.2 where we do have to instantiate a "drop" entry in the forwarding for an invalid SR Policy. > > > > > > > > > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." > > > There's nothing in the IANA registry for SAFI > > > (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml= ) > > > about > > > LISP, and RFC 6830 doesn't talk about SAFI. What is this referring t= o? > > > > > > > KT> Ack - there is no SAFI in LISP and the reference was meant to be fo= r > > routing of both IPv4 and IPv6 packets with LISP. Will fix this. > > The new text is still a bit terse/opaque for me to be confident that I > understand properly, but I will drop the discuss point as I think I see h= ow > it works. > > > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > There's a lot of this document that feels like just some informationa= l > > > discussion of "here are some things that many people do", "here are > some > > > possible things you can do with SR", etc.. There are also a small > handful > > > of places in the document that look to actually be specifying parts o= f > > > protocol behavior (I suspect that John has already identified them in > his > > > enumeration), and the overall impression ends up being a bit jumbled, > > > like there are a bunch of topics stuck together without an overarchin= g > > > theme. > > > I think the overall content would be more valuable if divided into a > tight > > > "protocol specification" portion that could stay at proposed standard= , > plus > > > an informational "architecture details" document that contains the > > > in-depth exposition that didn't make it into 8402. > > > > > > This draft would benefit greatly from a terminology section. I note > in the > > > section-by-section comments several places where a term is first used > > > without sufficient background/definition, leaving the matter at hand > > > underspecified for the reader. > > > > > > Section 2 > > > > > > An SR Policy is a framework that enables the instantiation of an > > > ordered list of segments on a node for implementing a source routi= ng > > > > > > Really, an SR policy is a *framework*? I thought an SR policy was a > > > specific instantiation of a list of segments, or at least that's what > I'm > > > getting from RFC 8402. Perhaps we should say that the general concep= t > of > > > SR > > > Policy provides a framework? > > > > > > > KT> Ack. Will rephrase. > > > > > > > > > > Section 2.1 > > > > > > An SR Policy MUST be identified through the tuple > > endpoint>. In the context of a specific headend, an SR policy MUS= T > > > be identified by the tuple. > > > > > > These two MUSTs appear to be in (nominal) conflict. Maybe start the > first > > > one with "absent further context" or "absent the context of a known > headend > > > node"? > > > > > > > KT> It is not "absence of context" but "within the context of a specifi= c > > headend". > > > > > > > > > > The headend is the node where the policy is > instantiated/implemented. > > > The headend is specified as an IPv4 or IPv6 address and is expecte= d > > > to be unique in the domain. > > > > > > This is the first instance of the word "domain" in this document. I > > > suggest > > > using the introduction to introduce what is meant by the word, even i= f > just > > > by reference to RFC 8402. > > > > > > > KT> Ack. It should be SR Domain. > > > > > > > > > > An implementation MAY allow the assignment of a symbolic name > > > comprising printable ASCII [RFC0020] characters (i.e. 0x20 to 0x7= E) > > > to an SR Policy to serve as a user-friendly attribute for debuggin= g > > > and troubleshooting purposes. [...] > > > > > > I agree with the other ADs that limiting to US-ASCII is not actually > > > user-friendly for many users, and that the likelihood of some > > > implementations not properly enforcing such a limitation to be high. > > > (Likewise for the other places where symbolic names are admitted.) > > > > > > > KT> Please see the response to the other reviews on this point. > > I don't find them compelling, but this is just the COMMENT section so > you're not obligated to persuade me. > > > > > > > > > Section 2.2 > > > > > > A dynamic candidate path expresses an optimization objective and a > > > set of constraints. [...] > > > > > > Down in =C2=A75.2 when we discuss validation procedures for dynamic > candidate > > > paths, we say that the optimization problem is solved "for either the > > > SR-MPLS or the SRv6 data-plane as specified". Does the data plane > need to > > > be specified as part of the dynamic candidate path itself? > > > > > > > KT> Yes. > > Should we say that here, e.g., "a dynamic candidate path expresses an > optimization objective and a set of constraints within a specified data > plane"? > KT2> Ack. Have clarified this in the text. > > > > > > > > > Section 2.3 > > > > > > in Section 2.9. The table below specifies the RECOMMENDED default > > > values of Protocol-Origin: > > > > > > I feel like it would be useful to provide some justification for why > the > > > recommended default behavior prefers BGP SR configuration over PCEP, > even > > > if > > > that justification is just "we need to have a clear ordering and this > one > > > is > > > arbitrary". > > > > > > > KT> Ack. Will clarify that. > > > > > > > > > > Section 2.4 > > > > > > o Node Address : represented as a 128-bit value. IPv4 addresses > > > MUST be encoded in the lowest 32 bits, and the high-order bits > > > MUST be set to zero. > > > > > > Its application in the candidate path selection is described in > > > Section 2.9. > > > > > > The tie-breaker procedure for path selection described in =C2=A72.9 s= eems to > > > always prefer IPv4 originators over IPv6 ones (by virtue of preferrin= g > the > > > smaller value). I guess if we wanted to change that to prefer IPv6 w= e > have > > > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped > unicast) > > > from BCP 153, but it's a bit hard to justify either of those as > appropriate > > > on technical grounds, and since this is just a tie-breaker and the > > > Preference is explicitly preferred, it seems like this is probably > "good > > > enough" as-is. > > > > > > > KT> Ack. As clarified in a recent text update in v17, preference is the > key > > parameter really. > > > > > > > > > > Section 2.5 > > > > > > The Discriminator is a 32-bit value associated with a candidate pa= th > > > that uniquely identifies it within the context of an SR Policy fro= m > a > > > specific Protocol-Origin as specified below: > > > > > > What are the constraints that underlie the 32-bit requirement here? > > > It looks like some of the scenarios are going to involve uncoordinate= d > > > (random) assignment of these discriminator values (e.g., with the BGP > > > distribution mechanism, when coming from different BGP peers), and th= e > > > birthday-bound collision probability is not negligible for this few > bits. > > > That, in turn, calls into question the "uniquely identifies" property > being > > > claimed. Or is there some other property that means that only > > > discriminators from a single issuer will ever need to be compared wit= h > each > > > other (making the allocation "coordinated"), such as being additional= ly > > > associated with the originator? > > > If my initial analysis was incorrect and these are indeed allocated i= n > a > > > "coordinated" fashion, would it be typical/expected for the allocatio= n > to > > > occur by incrementing a local counter on the originator? In some > > > situations > > > such allocation by counter can have security considerations, which > > > draft-gont-numeric-ids-sec-considerations attempts to cover. > > > > > > > KT> The discriminator is scoped to a particular originating node for th= e > > candidate path and as such, there is no requirement for coordination > across > > sources/nodes. Therefore, 32-bit is more than sufficient. > > When you say "originating node", does that refer to the SR headend, or th= e > (BGP) originator of the BGP route containing the SR Policy NLRI? > KT2> The BGP originator as you've correctly understood below. > > I assume the latter, and agree that *within the context of BGP*, the > discriminator is scoped to the originating BGP node. But the description > we give in =C2=A72.5 of this document does not say anything about making = use of > such information. As far as I know, the BGP originator information is lo= st > when the BGP distinguisher is converted into the SR Policy candidate path > discriminator data model. KT2> The BGP originator information is not lost. We have clarified this in the text below in sec 2.5 itself: o When signaling is via BGP SR Policy, the BGP process receiving the route provides the distinguisher (refer to Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy ]) as the discriminator. > And we don't say anything about how candidate > paths for a given SR Policy can only be originated from a single BGP node= , > so I have to account somehow for the possibility that two BGP nodes are > independently announcing candidate paths for the same SR Policy, and thus > might collide in their assignment of distinguisher. KT2> You are correct. This can and does indeed happen today in deployments for redundancy and other reasons. > Whereas BGP can > resolve that collision via the BP origination information, I don't see ho= w > that would be done in the SR data model. Does that help you understand > what part I am missing? > KT2> We did have some text in this document in the early days to explain these scenarios but it was moved out to an individual draft. Sec 2.9 has a pointer to this informative draft. Please check https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-consi= derations-08#section-4 and if they clarify. > > > > > > > > > > Section 2.8 > > > > > > A candidate path is usable when it is valid. A common path validi= ty > > > criterion is the validity of any of its constituent Segment-Lists. > > > The validation rules are specified in Section 5. > > > > > > This document claims to target Proposed Standard status; are we reall= y > > > content to say only that this is "a common" criterion? Even when we > also > > > go > > > on to flat-out state "the validation rules are specified [below]"? > > > > > > > KT> We will change this to introduce the word RECOMMENDED. There are > > deployments where an operator might need a local policy to declare the > > candidate path invalid when the number of valid SLs drops below a certa= in > > threshold (for b/w or load-balancing considerations). > > > > > > > > > > Section 2.9 > > > > > > The candidate path selection process operates primarily on the > > > candidate path Preference. A candidate path is selected when it i= s > > > valid and it has the highest preference value among all the > candidate > > > paths of the SR Policy. > > > > > > Should this be "among all the valid candidate paths"? A path that's > > > invalid > > > is still invalid, even if it has the highest preference value. > > > > > > > KT> Ack - will clarify this. > > > > > > > > > > 2. If specified by configuration, prefer the existing installed > > > path. > > > > > > Does "if specified by configuration" refer to the act of applying thi= s > rule > > > at all, or that the existing installed path was one specified by > > > configuration? > > > > > > > KT> The existing installed path. The rationale was that in some > deployment > > designs an operator may not want to disturb/churn an active and > > valid/working path that has been installed in the forwarding. > > > > > > > > > > Section 2.11 > > > > > > The fraction of the flows associated with a given Segment-List is = w/ > > > Sw, where w is the weight of the Segment-List and Sw is the sum of > > > the weights of the Segment-Lists of the selected path of the SR > > > Policy. > > > > > > Thank you for stating this clearly! > > > > > > Section 3 > > > > > > o TE Link Attributes (such as TE metric, Shared Risk Link Groups, > > > attribute-flag, extended admin group) [RFC5305] [RFC3630]. > > > > > > Is RFC 5329 applicable here as well? > > > > > > > KT> Yes, will add that. Thanks. > > (It looks like a second 3630 reference got added in the -18, not 5329; I'= ll > mention that in my updated ballot remarks as well.) > KT2> Ooops :-( .. now fixed for real > > > > > > > > > Section 4 > > > > > > Type E: IPv4 Prefix with Local Interface ID: > > > This type allows identification of Adjacency SID or BGP Peer > > > Adjacency SID (as defined in [RFC8402]) SR-MPLS label for > > > point-to-point links including IP unnumbered links. The > > > headend is required to resolve the specified IPv4 Prefix > > > Address to the Node originating it and then use the Local > > > Interface ID to identify the point-to-point link whose > > > adjacency is being referred to. The Local Interface ID link > > > descriptor follows semantics as specified in [RFC7752]. Thi= s > > > > > > The phrase "local interface ID" does not appear in RFC 7752 (and even > > > "local > > > interface" appears just once"; please use terminology actually presen= t > in > > > the referred-to document to clarify what is being referenced. > > > > > > > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn > > references RFC5307 which in turn RFC4202. We use RFC7752 since it cover= s > > and explains the use of the various link descriptors that we use for > > various segment types. > > > > > > > > > > Section 4.1 > > > > > > When steering unlabeled IPv6 BGP destination traffic using an SR > > > policy composed of Segment-List(s) based on IPv4 SIDs, the Explici= t > > > Null Label Policy is processed as specified in > > > [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an > > > > > > It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced docum= ent. > > > > > > > KT> Ack. Will fix. > > > > > > > > > > Section 5.1 > > > > > > The computation/logic that leads to the choice of the Segment-List > is > > > external to the SR Policy headend. The SR Policy headend does not > > > compute the Segment-List. The SR Policy headend only confirms its > > > validity. > > > > > > Does the headend actually have to confirm validity? Is it okay to ju= st > > > trust the controller and blindly use what is provided? > > > > > > > KT> At least the first segment needs to be validated from a resolvabili= ty > > perspective. The subsequent segments depend on how (i.e., using what > > segment types) the controller has signalled the path to the headend. If > it > > is indicated by just referring to a Prefix (e.g. loopback) of a node, > then > > the headend will need to resolve and as such validate. While if specifi= ed > > as a label, then no resolution is required. > > Hmm. So maybe we could say "the SR Policy headend only confirms the > validity of any segments that it needs to resolve as part of packet > processing"? Or does that not actually convey the needed information? > KT2> IMHO, the term used in the draft "path resolution to the SID" is more informative and cleared (at least to someone working on the programming of forwarding entries) than "packet processing". > > > > > > > > > Section 6.2 > > > > > > When the active candidate path has a specified BSID, the SR Policy > > > uses that BSID if this value (label in MPLS, IPv6 address in SRv6) > is > > > available (i.e., not associated with any other usage: e.g. to > another > > > MPLS client, to another SRv6 client, to another SID, to another SR > > > Policy, outside the range of SRv6 Locators). > > > > > > I don't think I understand what is meant by "client" here (for "anoth= er > > > client"). This sentence is the only place where the word "client" > appears > > > in this document... > > > > > > > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be IS-= IS > > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a > > "label manager" within the router. > > I think this explanation actually makes me more concerned about the way > this is written than I previously was. It seems to imply that we are > trying to describe both that there is an MPLS vs SRv6 data-plane in use a= nd > that the node in question is a client of some unspecified protocol that c= an > allocate SIDs/MPLS labels, which could be as varied as an IGP or a > dedicated path computation protocol. Furthermore, not all of these > possible protocols would intrinsically provide for arbitrary headend node= s > to even know if the label/SID in question has already been allocated to > another "client"! > Is the determination of availability to be made by the controller or by t= he > headend? KT2> This is local on the headend. > I think we should state that clearly, since (given the above > discussion) it seems like it is the controller that is best place to > actually make the determination, but the phrasing "the SR Policy uses" > implies (at least to me) that the determination is made on the headend, > since it is the headend that actually instantiates the policy. > KT2> The controller can (and does in some of the deployments that I am aware of) keep track of the usage of the Labels in the SRGB and SRLB (refer RFC8402). The same goes for SRv6 SIDs from under the SRv6 Locator. In deployments where controllers do drive the whole SR Policy provisioning, they do keep track. However, this is not mandatory in general. The headend is taking care of the actual programming into the forwarding and doesn't have any option but to handle these conditions. > > > > > > > > > Optionally, instead of only checking that the BSID of the active > path > > > is available, a headend MAY check that it is available within a > given > > > SID range i.e., Segment Routing Local Block (SRLB) as specified in > > > [RFC8402]. > > > > > > Is the only allowed range to check the SRLB? If not, I think we need > to > > > s/i.e./e.g./. > > > > > > > KT> Yes, SRLB is the one to check/allocate from for such usage. > > Okay. I suspect we want s/a given/the given/ then, but am not 100% sure. > KT2> Ack. Fixed. > > > > > > > > When the specified BSID is not available (optionally is not in the > > > SRLB), an alert message MUST be generated. > > > > > > This is the first time (of only two) the word "alert" appears in this > > > document, and there is no prior expalanation of what entity might be > > > receiving alerts generated by a headend. Please clarify. > > > > > > > KT> Alert mechanism could be one or more of syslog, Netconf > notification, a > > telemetry mechanism, etc.. > > I think the clarification is best placed in the document itself, e.g., in= a > glossary/terminology section as I suggested in my high-level comments. > KT2> We have clarified inline. > > > > > > > > > Assuming that at time t the BSID of the SR Policy is B1, if at tim= e > > > t+dt a different candidate path becomes active and this new active > > > path does not have a specified BSID or its BSID is specified but i= s > > > not available (e.g. it is in use by something else), then the SR > > > Policy MAY keep the previous BSID B1. > > > > > > Is there a strict bound on or other guidance for what values of dt ar= e > > > allowable for this purpose? > > > > > > KT> None > > > > > > > Is the intent that there be an atomic > > > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-path= =3DP2? > > > > > > > KT> There is no atomicity requirement. A switch from one active CP to > > another will vary depending on the cause of the switch - e.g. if it is > due > > to a failure or because a more preferred path came up. > > > > > > > > > > The association of an SR Policy with a BSID thus MAY change over t= he > > > life of the SR Policy (e.g., upon active path change). Hence, the > > > BSID SHOULD NOT be used as an identification of an SR Policy. > > > > > > Is there any guidance available on how long to wait with a given BSID > value > > > unused before binding it to a new SR Policy? > > > > > > > KT> None. These depend on the implementation and scenarios like resourc= e > > availability e.g., a BSID might get re-used sooner if the system is > running > > short of labels. > > > > > > > > > > Section 6.2.3 > > > > > > An implementation MAY support the configuration of the Specified- > > > BSID-only restrictive behavior on the headend for all SR Policies = or > > > individual SR Policies. Further, this restrictive behavior MAY al= so > > > be signaled on a per SR Policy basis to the headend. > > > > > > Elsewhere in the document we discuss specific potential signaling > > > mechanisms/protocols, but here we say nothing. Is that vagueness > > > intentional? > > > > > > > KT> Since this isn't a protocol specification the mechanism is not > > described here. However, you can look at > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-p= olicy-14#section-2.4.2 > > and that document refers back to this specification. > > Okay, but if this document isn't a protocol specification and that's > grounds to not describe mechanism in it, then there are quite a few other > places in the document that should also not describe mechanism, if we wan= t > to be applying the rule consistently. > KT2> There may be very high-level references to some mechanisms in addition to the informative pointer to the specific protocol spec. This was done to improve readability. > > > > > > > > > Section 6.3 > > > > > > A valid SR Policy installs a BSID-keyed entry in the forwarding > plane > > > with the action of steering the packets matching this entry to the > > > selected path of the SR Policy. > > > > > > I don't think this is stated properly. An SR Policy is the list of > > > segments; it isn't the entity that's installing entries in the > forwarding > > > plane. Some other entity is installing an entry in the forwarding > plane to > > > realize the SR Policy in question, and we should make our writing > reflect > > > that. > > > > > > > KT> Ack. s/installs/results in the installation of > > > > > > > > > > Section 6.4 > > > > > > An implementation MAY choose to associate a Binding SID with any > type > > > of interface (e.g. a layer 3 termination of an Optical Circuit) or= a > > > tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE > > > tunnel, etc). This enables the use of other non-SR enabled > > > > > > Should we have some discussion that contrasts this scenario against t= he > > > End.X behavior from RFC 8986 (for the "interface" case)? > > > > > > > KT> What this document says is that a BSID may be also associated to > direct > > over these other types of interfaces/tunnels. We can look at them as > having > > no other segment being imposed but just redirecting to an interface. In > > that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID i= n > > SR-MPLS). However, those tend to be associated with protocol > adjacencies. I > > am not sure that I've followed your point though and please do let me > know > > if I've not. > > What you write here indicates to me that you got my point. My proposal w= as > for a sentence something like "this behavior is analogous to the End.X > behavior defined in [RFC8986] in that the SID is removed, no new SIDs > applied, and the packet is directed across a particular interface, but it > conceptually fits better as a Binding SID since the SID is bound to a > specific (logical or physical) interface and End.X is typically used with > protocol adjacencies rather than interfaces". But that's just a > suggestion, and if you think it doesn't make sense or doesn't add much > value, please ignore it. > > > > > > > > > Section 7 > > > > > > The SR Policy State is maintained on the headend to represent the > > > state of the policy and its candidate paths. [...] > > > > > > I confess I don't really understand why we need to have the current, > > > minimal, description of SR Policy State in this document. What would > be > > > lost if we deferred its discussion entirely until there is a more > > > comprehensive discussion available? > > > > > > > KT> We will add an informational pointer to the SR Policy YANG model. > What > > this document calls out is the requirement for reporting the operationa= l > > state and provides pointers to other specs where this is being worked > out. > > > > > > > > > > The SR Policy state can be reported by the headend node via BGP-LS > > > [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and > > > [I-D.ietf-pce-binding-label-sid]. > > > > > > The functionality of draft-ietf-pce-binding-label-sid seems much more > > > limited than that of draft-ietf-idr-te-lsp-distribution; in > particular, the > > > former does not seem to actually report SR Policy state to the headed > at > > > all; rather, it only concerns itself with BSID association to path, > with no > > > information about "active", "not preferred", etc. > > > > > > > KT> The PCEP work might be spread out over different documents but we d= o > > need to cover these requirements. That is one of the objectives of havi= ng > > this document coordinate work across protocol WGs. > > It still feels like we're claiming something here that isn't true -- "can > be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]". It seems > like we are really trying to say "... via extensions to PCEP [some of whi= ch > don't exist yet in a form that we're willing to reference]". > KT2> This document, like some others in SPRING, does provide informative references (perhaps still in the WG doc stage) for better readability and clarity. > > > > > > > > Section 8.3 > > > > > > If the SR Policy P is invalid, the BSID B is not in the forwarding > > > plane and hence the packet K is dropped by H. > > > > > > We literally just in the previous section talked about a scenario > where the > > > BSDI is kept in the forwarding plane (but with the action to drop, so > the > > > overall outcome is not changed from what this text describes). > > > Nonetheless, > > > it's inaccurate to state that "the BSID B is not in the forwarding > plane" > > > here. > > > > > > > KT> There is a difference between the drop being referred to in 8.2 and > > 8.3. What we have in 8.2 is like a route pointing to null where we may > > advertise and get packets but will drop it with normal counters > associated > > with that specific entry. While 8.3 is like we are dropping because we > have > > no route (ideally we shouldn't have got the packet) and we increment a > > generic lookup failed counter. The use-cases for both are different. > > I (think I) understand that the mechanisms are different and both have us= e > cases. I just don't think that the specific combination of words used he= re > makes a true statement. There are probably a number of ways to make a > slight > adjustment and come up with a true statement, such as starting it with a > caveat as in "When Drop-Upon-Invalid behavior is not in use, for an inval= id > SR Policy P, its BSID B is not in the forwarding plane and hence the pack= et > K is dropped by H". > KT2> Thanks for that suggestion. We've incorporated it. > > > > > > > > > Section 8.4.1 > > > > > > When a BGP route has multiple Color Extended communities each with= a > > > valid SR Policy, the BGP process installs the route on the SR Poli= cy > > > giving preference to the color with the highest numerical value. > > > > > > Do we want to say anything about this being an arbitrary tiebreaker > (rather > > > than an intentional preference), or is that thought to be implicitly > clear? > > > > > > > KT> It is an intentional preference. > > Peeking forward to =C2=A78.8.2, is this also referring to the BGP color r= ather > than the SR Policy color? If so, please specifically qualify the word > "color" as being the BGP one. > > If not, then I strongly suggest that the introduction of color in =C2=A72= .1 > state that the numerical value of the color is used as a preference > mechanism in addition to indicating intent or objective (with the > implication or explicit statement that assignment of color values must be > performed in a manner that is compatible with the operator's > preference/policy). > KT2> This document needs to refer to the "BGP color" as the "Color Extended Community". Thanks for catching that. This is not done in a few places and we've fixed that. > > > > > > > > > Section 8.5 > > > > > > In this section, independent of the a-priori existence of any > > > explicit candidate path of the SR policy (C, N), it is to be noted > > > that the BGP process at headend node H triggers the instantiation = of > > > a dynamic candidate path for the SR policy (C, N) as soon as: > > > > > > I strongly suggest providing a more explicit framework of what the > > > assumptions and preconditions are for the mechanism described in this > > > section. My intuition says that it's a fairly optional thing that > would > > > need to be specifically configured, but trying to wrap that sentiment > into > > > the long bullet point involving "a local policy" seems like a very > > > confusing > > > way to express the desired behavior. > > > > > > > KT> It is actually a matter of local policy with perhaps some template > and > > configuration to drive this. I believe this should get covered in the S= R > > Policy YANG model at some point in time. > > > > > > > > > > Section 8.6 > > > > > > o is configured to instantiate an array of paths to N where the > > > entry 0 is the IGP path to N, color C1 is the first entry and > > > Color C2 is the second entry. The index into the array is call= ed > > > a Forwarding Class (FC). The index can have values 0 to 7. > > > > > > Why are the only allowed values 0 to 7? Where does this restriction > arise > > > from? It is because of some protocol element? > > > > > > > KT> There is text further in the section to indicated that these > > ranges/values are implementation-specific. Historically, the 8 values > have > > come from the MPLS EXP bits. > > If the ranges/values are implementation-specific, then don't give a > specific range here stated as if it is a universal limitation! I would > either drop the sentence entirely or say something like "when the index i= s > conveyed using the MPLS EXP bits, only indices 0 to 7 are usable". > KT2> Ack. Have clarified. > > > > > > > > > If the local configuration does not specify any explicit forwardin= g > > > information for an entry of the array, then this entry is filled > with > > > the same information as entry 0 (i.e. the IGP shortest path). > > > > > > If the SR Policy mapped to an entry of the array becomes invalid, > > > then this entry is filled with the same information as entry 0. > When > > > all the array entries have the same information as entry0, the > > > forwarding entry for N is updated to bypass the array and point > > > directly to its outgoing interface and next-hop. > > > > > > I can't tell how much of this is supposed to be protocol specificatio= n > and > > > how much an illustrative example. Is A(0) always the IGP shortest > path? > > > Are these protocol requirements to fall back to the IGP shortest path > when > > > an entry is otherwise unpopulated or the associated SR Policy becomes > > > invalid? > > > > > > > KT> The specifics are for illustration purposes. Most of these are poli= cy > > knobs/options. > > Please add a note at the top of the section that "this section provides a= n > example of how a headend might apply per-flow steering in practice". > KT2> Ack. Added. > > > > > > > > > Section 8.8.2 > > > > > > The steering preference is first based on the highest color value > and > > > then CO-dependent for the color. [...] > > > > > > This seems to contradict what I assumed earlier about the "highest > color" > > > rule being a tiebreaker, e.g., the word "preference" is used here. I= s > it > > > actually intended to be a deliberately configured priority/preference > > > scheme? If so, that would seem to require some wide-ranging reworkin= g > > > throughout the document. > > > > > > > KT> There is the color that is in the identification of an SR Policy - > > (color, endpoint). This does not get into any tiebreaker or selection > > logic. All that (sec 2.9) is about the selection of a candidate path > within > > an SR Policy. Then there is the color value signaled via the Color > Extended > > community on the BGP routes and here, we have the preference for higher > > color when the route is advertised with multiple colors tagged to it. > > I think you should clarify that this section refers to the BGP Color, the= n > -- previously in the document it has been the SR Policy color value and a= n > unqualified reference to "color value" seems like it refers to the concep= t > defined in this document, absent other qualifiers. > KT2> Ack. Fixed references as mentioned in a previous comment. > > > > > > > > > Section 9.3 > > > > > > the most appropriate alternative for the active candidate path. A > > > fast re-route mechanism MAY then be used to trigger sub 50msec > > > switchover from the active to the backup candidate path in the > > > forwarding plane. Mechanisms like Bidirectional Forwarding > Detection > > > (BFD) MAY be used for fast detection of such failures. > > > > > > Why is the specific 50msec value important here? Is there some other > > > requirement that imposes it? > > > > > > > KT> This comes from "typical" expectations from fast-reroute mechanisms= . > > I'd consider '''to trigger "fast" (sub 50msec) switchover''', then, but > it's not very important. > > > > > > > > > Section 10 > > > > > > I think we also want to mention the security considerations of severa= l > more > > > documents, including (but not limited to) > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 898= 6. > > > > > > > KT> Ack on the three RFCs, but convinced about the > > draft-ietf-idr-segment-routing-te-policy since that depends on this and > not > > the other way around. > > I think this relates to John's Discuss point and whether this document > specifies the protocol behavior of the two bits in the context of the > extension defined in draft-ietf-idr-segment-routing-te-policy. You need = to > understand draft-ietf-idr-segment-routing-te-policy in order to understan= d > the security considerations relating to the protocol behavior controlled = by > those two bits, and IMO the protocol behavior specified by those two bits > is solely the responsibility of this document, so this document must > incorporate the security considerations of > draft-ietf-idr-segment-routing-te-policy in order to fully document the > security considerations of the concepts and protocol elements that this > document defines. > KT2> I am working with John to address his comments. Thanks, Ketan > > Thanks for this, and all the other parts I didn't specifically reply to. > > I will attempt to update my ballot position in the datatracker to remove > the parts that are fully addressed (though I will probably inadvertently > leave in something I shouldn't have). > > -Ben > > > > > > > > > Section 15.2 > > > > > > I agree with John that draft-ietf-idr-segment-routing-te-policy must = be > > > classified as a normative reference. > > > > > > It also seems that RFC 7752 should be classified as normative, as we > > > incorporate its definition for the semantics of several of the segmen= t > type > > > descriptions. > > > > > > > KT> Ack > > > > > > > > > > > > > NITS > > > > > > Section 1 > > > > > > Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of > > > segments (i.e. instructions) that represent a source-routed policy= . > > > > > > /Segment/A Segment/ > > > > > > > KT> Ack > > > > > > > > > > The headend node is said to steer a flow into a SR Policy. The > > > packets steered into an SR Policy carry an ordered list of segment= s > > > associated with that SR Policy. [...] > > > > > > In a certain sense this can be read as saying that the packets that > "carry > > > an ordered list of segments" are the ones prior to being steered into > an SR > > > policy, which would make this statement not true. Perhaps we want to > say > > > "after being steered into an SR Policy, packets carry an ordered list > ..."? > > > (I also went back and forth with myself about whether "packets ... > carry" > > > implies in the payload or not. I settled on "not" but make this note > just > > > in case I am missing an aspect of that question.) > > > > > > > KT> Ack. Will rephrase. > > > > > > > > > > Section 2 > > > > > > An SR Policy is a framework that enables the instantiation of an > > > ordered list of segments on a node for implementing a source routi= ng > > > > > > It's easy to read this as saying that all of the segments in the list > > > instantiated on the single node in question, which I assume is not th= e > > > intent. Probably the easiest way to aid readability here is to split > the > > > sentence up into multiple smaller sentences that are easier to parse. > > > > > > > KT> Will rephrase. > > > > > > > > > > Section 2.2 > > > > > > A dynamic candidate path expresses an optimization objective and a > > > set of constraints. The headend (potentially with the help of a > PCE) > > > computes the solution Segment-List (or set of Segment-Lists) that > > > solves the optimization problem. > > > > > > I'd suggest computes the solution/computes a solution/ for genericity= . > > > > > > > KT> Ack. > > > > > > > A stateful PCE might end up computing a path that is not the optimal > one > > > for > > > this specific optimization problem, due to a desire to cooperate with > other > > > paths in the network, and the "Min-Metric with margin and maximum > number of > > > SIDs" objective in draft-filsfils-spring-sr-policy-considerations > doesn't > > > even have a guaranteed unique best solution. > > > > > > Section 2.5 > > > > > > When provisioning is via configuration, this is an implementation'= s > > > configuration model-specific unique identifier for a candidate pat= h. > > > The default value is 0. > > > > > > I'm having a lot of trouble parsing this. Did we perhaps mean to > hyphenate > > > as "configuration-model-specific"? > > > > > > > KT> Ack > > > > > > > > > > Section 2.13 > > > > > > The SR Policy POL1 is identified by the tuple > > endpoint>. It has two candidate paths CP1 and CP2. Each is > > > identified by a tuple = . > > > > > > I suggest (for the last sentence) "identified within the scope of POL= 1" > > > > > > > KT> Ack > > > > > > > > > > forwarding instantiation of SR policy POL1. Traffic steered on PO= L1 > > > is flow-based hashed on Segment-List with a ratio > > > W1/(W1+W2). > > > > > > If I read "ratio" I would instinctively think of the ratio of (traffi= c > on > > > segment list 1)/(traffic on segment list 2), as opposed to the > proportion > > > of > > > all traffic, that would be measured as the indicated W1/(W1+W2). > > > > > > > KT> Ack. s/ratio/proportion > > > > > > > > > > Section 3 > > > > > > The attached domain topology may be learned via IGP, BGP-LS or > > > NETCONF. > > > > > > A non-attached (remote) domain topology may be learned via BGP-LS = or > > > NETCONF. > > > > > > I think these are both probably not exhaustive lists, so "e.g." or > similar > > > may be appropriate. > > > > > > > KT> Ack. > > > > > > > > > > Section 4 > > > > > > Type C: IPv4 Prefix with optional SR Algorithm: > > > The headend is required to resolve the specified IPv4 Prefix > > > Address to the SR-MPLS label corresponding to a Prefix SID > > > segment (as defined in [RFC8402]). The SR algorithm (refer = to > > > Section 3.1.1 of [RFC8402]) to be used MAY also be provided. > > > > > > Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: > > > In this case, the headend is required to resolve the specifi= ed > > > IPv6 Global Prefix Address to the SR-MPLS label correspondin= g > > > to its Prefix SID segment (as defined in [RFC8402]). The SR > > > Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used M= AY > > > > > > These are effectively just the IPv4 and IPv6 incarnations of the same > > > underlying procedure, right? Can't we minimize the diff between the > > > paragraphs further? > > > > > > > KT> Ack > > > > > > > > > > Section 5.1 > > > > > > Additionally, a Segment-List MAY be declared invalid when: > > > > > > We probably want another word here ("both"?), to specify how the two > > > conditions are combined. > > > > > > > KT> Ack - will rephrase. > > > > > > > > > > Section 5.2 > > > > > > When the local computation is not possible (e.g., a policy's > tail-end > > > is outside the topology known to the headend) or not desired, the > > > headend MAY send path computation request to a PCE supporting PCEP > > > extension specified in [RFC8664]. > > > > > > missing article ("the PCEP extension"). I forget if it should be > > > "extensions" plural. > > > > > > > KT> Ack > > > > > > > > > > Section 8.7 > > > > > > Finally, headend H MAY be configured with a local routing policy > > > which overrides any BGP/IGP path and steer a specified packet on a= n > > > > > > singular/plural mismatch -- s/steer/steers/ > > > > > > > KT> Ack. > > > > Thanks, > > Ketan > > --0000000000005d2db605d97636a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks=C2=A0fo= r your response and please check inline below with KT2

=
We've also just posted another update to address some of your comm= ents and those from other ADs.


On Fri, Feb 25, 20= 22 at 7:32 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Ketan,

Thanks for the replies here and the updates in the -18.
I think there are still some open topics, though; more inline.

On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote:
> Hi Ben,
>
> Thanks for your detailed review and your comments/inputs. Please check=
> inline for responses.
>
>
> On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-spring-segment-routing-policy-17: 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 cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT posi= tions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatrac= ker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > (1) I may just be misunderstanding things, but I'd like to pu= ll on a thread
> > in =C2=A78.4 a bit more.=C2=A0 We say that the headend H learns a= BGP route that has
> > a
> > VPN label V, but then the following procedures seem to say that w= e install
> > a
> > route on the appropriate SR Policy P and that when we receive a p= acket that
> > matches the route in question, push a label stack including the V= PN label,
> > and send the resulting packet out.
>
>
> KT> Note that we are sending the packet to the selected BGP NH (i.e= . egress
> PE) that advertised the route. The SR Policy is enabling the packets t= o
> traverse a path that is different from (perhaps) the best-effort IGP > routing.
>
>
> > Nowhere do we say to check the VPN
> > status of the incoming packet,
>
>
> KT> That is the ingress part of the forwarding entry which maps the=
> incoming traffic over a customer interface to their specific VPN conte= xt
> and then performs a lookup in their VPN specific table. This all is > unchanged.
>
>
> > so this seems like it would open a hole in
> > the VPN by allowing "arbitrary" incoming traffic (not m= arked as specific to
> > V) to enter that VPN.=C2=A0 Is the label V filling some other rol= e than
> > identifying a specific VPN of many VPNs that could run along the = route R/r?
> > (This is the only instance of the phrase "VPN label" in= the document, and
> > no
> > reference is given, so I'm relying heavily on instinct to asc= ertain the
> > intent here.)
> >
>
> KT> I hope my responses clarified that the only thing that is chang= ed here
> by the steering over the SR Policy is the path taken through the netwo= rk to
> get to the egress PE. Rest is as today. And yes, of course, we have th= e
> ability to indicate the need for such steering via the matching Color<= br> > Extended community to the BGP route.

Yes, these help clarify that the part we're focusing on in this documen= t is
conceptually "after" the determination of the incoming VPN, and s= o there
isn't any new processing needed for it.=C2=A0 Thanks for the explanatio= n.

>
> >
> > (2) The security considerations says that this document does not = define any
> > new protocol extensions and (accordingly) does not introduce any = further
> > security considerations.=C2=A0 The first part of this seems false= , not least
> > since we define the meaning of the "CO" bits in the Col= or Extended
> > Community.=C2=A0 I'm pretty sure that makes the second part a= lso false, and we
> > need to discuss the security considerations relating to imposing = SR
> > Policies
> > based only on color and not next-hop.=C2=A0 Alvaro has also noted= additional
> > aspects where security considerations are missing.
> >
>
> KT> Ack. We will add text in the security consideration sections fo= r the CO
> steering modes.

What about the SR-DB concept and other new concepts that Alvaro identified?=
Aren't there security and manageability considerations there as well?
=C2=A0
KT2> We've just added text for = the endpoint uniqueness and steering aspects. The SRDB is internal to the c= omputation node and the information within it is derived from existing rout= ing protocols and their extensions - we are not adding anything new to it. = Do let me know, however, if you feel we are missing something.

>
> >
> > (3) The Discriminator as defined in =C2=A72.5 does not seem wide = enough to be
> > able to provide the needed properties.=C2=A0 Some later clarifica= tion in =C2=A72.6
> > implies that the definition in =C2=A72.5 is incomplete and the wi= dth is actually
> > appropriate, but in either case =C2=A72.5 seems inadequate in its= current form.
> > (Details in the COMMENT.)
> >
>
> KT> 32 bit is wide enough and please see further response below.
I think I'm still failing to understand exactly why; more below.

> >
> > (4) Section 2.11 contains the statement, "A valid SR Policy = is instantiated
> > in the forwarding plane."
> >
> > Is this a statement of fact (i.e., a consequence of the definitio= n of
> > "valid") or a mandate for something (e.g., the headend)= to take action to
> > make it so?=C2=A0 Given that the point of SR is to be stateless o= n nodes other
> > than the headend, I suspect the former, but if we are relying on = the
> > headend
> > (or some other entity) to take action to ensure this is the case,= that
> > needs
> > to be a clearly stated normative requirement.
> >
>
> KT> The validity of a candidate path and as an extension, the SR Po= licy is
> discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its > constructs are instantiated in the forwarding plane.

Would it make sense to say something like "In order to be considered v= alid,
an SR policy needs to be instantiated in the forwarding plane (Section 5)&q= uot;?

KT2> The SR Policy may be vali= d, but could not be instantiated into the forwarding due to a resource issu= e. We are simply stating here that generally only a valid SR Policy is inst= antiated in the forwarding plane. We don't have the "only" he= re since we have use-cases as in section 8.2 where we do have to instantiat= e a "drop" entry in the forwarding for an invalid SR Policy.
=C2=A0

>
> >
> > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC68= 30]."
> > There's nothing in the IANA registry for SAFI
> > (https://www.iana.org/= assignments/safi-namespace/safi-namespace.xhtml)
> > about
> > LISP, and RFC 6830 doesn't talk about SAFI.=C2=A0 What is thi= s referring to?
> >
>
> KT> Ack - there is no SAFI in LISP and the reference was meant to b= e for
> routing of both IPv4 and IPv6 packets with LISP. Will fix this.

The new text is still a bit terse/opaque for me to be confident that I
understand properly, but I will drop the discuss point as I think I see how=
it works.

>
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > There's a lot of this document that feels like just some info= rmational
> > discussion of "here are some things that many people do"= ;, "here are some
> > possible things you can do with SR", etc..=C2=A0 There are a= lso a small handful
> > of places in the document that look to actually be specifying par= ts of
> > protocol behavior (I suspect that John has already identified the= m in his
> > enumeration), and the overall impression ends up being a bit jumb= led,
> > like there are a bunch of topics stuck together without an overar= ching
> > theme.
> > I think the overall content would be more valuable if divided int= o a tight
> > "protocol specification" portion that could stay at pro= posed standard, plus
> > an informational "architecture details" document that c= ontains the
> > in-depth exposition that didn't make it into 8402.
> >
> > This draft would benefit greatly from a terminology section.=C2= =A0 I note in the
> > section-by-section comments several places where a term is first = used
> > without sufficient background/definition, leaving the matter at h= and
> > underspecified for the reader.
> >
> > Section 2
> >
> >=C2=A0 =C2=A0 An SR Policy is a framework that enables the instant= iation of an
> >=C2=A0 =C2=A0 ordered list of segments on a node for implementing = a source routing
> >
> > Really, an SR policy is a *framework*?=C2=A0 I thought an SR poli= cy was a
> > specific instantiation of a list of segments, or at least that= 9;s what I'm
> > getting from RFC 8402.=C2=A0 Perhaps we should say that the gener= al concept of
> > SR
> > Policy provides a framework?
> >
>
> KT> Ack. Will rephrase.
>
>
> >
> > Section 2.1
> >
> >=C2=A0 =C2=A0 An SR Policy MUST be identified through the tuple &l= t;headend, color,
> >=C2=A0 =C2=A0 endpoint>.=C2=A0 In the context of a specific hea= dend, an SR policy MUST
> >=C2=A0 =C2=A0 be identified by the <color, endpoint> tuple.<= br> > >
> > These two MUSTs appear to be in (nominal) conflict.=C2=A0 Maybe s= tart the first
> > one with "absent further context" or "absent the c= ontext of a known headend
> > node"?
> >
>
> KT> It is not "absence of context" but "within the c= ontext of a specific
> headend".
>
>
> >
> >=C2=A0 =C2=A0 The headend is the node where the policy is instanti= ated/implemented.
> >=C2=A0 =C2=A0 The headend is specified as an IPv4 or IPv6 address = and is expected
> >=C2=A0 =C2=A0 to be unique in the domain.
> >
> > This is the first instance of the word "domain" in this= document.=C2=A0 I
> > suggest
> > using the introduction to introduce what is meant by the word, ev= en if just
> > by reference to RFC 8402.
> >
>
> KT> Ack. It should be SR Domain.
>
>
> >
> >=C2=A0 =C2=A0 An implementation MAY allow the assignment of a symb= olic name
> >=C2=A0 =C2=A0 comprising printable ASCII [RFC0020] characters (i.e= .=C2=A0 0x20 to 0x7E)
> >=C2=A0 =C2=A0 to an SR Policy to serve as a user-friendly attribut= e for debugging
> >=C2=A0 =C2=A0 and troubleshooting purposes.=C2=A0 [...]
> >
> > I agree with the other ADs that limiting to US-ASCII is not actua= lly
> > user-friendly for many users, and that the likelihood of some
> > implementations not properly enforcing such a limitation to be hi= gh.
> > (Likewise for the other places where symbolic names are admitted.= )
> >
>
> KT> Please see the response to the other reviews on this point.

I don't find them compelling, but this is just the COMMENT section so you're not obligated to persuade me.

>
> >
> > Section 2.2
> >
> >=C2=A0 =C2=A0 A dynamic candidate path expresses an optimization o= bjective and a
> >=C2=A0 =C2=A0 set of constraints.=C2=A0 [...]
> >
> > Down in =C2=A75.2 when we discuss validation procedures for dynam= ic candidate
> > paths, we say that the optimization problem is solved "for e= ither the
> > SR-MPLS or the SRv6 data-plane as specified".=C2=A0 Does the= data plane need to
> > be specified as part of the dynamic candidate path itself?
> >
>
> KT> Yes.

Should we say that here, e.g., "a dynamic candidate path expresses an<= br> optimization objective and a set of constraints within a specified data
plane"?

KT2> Ack. Have clarifie= d this in the text.
=C2=A0

>
> >
> > Section 2.3
> >
> >=C2=A0 =C2=A0 in Section 2.9.=C2=A0 The table below specifies the = RECOMMENDED default
> >=C2=A0 =C2=A0 values of Protocol-Origin:
> >
> > I feel like it would be useful to provide some justification for = why the
> > recommended default behavior prefers BGP SR configuration over PC= EP, even
> > if
> > that justification is just "we need to have a clear ordering= and this one
> > is
> > arbitrary".
> >
>
> KT> Ack. Will clarify that.
>
>
> >
> > Section 2.4
> >
> >=C2=A0 =C2=A0 o=C2=A0 Node Address : represented as a 128-bit valu= e.=C2=A0 IPv4 addresses
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be encoded in the lowest 32 bits, = and the high-order bits
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to zero.
> >
> >=C2=A0 =C2=A0 Its application in the candidate path selection is d= escribed in
> >=C2=A0 =C2=A0 Section 2.9.
> >
> > The tie-breaker procedure for path selection described in =C2=A72= .9 seems to
> > always prefer IPv4 originators over IPv6 ones (by virtue of prefe= rring the
> > smaller value).=C2=A0 I guess if we wanted to change that to pref= er IPv6 we have
> > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped u= nicast)
> > from BCP 153, but it's a bit hard to justify either of those = as appropriate
> > on technical grounds, and since this is just a tie-breaker and th= e
> > Preference is explicitly preferred, it seems like this is probabl= y "good
> > enough" as-is.
> >
>
> KT> Ack. As clarified in a recent text update in v17, preference is= the key
> parameter really.
>
>
> >
> > Section 2.5
> >
> >=C2=A0 =C2=A0 The Discriminator is a 32-bit value associated with = a candidate path
> >=C2=A0 =C2=A0 that uniquely identifies it within the context of an= SR Policy from a
> >=C2=A0 =C2=A0 specific Protocol-Origin as specified below:
> >
> > What are the constraints that underlie the 32-bit requirement her= e?
> > It looks like some of the scenarios are going to involve uncoordi= nated
> > (random) assignment of these discriminator values (e.g., with the= BGP
> > distribution mechanism, when coming from different BGP peers), an= d the
> > birthday-bound collision probability is not negligible for this f= ew bits.
> > That, in turn, calls into question the "uniquely identifies&= quot; property being
> > claimed.=C2=A0 Or is there some other property that means that on= ly
> > discriminators from a single issuer will ever need to be compared= with each
> > other (making the allocation "coordinated"), such as be= ing additionally
> > associated with the originator?
> > If my initial analysis was incorrect and these are indeed allocat= ed in a
> > "coordinated" fashion, would it be typical/expected for= the allocation to
> > occur by incrementing a local counter on the originator?=C2=A0 In= some
> > situations
> > such allocation by counter can have security considerations, whic= h
> > draft-gont-numeric-ids-sec-considerations attempts to cover.
> >
>
> KT> The discriminator is scoped to a particular originating node fo= r the
> candidate path and as such, there is no requirement for coordination a= cross
> sources/nodes. Therefore, 32-bit is more than sufficient.

When you say "originating node", does that refer to the SR headen= d, or the
(BGP) originator of the BGP route containing the SR Policy NLRI?

KT2> The BGP originator as you've correctl= y understood below.=C2=A0
=C2=A0

I assume the latter, and agree that *within the context of BGP*, the
discriminator is scoped to the originating BGP node.=C2=A0 But the descript= ion
we give in =C2=A72.5 of this document does not say anything about making us= e of
such information.=C2=A0 As far as I know, the BGP originator information is= lost
when the BGP distinguisher is converted into the SR Policy candidate path discriminator data model.=C2=A0

KT2> Th= e BGP originator information is not lost. We have clarified this in the tex= t below in sec 2.5 itself:

   o  When signaling is via BGP SR Policy, the BGP process receiving t=
he
      route provides the distinguisher (refer to Section 2.1 of
      [I-D.ietf-idr-segment-routing-te-policy]) as the discriminat=
or.
=C2=A0
And we don't say anything about how candidate
paths for a given SR Policy can only be originated from a single BGP node,<= br> so I have to account somehow for the possibility that two BGP nodes are
independently announcing candidate paths for the same SR Policy, and thus might collide in their assignment of distinguisher.=C2=A0

KT2> You are correct. This can and does indeed happen to= day in deployments for redundancy and other reasons.
=C2=A0
=
Whereas BGP can
resolve that collision via the BP origination information, I don't see = how
that would be done in the SR data model.=C2=A0 Does that help you understan= d
what part I am missing?

KT2> We did = have some text in this document in the early days to explain these scenario= s but it was moved out to an individual draft. Sec 2.9 has a pointer to thi= s informative draft. Please check=C2=A0https://datatracker.ietf.org/doc/html/draft-filsfils-sprin= g-sr-policy-considerations-08#section-4 and if they clarify.
= =C2=A0


>
> >
> > Section 2.8
> >
> >=C2=A0 =C2=A0 A candidate path is usable when it is valid.=C2=A0 A= common path validity
> >=C2=A0 =C2=A0 criterion is the validity of any of its constituent = Segment-Lists.
> >=C2=A0 =C2=A0 The validation rules are specified in Section 5.
> >
> > This document claims to target Proposed Standard status; are we r= eally
> > content to say only that this is "a common" criterion?= =C2=A0 Even when we also
> > go
> > on to flat-out state "the validation rules are specified [be= low]"?
> >
>
> KT> We will change this to introduce the word RECOMMENDED. There ar= e
> deployments where an operator might need a local policy to declare the=
> candidate path invalid when the number of valid SLs drops below a cert= ain
> threshold (for b/w or load-balancing considerations).
>
>
> >
> > Section 2.9
> >
> >=C2=A0 =C2=A0 The candidate path selection process operates primar= ily on the
> >=C2=A0 =C2=A0 candidate path Preference.=C2=A0 A candidate path is= selected when it is
> >=C2=A0 =C2=A0 valid and it has the highest preference value among = all the candidate
> >=C2=A0 =C2=A0 paths of the SR Policy.
> >
> > Should this be "among all the valid candidate paths"?= =C2=A0 A path that's
> > invalid
> > is still invalid, even if it has the highest preference value. > >
>
> KT> Ack - will clarify this.
>
>
> >
> >=C2=A0 =C2=A0 2.=C2=A0 If specified by configuration, prefer the e= xisting installed
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 path.
> >
> > Does "if specified by configuration" refer to the act o= f applying this rule
> > at all, or that the existing installed path was one specified by<= br> > > configuration?
> >
>
> KT> The existing installed path. The rationale was that in some dep= loyment
> designs an operator may not want to disturb/churn an active and
> valid/working path that has been installed in the forwarding.
>
>
> >
> > Section 2.11
> >
> >=C2=A0 =C2=A0 The fraction of the flows associated with a given Se= gment-List is w/
> >=C2=A0 =C2=A0 Sw, where w is the weight of the Segment-List and Sw= is the sum of
> >=C2=A0 =C2=A0 the weights of the Segment-Lists of the selected pat= h of the SR
> >=C2=A0 =C2=A0 Policy.
> >
> > Thank you for stating this clearly!
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 o=C2=A0 TE Link Attributes (such as TE metric, Share= d Risk Link Groups,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0attribute-flag, extended admin group) [= RFC5305] [RFC3630].
> >
> > Is RFC 5329 applicable here as well?
> >
>
> KT> Yes, will add that. Thanks.

(It looks like a second 3630 reference got added in the -18, not 5329; I= 9;ll
mention that in my updated ballot remarks as well.)
KT2> Ooops :-( .. now fixed for real
=C2=A0
=

>
> >
> > Section 4
> >
> >=C2=A0 =C2=A0 Type E: IPv4 Prefix with Local Interface ID:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This type allows identification= of Adjacency SID or BGP Peer
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adjacency SID (as defined in [R= FC8402]) SR-MPLS label for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point-to-point links including = IP unnumbered links.=C2=A0 The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 headend is required to resolve = the specified IPv4 Prefix
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address to the Node originating= it and then use the Local
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interface ID to identify the po= int-to-point link whose
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 adjacency is being referred to.= =C2=A0 The Local Interface ID link
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descriptor follows semantics as= specified in [RFC7752].=C2=A0 This
> >
> > The phrase "local interface ID" does not appear in RFC = 7752 (and even
> > "local
> > interface" appears just once"; please use terminology a= ctually present in
> > the referred-to document to clarify what is being referenced.
> >
>
> KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn=
> references RFC5307 which in turn RFC4202. We use RFC7752 since it cove= rs
> and explains the use of the various link descriptors that we use for > various segment types.
>
>
> >
> > Section 4.1
> >
> >=C2=A0 =C2=A0 When steering unlabeled IPv6 BGP destination traffic= using an SR
> >=C2=A0 =C2=A0 policy composed of Segment-List(s) based on IPv4 SID= s, the Explicit
> >=C2=A0 =C2=A0 Null Label Policy is processed as specified in
> >=C2=A0 =C2=A0 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.= 4.4.=C2=A0 When an
> >
> > It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced d= ocument.
> >
>
> KT> Ack. Will fix.
>
>
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 The computation/logic that leads to the choice of th= e Segment-List is
> >=C2=A0 =C2=A0 external to the SR Policy headend.=C2=A0 The SR Poli= cy headend does not
> >=C2=A0 =C2=A0 compute the Segment-List.=C2=A0 The SR Policy headen= d only confirms its
> >=C2=A0 =C2=A0 validity.
> >
> > Does the headend actually have to confirm validity?=C2=A0 Is it o= kay to just
> > trust the controller and blindly use what is provided?
> >
>
> KT> At least the first segment needs to be validated from a resolva= bility
> perspective. The subsequent segments depend on how (i.e., using what > segment types) the controller has signalled the path to the headend. I= f it
> is indicated by just referring to a Prefix (e.g. loopback) of a node, = then
> the headend will need to resolve and as such validate. While if specif= ied
> as a label, then no resolution is required.

Hmm.=C2=A0 So maybe we could say "the SR Policy headend only confirms = the
validity of any segments that it needs to resolve as part of packet
processing"?=C2=A0 Or does that not actually convey the needed informa= tion?

KT2> IMHO, the term used in th= e draft "path resolution to the SID" is more informative and clea= red=C2=A0(at least to someone working on the programming of forwarding entr= ies) than "packet processing".=C2=A0
=C2=A0

>
> >
> > Section 6.2
> >
> >=C2=A0 =C2=A0 When the active candidate path has a specified BSID,= the SR Policy
> >=C2=A0 =C2=A0 uses that BSID if this value (label in MPLS, IPv6 ad= dress in SRv6) is
> >=C2=A0 =C2=A0 available (i.e., not associated with any other usage= : e.g. to another
> >=C2=A0 =C2=A0 MPLS client, to another SRv6 client, to another SID,= to another SR
> >=C2=A0 =C2=A0 Policy, outside the range of SRv6 Locators).
> >
> > I don't think I understand what is meant by "client"= ; here (for "another
> > client").=C2=A0 This sentence is the only place where the wo= rd "client" appears
> > in this document...
> >
>
> KT> The term is "MPLS client" or "SRv6 client".= MPLS clients can be IS-IS
> enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from = a
> "label manager" within the router.

I think this explanation actually makes me more concerned about the way
this is written than I previously was.=C2=A0 It seems to imply that we are<= br> trying to describe both that there is an MPLS vs SRv6 data-plane in use and=
that the node in question is a client of some unspecified protocol that can=
allocate SIDs/MPLS labels, which could be as varied as an IGP or a
dedicated path computation protocol.=C2=A0 Furthermore, not all of these possible protocols would intrinsically provide for arbitrary headend nodes<= br> to even know if the label/SID in question has already been allocated to
another "client"!=C2=A0

Is the determination of availability to be made by the controller or by the=
headend?=C2=A0

KT2> This is local on th= e headend.
=C2=A0
I think we should state that clearly, since (given the above
discussion) it seems like it is the controller that is best place to
actually make the determination, but the phrasing "the SR Policy uses&= quot;
implies (at least to me) that the determination is made on the headend,
since it is the headend that actually instantiates the policy.

KT2> The controller can (and does in some of the= deployments that I am aware of) keep track of the usage of the Labels in t= he SRGB and SRLB (refer RFC8402). The same goes for SRv6 SIDs from under th= e SRv6 Locator. In deployments where controllers do drive the whole SR Poli= cy provisioning, they do keep track.=C2=A0However, this is not mandatory in= general. The headend is taking care of the actual programming into the for= warding and doesn't have any option but to handle these conditions.
=C2=A0

>
> >
> >=C2=A0 =C2=A0 Optionally, instead of only checking that the BSID o= f the active path
> >=C2=A0 =C2=A0 is available, a headend MAY check that it is availab= le within a given
> >=C2=A0 =C2=A0 SID range i.e., Segment Routing Local Block (SRLB) a= s specified in
> >=C2=A0 =C2=A0 [RFC8402].
> >
> > Is the only allowed range to check the SRLB?=C2=A0 If not, I thin= k we need to
> > s/i.e./e.g./.
> >
>
> KT> Yes, SRLB is the one to check/allocate from for such usage.

Okay.=C2=A0 I suspect we want s/a given/the given/ then, but am not 100% su= re.

KT2> Ack. Fixed.
=C2= =A0
>
> >
> >=C2=A0 =C2=A0 When the specified BSID is not available (optionally= is not in the
> >=C2=A0 =C2=A0 SRLB), an alert message MUST be generated.
> >
> > This is the first time (of only two) the word "alert" a= ppears in this
> > document, and there is no prior expalanation of what entity might= be
> > receiving alerts generated by a headend.=C2=A0 Please clarify. > >
>
> KT> Alert mechanism could be one or more of syslog, Netconf notific= ation, a
> telemetry mechanism, etc..

I think the clarification is best placed in the document itself, e.g., in a=
glossary/terminology section as I suggested in my high-level comments.
<= /blockquote>

KT2> We have clarified inline.
=C2=A0

>
> >
> >=C2=A0 =C2=A0 Assuming that at time t the BSID of the SR Policy is= B1, if at time
> >=C2=A0 =C2=A0 t+dt a different candidate path becomes active and t= his new active
> >=C2=A0 =C2=A0 path does not have a specified BSID or its BSID is s= pecified but is
> >=C2=A0 =C2=A0 not available (e.g. it is in use by something else),= then the SR
> >=C2=A0 =C2=A0 Policy MAY keep the previous BSID B1.
> >
> > Is there a strict bound on or other guidance for what values of d= t are
> > allowable for this purpose?
>
>
> KT> None
>
>
> >=C2=A0 =C2=A0Is the intent that there be an atomic
> > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-pa= th=3DP2?
> >
>
> KT> There is no atomicity requirement. A switch from one active CP = to
> another will vary depending on the cause of the switch - e.g. if it is= due
> to a failure or because a more preferred path came up.
>
>
> >
> >=C2=A0 =C2=A0 The association of an SR Policy with a BSID thus MAY= change over the
> >=C2=A0 =C2=A0 life of the SR Policy (e.g., upon active path change= ).=C2=A0 Hence, the
> >=C2=A0 =C2=A0 BSID SHOULD NOT be used as an identification of an S= R Policy.
> >
> > Is there any guidance available on how long to wait with a given = BSID value
> > unused before binding it to a new SR Policy?
> >
>
> KT> None. These depend on the implementation and scenarios like res= ource
> availability e.g., a BSID might get re-used sooner if the system is ru= nning
> short of labels.
>
>
> >
> > Section 6.2.3
> >
> >=C2=A0 =C2=A0 An implementation MAY support the configuration of t= he Specified-
> >=C2=A0 =C2=A0 BSID-only restrictive behavior on the headend for al= l SR Policies or
> >=C2=A0 =C2=A0 individual SR Policies.=C2=A0 Further, this restrict= ive behavior MAY also
> >=C2=A0 =C2=A0 be signaled on a per SR Policy basis to the headend.=
> >
> > Elsewhere in the document we discuss specific potential signaling=
> > mechanisms/protocols, but here we say nothing.=C2=A0 Is that vagu= eness
> > intentional?
> >
>
> KT> Since this isn't a protocol specification the mechanism is = not
> described here. However, you can look at
> = https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-pol= icy-14#section-2.4.2
> and that document refers back to this specification.

Okay, but if this document isn't a protocol specification and that'= s
grounds to not describe mechanism in it, then there are quite a few other places in the document that should also not describe mechanism, if we want<= br> to be applying the rule consistently.

K= T2> There may be very high-level references to some mechanisms in additi= on to the informative pointer to the specific protocol spec. This was done = to improve readability.
=C2=A0

>
> >
> > Section 6.3
> >
> >=C2=A0 =C2=A0 A valid SR Policy installs a BSID-keyed entry in the= forwarding plane
> >=C2=A0 =C2=A0 with the action of steering the packets matching thi= s entry to the
> >=C2=A0 =C2=A0 selected path of the SR Policy.
> >
> > I don't think this is stated properly.=C2=A0 An SR Policy is = the list of
> > segments; it isn't the entity that's installing entries i= n the forwarding
> > plane.=C2=A0 Some other entity is installing an entry in the forw= arding plane to
> > realize the SR Policy in question, and we should make our writing= reflect
> > that.
> >
>
> KT> Ack. s/installs/results in the installation of
>
>
> >
> > Section 6.4
> >
> >=C2=A0 =C2=A0 An implementation MAY choose to associate a Binding = SID with any type
> >=C2=A0 =C2=A0 of interface (e.g. a layer 3 termination of an Optic= al Circuit) or a
> >=C2=A0 =C2=A0 tunnel (e.g.=C2=A0 IP tunnel, GRE tunnel, IP/UDP tun= nel, MPLS RSVP-TE
> >=C2=A0 =C2=A0 tunnel, etc).=C2=A0 This enables the use of other no= n-SR enabled
> >
> > Should we have some discussion that contrasts this scenario again= st the
> > End.X behavior from RFC 8986 (for the "interface" case)= ?
> >
>
> KT> What this document says is that a BSID may be also associated t= o direct
> over these other types of interfaces/tunnels. We can look at them as h= aving
> no other segment being imposed but just redirecting to an interface. I= n
> that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID = in
> SR-MPLS). However, those tend to be associated with protocol adjacenci= es. I
> am not sure that I've followed your point though and please do let= me know
> if I've not.

What you write here indicates to me that you got my point.=C2=A0 My proposa= l was
for a sentence something like "this behavior is analogous to the End.X=
behavior defined in [RFC8986] in that the SID is removed, no new SIDs
applied, and the packet is directed across a particular interface, but it conceptually fits better as a Binding SID since the SID is bound to a
specific (logical or physical) interface and End.X is typically used with protocol adjacencies rather than interfaces".=C2=A0 But that's jus= t a
suggestion, and if you think it doesn't make sense or doesn't add m= uch
value, please ignore it.

>
> >
> > Section 7
> >
> >=C2=A0 =C2=A0 The SR Policy State is maintained on the headend to = represent the
> >=C2=A0 =C2=A0 state of the policy and its candidate paths.=C2=A0 [= ...]
> >
> > I confess I don't really understand why we need to have the c= urrent,
> > minimal, description of SR Policy State in this document.=C2=A0 W= hat would be
> > lost if we deferred its discussion entirely until there is a more=
> > comprehensive discussion available?
> >
>
> KT> We will add an informational pointer to the SR Policy YANG mode= l. What
> this document calls out is the requirement for reporting the operation= al
> state and provides pointers to other specs where this is being worked = out.
>
>
> >
> >=C2=A0 =C2=A0 The SR Policy state can be reported by the headend n= ode via BGP-LS
> >=C2=A0 =C2=A0 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231]= and
> >=C2=A0 =C2=A0 [I-D.ietf-pce-binding-label-sid].
> >
> > The functionality of draft-ietf-pce-binding-label-sid seems much = more
> > limited than that of draft-ietf-idr-te-lsp-distribution; in parti= cular, the
> > former does not seem to actually report SR Policy state to the he= aded at
> > all; rather, it only concerns itself with BSID association to pat= h, with no
> > information about "active", "not preferred", = etc.
> >
>
> KT> The PCEP work might be spread out over different documents but = we do
> need to cover these requirements. That is one of the objectives of hav= ing
> this document coordinate work across protocol WGs.

It still feels like we're claiming something here that isn't true -= - "can
be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]".=C2=A0 = It seems
like we are really trying to say "... via extensions to PCEP [some of = which
don't exist yet in a form that we're willing to reference]".
=C2=A0
KT2> This document, like some other= s in SPRING, does provide informative references (perhaps still in the WG d= oc stage) for better readability and clarity.=C2=A0


>
> >
> > Section 8.3
> >
> >=C2=A0 =C2=A0 If the SR Policy P is invalid, the BSID B is not in = the forwarding
> >=C2=A0 =C2=A0 plane and hence the packet K is dropped by H.
> >
> > We literally just in the previous section talked about a scenario= where the
> > BSDI is kept in the forwarding plane (but with the action to drop= , so the
> > overall outcome is not changed from what this text describes). > > Nonetheless,
> > it's inaccurate to state that "the BSID B is not in the = forwarding plane"
> > here.
> >
>
> KT> There is a difference between the drop being referred to in 8.2= and
> 8.3. What we have in 8.2 is like a route pointing to null where we may=
> advertise and get packets but will drop it with normal counters associ= ated
> with that specific entry. While 8.3 is like we are dropping because we= have
> no route (ideally we shouldn't have got the packet) and we increme= nt a
> generic lookup failed counter. The use-cases for both are different.
I (think I) understand that the mechanisms are different and both have use<= br> cases.=C2=A0 I just don't think that the specific combination of words = used here
makes a true statement.=C2=A0 There are probably a number of ways to make a= slight
adjustment and come up with a true statement, such as starting it with a caveat as in "When Drop-Upon-Invalid behavior is not in use, for an in= valid
SR Policy P, its BSID B is not in the forwarding plane and hence the packet=
K is dropped by H".

KT2> Thanks= for that suggestion. We've incorporated it.
=C2=A0

>
> >
> > Section 8.4.1
> >
> >=C2=A0 =C2=A0 When a BGP route has multiple Color Extended communi= ties each with a
> >=C2=A0 =C2=A0 valid SR Policy, the BGP process installs the route = on the SR Policy
> >=C2=A0 =C2=A0 giving preference to the color with the highest nume= rical value.
> >
> > Do we want to say anything about this being an arbitrary tiebreak= er (rather
> > than an intentional preference), or is that thought to be implici= tly clear?
> >
>
> KT> It is an intentional preference.

Peeking forward to =C2=A78.8.2, is this also referring to the BGP color rat= her
than the SR Policy color?=C2=A0 If so, please specifically qualify the word=
"color" as being the BGP one.

If not, then I strongly suggest that the introduction of color in =C2=A72.1=
state that the numerical value of the color is used as a preference
mechanism in addition to indicating intent or objective (with the
implication or explicit statement that assignment of color values must be performed in a manner that is compatible with the operator's
preference/policy).

KT2> This docume= nt needs to refer to the "BGP color" as the "Color Extended = Community". Thanks for catching that. This is not done in a few places= and we've fixed that.
=C2=A0

>
> >
> > Section 8.5
> >
> >=C2=A0 =C2=A0 In this section, independent of the a-priori existen= ce of any
> >=C2=A0 =C2=A0 explicit candidate path of the SR policy (C, N), it = is to be noted
> >=C2=A0 =C2=A0 that the BGP process at headend node H triggers the = instantiation of
> >=C2=A0 =C2=A0 a dynamic candidate path for the SR policy (C, N) as= soon as:
> >
> > I strongly suggest providing a more explicit framework of what th= e
> > assumptions and preconditions are for the mechanism described in = this
> > section.=C2=A0 My intuition says that it's a fairly optional = thing that would
> > need to be specifically configured, but trying to wrap that senti= ment into
> > the long bullet point involving "a local policy" seems = like a very
> > confusing
> > way to express the desired behavior.
> >
>
> KT> It is actually a matter of local policy with perhaps some templ= ate and
> configuration to drive this. I believe this should get covered in the = SR
> Policy YANG model at some point in time.
>
>
> >
> > Section 8.6
> >
> >=C2=A0 =C2=A0 o=C2=A0 is configured to instantiate an array of pat= hs to N where the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0entry 0 is the IGP path to N, color C1 = is the first entry and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Color C2 is the second entry.=C2=A0 The= index into the array is called
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0a Forwarding Class (FC).=C2=A0 The inde= x can have values 0 to 7.
> >
> > Why are the only allowed values 0 to 7?=C2=A0 Where does this res= triction arise
> > from?=C2=A0 It is because of some protocol element?
> >
>
> KT> There is text further in the section to indicated that these > ranges/values are implementation-specific. Historically, the 8 values = have
> come from the MPLS EXP bits.

If the ranges/values are implementation-specific, then don't give a
specific range here stated as if it is a universal limitation!=C2=A0 I woul= d
either drop the sentence entirely or say something like "when the inde= x is
conveyed using the MPLS EXP bits, only indices 0 to 7 are usable".
=

KT2> Ack. Have clarified.
=C2= =A0

>
> >
> >=C2=A0 =C2=A0 If the local configuration does not specify any expl= icit forwarding
> >=C2=A0 =C2=A0 information for an entry of the array, then this ent= ry is filled with
> >=C2=A0 =C2=A0 the same information as entry 0 (i.e. the IGP shorte= st path).
> >
> >=C2=A0 =C2=A0 If the SR Policy mapped to an entry of the array bec= omes invalid,
> >=C2=A0 =C2=A0 then this entry is filled with the same information = as entry 0.=C2=A0 When
> >=C2=A0 =C2=A0 all the array entries have the same information as e= ntry0, the
> >=C2=A0 =C2=A0 forwarding entry for N is updated to bypass the arra= y and point
> >=C2=A0 =C2=A0 directly to its outgoing interface and next-hop.
> >
> > I can't tell how much of this is supposed to be protocol spec= ification and
> > how much an illustrative example.=C2=A0 Is A(0) always the IGP sh= ortest path?
> > Are these protocol requirements to fall back to the IGP shortest = path when
> > an entry is otherwise unpopulated or the associated SR Policy bec= omes
> > invalid?
> >
>
> KT> The specifics are for illustration purposes. Most of these are = policy
> knobs/options.

Please add a note at the top of the section that "this section provide= s an
example of how a headend might apply per-flow steering in practice".

KT2> Ack. Added.
=C2=A0

>
> >
> > Section 8.8.2
> >
> >=C2=A0 =C2=A0 The steering preference is first based on the highes= t color value and
> >=C2=A0 =C2=A0 then CO-dependent for the color.=C2=A0 [...]
> >
> > This seems to contradict what I assumed earlier about the "h= ighest color"
> > rule being a tiebreaker, e.g., the word "preference" is= used here.=C2=A0 Is it
> > actually intended to be a deliberately configured priority/prefer= ence
> > scheme?=C2=A0 If so, that would seem to require some wide-ranging= reworking
> > throughout the document.
> >
>
> KT> There is the color that is in the identification of an SR Polic= y -
> (color, endpoint). This does not get into any tiebreaker or selection<= br> > logic. All that (sec 2.9) is about the selection of a candidate path w= ithin
> an SR Policy. Then there is the color value signaled via the Color Ext= ended
> community on the BGP routes and here, we have the preference for highe= r
> color when the route is advertised with multiple colors tagged to it.<= br>
I think you should clarify that this section refers to the BGP Color, then<= br> -- previously in the document it has been the SR Policy color value and an<= br> unqualified reference to "color value" seems like it refers to th= e concept
defined in this document, absent other qualifiers.
KT2> Ack. Fixed references as mentioned in a previous commen= t.
=C2=A0

>
> >
> > Section 9.3
> >
> >=C2=A0 =C2=A0 the most appropriate alternative for the active cand= idate path.=C2=A0 A
> >=C2=A0 =C2=A0 fast re-route mechanism MAY then be used to trigger = sub 50msec
> >=C2=A0 =C2=A0 switchover from the active to the backup candidate p= ath in the
> >=C2=A0 =C2=A0 forwarding plane.=C2=A0 Mechanisms like Bidirectiona= l Forwarding Detection
> >=C2=A0 =C2=A0 (BFD) MAY be used for fast detection of such failure= s.
> >
> > Why is the specific 50msec value important here?=C2=A0 Is there s= ome other
> > requirement that imposes it?
> >
>
> KT> This comes from "typical" expectations from fast-rero= ute mechanisms.

I'd consider '''to trigger "fast" (sub 50msec) sw= itchover''', then, but
it's not very important.

>
> >
> > Section 10
> >
> > I think we also want to mention the security considerations of se= veral more
> > documents, including (but not limited to)
> > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and= 8986.
> >
>
> KT> Ack on the three RFCs, but convinced about the
> draft-ietf-idr-segment-routing-te-policy since that depends on this an= d not
> the other way around.

I think this relates to John's Discuss point and whether this document<= br> specifies the protocol behavior of the two bits in the context of the
extension defined in draft-ietf-idr-segment-routing-te-policy.=C2=A0 You ne= ed to
understand draft-ietf-idr-segment-routing-te-policy in order to understand<= br> the security considerations relating to the protocol behavior controlled by=
those two bits, and IMO the protocol behavior specified by those two bits is solely the responsibility of this document, so this document must
incorporate the security considerations of
draft-ietf-idr-segment-routing-te-policy in order to fully document the
security considerations of the concepts and protocol elements that this
document defines.

KT2> I am working = with John to address his comments.

Thanks,
Ketan
=C2=A0

Thanks for this, and all the other parts I didn't specifically reply to= .

I will attempt to update my ballot position in the datatracker to remove the parts that are fully addressed (though I will probably inadvertently leave in something I shouldn't have).

-Ben

>
> >
> > Section 15.2
> >
> > I agree with John that draft-ietf-idr-segment-routing-te-policy m= ust be
> > classified as a normative reference.
> >
> > It also seems that RFC 7752 should be classified as normative, as= we
> > incorporate its definition for the semantics of several of the se= gment type
> > descriptions.
> >
>
> KT> Ack
>
>
> >
> >
> > NITS
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 Segment Routing Policy (SR Policy) [RFC8402] is an o= rdered list of
> >=C2=A0 =C2=A0 segments (i.e. instructions) that represent a source= -routed policy.
> >
> > /Segment/A Segment/
> >
>
> KT> Ack
>
>
> >
> >=C2=A0 =C2=A0 The headend node is said to steer a flow into a SR P= olicy.=C2=A0 The
> >=C2=A0 =C2=A0 packets steered into an SR Policy carry an ordered l= ist of segments
> >=C2=A0 =C2=A0 associated with that SR Policy.=C2=A0 [...]
> >
> > In a certain sense this can be read as saying that the packets th= at "carry
> > an ordered list of segments" are the ones prior to being ste= ered into an SR
> > policy, which would make this statement not true.=C2=A0 Perhaps w= e want to say
> > "after being steered into an SR Policy, packets carry an ord= ered list ..."?
> > (I also went back and forth with myself about whether "packe= ts ... carry"
> > implies in the payload or not.=C2=A0 I settled on "not"= but make this note just
> > in case I am missing an aspect of that question.)
> >
>
> KT> Ack. Will rephrase.
>
>
> >
> > Section 2
> >
> >=C2=A0 =C2=A0 An SR Policy is a framework that enables the instant= iation of an
> >=C2=A0 =C2=A0 ordered list of segments on a node for implementing = a source routing
> >
> > It's easy to read this as saying that all of the segments in = the list
> > instantiated on the single node in question, which I assume is no= t the
> > intent.=C2=A0 Probably the easiest way to aid readability here is= to split the
> > sentence up into multiple smaller sentences that are easier to pa= rse.
> >
>
> KT> Will rephrase.
>
>
> >
> > Section 2.2
> >
> >=C2=A0 =C2=A0 A dynamic candidate path expresses an optimization o= bjective and a
> >=C2=A0 =C2=A0 set of constraints.=C2=A0 The headend (potentially w= ith the help of a PCE)
> >=C2=A0 =C2=A0 computes the solution Segment-List (or set of Segmen= t-Lists) that
> >=C2=A0 =C2=A0 solves the optimization problem.
> >
> > I'd suggest computes the solution/computes a solution/ for ge= nericity.
> >
>
> KT> Ack.
>
>
> > A stateful PCE might end up computing a path that is not the opti= mal one
> > for
> > this specific optimization problem, due to a desire to cooperate = with other
> > paths in the network, and the "Min-Metric with margin and ma= ximum number of
> > SIDs" objective in draft-filsfils-spring-sr-policy-considera= tions doesn't
> > even have a guaranteed unique best solution.
> >
> > Section 2.5
> >
> >=C2=A0 =C2=A0 When provisioning is via configuration, this is an i= mplementation's
> >=C2=A0 =C2=A0 configuration model-specific unique identifier for a= candidate path.
> >=C2=A0 =C2=A0 The default value is 0.
> >
> > I'm having a lot of trouble parsing this.=C2=A0 Did we perhap= s mean to hyphenate
> > as "configuration-model-specific"?
> >
>
> KT> Ack
>
>
> >
> > Section 2.13
> >
> >=C2=A0 =C2=A0 The SR Policy POL1 is identified by the tuple <he= adend, color,
> >=C2=A0 =C2=A0 endpoint>.=C2=A0 It has two candidate paths CP1 a= nd CP2.=C2=A0 Each is
> >=C2=A0 =C2=A0 identified by a tuple <protocol-origin, originato= r, discriminator>.
> >
> > I suggest (for the last sentence) "identified within the sco= pe of POL1"
> >
>
> KT> Ack
>
>
> >
> >=C2=A0 =C2=A0 forwarding instantiation of SR policy POL1.=C2=A0 Tr= affic steered on POL1
> >=C2=A0 =C2=A0 is flow-based hashed on Segment-List <SID11...SID= 1i> with a ratio
> >=C2=A0 =C2=A0 W1/(W1+W2).
> >
> > If I read "ratio" I would instinctively think of the ra= tio of (traffic on
> > segment list 1)/(traffic on segment list 2), as opposed to the pr= oportion
> > of
> > all traffic, that would be measured as the indicated W1/(W1+W2).<= br> > >
>
> KT> Ack. s/ratio/proportion
>
>
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 The attached domain topology may be learned via IGP,= BGP-LS or
> >=C2=A0 =C2=A0 NETCONF.
> >
> >=C2=A0 =C2=A0 A non-attached (remote) domain topology may be learn= ed via BGP-LS or
> >=C2=A0 =C2=A0 NETCONF.
> >
> > I think these are both probably not exhaustive lists, so "e.= g." or similar
> > may be appropriate.
> >
>
> KT> Ack.
>
>
> >
> > Section 4
> >
> >=C2=A0 =C2=A0 Type C: IPv4 Prefix with optional SR Algorithm:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The headend is required to reso= lve the specified IPv4 Prefix
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address to the SR-MPLS label co= rresponding to a Prefix SID
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segment (as defined in [RFC8402= ]).=C2=A0 The SR algorithm (refer to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 3.1.1 of [RFC8402]) to = be used MAY also be provided.
> >
> >=C2=A0 =C2=A0 Type D: IPv6 Global Prefix with optional SR Algorith= m for SR-MPLS:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In this case, the headend is re= quired to resolve the specified
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Global Prefix Address to t= he SR-MPLS label corresponding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to its Prefix SID segment (as d= efined in [RFC8402]).=C2=A0 The SR
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Algorithm (refer to Section 3.1= .1 of [RFC8402]) to be used MAY
> >
> > These are effectively just the IPv4 and IPv6 incarnations of the = same
> > underlying procedure, right?=C2=A0 Can't we minimize the diff= between the
> > paragraphs further?
> >
>
> KT> Ack
>
>
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 Additionally, a Segment-List MAY be declared invalid= when:
> >
> > We probably want another word here ("both"?), to specif= y how the two
> > conditions are combined.
> >
>
> KT> Ack - will rephrase.
>
>
> >
> > Section 5.2
> >
> >=C2=A0 =C2=A0 When the local computation is not possible (e.g., a = policy's tail-end
> >=C2=A0 =C2=A0 is outside the topology known to the headend) or not= desired, the
> >=C2=A0 =C2=A0 headend MAY send path computation request to a PCE s= upporting PCEP
> >=C2=A0 =C2=A0 extension specified in [RFC8664].
> >
> > missing article ("the PCEP extension").=C2=A0 I forget = if it should be
> > "extensions" plural.
> >
>
> KT> Ack
>
>
> >
> > Section 8.7
> >
> >=C2=A0 =C2=A0 Finally, headend H MAY be configured with a local ro= uting policy
> >=C2=A0 =C2=A0 which overrides any BGP/IGP path and steer a specifi= ed packet on an
> >
> > singular/plural mismatch -- s/steer/steers/
> >
>
> KT> Ack.
>
> Thanks,
> Ketan

--0000000000005d2db605d97636a9-- From nobody Sat Mar 5 23:46:58 2022 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 9ECA43A00DF; Sat, 5 Mar 2022 23:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 KRGWRLG_MVW4; Sat, 5 Mar 2022 23:46:17 -0800 (PST) Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (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 560343A03F5; Sat, 5 Mar 2022 23:46:15 -0800 (PST) Received: by mail.swisscom.com; Sun, 6 Mar 2022 08:46:13 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_5415651_878339106.1646552772811" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gg17HbBpcgHg7CEcNeJZaZm1SFRcPJbf13ilJucE3aHnMQCipnFFlB+jCjZnHPNx5GEkCKuWo82YDDfdcoTZHv/rWNMuURYN199KOnuAHt2VZvCPMTPIppvce5W7bMZZib08C9u0NwBaMhKp1Js/bPUhfODBNs3H9sb+FokjWTo65l7wljMYPuH9Dca0qgJFIjF9cKEI1pDxVMy4Than5kZYUlMyhrXZ3LFhHmtpilhlQULj1yTqY6tgjp5gfNVXt2PAB6xaa655d15n6MN9iKZmGkNROiJ+QCMhwGONJ8on0nCa0kYWutYg3g+b563w6Q8PWd5M9tSA4jiy0lC3Hw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gUbrzpEkAM2uwWvq6ZieB3TEksUARVBarcbi41NqadU=; b=bWpfv0ApxODUrNlkV2c6haetA9lzqodFotXXHYKSBbx8mfUhBSiYC9rT06nW9NCHSEqmuHZ1DaQ16mptLslnrBZmOYAG2KB8ojt4XzPOIuq3HXV0q8QE/7EhHT6iw8YjiAgYH6pYceOumKuudLmF+vYwq/XutshJGC9i3pOQExRidTxuU461SZ/tjhuZD/rSQJKOg93ASqo8ZFnzxomOWvOUwd6dShabWeYjLk1oo50xSgHk+S3sOC3Uo5OOo+OnY7fCIam+GAtMJTJw/V+zxPi5O8wE4FPQH++hgyOUZhhmsHnH8JyXoyk+nkdMcop2/s3MW8IutULtxjvLJzCOZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , Thread-Topic: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-02.txt Thread-Index: AQHYMSy364GMZj6QJU2LfxMuF870Iqyx9z2Q Date: Sun, 6 Mar 2022 07:46:09 +0000 Message-ID: References: <164655210645.9671.6215224488696350140@ietfa.amsl.com> In-Reply-To: <164655210645.9671.6215224488696350140@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=true; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2022-03-06T07:46:10Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=ca45ac0e-d5ae-4e4c-bb6c-6618b3aad25f; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1685b432-e4f6-4101-70a3-08d9ff4560fa x-ms-traffictypediagnostic: GV0P278MB0702:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mVxWLCRBqx45kEi/Dxm7kpSqtuc8xZ45fzKb9Izf9GippZpiovuLo997mdFrl2fMgLQUObKJwsQHH9Q5IC40YPqvHSDaaM5icON2weZa2LfXplgBdSbzHI615u1zowPOVUuz0JBxh8Ox1KZb60ncnqmD/0rzWWBwOkJP8gxdCu/+uqRmq19wQpNIOBkn3YL1O+7t5b9+sVZb3zRnln0i0fyJtJWS+eUPhQVChfI3pUumb2uEX0PPGGiLGFhJqn9BGzVfIg9h6k0eGb5TXbBkcEeAFvcCAP0JYBaOoFoxuYRCJIW8SZECCaGcHw7JiDWPx5xPMg4lYxxZsc5sixPkPV/exaUECk77sKUBjoM61EpUum8MyhrNJe8rrE3JerwyO8zQrn8LVJv03HSGrgpU+rtbTkA3lUh3MJ/LmBCCbKHLdYjHNqxx6kCjUMAT+GP9t3sEy4y8aM+Q3DUxq2Y/zm3NPOOtlOEQR2PWVHitRWzMy7TvuVlgPDTwLsKk3M4+CcAlc/90CDfpshHBV7GNgrVcvKdWzQTcTj9wja5/Uyv4oSpskcIfeSdI+GA0vOI7aFakcOKGPqBEMZTzOXJY5fuVaXXjEVu+d0xn3V3HW0wePZ77ZbLbjth6c25TVv8s7XeOacZf5qrxh8kEhJ/cSeirrw8gAIwUXIk6ce11TuqWqgOgQhjVJAsc+Qv00ZrUZCBL/DfoBL3nCSs+GnpdC2WL0yGIMg6XWsU1/Qh1uh37vmZn65uAqCNxKZ3O/c1iRkIvq8JKrxm78S48LokGoZftJB1br6ZLjiHpAXx9Ffk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(82960400001)(122000001)(55016003)(64756008)(10290500003)(508600001)(186003)(66446008)(26005)(8676002)(66476007)(66556008)(66946007)(450100002)(76116006)(86362001)(71200400001)(15650500001)(66574015)(9686003)(52536014)(83380400001)(7696005)(6506007)(38070700005)(5660300002)(10300500001)(19627235002)(110136005)(316002)(33656002)(38100700002)(53546011)(966005)(2906002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/zhBmeVslFMJnb1LdfrLUG8KiO4VO5AQVOmSocyv4nZJveFDOAroHqtbFskq?= =?us-ascii?Q?xkKJMitE3wzm0WBIgQKlpemypEhjIlcXKD4W9kixLvduaHFKSQs1vHiS2BKE?= =?us-ascii?Q?V3OraSaKO8VxpvDWzS6XYI8eqzhd4rzlMA1Fvyf1OHY468Fh4sw1bCQRZyFY?= =?us-ascii?Q?MPsfKWyjlJJ3xssULz8Rq/GiO5jRb3QBFCXGYFXRDq76N1A9lCJfyyK5upD/?= =?us-ascii?Q?Oa38zkdb/ARNhylQQ5S4UJCFm9HYk++cx4U4tz7kMWHDM+Dwkj2OKflEFeAC?= =?us-ascii?Q?h4o0IhjI/kXfqKRZQTeFTdXAPyG2TidQTRVAIpNGanlvDvgKes/4GeYuDfPE?= =?us-ascii?Q?Za7b6uFSwG9pEdIWin7zlwbEwdTZs2eXHcV8/ZHXIfZWa0jpdbUBcBJw+onU?= =?us-ascii?Q?leOX4d0N79H+zeJ7vp9fz14XZZqY+dPs8ge56nSwNg3q30HqVyYTPBnyApnh?= =?us-ascii?Q?svnbO5SbVaS7RZynbJAHI7tbbh7ZQDCBuchXxeTwWFlh08bp3etyn28m9s1F?= =?us-ascii?Q?YTWwShPs3B/WM3OqBXhUkLPzKQr3X4Ukkzr8NaYHxfI+sPUcNxO0rZkH6dmX?= =?us-ascii?Q?fabGhhR8czEWtR5YJkAnuFUZoT9GLMv7SW2L8sXPph1M6dP8QVrE0a+aYjug?= =?us-ascii?Q?2rnP7CD3z5PH2/07FInKBg6sSGXHbNCrlQB2Swuj7NuosFgMECE6T1HLRVhd?= =?us-ascii?Q?CfyhX4+5FlEy3yeK/NR3ATzypbN4GTJSjvgIXR/0ku8RAsAoG5smV46udG4K?= =?us-ascii?Q?daFsvOzkHuL+Ag0YsusbpZ2pqF7xLkL1i0tX88KL08rjiqrDuewRRmbnWkkf?= =?us-ascii?Q?OVGq6zBbJHxfmmXJseJ/Mlms1/VuPtaG3d2ar1jQmXIUxjUw3EhSfJdhJBo5?= =?us-ascii?Q?SRN3j/gCVwlBWhi9ON6hLUI225UcfrHDQKCaYKPsVC0MzUhi5JriQDhQl3jb?= =?us-ascii?Q?i1MJ2m3o9mWbzS5/2g55pLYF2Wm59U4/lx7M9yEojgW4tcoMiVj6e65zwxWS?= =?us-ascii?Q?N6VO6LtZVNNnCD9pb7KEkycvuYU/6oPirgD5Oq9Eq82lLVvZCoLAH6G/47PW?= =?us-ascii?Q?tC4GxLOMqBrJ7MjCxpHxpVbvLue7sOHLryPOwqlAEy3ahWOJog4PSLcCWBDI?= =?us-ascii?Q?oB7VqVXMzI0w2FhnNb6EaiYy8OkTCjWxCvLoPFgSiphOsA8F1cy2YE2k1wbG?= =?us-ascii?Q?3cMaSNXF6szRUMjTPtPmCDMmEKT64GyiuQw8hbNZdh4ppLsbwf6DCLA15GxV?= =?us-ascii?Q?/XH0FS4kfDE/L24OgPSwpnvXIIQY5nA1H4dKRTlP6JNw+mw34W//08mtD9Jr?= =?us-ascii?Q?fUFCiH/b6zJdobWsDQ/0M6KCs/GPQonCQIk1sXrntGt4pmmAhCdyslZqvPeQ?= =?us-ascii?Q?yPvt5S29p0FhoCijHyany9pItIWR7Kumu2+kebzVW5w9qhubH440yg0Hm7EG?= =?us-ascii?Q?aghOKhe3pweGvSu1yvHqQucXLHxjHivwd6BrHGFJWPVNJc0YoFVrG1Zrywc9?= =?us-ascii?Q?o4w9C8619zybEv+mJa06EM7KK1jvcC/kOuFZnGms1crFVLeXe17EObcwW+iZ?= =?us-ascii?Q?vSYZfYKdTxAi+Kn8+cc/2FthQ7hPCOuyXhD9pqUOUiuXn32zca/NLNMylUoj?= =?us-ascii?Q?nhmF4ZQo4s0ViC0iKhnHLB5WqgWIvvqGxWx4FIrUap3ZQb6+hXvPJgMQlIEt?= =?us-ascii?Q?WFee9w=3D=3D?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1685b432-e4f6-4101-70a3-08d9ff4560fa X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2022 07:46:09.3550 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OaCUY6pbkPC3BDI0RTYH1Ocdk4g24C0ak+7eaSupGiblhQ2V0aeJorUq3fSdFb//klsJEyzvAXU6Ks7DAxERx4D2kLzqNGh3bT/v/jtVkko= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV0P278MB0702 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Mailer: Totemo_TrustMail_(Notification) X-Trustmail: processed Archived-At: Subject: [spring] FW: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-02.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: Sun, 06 Mar 2022 07:46:22 -0000 ------=_Part_5415651_878339106.1646552772811 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear OPSAWG and SPRING working group, Based on the feedbacks I received, I updated the document.=20 Apart from the small editorial changes, the following points have been addr= essed - updated IANA sections according to RFC 8126 - added ipv6SRHSegmentListSection to facilitate immediate export without da= ta flow manipulation - added Operational Considerations section to described differences between= ipv6SRHSegmentBasicList and ipv6SRHSegmentListSection Looking forward for further reviews and comments. Based wishes Thomas -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Sunday, March 6, 2022 8:35 AM To: Benoit Claise ; Graf Thomas, INI-NET-TCZ-ZH1 = Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-02.= txt A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-02.txt has been successfully submitted by Thomas Graf and posted to the IETF repos= itory. Name:=09=09draft-tgraf-opsawg-ipfix-srv6-srh Revision:=0902 Title:=09=09Export of Segment Routing IPv6 Information in IP Flow Informati= on Export (IPFIX) Document date:=092022-03-06 Group:=09=09Individual Submission Pages:=09=0912 URL: https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-sr= v6-srh-02.txt Status: https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-s= rv6-srh/ Htmlized: https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ip= fix-srv6-srh Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tgraf-opsawg-ipfi= x-srv6-srh-02 Abstract: This document introduces new IP Flow Information Export (IPFIX) information elements to identify the SRv6 Segment Routing Header dimensions and SRv6 Control Plane Protocol that traffic is being forwarded with. = =20 The IETF Secretariat ------=_Part_5415651_878339106.1646552772811 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMzA2MDc0NjEyWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCCxJjFP gpjdZfx3tjTn8PS1xQRDWhBDPWTsWGZ2XTrh1DB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQBWNChcz+DHpbXfLQGMZyn9woQ2 uoQd3rlksmS0s4LyaQV6ULcKeDRRL7otZQFPNGrYEjpfdY2xLqS7nTM79ZCOUr6O2G0fqX9+tH8u 7P86qIKiUH/svi1NIST0GeEp830+wJDtrgasTvejOrSoOAopV7yfPCX35+Mt1looOMjCuUgRwJZ7 upT82WPxJv22emvmIr56YqDugkVuBqWKAeJSoATIlrD+YuV+FdEfuTJsCooiNc3IHFn9N9zsDOCV 6SApPp5l529lKJR3x9yIOOmGRVKV5a+od5CdrH9+3kiCjZG0Y6Hhw+da1Go21n6iP3yshjvGIdFw J42cBe2YwvC1AAAAAAAA ------=_Part_5415651_878339106.1646552772811-- From nobody Sat Mar 5 23:52:38 2022 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 9978D3A0113; Sat, 5 Mar 2022 23:51:45 -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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164655310553.30884.3982379764531321689@ietfa.amsl.com> Date: Sat, 05 Mar 2022 23:51:45 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-resource-aware-segments-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: Sun, 06 Mar 2022 07:51:46 -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 : Introducing Resource Awareness to SR Segments Authors : Jie Dong Stewart Bryant Takuya Miyasaka Yongqing Zhu Fengwei Qin Zhenqiang Li Francois Clad Filename : draft-ietf-spring-resource-aware-segments-04.txt Pages : 13 Date : 2022-03-05 Abstract: This document describes the mechanism to associate network resource attributes to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource- aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resource-aware-segments-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Mar 5 23:55:25 2022 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 9C9D13A0317; Sat, 5 Mar 2022 23:55:23 -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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164655332358.23079.12600527370313643770@ietfa.amsl.com> Date: Sat, 05 Mar 2022 23:55:23 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-for-enhanced-vpn-02.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: Sun, 06 Mar 2022 07:55:24 -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 : Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN Authors : Jie Dong Stewart Bryant Takuya Miyasaka Yongqing Zhu Fengwei Qin Zhenqiang Li Francois Clad Filename : draft-ietf-spring-sr-for-enhanced-vpn-02.txt Pages : 19 Date : 2022-03-05 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, a group of resource-aware SIDs may be used to build SR based virtual underlay networks, which have customized network topology and resource attributes required by one or a group of customers and/or services. Such virtual networks are the SR instantiations of Virtual Transport Networks (VTNs). This document describes a suggested use of resource-aware SIDs to build SR based VTNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-for-enhanced-vpn/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-for-enhanced-vpn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-for-enhanced-vpn-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Mar 6 22:04:19 2022 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 DA6E53A0E21; Sun, 6 Mar 2022 22:04: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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164663304884.10203.13743329832098894250@ietfa.amsl.com> Date: Sun, 06 Mar 2022 22:04:08 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-20.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: Mon, 07 Mar 2022 06:04:10 -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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-20.txt Pages : 40 Date : 2022-03-06 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into a SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC8402 as it details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-20 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Mar 6 22:21:34 2022 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 71BBA3A0FAF; Sun, 6 Mar 2022 22:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 Isaw6Br4Y_ns; Sun, 6 Mar 2022 22:20:45 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 69DE13A0E7E; Sun, 6 Mar 2022 22:20:45 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id g21so15501628vsp.6; Sun, 06 Mar 2022 22:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/wXBDUZBsGysc3GBXGNq8oEmTGzH7QVmxFKPLqwypwQ=; b=lYvE1hXa7ytGdOAcV3pubWJRs8e44T8RJr9UY0jC5YclH3tst09HhKoLjF56qReLUG SFvBO+XqutvgDB2mkLNCy+WTULFJau8oliJlGAtGCkWD9V+lNwgfniX3vkp8+r3GvS81 J2QWqdrh0pRfB8iWx7Y01tkpg2PvkhGOAYZGMqhhuo3T+wrFjY8KmgVihwzTNzR1/hxO eChwiqxhvZTQJdCbO5UFavp4JNlCoA1GfxDpvdXgTBZmmtyUCH0T/yih+n3YDm3R3NYn r83MLZMAjEgPOvPQx7tvSEbpAqSo8JJtfSrPhI3mgede8wok8/vprSRyK0timdV5SnmL DVwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/wXBDUZBsGysc3GBXGNq8oEmTGzH7QVmxFKPLqwypwQ=; b=RI4cytFj6Q65DIiYf6iR6CgcQKaCBukvu63QmVubZxl+M8Wy+I2E/CskpufLPAEzXI 6sYACK+GOZRmwyhMM/V5TxVqwtut3ihnV/STa2o3mNCXUn+gDNxahHg5cUw8x3sM9mxV fbEjlSu6+WC20eUNCAyAibKfO05Zqcd3rEgAdiemhP9EbFWTOXmkUVqulkzr8sXy2/Eo msw7YPAwzD0qFmyLTnKbjOViUnSucNAys4Xd48yD7QBInVm9gq4sEn0ez4VVqQZRf6f9 5AuO0ih/CXOlUhhnbtGhIlvon6PqyOCtHdMUTPCIFF1tE4I03wvMfZa/e4BNdWjN0N73 0/YA== X-Gm-Message-State: AOAM530/PCo9nuoBTx6Zppi2mI81xibIQIA5zSQJAHjYt6jEcjHkJozw 0YVAMeVv4ga+vDPeItPyf4DsOvgWz7er7f/tn9LxQxmWy40= X-Google-Smtp-Source: ABdhPJz0TlJu2zVr2X3fj/MMnD4KDCA3DRjIp679wnpWrBwfR/i6Zbq8h76PbZ7AISRUFN3L/JM+Nm8s8f2kzt5Ro9Y= X-Received: by 2002:a05:6102:3583:b0:320:b8d1:cf9f with SMTP id h3-20020a056102358300b00320b8d1cf9fmr1235771vsu.34.1646634043480; Sun, 06 Mar 2022 22:20:43 -0800 (PST) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Mon, 7 Mar 2022 11:50:32 +0530 Message-ID: To: John Scudder Cc: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="0000000000003c9e8f05d99add8e" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 07 Mar 2022 06:21:08 -0000 --0000000000003c9e8f05d99add8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, We've just posted an update to the draft for the Color-Only steering modes and the allocation of bits from the BGP Color Extended community. https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-20 This is along the lines of your suggestions and the ongoing discussions on the IDR list for the draft-ietf-idr-segment-routing-te-policy : https://mailarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fFh5F9wlQA/ Looking forward to your response on your discuss & comments on this document. Please let know of any outstanding discuss or comments that remain to be addressed in the document. Thanks, Ketan On Thu, Feb 17, 2022 at 1:12 AM John Scudder wrote: > Hi Ketan, > > > On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar > wrote: > > > > Hi John, > > > > Thanks for your review and please check inline below for responses. > > Thanks for your reply. For this response I=E2=80=99m confining myself to = points 3 > and 4. > > [snip] > > > 3. Related to the above, at least one of the references listed as > informational > > clearly has to be normative with the document as it stands. > > draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinkin= g of, for > > example its use in =C2=A72.4 seems like it may rise to the "normative" = level, > =C2=A72.5 > > almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icing= on the cake > > because this document defines semantics for a field that isn=E2=80=99t = even > allocated > > until and unless draft-ietf-idr-segment-routing-te-policy is published. > > > > KT> It is the other way round. The SPRING document specifies the > information model and the constructs of the SR Policy. The IDR document i= s > primarily about signaling of the SR Policy from a controller to the heade= nd > using the new SR Policy SAFI (73) - as such it does refer normatively to > the SPRING SR Policy. > > Without getting too far into the details on this one, you just can=E2=80= =99t write > a spec about a field (or set of flags) that doesn=E2=80=99t (don=E2=80=99= t) exist. The way > you=E2=80=99ve structured these two documents, that field (I will call it= a field) > doesn=E2=80=99t formally exist until and unless > draft-ietf-idr-segment-routing-te-policy is published. Therefore, > draft-ietf-spring-segment-routing-policy has a hard dependency on it, and > this is one thing that makes a reference =E2=80=9Cnormative=E2=80=9D. The= se would hardly be > the first two documents to normatively reference one another, it=E2=80=99= s what the > RFC Editor uses clusters for (amongst other things). > > You could also resolve this particular issue by restructuring the > documents to make them more self-contained. If you do, then perhaps we > would need to revisit the other references to > draft-ietf-idr-segment-routing-te-policy in more detail =E2=80=94 but unt= il then it > wouldn=E2=80=99t be time well spent, as the =C2=A78.8.1 reference is suff= icient to > cement the requirement. > > > 4. In =C2=A72.1 you talk about the signaling of symbolic names for cand= idate > paths. > > Although you are careful to say that such symbolic names are only used > for > > presentation purposes, it seems to me they still could be considered a > new > > potential source of vulnerability, since a string that has no > sanity-checking > > whatsoever applied by the protocol can display literally anything to an > > operator viewing it. Shouldn=E2=80=99t this be addressed in your Securi= ty > > Considerations? (For an example of a related Security Considerations, > see RFC > > 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the = one I had at my > > fingertips=E2=80=A6) > > > > KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As > such, I am not aware of security issues around printable ASCII - please d= o > point me to any references. > > You=E2=80=99re thinking too much like a protocol designer. The kind of co= ncern I=E2=80=99m > thinking about has to do with using the string as a vector to put some > words in front of an operator, as part of a larger social engineering > attempt. I don=E2=80=99t have a detailed attack scenario to paint for you= , but a > quick sketch is along the lines of > > - Attacker manages to inject a candidate path with the name > =E2=80=9CBig_Bank_Low_Latency=E2=80=9D > - ProTip: the candidate path does not actually terminate at > Big_Bank > - Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_Bank > traffic onto that path > > You get the idea, I hope. > > > Also note that this document does not specify protocol encodings where > some extra verbiage is normally required (e.g. that it is signaled withou= t > NULL, handling truncation/overruns, etc.). > > But yet it does specify the precise character set to be used, and a > near-obsolescent one at that. Why is that? I mean, I don=E2=80=99t hate A= SCII, but > I just find it odd and assume you actually have a reason for it, instead = of > taking either the option of leaving the character set unspecified (as you > point out there are many such details you don=E2=80=99t concern yourself = with in > this document) or if specifying it, using UTF-8 or similar. > > > KT> As discussed in the WG, we are sticking to printable ASCII. When th= e > encoding is specified to be printable ASCII, it is expected that > implementations valid that. > > I admire your optimism. > > =E2=80=94John --0000000000003c9e8f05d99add8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

We've just posted an updat= e to the draft for the Color-Only steering modes and the allocation of bits= from the BGP Color Extended community.


=
This is along the lines of your suggestions and the ongoing disc= ussions on the IDR list for the draft-ietf-idr-segment-routing-te-policy := =C2=A0https://mailarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fF= h5F9wlQA/=C2=A0

Looking forward to your respon= se on your discuss=C2=A0& comments on this document. Please let know of= any outstanding discuss or comments that remain to be addressed in the doc= ument.

Thanks,
Ketan


On Thu, Feb 17, 2022 at 1:12 AM John Scudder <jgs@juniper.net> wrote:
Hi Ketan,

> On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:=
>
> Hi John,
>
> Thanks for your review and please check inline below for responses.
Thanks for your reply. For this response I=E2=80=99m confining myself to po= ints 3 and 4.

[snip]

> 3. Related to the above, at least one of the references listed as info= rmational
> clearly has to be normative with the document as it stands.
> draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinki= ng of, for
> example its use in =C2=A72.4 seems like it may rise to the "norma= tive" level, =C2=A72.5
> almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icin= g on the cake
> because this document defines semantics for a field that isn=E2=80=99t= even allocated
> until and unless draft-ietf-idr-segment-routing-te-policy is published= .
>
> KT> It is the other way round. The SPRING document specifies the in= formation model and the constructs of the SR Policy. The IDR document is pr= imarily about signaling of the SR Policy from a controller to the headend u= sing the new SR Policy SAFI (73) - as such it does refer normatively to the= SPRING SR Policy.

Without getting too far into the details on this one, you just can=E2=80=99= t write a spec about a field (or set of flags) that doesn=E2=80=99t (don=E2= =80=99t) exist. The way you=E2=80=99ve structured these two documents, that= field (I will call it a field) doesn=E2=80=99t formally exist until and un= less draft-ietf-idr-segment-routing-te-policy is published. Therefore, draf= t-ietf-spring-segment-routing-policy has a hard dependency on it, and this = is one thing that makes a reference =E2=80=9Cnormative=E2=80=9D. These woul= d hardly be the first two documents to normatively reference one another, i= t=E2=80=99s what the RFC Editor uses clusters for (amongst other things).
You could also resolve this particular issue by restructuring the documents= to make them more self-contained. If you do, then perhaps we would need to= revisit the other references to draft-ietf-idr-segment-routing-te-policy i= n more detail =E2=80=94 but until then it wouldn=E2=80=99t be time well spe= nt, as the =C2=A78.8.1 reference is sufficient to cement the requirement.
> 4. In =C2=A72.1 you talk about the signaling of symbolic names for can= didate paths.
> Although you are careful to say that such symbolic names are only used= for
> presentation purposes, it seems to me they still could be considered a= new
> potential source of vulnerability, since a string that has no sanity-c= hecking
> whatsoever applied by the protocol can display literally anything to a= n
> operator viewing it. Shouldn=E2=80=99t this be addressed in your Secur= ity
> Considerations? (For an example of a related Security Considerations, = see RFC
> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the= one I had at my
> fingertips=E2=80=A6)
>
> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As= such, I am not aware of security issues around printable ASCII - please do= point me to any references.

You=E2=80=99re thinking too much like a protocol designer. The kind of conc= ern I=E2=80=99m thinking about has to do with using the string as a vector = to put some words in front of an operator, as part of a larger social engin= eering attempt. I don=E2=80=99t have a detailed attack scenario to paint fo= r you, but a quick sketch is along the lines of

- Attacker manages to inject a candidate path with the name =E2=80=9CBig_Ba= nk_Low_Latency=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - ProTip: the candidate path does not actually = terminate at Big_Bank
- Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_Bank t= raffic onto that path

You get the idea, I hope.

> Also note that this document does not specify protocol encodings where= some extra verbiage is normally required (e.g. that it is signaled without= NULL, handling truncation/overruns, etc.).

But yet it does specify the precise character set to be used, and a near-ob= solescent one at that. Why is that? I mean, I don=E2=80=99t hate ASCII, but= I just find it odd and assume you actually have a reason for it, instead o= f taking either the option of leaving the character set unspecified (as you= point out there are many such details you don=E2=80=99t concern yourself w= ith in this document) or if specifying it, using UTF-8 or similar.

> KT> As discussed in the WG, we are sticking to printable ASCII. Whe= n the encoding is specified to be printable ASCII, it is expected that impl= ementations valid that.

I admire your optimism.

=E2=80=94John
--0000000000003c9e8f05d99add8e-- From nobody Mon Mar 7 02:37:09 2022 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 9F17D3A0ECB; Mon, 7 Mar 2022 02:36:41 -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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164664940132.3384.11359086248804015226@ietfa.amsl.com> Date: Mon, 07 Mar 2022 02:36:41 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-protection-sr-te-paths-03.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: Mon, 07 Mar 2022 10:36:43 -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 : Segment Protection for SR-TE Paths Authors : Shraddha Hegde Chris Bowers Stephane Litkowski Xiaohu Xu Feng Xu Filename : draft-ietf-spring-segment-protection-sr-te-paths-03.txt Pages : 20 Date : 2022-03-07 Abstract: Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-protection-sr-te-paths/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-protection-sr-te-paths-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-protection-sr-te-paths-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 09:54:29 2022 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 017513A1317; Mon, 7 Mar 2022 09:54:10 -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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164667564995.28976.2073125152512560970@ietfa.amsl.com> Date: Mon, 07 Mar 2022 09:54:09 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-replication-segment-07.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: Mon, 07 Mar 2022 17:54:19 -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 : SR Replication Segment for Multi-point Service Delivery Authors : Daniel Voyer (editor) Clarence Filsfils Rishabh Parekh Hooman Bidgoli Zhaohui Zhang Filename : draft-ietf-spring-sr-replication-segment-07.txt Pages : 13 Date : 2022-03-07 Abstract: This document describes the SR Replication segment for Multi-point service delivery. A SR Replication segment allows a packet to be replicated from a Replication Node to downstream nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-replication-segment-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-replication-segment-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 17:58:11 2022 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 227663A0847 for ; Mon, 7 Mar 2022 17:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 LCpj2W29Qg3N for ; Mon, 7 Mar 2022 17:58:06 -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 9375D3A0814 for ; Mon, 7 Mar 2022 17:58:06 -0800 (PST) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KCJPH6Ndnz67PMg for ; Tue, 8 Mar 2022 09:57:39 +0800 (CST) Received: from kwepeml100005.china.huawei.com (7.221.188.221) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Mar 2022 02:58:02 +0100 Received: from kwepeml500002.china.huawei.com (7.221.188.128) by kwepeml100005.china.huawei.com (7.221.188.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Mar 2022 09:58:01 +0800 Received: from kwepeml500002.china.huawei.com ([7.221.188.128]) by kwepeml500002.china.huawei.com ([7.221.188.128]) with mapi id 15.01.2308.021; Tue, 8 Mar 2022 09:58:01 +0800 From: "Xiejingrong (Jingrong)" To: "spring@ietf.org" Thread-Topic: Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) Thread-Index: Adgyj2pEDTIYoRv+Rwm6VOp4IGlK2w== Date: Tue, 8 Mar 2022 01:58:00 +0000 Message-ID: <5138b23393b7434fa674eefd1886385d@huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.232.176] Content-Type: multipart/alternative; boundary="_000_5138b23393b7434fa674eefd1886385dhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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 Mar 2022 01:58:09 -0000 --_000_5138b23393b7434fa674eefd1886385dhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpJIGp1c3QgcG9zdGVkIGEgZHJhZnQgdGhhdCBzcGVjaWZpZXMgYSBmcmFtZXdv cmsgYW5kIHNvbWUgbW9yZSBkZXRhaWwgb2YgdGhlIGlkZWEgZm9yIHByb3Zpc2lvbmluZyBvZiB1 bmRlcmxheSBzZXJ2aWNlcyAoU2xpY2UvU1ItcG9saWN5L01jYXN0L2V0YykgdG8gb3ZlcmxheSBu ZXR3b3JrcyhTRC1XQU4vQ0ROL2V0YyksIHVzaW5nIFNSdjYuDQoNCg0KDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9yLW92 ZXJsYXkNCg0KDQoNClBsZWFzZSBjb21tZW50IGFuZCBzZW5kIGFueSBmZWVkYmFjay4NCg0KDQoN Ckkgd291bGQgbGlrZSB0byBkaXNjdXNzIHRoaXMgZG9jdW1lbnQgb3ZlciBlLW1haWwvbWFpbC1s aXN0Lg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpKaW5ncm9uZyBYaWUNCg0KDQoNCg0K --_000_5138b23393b7434fa674eefd1886385dhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5DaGFyDQoJe21z by1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQovKiBQYWdlIERlZmluaXRpb25zICov DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9InRleHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGp1c3QgcG9zdGVk IGEgZHJhZnQgdGhhdCBzcGVjaWZpZXMgYSBmcmFtZXdvcmsgYW5kIHNvbWUgbW9yZSBkZXRhaWwg b2YgdGhlIGlkZWEgZm9yIHByb3Zpc2lvbmluZyBvZiB1bmRlcmxheSBzZXJ2aWNlcyAoU2xpY2Uv U1ItcG9saWN5L01jYXN0L2V0YykgdG8gb3ZlcmxheSBuZXR3b3JrcyhTRC1XQU4vQ0ROL2V0Yyks IHVzaW5nIFNSdjYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9y LW92ZXJsYXkiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGll LXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PlBsZWFzZSBjb21tZW50IGFuZCBzZW5kIGFueSBmZWVkYmFjay48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkkgd291bGQgbGlrZSB0byBkaXNjdXNzIHRoaXMgZG9jdW1lbnQgb3ZlciBlLW1haWwv bWFpbC1saXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCBSZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5KaW5ncm9uZyBYaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5138b23393b7434fa674eefd1886385dhuaweicom_-- From nobody Tue Mar 8 18:50:13 2022 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 1B18D3A0937; Tue, 8 Mar 2022 18:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 fXOCEkN7o_zj; Tue, 8 Mar 2022 18:50:00 -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 DA8093A0915; Tue, 8 Mar 2022 18:49:59 -0800 (PST) Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KCxTR6DgHz67bml; Wed, 9 Mar 2022 10:48:27 +0800 (CST) Received: from canpemm100008.china.huawei.com (7.192.104.152) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 9 Mar 2022 03:49:56 +0100 Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm100008.china.huawei.com (7.192.104.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 9 Mar 2022 10:49:54 +0800 Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.021; Wed, 9 Mar 2022 10:49:54 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: SPRING agenda is posted @IETF113 Thread-Index: AdgzYE5OfuLqkRWvR3eoIo0Q+UstjA== Date: Wed, 9 Mar 2022 02:49:54 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.177.127] Content-Type: multipart/alternative; boundary="_000_fcaa1a00195f4e4d8ce2fb89ac3ec61chuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] SPRING agenda is posted @IETF113 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 Mar 2022 02:50:12 -0000 --_000_fcaa1a00195f4e4d8ce2fb89ac3ec61chuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The agenda has been posted. Please let us know if you want to make any chan= ges. https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt Please upload your slides directly to https://datatracker.ietf.org/meeting/= 113/session/spring or send them to spring-chairs@ietf.org. Please upload your slides 24H or 48H before the section. Thank you! Best regards, Shuping --_000_fcaa1a00195f4e4d8ce2fb89ac3ec61chuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The agenda has been posted. Ple= ase let us know if you want to make any changes.

 

https://datatracke= r.ietf.org/meeting/113/materials/agenda-113-spring-00.txt

 

Please upload your slides direc= tly to https://datatracker.ietf.org/meeting/113/session/spring  or send t= hem to spring-chairs@ietf.org.

 

Please upload your slides 24H o= r 48H before the section.

 

Thank you!

 

Best regards,=

Shuping

--_000_fcaa1a00195f4e4d8ce2fb89ac3ec61chuaweicom_-- From nobody Wed Mar 9 06:14:18 2022 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 1A72A3A11C2; Wed, 9 Mar 2022 06:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.604 X-Spam-Level: X-Spam-Status: No, score=-9.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=a4cqtgFq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eLNz8lYq 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 Ms-XgTgdn3ju; Wed, 9 Mar 2022 06:13:16 -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 CBBE93A11C3; Wed, 9 Mar 2022 06:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10501; q=dns/txt; s=iport; t=1646835195; x=1648044795; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/NYg97RjodwsRTCBt/uF57xtDOwmOlueh52To7Q54SU=; b=a4cqtgFqi7KqGxJa9MUXurn0nS+M/2xwabDnlvBC5p90GyJDP8/VUTjX awyHtDytds6OHj2s7Qz/3nIvtFvXt3yw9P8ipx4QF30Tx212SuzttBFZN QnNeLlQWEbTpBRd8mH2NWCjKL+4bdg6yq/7zQrrhbqF8WIgiYQQqoVEos Q=; X-IPAS-Result: =?us-ascii?q?A0D3AAA0tShimIkNJK1aHgEBCxIMQIFPC4EhMVZ+WjdEi?= =?us-ascii?q?B4DhTmFEIMCA5YbhRaBLhSBEQNUCwEBAQ0BATcKBAEBhQcChCECJTQJDgECB?= =?us-ascii?q?AEBAQEDAgMBAQEBAQEDAQEFAQEBAgEGBBQBAQEBAQEBAQkUBwYMBQ4QJ4VoD?= =?us-ascii?q?YZCAQEBAQMSLgEBNQMPAgEIEQMBAi8yGwEBBQMCBAESCBqCYgGCDlcDLgEOo?= =?us-ascii?q?TwBgToCih94gTOBAYIIAQEGBASBNwEDBAxBgn8YgjcDBoE8gxGEI4cUJxyBS?= =?us-ascii?q?USBWIJnPoJjAQECAYEjPB4NgySCLpYRgTAEUQIURgyBBqBFQKAnCoNJiwqUf?= =?us-ascii?q?xWoMpZVIIxzlBorhHgCBAIEBQIOAQEGgWGCFXAVGiGCaVEZD44gCRAJg1CFF?= =?us-ascii?q?IVKdQI2AgYLAQEDCZFvAQE?= IronPort-PHdr: A9a23:ZNop9BJzgpnfO2zwZdmcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J 0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8E YxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig= IronPort-Data: A9a23:A+7/gqw9bVD0JSA4jT56t+cZxirEfRIJ4+MujC+fZmUNrF6WrkUDz WccUWqHaa6LYGv8f4p1aYXl8x4D7MWAmtc3TVA6qVhgHilAwSbn6Xt1DatR0we6dJCroJdPt p1GAjX4BJloCCea/H9BC5C5xZVG/fngqoHUVaiVYkideSc+EH170Uk7yrZj6mJVqYHR7z2l6 IuaT/L3YDdJ6xYsWo7Dw/vewP/HlK2aVAIw5jTSV9gS1LPtvyV94KYkGE2EByCQrr+4sQKNb 72rILmRpgs19vq2Yz+vuu6TnkYiGtY+MeUS45Zbc/DKv/RMmsA9+v46DNgmMxcNtxLXvO4rl PVHl5+BZgh8a8UgmMxFO/VZOyh6OasD87jdLD3j98eS1EbBNXDrxp2CDmlvYtZeobgxWDoIr KdHQNwORkjra+aeybKyQOVhgt8LJ8jwN4RZsXZlpd3cJaZ/HMiaGfyTuLe02h8dh+oTNrXQV fFEeB4oQgzkZhcQIHwuXcdWcOCA3ymjLGIwREiujasv+237zQFt3v7qKtW9UseSX8RTkQOTp mvH5X/RAxwGOpqY0zXt2mm0nO7Jkgv6VZ4cUrqi+ZZXbEa7z2gXDlgdUkG25KX/gU+lUNUZI EsRksYzkUQs3BSqdvvHBU3inFnanSBGB/paMe4Lxw7Yn8I4/D2lLmQDSzdAbvkvu8k3WSEm2 ze1czXBWGAHXFq9FCn1y1uEkd+hEXNOdDZdO0foWSNAsoe9/9Bq5v7aZo87SMaIYsvJ9SYcK txghAE6g7gV5SLg//rmpQmc695AS2Sgc+LYzgzTWmTg5QRjacv5IYep8lPcq/1HKe51r2VtX lBZxqByD8hXUPlhcRBhps1WRdlFAN7ealXhbaZHRcVJythU0yfLkXpsyD9/Plx1Fc0PZCXkZ kTe0SsIusMNYyX2N/cnOd7qYyjP8UQGPYm1PhwzRocRCqWdiCfclM2TTRfKhju0wBREfV8XY MrALa5A8kr2+Yw+nGbpGI/xIJcgxzs1wivIVIvnwhG8uYdyl1bLIYrpxGCmN7hjhIvd+V292 48Ga6OilkUOOMWjM3K/2dNCcjgicyNhbbio8JM/SwJ2Clc8cI3XI6WPkepJlk0Mt/k9q9okC VnmAx4GkgWj3SObQehIA1g6AI7SsV9EhSpTFUQR0ZyAghDPva7HAH8jSqYK IronPort-HdrOrdr: A9a23:R5Vhwa4cnvHfJUUzsQPXwXeBI+orL9Y04lQ7vn2ZFiY1TiXIra 6TdaoguiMc0AxhJE3I6urwR5VoIEmsuaKdhLNwAV7MZnifhILFFvAG0WKm+UycJ8SczJ8T6U 4DSdkENDSYNzET5qyWjHjaYrQdKZu8gdqVbIzlvhBQpHRRGthdBnBCe2Cm+yNNNW17LKt8MK DZyttMpjKmd3hSRN+8HGM5U+/KoMCOvI76YDYdbiRXpjWmvHeN0vrXAhKY1hARX3dk2rE561 XIlAT/++GKr+y78BnBzGXehq4m2ecJi+EzRPBkuPJlaAkEuTzYIbiJnIfy+Azdldvfq2rCVu O85CvIcf4DrU85NVvF3ycFkzOQoQrGrUWSkGNxRRDY0JfErPVQMbsYuWsRSGqo12Mw+N57y6 5FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwtorQc/tQ0XbWIlUs4YkWXfxjIgLL4QWCbhrIw3Gu hnC8/RoP5QbFOBdnjc+m1i2salUHg/FgqPBhFqgL3Z7xFG2HRii0cIzs0WmXkNsJo7Vplf/u zBdqBljqtHQMMaZb90QO0BXcy0AGrQRg+kChPZHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33I /MVVtJ3FRCDX4Gyff+q6Gj3iq9MllVBw6duf22z6IJz4HBeA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,167,1643673600"; d="scan'208,217";a="815012115" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Mar 2022 14:13:14 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 229EDEfJ019710 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2022 14:13:14 GMT Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 9 Mar 2022 08:13:14 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 9 Mar 2022 09:13:13 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 9 Mar 2022 08:13:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RzSooWQ6qpwEDQTFI90Pnw7yjc8rKcuVK60RTfiSg0kAhnGMqOOCPsmYaFj2uQpN26V1IePjLHUtxDwybDIQbz5b0bKnaRzgHBEvuyv8zvxfbohA4rrf7w/h/KzX4JwiRAZtQu2Mizbd77bX+KydaaxJ3myCyGtYD9rvlboBHzGkyHWCYTUByadkw+dV3rqQI7jTAa/STIK/VG/S3g18mIN/5+kMgJrtFPa7oEbSVPk035NorU+ig2gq6CIvDPuxKeXZpz6qf9GFmKuPhGrvQEVrv0KxRllcXbIsN6keI30Rl0+zTDl/ddn+j8aPQvoC5D155jh4M/po0Nu0fsJawg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GUoae+hGQsNVmL/GIN2s5LHiy8kstpyJD06wlRObKxU=; b=bhBd023+IiV0Aq5KjOKLxxfms9U1wVHcN5sI2DLoTihe2dckOxqq+gaTSO2pAWWuStyvywQ76iG8e6bEPQZnXnksyKjz3hiPSo7AqsFqCW52JbL+xy6dWlK2UqI9yDc8HasFNm0tsZgOxOaMFTBKIhruVirB/emGSHssEPF08w1VJk2HQXg4yb33aPFTHwZ8xfrYLn/66hiMA3D7rxiOdBbsB63nrswrS5K1TV+CIqntmmfQlGl5zW5OR6z1rmwO/wVDcwixRyxkjjggO8807ocR6ilu+HOeuup3YLoRqR/XW/UsgYD83/oigvzgOqGUsVgFtKvypu1bHc3qF/k0qA== 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=GUoae+hGQsNVmL/GIN2s5LHiy8kstpyJD06wlRObKxU=; b=eLNz8lYq/1lIN6QuMUukYXVZwU49Jg9XzJ8sBVgnHzZRfs1hHlxj+mw97l+SovFTMEDmDRU5f4VqS532kqpBW04hb6xUgJZ0gpHLeu7gi0Y5Eg/dswfBMlEUdIO2nfJWGlJxurqkWJNF864DtU/SsWribsNvbLB8OSZG91WknKE= Received: from PH0PR11MB5829.namprd11.prod.outlook.com (2603:10b6:510:140::8) by BL0PR11MB3092.namprd11.prod.outlook.com (2603:10b6:208:7d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.21; Wed, 9 Mar 2022 14:13:06 +0000 Received: from PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c]) by PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c%7]) with mapi id 15.20.5038.026; Wed, 9 Mar 2022 14:13:06 +0000 From: "Ahmed Abdelsalam (ahabdels)" To: "spring@ietf.org" , "spring-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-path-tracing-00.txt Thread-Index: AQHYL99cD4laBHfqlECFrXblL/g+Fay3HxwE Date: Wed, 9 Mar 2022 14:13:06 +0000 Message-ID: References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: <164640893348.28277.3971579812610487211@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f3e20cd-9c95-408e-67de-08da01d6eed4 x-ms-traffictypediagnostic: BL0PR11MB3092:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zFYwX84P4sZunQ5/FU/qsqvZxBje/+ZmNFOqkuSNhXs8EiIPZEX2cc/7/r0HOgshX2KqTrj4rSJYX2OGrGVV0ucgHGfcJwvQ0zUrOLW5sCVz6q109c3zWCJRMYBW1ZQLrWijdLGPm1GbAMvXpk5ZuMk6KZLrWWrUrSZ4/ipDMVTojOqqOQYrngubUhuXKZk2kcJNG1B6w/1UCExXj+YOnSq0zkd7BfKXGVRksbaIRDC1H94Q17DVWj3WDzo+JNPrc2/AxoGc65jc1BtvSbNd/6TU1fT2RdW33al8MRx+EAV8mfcc55tUroIcFlTwgQMaXaePHJQXelulpO7nvSbwiKPZXgAoa7Drfq7pkPyCvmI/K+SYvIiqNB1WeRSYY3z1mRdNxrg85ONxsxLWNTyXxn/V9ajvAEUZjGzJtYUwFYpEiKJDYaTvJc16jjxtSzw6dJjvF80Pktlo9qsWdIaw/NK6DiU1QGm4ykno5aJ8FygnmUdbLvHim9Yf5aTjJ2FMLao1j0CgfpF70H4kZTupcehd2yXUTjF+H8qWC85ClK451d04VHh6azFK6+GEQHLBNKfpMFdABkmSQ+7Ox6lVyAjcL4oeOta4m4e4adg18Ys8H5IuBE9gdXYOksMMVX56PH74gPd4pkYfEEQj8Zezkz5KmBaAU1EjfZ8WpF8I3MXXi+YLsvMMqO/bdw0mGgn61Ybd3mUYetCd78C2DKITco+TrwT9sg8tYp94yUs4kQbe/d4Uwi7ua3Mkl/Y8R8IqTke1Hfl1SvdscUWcyRdqdZqG30HgGEvMSnr0k+qnu8lurSeJlNFcVD55ste8pXSoWzfcbwyzKd6n3oqp1i/WGg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5829.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(33656002)(966005)(66574015)(316002)(110136005)(71200400001)(66476007)(64756008)(76116006)(8676002)(66446008)(66946007)(66556008)(508600001)(38070700005)(86362001)(91956017)(450100002)(83380400001)(122000001)(26005)(5660300002)(186003)(15650500001)(6506007)(2906002)(8936002)(7696005)(38100700002)(53546011)(52536014)(9686003)(55016003)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?67xXuCDxcJww2inkJ2vrlXuEkKtWEVMco9ATbHE7iLp6ehus96uZeb2mI/dE?= =?us-ascii?Q?G1JcK7tJbzGI3lce5DkE+GqgHcDon6JSPQjXKRyPt7rQcyb0rhHXDpfrQoSh?= =?us-ascii?Q?qCdoVUlAeSImorh8GH/7iJEcmJ2Q1gOFY46yuGHrMmY8CD4C8gSK6CBU4INi?= =?us-ascii?Q?b1TyZSM77Gsakje2YLXKcI/SznY0fwsIR+I+xn61RGGFiSyaKHOMKd8g6FJ3?= =?us-ascii?Q?mKI88FWsP6hryhUKIY+gDZ+gDaMAMEs1OFSojNZgT2hY9nLZSIqqnkq5zg7s?= =?us-ascii?Q?75JbY+31OeVttKxknR1XiDFbt/+P2GHRX1cIZJUlowoowKWVKVWv8Fm5cMUz?= =?us-ascii?Q?+UFeKzOSgMytnoAnehbko48jcP//eMNiDoisi901dvea8K/IwYISINVngdeI?= =?us-ascii?Q?fbWyJXoQ5L1+mh0M3HUlyCvsdJLDPrxlbFOHAhd2VhuBV0v+SQyvV3sOU0y9?= =?us-ascii?Q?g8uOZ4Tz516ehWgc2kCc6tbMJMEBtRFaYZOV8eT/b+ApcNyOZBLZe1Km6dMW?= =?us-ascii?Q?IwX5lGA/KhfagiGk3RAsSyhUUltNOnufADzzYWxrTFyigoiDa0KwkHITnyCS?= =?us-ascii?Q?QyudWFWARwVERdIiYv9Touok8alx7UarqC8PNnp0gw8FuYKvCVxpWPVKRytZ?= =?us-ascii?Q?yAnt5fo89r04oBrkERddrhXLrNCNklM8Xeq0YqtDSEwfPzsXey6sUcyQMHyM?= =?us-ascii?Q?L9mqGVre02+5JW4uugW4MTrR+3tlUbcH/q8c/2bc+7h4CvYxLHx0xpWjoYOe?= =?us-ascii?Q?B+yw6pinwuuw1leJX0fC72L/czLPAv+zVoMeYG5pEF1tJqU4UugXO6EhvjRR?= =?us-ascii?Q?48bKgGOHJ70DrvJVtPf2eE+0YEfARi3laAeAfkZEYR9pJVTyvpBVKjGK6fsn?= =?us-ascii?Q?XrRKi+Y06BTAcQXs6hjoPC9AKQro5JOpi9o+35ecB9OvReqHCcuGlMyq1Ybw?= =?us-ascii?Q?MhTuGektVR5EMmlH15LrBsTZzz02wIkwmD+6dMQnCRNE2cMipFS6yYjZ3ISZ?= =?us-ascii?Q?BKfwQELvDbLGLjR/1FZ6M10fHzZ1HTY5ZVwXL40aHCy4LEejfd1TRECMultf?= =?us-ascii?Q?FKj1sXdG04I9MFmGTOfVWtHB87xjRhKEJFSmpJh2j4zmhAJR8nP8WKHfWFnv?= =?us-ascii?Q?PAST/dqVtg9zMyileNbdw1ffzgFHlAVdWDEVYHHu6hhLWVe+Jwj2PnnbiurF?= =?us-ascii?Q?Pxgofng0l0mHan3/ThAd13XNPTuel2mXHxV/9DJxLOsJOfam8+oN8mnkI8kZ?= =?us-ascii?Q?r9qDFB/UEu7hT1pIzwqkFEa1mSk0p9hXr0m/1EWEGP9yy4piRJUlIFpb1owj?= =?us-ascii?Q?Mkcp9JvQllgd7Gv48DBSlNQZ5FqbA3qViZhWUVRH+/dcout3D7Zd4cSZXCMX?= =?us-ascii?Q?ojJa2ZF+3wQc/lwa/Xrz3za+vXAJSoobSX+XUKE9T3GYRB0FT6hCXS6saHLM?= =?us-ascii?Q?CmZ0L7dd0HaW3w3s/ynfzyDG5xV2iT94Q9KuqyN7QVESXuHH6L4Kpw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB58292EFBE456FB0108CD620BD40A9PH0PR11MB5829namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5829.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f3e20cd-9c95-408e-67de-08da01d6eed4 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2022 14:13:06.6935 (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: jgqzUymO8WZg39A+H3ycqQYvi7inM20gGOTB6nJTQc6T1X64CAniU603iCHhwMm0vLtfdizzPcxD2UvMUdh7TQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3092 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: [spring] FW: New Version Notification for draft-filsfils-spring-path-tracing-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, 09 Mar 2022 14:13:22 -0000 --_000_PH0PR11MB58292EFBE456FB0108CD620BD40A9PH0PR11MB5829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear SPRING WG, IPPM WG, We have submitted a new I-D for Path Tracing in SRv6 networks (https://data= tracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG. We are looking for your feedback and comments. Path Tracing provides a record of the packet path as a sequence of interfac= e ids. In addition, it provides a record of end-to-end delay, per-hop delay= , and load on each egress interface along the packet delivery path to facil= itate operation of SR networks. Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop e= xtension header. We will present Path Tracing to the SPRING WG at next IETF (https://datatra= cker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) Thanks, Ahmed From: internet-drafts@ietf.org Date: Friday, 4 March 2022 at 16:48 To: Ahmed Abdelsalam (ahabdels) , cf(mailer list) , Mark Yufit , Pablo Camarillo (pcamaril)= , Pablo Camarillo (pcamaril) , Sat= oru Matsushima , Thomas.Graf , Yuanchao Su Subject: New Version Notification for draft-filsfils-spring-path-tracing-00= .txt A new version of I-D, draft-filsfils-spring-path-tracing-00.txt has been successfully submitted by Pablo Camarillo Garvia and posted to the IETF repository. Name: draft-filsfils-spring-path-tracing Revision: 00 Title: Path Tracing in SRv6 networks Document date: 2022-03-04 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-filsfils-spring-path-= tracing-00.txt Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-path= -tracing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-filsfils-spring= -path-tracing Abstract: Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. The IETF Secretariat --_000_PH0PR11MB58292EFBE456FB0108CD620BD40A9PH0PR11MB5829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear SPRING WG,  IPPM WG,

 

We have submitted a new I-D for Path Tracing in SRv6 networks (https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-trac= ing) to SPRING WG.

 

We are looking for your feedback and comments.

 

Path Tracing provides a record of the packet path as a sequence of = interface ids. In addition, it provides a record of end-to-end delay, per-h= op delay, and load on each egress interface along the packet delivery path to facilitate operation of SR networks.

 

Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-= by-Hop extension header.

 

We will present Path Tracing to the SPRING WG at next IETF (https:/= /datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt)

 

Thanks,

Ahmed

 

From: internet-drafts@iet= f.org <internet-drafts@ietf.org>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, cf(maile= r list) <cf@cisco.com>, Mark Yufit <mark.yufit@broadcom.com>, P= ablo Camarillo (pcamaril) <pcamaril@cisco.com>, Pablo Camarillo (pcam= aril) <pcamaril@cisco.com>, Satoru Matsushima <satoru.matsushima@g= .softbank.co.jp>, Thomas.Graf <Thomas.Graf@swisscom.com>, Yuanchao Su <yitai.syc@al= ibaba-inc.com>
Subject: New Version Notification for draft-filsfils-spring-path-tra= cing-00.txt


A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the=
IETF repository.

Name:           draft-fil= sfils-spring-path-tracing
Revision:       00
Title:          Path Tracing i= n SRv6 networks
Document date:  2022-03-04
Group:          Individual Sub= mission
Pages:          15
URL:            https://www.ietf.org/archive= /id/draft-filsfils-spring-path-tracing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-filsfils-= spring-path-tracing/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-filsfils-= spring-path-tracing


Abstract:
   Path Tracing provides a record of the packet path as a sequenc= e of
   interface ids.  In addition, it provides a record of end-= to-end
   delay, per-hop delay, and load on each egress interface along = the
   packet delivery path.

   Path Tracing allows to trace 14 hops with only a 40-bytes IPv6= Hop-
   by-Hop extension header.

   Path Tracing supports fine grained timestamp.  It has bee= n designed
   for linerate hardware implementation in the base pipeline.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

--_000_PH0PR11MB58292EFBE456FB0108CD620BD40A9PH0PR11MB5829namp_-- From nobody Wed Mar 9 06:43:30 2022 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 522643A078A for ; Wed, 9 Mar 2022 06:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 irvPeP5g-6Md for ; Wed, 9 Mar 2022 06:43:24 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::52]) (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 C993A3A0770 for ; Wed, 9 Mar 2022 06:43:22 -0800 (PST) Received: from [2a02:8010:69a6:0:39cc:c7b2:817c:1996] by painless-b.tch.aa.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nRxX6-009pyh-8x for spring@ietf.org; Wed, 09 Mar 2022 14:43:19 +0000 Message-ID: Date: Wed, 9 Mar 2022 14:43:13 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB To: spring@ietf.org References: <5138b23393b7434fa674eefd1886385d@huawei.com> From: Tom Hill In-Reply-To: <5138b23393b7434fa674eefd1886385d@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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 Mar 2022 14:43:29 -0000 Hi Jinrong, On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote: > I just posted a draft that specifies a framework and some more detail of > the idea for provisioning of underlay services > (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using SRv6. > > https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-overlay > > > Please comment and send any feedback. > > I would like to discuss this document over e-mail/mail-list. I'm concerned that this draft is explicitly violating the concept of SRv6 as a protocol that operates within a Limited Domain. As per Section 3.2 of this draft, "... the network operator of AN, TN and Internet can be different from each other." Further, "In some scenarios, the AN can be an Internet exchange provider (IXP) independent of ISP and NSP. In some other scenarios, the AN can be an ISP that running Internet backbone as well." This would read to me that the proposal is explicitly intended to be inter-domain, and not at all limited to any one administrative domain. Additionally, I cannot determine if the draft implicitly requires the use of SIDs across the public Internet? Could I ask for some clarification on the scope of the draft, with respect to Limited Domains, and also the use of SIDs over the public Internet? Kind regards, -- Tom From nobody Wed Mar 9 22:40:38 2022 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 7FA853A0B70 for ; Wed, 9 Mar 2022 22:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 YURPynk6W-oL for ; Wed, 9 Mar 2022 22:40:33 -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 CE99A3A0B60 for ; Wed, 9 Mar 2022 22:40:32 -0800 (PST) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KDfXx13W0z6H7gS for ; Thu, 10 Mar 2022 14:38:57 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Mar 2022 07:40:29 +0100 Received: from kwepeml500002.china.huawei.com (7.221.188.128) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Mar 2022 14:40:27 +0800 Received: from kwepeml500002.china.huawei.com ([7.221.188.128]) by kwepeml500002.china.huawei.com ([7.221.188.128]) with mapi id 15.01.2308.021; Thu, 10 Mar 2022 14:40:27 +0800 From: "Xiejingrong (Jingrong)" To: Tom Hill , "spring@ietf.org" Thread-Topic: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) Thread-Index: Adgyj2pEDTIYoRv+Rwm6VOp4IGlK2wA8YiOAADHZrvA= Date: Thu, 10 Mar 2022 06:40:27 +0000 Message-ID: References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.232.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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 Mar 2022 06:40:36 -0000 Hi Tom, Thanks for reading the draft and raise discussions. In the proposal the SRv6 domain is the overlay network, belonging to one ad= ministrative domain -- the overlay network operator(say ONO).=20 For your concern about use of SIDs "across" the public Internet. Let me try= to explain using following figure (hope it works): CPE1 CPE2 CPE3 + + + + | +--------+ | | +----------+ | +---[1] TN1 [1]---+ +---+ Internet |---+ +--------+ +----------+=20 In the perspective of the ONO, it has the following SIDs: SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO. SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, ma= rked [1] in the figure). The ONO can use these SIDs, and I would think they are all "in the overlay = network", and are running "Over the Internet".=20 You mentioned in the last sentence "the use of SIDs over the public Interne= t". That is what I am modeling above. Thanks Jingrong -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Tom Hill Sent: Wednesday, March 9, 2022 10:43 PM To: spring@ietf.org Subject: Re: [spring] Network Programming Interface for Provisioning of Und= erlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-fo= r-overlay) Hi Jinrong, On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote: > I just posted a draft that specifies a framework and some more detail=20 > of the idea for provisioning of underlay services > (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using SR= v6. >=20 > https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov > erlay=20 > verlay> >=20 > Please comment and send any feedback. >=20 > I would like to discuss this document over e-mail/mail-list. I'm concerned that this draft is explicitly violating the concept of SRv6 as a protocol that operates within a Limited Domain. As per Section 3.2 of this draft, "... the network operator of AN, TN and I= nternet can be different from each other." Further, "In some scenarios, the AN can be an Internet exchange provider (IXP) independent of ISP and NSP. In some other scenarios, the AN can be an= ISP that running Internet backbone as well." This would read to me that the proposal is explicitly intended to be inter-= domain, and not at all limited to any one administrative domain.=20 Additionally, I cannot determine if the draft implicitly requires the use o= f SIDs across the public Internet? Could I ask for some clarification on the scope of the draft, with respect = to Limited Domains, and also the use of SIDs over the public Internet? Kind regards, -- Tom _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Mar 10 06:59:28 2022 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 4E42A3A1803 for ; Thu, 10 Mar 2022 06:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=liquid.tech 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 rbIyAt5BuSgm for ; Thu, 10 Mar 2022 06:59:04 -0800 (PST) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.85.182]) (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 106AB3A17FB for ; Thu, 10 Mar 2022 06:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1646924341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=N9pcyL2QUCxMym2l5Qx8gbhzSl/Uu92VTGY7j8d4ZUE=; b=cCzKV6CeHfL0B94j7pqh8D0RLCNENH7mXUZ5djKUUt6uV9zrWvz0dv2lff/Wwbi8PCVXYd BkOOcLimyIfHkUMhCnw/1KpVYU2ooeRDSKJfbhdpMhD1EN9B/Lo5okvyUfbaYpeb/PuxK6 oVlMh1Q0fA6ajfFpmYzk+EV1vWiRViE= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2059.outbound.protection.outlook.com [104.47.14.59]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id uk-mta-196-2xueZ2AsN-abUYQsF93JJg-1; Thu, 10 Mar 2022 14:58:58 +0000 X-MC-Unique: 2xueZ2AsN-abUYQsF93JJg-1 Received: from AM7PR03MB6451.eurprd03.prod.outlook.com (2603:10a6:20b:1b3::22) by AM0PR03MB4067.eurprd03.prod.outlook.com (2603:10a6:208:74::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.22; Thu, 10 Mar 2022 14:58:56 +0000 Received: from AM7PR03MB6451.eurprd03.prod.outlook.com ([fe80::4840:edb3:af81:2086]) by AM7PR03MB6451.eurprd03.prod.outlook.com ([fe80::4840:edb3:af81:2086%7]) with mapi id 15.20.5038.018; Thu, 10 Mar 2022 14:58:56 +0000 From: Andrew Alston - IETF To: "Xiejingrong (Jingrong)" , Tom Hill , "spring@ietf.org" Thread-Topic: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) Thread-Index: Adgyj2pEDTIYoRv+Rwm6VOp4IGlK2wBNJauAACFuVoAAEUkkQA== Date: Thu, 10 Mar 2022 14:58:56 +0000 Message-ID: References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b13dbff8-bf5e-4b3d-3f51-08da02a6802b x-ms-traffictypediagnostic: AM0PR03MB4067:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: iUEFO65yvgRmDv0T90tA85Dc3ULPh5V+vydMjojkBWAPS1ehXsuQrb1B6mOfh6KmMdWoMrDv+BSSC2dEJ8rQUfbe0s1cuCeG9h42H1ZxcincxXBXUVUZ4tNZHH3NJ3LSRNDZUEsgE4Kj/4mI3RxFM9HvZR0BhqYR8KeM+be8APHVJKs4uxwJpmJfqqCoOSDn80koDjjnUfbEBBxVBTdZi/EkYR8jKCx6QZAo3vwzLkb9OkytdC08fvS3ZSO5EscaiLCVOJKxQqxkuKEzOIea+286OJ1DOzUCKLpT6Ce8QXJkoRiaAGFIZ14kuUxSgXuW+Q/wONbNeBfMQEbhtvOrmjpS/ZGxTzCXb64emLMD7UxXJR4dC47uLINkHHIUWJgiIgIxp3sT3HI9SIpm9IveIKfzddJn3dpK11d4Ehm15SUoTXSygz68Lv2CKzjb1oyUAIX7YR4F1CYaC/FBKUplFN45dZqDHsH80MqMdhPlsBHQzjgmqRu0FVB3fLXDSPNjZKejzdYY3dDn+Y+poxenWQvuMuqlCQv3ucd+UfGhzc4gJg18Rui9cvrOHA/EMYuQGxNs44L8ETM2NAELh0cm4CyJrRAaqvTNlj/YT+y8K+LVYAn72qH3N6VGmgSXHs84OZoy0cu/AxN0gg9LxocOxjH30MKGvAIopsCH+qxV1Oe5QqWl90kW4+xFQs2nu2VAROt4byBGeQS7ZovHt5CXAyCNoIBJQnLuPmsx2kRLhrhbRbVxOa1Oukug2uyuCs/Au0vN0gmqxWL5twtWmKuc0pNun0V+skHcdsC9sc9hN0QoCISDdc78yRyjcOQ5l8oZqUjpRCnoHBKDvOrInKupKA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR03MB6451.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(9686003)(7696005)(53546011)(186003)(86362001)(2906002)(83380400001)(6506007)(52536014)(122000001)(66556008)(71200400001)(5660300002)(66574015)(8936002)(9326002)(110136005)(33656002)(64756008)(66446008)(76116006)(508600001)(316002)(66946007)(66476007)(55016003)(966005)(166002)(8676002)(38100700002); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KTAJFUyOJjZKVDTZ8TFZxnsky27BRnVOmk6RIABgWDB1ssaHRIRYJfylpGkK?= =?us-ascii?Q?KEofXHGACPg6yiTXHBVj6C8Ym9duFt0xeJVx2mfFPcFh2rB2caPPblbe9DUx?= =?us-ascii?Q?MUw1EGEHBG1wrsjYCfzY4CGutPjbxVQhpOXNd2rgrBXW9u/D1i4VfCH3JLg0?= =?us-ascii?Q?/NOKuHy3yzWXCiXSmnYUTc6qtDS4CmTh7t+z2ZafF24SchouyyfGIjDNwcPX?= =?us-ascii?Q?JgMldtHwedJuBVtO7nl29XyR+ecs4+iZ3Y2mMCpnv5rAKoUsFszrdA4HdWvA?= =?us-ascii?Q?b/pKDl0VB3DWjEwGQA5f4P78Bv50pH3tiySaZbwJtEnZWiKmkUOHCNhr1R2Z?= =?us-ascii?Q?u8JHtrDFtA3Dzoib+4g+NJFfSd3BG4aNhVwwW6fYAIkTN6SfClumnrCSv7X1?= =?us-ascii?Q?SUR2B3mDY08yY3zObhMh6cD6tJlmVJRoYOcX7CPR2h2FSkIF9fcIaB14ByQO?= =?us-ascii?Q?0QKIONGS8Qapt5vthU6EpsxAIrb3UtaCzF2u+pPWFxNaGBtaJhvoF50MBSnj?= =?us-ascii?Q?7tRRNNNGIaf02huz/JsnbnmeaPw5v8nYN7SaoFhIJU4HfCDx6MY4mkK0a0vc?= =?us-ascii?Q?RawnJ7fYolaHTEzd5ol/Tk9wt8cwk6cl1SuggiLm9STABXu2OeXa1e5vcFpk?= =?us-ascii?Q?a8q9sbjKtsHw+fCqdEFLyHCsyBAVMtPDc61TTdxbIIr3xdXieE4Xz7B+zB5W?= =?us-ascii?Q?FXVoMV1Glr5V5iGucfx00ok0cG8HrGX1rt2QHF3xMh6+do6B1k5mWnKtzPEe?= =?us-ascii?Q?z3FXn91Ncust9xmjoS1aivjiJ3AZ1OJ0WzRAXHhbkvO8XztnTjcVVOnpheNw?= =?us-ascii?Q?T+cLrhaKIahDpnurFRY3eS5ZMln8jraekUCO9Um0Mh30ysk/b/swzi1cTPDu?= =?us-ascii?Q?OL9HWqBh7b7CPfRzHyay/vj6qulEUCZHd8cmeNh6QBi+PKrOSWXUXo3RQera?= =?us-ascii?Q?9JXddoOQfO//q1xMryPsP4mLS2iCjy/STAF+RAVx9BecdZ91siaHOcZ0PPz8?= =?us-ascii?Q?ERy9lAoDtTDlUW8YKc8MqnYe7DZ68C4QJsGuPBROeeNFx5r37ipEBKXtS5IK?= =?us-ascii?Q?Uht1AQJA/2bYxEnuBofgeHPLTJvaMM/idp5yeXV/OTCh6LXPOTMiUYlk9hl2?= =?us-ascii?Q?LbU1ksCdWkgLc6HG6na4j5xQPGIgoAssDn6R9aIBOVXPol/mMR5vnCeENndl?= =?us-ascii?Q?16KDV4JNdIjwMCOV6qnXtWsmFsqbnWvvy4WlaN57v31qCqy1yX2YwF5m87TQ?= =?us-ascii?Q?+jftiZ7hmv0qLydtqJmsbLKCaWR0Dw4u8brke+vYoabpafXcv+DSf1GJnru5?= =?us-ascii?Q?VU3r4NxB6lc8nErxMcTAY0ENmFAhAl5pUIa3MiMVwLfhv/ViSJNE/oapq7sN?= =?us-ascii?Q?KcZGGITaxiyJ+ISCrDe5eLbBhpRgAjW781vSK8aZtHWl34nnYi+DGKjfA2La?= =?us-ascii?Q?LJUWlFCUIi1ad0ChIWX73XKva5G6HaWGOBPDn0HyJD7ytZp2Jl2KTzmTWoT/?= =?us-ascii?Q?ty4F/d7vU1jFtmjEky/M6RAo/SY33KZiHK/qul2Nw4s2gC+QbfTn+Iu5dw?= =?us-ascii?Q?=3D=3D?= MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR03MB6451.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b13dbff8-bf5e-4b3d-3f51-08da02a6802b X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2022 14:58:56.3866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OkDamHiGlkgYCv7LfsBdLeQOf4hG8TN5u4EnxnPMvAJHyI+T3kgj/a081OAcneCERM9f45yj14ESxtEdRMOMzayI3NkcAu7LcXhXJbmuJkc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4067 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew-ietf@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM7PR03MB64513AEDE5ED62ECE0F50280EE0B9AM7PR03MB6451eurp_" Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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 Mar 2022 14:59:16 -0000 --_000_AM7PR03MB64513AEDE5ED62ECE0F50280EE0B9AM7PR03MB6451eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Jingrong, I'm struggling to entirely understand this. I think the question for me is= - if you are sending packets with SID's over the open internet - are you e= ncapsulating those packets and is this encapsulation cryptographically prot= ected - I.E the SID's are not visible outside of the encapsulation, to pres= erve the limited domain. Limited domains are typically extended via tunnel mechanisms, very often wi= th cryptographic protection, hence the question Thanks Andrew From: spring On Behalf Of Xiejingrong (Jingrong) Sent: Thursday, March 10, 2022 9:40 AM To: Tom Hill ; spring@ietf.org Subject: Re: [spring] Network Programming Interface for Provisioning of Und= erlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-fo= r-overlay) Hi Tom, Thanks for reading the draft and raise discussions. In the proposal the SRv6 domain is the overlay network, belonging to one ad= ministrative domain -- the overlay network operator(say ONO). For your concern about use of SIDs "across" the public Internet. Let me try= to explain using following figure (hope it works): CPE1 CPE2 CPE3 + + + + | +--------+ | | +----------+ | +---[1] TN1 [1]---+ +---+ Internet |---+ +--------+ +----------+ In the perspective of the ONO, it has the following SIDs: SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO. SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, ma= rked [1] in the figure). The ONO can use these SIDs, and I would think they are all "in the overlay = network", and are running "Over the Internet". You mentioned in the last sentence "the use of SIDs over the public Interne= t". That is what I am modeling above. Thanks Jingrong -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Tom Hill Sent: Wednesday, March 9, 2022 10:43 PM To: spring@ietf.org Subject: Re: [spring] Network Programming Interface for Provisioning of Und= erlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-fo= r-overlay) Hi Jinrong, On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote: > I just posted a draft that specifies a framework and some more detail > of the idea for provisioning of underlay services > (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using SR= v6. > > https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov > erlay > > verlay> > > Please comment and send any feedback. > > I would like to discuss this document over e-mail/mail-list. I'm concerned that this draft is explicitly violating the concept of SRv6 as a protocol that operates within a Limited Domain. As per Section 3.2 of this draft, "... the network operator of AN, TN and I= nternet can be different from each other." Further, "In some scenarios, the AN can be an Internet exchange provider (IXP) independent of ISP and NSP. In some other scenarios, the AN can be an= ISP that running Internet backbone as well." This would read to me that the proposal is explicitly intended to be inter-= domain, and not at all limited to any one administrative domain. Additionally, I cannot determine if the draft implicitly requires the use o= f SIDs across the public Internet? Could I ask for some clarification on the scope of the draft, with respect = to Limited Domains, and also the use of SIDs over the public Internet? Kind regards, -- Tom _______________________________________________ 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 --_000_AM7PR03MB64513AEDE5ED62ECE0F50280EE0B9AM7PR03MB6451eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Jingrong,

 

I’m struggling to entirely understand this.&nb= sp; I think the question for me is – if you are sending packets with = SID’s over the open internet – are you encapsulating those pack= ets and is this encapsulation cryptographically protected – I.E the SID’s are not visible outside of the encapsulation, to preserve = the limited domain.

 

Limited domains are typically extended via tunnel me= chanisms, very often with cryptographic protection, hence the question=

 

Thanks

 

Andrew

 

 

From: spring <spring-bounces@ietf.org> = On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill <tom@ninjabadger.net>; spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning= of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6= -npi-for-overlay)

 

Hi Tom,

Thanks for reading the draft and raise discussions.

In the proposal the SRv6 domain is the overlay network, belonging to one ad= ministrative domain -- the overlay network operator(say ONO).

For your concern about use of SIDs "across" the public Internet. = Let me try to explain using following figure (hope it works):

CPE1 CPE2 CPE3
+ + + +
| +--------+ | | +----------+ |
+---[1] TN1 [1]---+ +---+ Internet |---+
+--------+ +----------+

In the perspective of the ONO, it has the following SIDs:
SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO.
SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, ma= rked [1] in the figure).
The ONO can use these SIDs, and I would think they are all "in the ove= rlay network", and are running "Over the Internet".

You mentioned in the last sentence "the use of SIDs over the public In= ternet". That is what I am modeling above.

Thanks
Jingrong


-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning of Und= erlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-fo= r-overlay)

Hi Jinrong,

On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> I just posted a draft that specifies a framework and some more detail =
> of the idea for provisioning of underlay services
> (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using= SRv6.
>
> https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov<= br> > erlay
> <https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6= -npi-for-o
> verlay>
>
> Please comment and send any feedback.
>
> I would like to discuss this document over e-mail/mail-list.


I'm concerned that this draft is explicitly violating the concept of
SRv6 as a protocol that operates within a Limited Domain.

As per Section 3.2 of this draft, "... the network operator of AN, TN = and Internet can be different from each other."

Further, "In some scenarios, the AN can be an Internet exchange provid= er
(IXP) independent of ISP and NSP. In some other scenarios, the AN can be an= ISP that running Internet backbone as well."

This would read to me that the proposal is explicitly intended to be inter-= domain, and not at all limited to any one administrative domain.
Additionally, I cannot determine if the draft implicitly requires the use o= f SIDs across the public Internet?

Could I ask for some clarification on the scope of the draft, with respect = to Limited Domains, and also the use of SIDs over the public Internet?

Kind regards,

--
Tom

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

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

--_000_AM7PR03MB64513AEDE5ED62ECE0F50280EE0B9AM7PR03MB6451eurp_-- From nobody Fri Mar 11 10:20:18 2022 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 6A8C13A0E12; Fri, 11 Mar 2022 10:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 BMXfCXp44rgK; Fri, 11 Mar 2022 10:20:04 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 6CC0F3A0DCA; Fri, 11 Mar 2022 10:20:04 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id yy13so20883030ejb.2; Fri, 11 Mar 2022 10:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=QbZU5/pmbAEm3HcuPHmgHdOf9vANzMH0gtOvnPb/m4k=; b=gXXaPKKLh9X1K4nKqNVP9B4tuqRgFYRXkgD0IbXNLju84EgjwImwOg5QFXULkVSzY3 ZCd2KDznRbx61n4qI2Jy8GWDpIbfTrFMuWbmbSY42jvWvu5cZ8mn1tueITRL9pg3gOMO B0luU0MOt18pe3LUDkFx/MEEmiYZ2cqUuc5ozIjFCFYls2OJoSsr7+1lmOyYpImb+3lj /OcH/mCz3oTeaQryNLBQ6aBACH2ZCDx8Cq8cpNzEBJ8wREomGidInuyL07b4ejwlLTvb EvX0rWueyBsKW2wajml8zymmdSq+RsB6s1eQX7VhoQkUeSIpJCJMltkB6PLyweoF4DYB vr/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=QbZU5/pmbAEm3HcuPHmgHdOf9vANzMH0gtOvnPb/m4k=; b=vLkBzvhAtm2qQgAbny0YUjHvDNRWic7ypvYYR18DRiBvlPN0EA2Qrji8/WQp7O2bRS 0K5NUzoUYn25dTz2klrQcofACRpDROWbZfmmGRPWsFRENASEJLyINJmYRWZmEnklY3Z0 Hap9xCHMmA3De8+7fhCTIOVB/I5ZaYB0DlB3NcGBckfPEoFIHgXIgUs2hHDO0TTfb1BR owzW9z757/IqH/5KsaugzdfXDn0Cm8/K5F7Q2XGjsJDYXw4p6KyIv3gl7XKjkUAFFfjq PsQQ9ebPoO/iYdDTKYlh0L+gmqgdzHZIH9wPtDeeHPpMLURUOm9J7z5klsivbB+IRPwB IHRA== X-Gm-Message-State: AOAM53390vw5+fMEFPFEXOHGNfPpUQGDwpMkHvEprm3Fd9t1bd5uihUH Kt26Pi4tdv6iIiZPKrKtd61UCrizDyq4cBnNp+w= X-Google-Smtp-Source: ABdhPJwE22q95ZKH8iIFGV3gwvCJBYq5nUVA+Wn764533T7AeaIKJ27y9896tv8mdKg7G3UOFlsIpFTxMM7vw/hsW3E= X-Received: by 2002:a17:907:1c91:b0:6d7:b83:cddb with SMTP id nb17-20020a1709071c9100b006d70b83cddbmr9310530ejc.739.1647022802330; Fri, 11 Mar 2022 10:20:02 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 11 Mar 2022 10:20:01 -0800 From: Alvaro Retana In-Reply-To: References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> MIME-Version: 1.0 Date: Fri, 11 Mar 2022 10:20:01 -0800 Message-ID: To: Ketan Talaulikar Cc: SPRING WG , spring-chairs@ietf.org, The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, james.n.guichard@futurewei.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 11 Mar 2022 18:20:08 -0000 On March 5, 2022 at 5:29:36 AM, Ketan Talaulikar wrote: Ketan: Hi! > We have also just posted an update to address some of the comments below = and > from other ADs. > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-19 That version addresses my DISCUSS -- I'm clearing. =C2=A0I have one reply in the comments below. Thanks! Alvaro. ... > > > > (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD b= e set to > > > > 0 by default when not available or known." > > > > > > > > When is it ok for the ASN to not be set to 0 (when not available or > > > > known)? If that possibility exists, the PCE can use any value > > > > (including the real number or a random one). What issues exist with > > > > uncoordinated (or rogue) PCEs using potentially arbitrary ASNs? > > > > > > > > Why is this action recommended and not required? > > > > > > KT> AFAIR PCEP signaling does not carry AS number. So this is a > > > recommendation, though a local policy or a future PCEP extension coul= d > > > change that and we don't want to preclude it. > > ... > > If the ASN can be signaled, when is it ok for it to not be set to 0 > > (when not available or known)? If that possibility exists, the PCE > > can use any value (including the real number or a random one). What > > issues exist with uncoordinated (or rogue) PCEs using potentially > > arbitrary ASNs? > > KT> I will leave this question for the PCEP WG if and when they decide to= add > support for ASN to be signaled. It does not make any impact from this > specification perspective since it is only used to identify the originato= r. The impact on this document it that it is specifying the behavior Normatively =C2=A0- let's eliminate that. Suggestion> =C2=A0 =C2=A0If signaling via PCEP, it is the IPv4 or IPv6 address of the P= CE and =C2=A0 =C2=A0the AS number is expected to be set to 0 by default when not a= vailable =C2=A0 =C2=A0or known. From nobody Sat Mar 12 16:26:49 2022 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 1D8363A0D28 for ; Sat, 12 Mar 2022 16:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, T_SCC_BODY_TEXT_LINE=-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 iadqYnPHbMaS for ; Sat, 12 Mar 2022 16:26:41 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 CE9863A0D23 for ; Sat, 12 Mar 2022 16:26:41 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id gj15-20020a17090b108f00b001bef86c67c1so11347812pjb.3 for ; Sat, 12 Mar 2022 16:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=67h7AY9+XPDptXCO9HCZO7NIy0Ztwbf3NUJUPvQOSBE=; b=n5HeUKstTe7Jg0g6D72OyhUck8+5zUknnTIPklRW53yozbBgnAo9zmitKT9/CIV5Bd 5xoi/Rvr2zq51LE9GBJTyRXRSCH3dDd4OleQ9ha7HUObXeIien1eExgxKmnewUgIfWgZ 9rqyb2nrppPqOsIq76egruXCZr0hlYY3Rzk5xKadZxMOgZibBFrmvf8EnRPxA1X4ukkW yO4xLIDeH5e/F4UnAsCdKwEbdlh6MhHb2fWkPbiJKnAa17aOYf4IeXAIyCof10EzR8Sg ZQ8Z6u0BZrG4vHuniPhq686i88THc93fEMMoR3JX/UVuQuVarS3Mj3juVyEB7QU7ae2z Y1Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=67h7AY9+XPDptXCO9HCZO7NIy0Ztwbf3NUJUPvQOSBE=; b=1m40p9BIkPxi+p45MUOJyIq5dA+veQkmlNSG1Op36WRm1yVFO2qJUyOfRrLyUClfQm tXgJhZceJkGG5vEPTttxgoqdgRfaEhN3gA0kEzajrDQbn3UDFJtqSChzykcnY26Zlbk8 4l/3oXuBi3aYdEF/KulKRH5ZfADStQCsV/fYejoWZFf2zP/1h7dqph3X5sIxVol9LuW5 nkm6zUncIPw/B2yLc/7AzBa20UJgDEVYnmDmwnLF9TMZaOR6J6lZkY8WGZfIPAv/2wlo OerY9bMna3aEONaEUWBiwbX50VqeIG5oLIcUEtAIDtEHADW6gL9gez+e2OE74hJKV7WX t7gw== X-Gm-Message-State: AOAM531hLKjbRz6Y/I8/k8I+6S9jw3+yFEmhANK9cwuFcGZDd2NmXWZB GrVaslPv4hiBu//sdhf0XjMx4dMRCny7eS1wwU3IeAHY X-Google-Smtp-Source: ABdhPJzyK1U8wkq2QywkU2mwYopoPom5lgFLEXf5VF5DuSNiBl9lnBP6NLWatuj76AE7EvwG1QpYg3ymU2c1mR+pCQY= X-Received: by 2002:a17:90b:4f4e:b0:1bf:88f6:e5b5 with SMTP id pj14-20020a17090b4f4e00b001bf88f6e5b5mr28267049pjb.47.1647131200649; Sat, 12 Mar 2022 16:26:40 -0800 (PST) MIME-Version: 1.0 References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: From: Gyan Mishra Date: Sat, 12 Mar 2022 19:26:29 -0500 Message-ID: To: Andrew Alston - IETF Cc: Tom Hill , "Xiejingrong (Jingrong)" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001cfe8105da0e9ef7" Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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: Sun, 13 Mar 2022 00:26:48 -0000 --0000000000001cfe8105da0e9ef7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jingrong I reads the draft and was trying to understand the problem statement as well as the solution. So I believe the problem statement is how to interconnect desperate sites over the internet using a managed IPSEC VPN or SDWAN solution or managed MPLS and complexity of provisioning CE attachment. The solution is an automated solution using SRv6 over the internet using BSID. This involves running SRv6 over the internet, however SRv6 is limited to closed domains. It appears an E2E pseudowire is used in provisioning the service. Have you though of using NG L2 VPN EVPN all or single active multi home over SRv6. Does all the provisioning use a PCE / SDN controller? Thanks Gyan On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF wrote: > Hi Jingrong, > > > > I=E2=80=99m struggling to entirely understand this. I think the question= for me > is =E2=80=93 if you are sending packets with SID=E2=80=99s over the open = internet =E2=80=93 are you > encapsulating those packets and is this encapsulation cryptographically > protected =E2=80=93 I.E the SID=E2=80=99s are not visible outside of the = encapsulation, to > preserve the limited domain. > > > > Limited domains are typically extended via tunnel mechanisms, very often > with cryptographic protection, hence the question > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Xiejingrong > (Jingrong) > *Sent:* Thursday, March 10, 2022 9:40 AM > *To:* Tom Hill ; spring@ietf.org > *Subject:* Re: [spring] Network Programming Interface for Provisioning of > Underlay Services to Overlay Networks Using SRv6 > (draft-xie-spring-srv6-npi-for-overlay) > > > > Hi Tom, > > Thanks for reading the draft and raise discussions. > > In the proposal the SRv6 domain is the overlay network, belonging to one > administrative domain -- the overlay network operator(say ONO). > > For your concern about use of SIDs "across" the public Internet. Let me > try to explain using following figure (hope it works): > > CPE1 CPE2 CPE3 > + + + + > | +--------+ | | +----------+ | > +---[1] TN1 [1]---+ +---+ Internet |---+ > +--------+ +----------+ > > In the perspective of the ONO, it has the following SIDs: > SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO. > SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, > marked [1] in the figure). > The ONO can use these SIDs, and I would think they are all "in the overla= y > network", and are running "Over the Internet". > > You mentioned in the last sentence "the use of SIDs over the public > Internet". That is what I am modeling above. > > Thanks > Jingrong > > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org ] > On Behalf Of Tom Hill > Sent: Wednesday, March 9, 2022 10:43 PM > To: spring@ietf.org > Subject: Re: [spring] Network Programming Interface for Provisioning of > Underlay Services to Overlay Networks Using SRv6 > (draft-xie-spring-srv6-npi-for-overlay) > > Hi Jinrong, > > On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote: > > I just posted a draft that specifies a framework and some more detail > > of the idea for provisioning of underlay services > > (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using > SRv6. > > > > https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov > > erlay > > > verlay> > > > > Please comment and send any feedback. > > > > I would like to discuss this document over e-mail/mail-list. > > > I'm concerned that this draft is explicitly violating the concept of > SRv6 as a protocol that operates within a Limited Domain. > > As per Section 3.2 of this draft, "... the network operator of AN, TN and > Internet can be different from each other." > > Further, "In some scenarios, the AN can be an Internet exchange provider > (IXP) independent of ISP and NSP. In some other scenarios, the AN can be > an ISP that running Internet backbone as well." > > This would read to me that the proposal is explicitly intended to be > inter-domain, and not at all limited to any one administrative domain. > Additionally, I cannot determine if the draft implicitly requires the use > of SIDs across the public Internet? > > Could I ask for some clarification on the scope of the draft, with respec= t > to Limited Domains, and also the use of SIDs over the public Internet? > > Kind regards, > > -- > Tom > > _______________________________________________ > 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 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000001cfe8105da0e9ef7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jingrong=C2=A0

I reads the draft and was trying to understand the problem stat= ement as well as the solution.

So I believe the problem statement is how to interconnect desperate = sites over the internet using a managed IPSEC VPN or SDWAN solution or mana= ged MPLS and complexity of provisioning CE attachment.

The solution is an automated solution using = SRv6 over the internet using BSID.=C2=A0 This involves running SRv6 over th= e internet, however SRv6 is limited to closed domains.=C2=A0 It appears an = E2E pseudowire is used in provisioning the service.=C2=A0 Have you though o= f using NG L2 VPN EVPN all or single active multi home over SRv6.=C2=A0

Does all the provisioning u= se a PCE / SDN controller?=C2=A0


Thanks=C2=A0
<= br>
Gyan

On Thu, Mar 10, 2022 at 9:59 AM Andrew = Alston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org> wrote:

Hi Jingrong,

=C2=A0

I=E2=80=99m struggling to entirely understand this.= =C2=A0 I think the question for me is =E2=80=93 if you are sending packets = with SID=E2=80=99s over the open internet =E2=80=93 are you encapsulating t= hose packets and is this encapsulation cryptographically protected =E2=80= =93 I.E the SID=E2=80=99s are not visible outside of the encapsulation, to preserv= e the limited domain.

=C2=A0

Limited domains are typically extended via tunnel me= chanisms, very often with cryptographic protection, hence the question

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

From: spring <spring-bounces@ietf.org> On Beha= lf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill <tom@ninjabadger.net>; spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning= of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6= -npi-for-overlay)

=C2=A0

Hi Tom,

Thanks for reading the draft and raise discussions.

In the proposal the SRv6 domain is the overlay network, belonging to one ad= ministrative domain -- the overlay network operator(say ONO).

For your concern about use of SIDs "across" the public Internet. = Let me try to explain using following figure (hope it works):

CPE1 CPE2 CPE3
+ + + +
| +--------+ | | +----------+ |
+---[1] TN1 [1]---+ +---+ Internet |---+
+--------+ +----------+

In the perspective of the ONO, it has the following SIDs:
SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO.
SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, ma= rked [1] in the figure).
The ONO can use these SIDs, and I would think they are all "in the ove= rlay network", and are running "Over the Internet".

You mentioned in the last sentence "the use of SIDs over the public In= ternet". That is what I am modeling above.

Thanks
Jingrong


-----Original Message-----
From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning of Und= erlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-fo= r-overlay)

Hi Jinrong,

On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> I just posted a draft that specifies a framework and some more detail =
> of the idea for provisioning of underlay services
> (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using= SRv6.
>
> https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov<= br> > erlay
> <https://datatracker.ietf.org/doc/html/dra= ft-xie-spring-srv6-npi-for-o
> verlay>
>
> Please comment and send any feedback.
>
> I would like to discuss this document over e-mail/mail-list.


I'm concerned that this draft is explicitly violating the concept of SRv6 as a protocol that operates within a Limited Domain.

As per Section 3.2 of this draft, "... the network operator of AN, TN = and Internet can be different from each other."

Further, "In some scenarios, the AN can be an Internet exchange provid= er
(IXP) independent of ISP and NSP. In some other scenarios, the AN can be an= ISP that running Internet backbone as well."

This would read to me that the proposal is explicitly intended to be inter-= domain, and not at all limited to any one administrative domain.
Additionally, I cannot determine if the draft implicitly requires the use o= f SIDs across the public Internet?

Could I ask for some clarification on the scope of the draft, with respect = to Limited Domains, and also the use of SIDs over the public Internet?

Kind regards,

--
Tom

_______________________________________________
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

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--0000000000001cfe8105da0e9ef7-- From nobody Mon Mar 14 00:16:33 2022 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 4CDF13A0897 for ; Mon, 14 Mar 2022 00:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 w_kJBUv8jMPK for ; Mon, 14 Mar 2022 00:16:25 -0700 (PDT) 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 EDCA73A1A3D for ; Mon, 14 Mar 2022 00:16:24 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KH79S5d03z67w2D; Mon, 14 Mar 2022 15:15:40 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Mon, 14 Mar 2022 08:16:21 +0100 Received: from kwepeml500002.china.huawei.com (7.221.188.128) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 14 Mar 2022 15:16:19 +0800 Received: from kwepeml500002.china.huawei.com ([7.221.188.128]) by kwepeml500002.china.huawei.com ([7.221.188.128]) with mapi id 15.01.2308.021; Mon, 14 Mar 2022 15:16:19 +0800 From: "Xiejingrong (Jingrong)" To: Gyan Mishra , Andrew Alston - IETF CC: Tom Hill , "spring@ietf.org" Thread-Topic: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) Thread-Index: Adgyj2pEDTIYoRv+Rwm6VOp4IGlK2wA8YiOAADHZrvAAAP1xAAB4Z3+AAFEevQA= Date: Mon, 14 Mar 2022 07:16:19 +0000 Message-ID: References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.112.232.176] Content-Type: multipart/related; boundary="_004_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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, 14 Mar 2022 07:16:31 -0000 --_004_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_ Content-Type: multipart/alternative; boundary="_000_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_" --_000_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgSSBub3cgdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIGNvbmNlcm4gYWJvdXQg InRoZSB1c2Ugb2YgU0lEcyBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQiLg0KSW4gbXkgcHJldmlv dXMgbWFpbCwgdGhlIFNJRDIvU0lEMyB1c2VkIGJldHdlZW4gQ1BFMi1JbnRlcm5ldC1DUEUzIGlz IHRvIGV4cGxhaW4gdGhlIGxheWVyaW5nIG1vZGVsIChvdmVyIHZzIGFjcm9zcyksIGJ1dCBpdCBp cyBub3QgdGhlIHByb3Bvc2FsIG9mIHRoZSBkcmFmdC4NClRoZSBkcmFmdCBpcyB0YWxraW5nIGFi b3V0IHRoZSBpbnRlcmZhY2UgKG5hbWUgTlBJKSB0aGF0IG92ZXJsYXkgbmV0d29ya3MgdXNlIHRv IGFjY2VzcyB0aGUgdW5kZXJseWluZyBuZXR3b3JrIGluIHRoZSBsYXN0IG1pbGUuDQpUaGVyZSBt YXkgYmUgYW4gQWNjZXNzIE5ldHdvcmsgKEFOKSBpbiB0aGUgbGFzdCBtaWxlLCBhbmQgdGhlIEFO IG1heSBhbHNvIGNvbm5lY3QgdG8gSW50ZXJuZXQgYmFja2JvbmUgYW5kL29yIG11bHRpcGxlIHVu ZGVybHlpbmcgbmV0d29ya3MsIGJ1dCBpdCBpcyBkaXN0aW5jdCBmcm9tIHRoZSAib3BlbiBJbnRl cm5ldCIuDQpNYWtlIG1vcmUgc2Vuc2UgaWYgdGhlIEFOIGNhbiBlbmhhbmNlIChpZiBubyB3YXkg dG8gZW5mb3JjZSkgbm90IHRvIGxlYWsgdGhlIFNSdjYgQlNJRCB0byBJbnRlcm5ldCBiYWNrYm9u ZSBvciBvdGhlciBUTnMgPw0KDQpGb3IgdGhlIGNvbnRyb2wgcGxhbmUsIGl0IGlzIHN0aWxsIG5v dCBjbGVhciBpZiBhIGNvbnRyb2xsZXIgaXMgcmVxdWlyZWQsIGJ1dCBvbmUgdGhpbmcgSSBjb25z aWRlcmVkIGlzIHRvIHVzZSBhbiBJRVRGIHN0YW5kYXJkIHByb3RvY29sIGJlY2F1c2UgdGhlIFBF IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBOUEkuDQoNClJlZ2FyZHMsDQpKaW5ncm9uZw0KDQpGcm9t OiBHeWFuIE1pc2hyYSBbbWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRh eSwgTWFyY2ggMTMsIDIwMjIgODoyNiBBTQ0KVG86IEFuZHJldyBBbHN0b24gLSBJRVRGIDxhbmRy ZXctaWV0ZkBsaXF1aWQudGVjaD4NCkNjOiBUb20gSGlsbCA8dG9tQG5pbmphYmFkZ2VyLm5ldD47 IFhpZWppbmdyb25nIChKaW5ncm9uZykgPHhpZWppbmdyb25nQGh1YXdlaS5jb20+OyBzcHJpbmdA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIEludGVy ZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkgTmV0 d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheSkN Cg0KSGkgSmluZ3JvbmcNCg0KSSByZWFkcyB0aGUgZHJhZnQgYW5kIHdhcyB0cnlpbmcgdG8gdW5k ZXJzdGFuZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYXMgd2VsbCBhcyB0aGUgc29sdXRpb24uDQoN ClNvIEkgYmVsaWV2ZSB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgaG93IHRvIGludGVyY29ubmVj dCBkZXNwZXJhdGUgc2l0ZXMgb3ZlciB0aGUgaW50ZXJuZXQgdXNpbmcgYSBtYW5hZ2VkIElQU0VD IFZQTiBvciBTRFdBTiBzb2x1dGlvbiBvciBtYW5hZ2VkIE1QTFMgYW5kIGNvbXBsZXhpdHkgb2Yg cHJvdmlzaW9uaW5nIENFIGF0dGFjaG1lbnQuDQoNClRoZSBzb2x1dGlvbiBpcyBhbiBhdXRvbWF0 ZWQgc29sdXRpb24gdXNpbmcgU1J2NiBvdmVyIHRoZSBpbnRlcm5ldCB1c2luZyBCU0lELiAgVGhp cyBpbnZvbHZlcyBydW5uaW5nIFNSdjYgb3ZlciB0aGUgaW50ZXJuZXQsIGhvd2V2ZXIgU1J2NiBp cyBsaW1pdGVkIHRvIGNsb3NlZCBkb21haW5zLiAgSXQgYXBwZWFycyBhbiBFMkUgcHNldWRvd2ly ZSBpcyB1c2VkIGluIHByb3Zpc2lvbmluZyB0aGUgc2VydmljZS4gIEhhdmUgeW91IHRob3VnaCBv ZiB1c2luZyBORyBMMiBWUE4gRVZQTiBhbGwgb3Igc2luZ2xlIGFjdGl2ZSBtdWx0aSBob21lIG92 ZXIgU1J2Ni4NCg0KRG9lcyBhbGwgdGhlIHByb3Zpc2lvbmluZyB1c2UgYSBQQ0UgLyBTRE4gY29u dHJvbGxlcj8NCg0KDQpUaGFua3MNCg0KR3lhbg0KDQpPbiBUaHUsIE1hciAxMCwgMjAyMiBhdCA5 OjU5IEFNIEFuZHJldyBBbHN0b24gLSBJRVRGIDxhbmRyZXctaWV0Zj00MGxpcXVpZC50ZWNoQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MGxpcXVpZC50ZWNoQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQpIaSBKaW5ncm9uZywNCg0KSeKAmW0gc3RydWdnbGluZyB0byBlbnRpcmVseSB1bmRlcnN0YW5k IHRoaXMuICBJIHRoaW5rIHRoZSBxdWVzdGlvbiBmb3IgbWUgaXMg4oCTIGlmIHlvdSBhcmUgc2Vu ZGluZyBwYWNrZXRzIHdpdGggU0lE4oCZcyBvdmVyIHRoZSBvcGVuIGludGVybmV0IOKAkyBhcmUg eW91IGVuY2Fwc3VsYXRpbmcgdGhvc2UgcGFja2V0cyBhbmQgaXMgdGhpcyBlbmNhcHN1bGF0aW9u IGNyeXB0b2dyYXBoaWNhbGx5IHByb3RlY3RlZCDigJMgSS5FIHRoZSBTSUTigJlzIGFyZSBub3Qg dmlzaWJsZSBvdXRzaWRlIG9mIHRoZSBlbmNhcHN1bGF0aW9uLCB0byBwcmVzZXJ2ZSB0aGUgbGlt aXRlZCBkb21haW4uDQoNCkxpbWl0ZWQgZG9tYWlucyBhcmUgdHlwaWNhbGx5IGV4dGVuZGVkIHZp YSB0dW5uZWwgbWVjaGFuaXNtcywgdmVyeSBvZnRlbiB3aXRoIGNyeXB0b2dyYXBoaWMgcHJvdGVj dGlvbiwgaGVuY2UgdGhlIHF1ZXN0aW9uDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpGcm9tOiBz cHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZz4+IE9uIEJlaGFsZiBPZiBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpDQpTZW50OiBUaHVyc2Rh eSwgTWFyY2ggMTAsIDIwMjIgOTo0MCBBTQ0KVG86IFRvbSBIaWxsIDx0b21AbmluamFiYWRnZXIu bmV0PG1haWx0bzp0b21AbmluamFiYWRnZXIubmV0Pj47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIE5ldHdvcmsgUHJvZ3JhbW1p bmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25pbmcgb2YgVW5kZXJsYXkgU2VydmljZXMgdG8gT3Zl cmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChkcmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1v dmVybGF5KQ0KDQpIaSBUb20sDQoNClRoYW5rcyBmb3IgcmVhZGluZyB0aGUgZHJhZnQgYW5kIHJh aXNlIGRpc2N1c3Npb25zLg0KDQpJbiB0aGUgcHJvcG9zYWwgdGhlIFNSdjYgZG9tYWluIGlzIHRo ZSBvdmVybGF5IG5ldHdvcmssIGJlbG9uZ2luZyB0byBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWlu IC0tIHRoZSBvdmVybGF5IG5ldHdvcmsgb3BlcmF0b3Ioc2F5IE9OTykuDQoNCkZvciB5b3VyIGNv bmNlcm4gYWJvdXQgdXNlIG9mIFNJRHMgImFjcm9zcyIgdGhlIHB1YmxpYyBJbnRlcm5ldC4gTGV0 IG1lIHRyeSB0byBleHBsYWluIHVzaW5nIGZvbGxvd2luZyBmaWd1cmUgKGhvcGUgaXQgd29ya3Mp Og0KDQpDUEUxIENQRTIgQ1BFMw0KKyArICsgKw0KfCArLS0tLS0tLS0rIHwgfCArLS0tLS0tLS0t LSsgfA0KKy0tLVsxXSBUTjEgWzFdLS0tKyArLS0tKyBJbnRlcm5ldCB8LS0tKw0KKy0tLS0tLS0t KyArLS0tLS0tLS0tLSsNCg0KSW4gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBPTk8sIGl0IGhhcyB0 aGUgZm9sbG93aW5nIFNJRHM6DQpTSUQxLzIvMzogYWxsb2NhdGVkIG9uIENQRTEvQ1BFMi9DUEUz IGJ5IHRoZSBPTk8uDQpTSUQ0LzU6IGFsbG9jYXRlZCBieSBUTiBvcGVyYXRvciBidXQgc2VydmVz IGZvciB0aGUgT05PIChUZW5hbnQtMSBvZiBUTiwgbWFya2VkIFsxXSBpbiB0aGUgZmlndXJlKS4N ClRoZSBPTk8gY2FuIHVzZSB0aGVzZSBTSURzLCBhbmQgSSB3b3VsZCB0aGluayB0aGV5IGFyZSBh bGwgImluIHRoZSBvdmVybGF5IG5ldHdvcmsiLCBhbmQgYXJlIHJ1bm5pbmcgIk92ZXIgdGhlIElu dGVybmV0Ii4NCg0KWW91IG1lbnRpb25lZCBpbiB0aGUgbGFzdCBzZW50ZW5jZSAidGhlIHVzZSBv ZiBTSURzIG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldCIuIFRoYXQgaXMgd2hhdCBJIGFtIG1vZGVs aW5nIGFib3ZlLg0KDQpUaGFua3MNCkppbmdyb25nDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgVG9tIEhpbGwNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggOSwgMjAyMiAxMDo0MyBQ TQ0KVG86IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtzcHJpbmddIE5ldHdvcmsgUHJvZ3JhbW1pbmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25p bmcgb2YgVW5kZXJsYXkgU2VydmljZXMgdG8gT3ZlcmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChk cmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1vdmVybGF5KQ0KDQpIaSBKaW5yb25nLA0KDQpP biAwOC8wMy8yMDIyIDAxOjU4LCBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpIHdyb3RlOg0KPiBJIGp1 c3QgcG9zdGVkIGEgZHJhZnQgdGhhdCBzcGVjaWZpZXMgYSBmcmFtZXdvcmsgYW5kIHNvbWUgbW9y ZSBkZXRhaWwNCj4gb2YgdGhlIGlkZWEgZm9yIHByb3Zpc2lvbmluZyBvZiB1bmRlcmxheSBzZXJ2 aWNlcw0KPiAoU2xpY2UvU1ItcG9saWN5L01jYXN0L2V0YykgdG8gb3ZlcmxheSBuZXR3b3JrcyhT RC1XQU4vQ0ROL2V0YyksIHVzaW5nIFNSdjYuDQo+DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3YNCj4gZXJsYXkN Cj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGllLXNwcmlu Zy1zcnY2LW5waS1mb3Itbw0KPiB2ZXJsYXk+DQo+DQo+IFBsZWFzZSBjb21tZW50IGFuZCBzZW5k IGFueSBmZWVkYmFjay4NCj4NCj4gSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhpcyBkb2N1bWVu dCBvdmVyIGUtbWFpbC9tYWlsLWxpc3QuDQoNCg0KSSdtIGNvbmNlcm5lZCB0aGF0IHRoaXMgZHJh ZnQgaXMgZXhwbGljaXRseSB2aW9sYXRpbmcgdGhlIGNvbmNlcHQgb2YNClNSdjYgYXMgYSBwcm90 b2NvbCB0aGF0IG9wZXJhdGVzIHdpdGhpbiBhIExpbWl0ZWQgRG9tYWluLg0KDQpBcyBwZXIgU2Vj dGlvbiAzLjIgb2YgdGhpcyBkcmFmdCwgIi4uLiB0aGUgbmV0d29yayBvcGVyYXRvciBvZiBBTiwg VE4gYW5kIEludGVybmV0IGNhbiBiZSBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLiINCg0KRnVy dGhlciwgIkluIHNvbWUgc2NlbmFyaW9zLCB0aGUgQU4gY2FuIGJlIGFuIEludGVybmV0IGV4Y2hh bmdlIHByb3ZpZGVyDQooSVhQKSBpbmRlcGVuZGVudCBvZiBJU1AgYW5kIE5TUC4gSW4gc29tZSBv dGhlciBzY2VuYXJpb3MsIHRoZSBBTiBjYW4gYmUgYW4gSVNQIHRoYXQgcnVubmluZyBJbnRlcm5l dCBiYWNrYm9uZSBhcyB3ZWxsLiINCg0KVGhpcyB3b3VsZCByZWFkIHRvIG1lIHRoYXQgdGhlIHBy b3Bvc2FsIGlzIGV4cGxpY2l0bHkgaW50ZW5kZWQgdG8gYmUgaW50ZXItZG9tYWluLCBhbmQgbm90 IGF0IGFsbCBsaW1pdGVkIHRvIGFueSBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KQWRkaXRp b25hbGx5LCBJIGNhbm5vdCBkZXRlcm1pbmUgaWYgdGhlIGRyYWZ0IGltcGxpY2l0bHkgcmVxdWly ZXMgdGhlIHVzZSBvZiBTSURzIGFjcm9zcyB0aGUgcHVibGljIEludGVybmV0Pw0KDQpDb3VsZCBJ IGFzayBmb3Igc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQsIHdp dGggcmVzcGVjdCB0byBMaW1pdGVkIERvbWFpbnMsIGFuZCBhbHNvIHRoZSB1c2Ugb2YgU0lEcyBv dmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQ/DQoNCktpbmQgcmVnYXJkcywNCg0KLS0NClRvbQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1h aWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0K c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCi0tDQoNClvlm77lg4/lt7Looqvlj5Hku7bkurrliKDpmaTjgIJdPGh0 dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KDQpHeWFuIE1pc2hyYQ0KDQpOZXR3b3JrIFNvbHV0aW9u cyBBcmNoaXRlY3QNCg0KRW1haWwgZ3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lh bi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4NCg0KTSAzMDEgNTAyLTEzNDcNCg0K --_000_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIEkgbm93 IHVuZGVyc3RhbmQgYmV0dGVyIHRoZSBjb25jZXJuIGFib3V0ICZxdW90O3RoZSB1c2Ugb2YgU0lE cyBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgU0lEMi9TSUQzIHVzZWQgYmV0d2VlbiBD UEUyLUludGVybmV0LUNQRTMgaXMgdG8gZXhwbGFpbiB0aGUgbGF5ZXJpbmcgbW9kZWwgKG92ZXIg dnMgYWNyb3NzKSwgYnV0IGl0IGlzIG5vdCB0aGUgcHJvcG9zYWwNCiBvZiB0aGUgZHJhZnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgaXMgdGFsa2luZyBhYm91dCB0 aGUgaW50ZXJmYWNlIChuYW1lIE5QSSkgdGhhdCBvdmVybGF5IG5ldHdvcmtzIHVzZSB0byBhY2Nl c3MgdGhlIHVuZGVybHlpbmcgbmV0d29yayBpbiB0aGUgbGFzdCBtaWxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgbWF5IGJlIGFuIEFjY2VzcyBOZXR3b3JrIChBTikgaW4g dGhlIGxhc3QgbWlsZSwgYW5kIHRoZSBBTiBtYXkgYWxzbyBjb25uZWN0IHRvIEludGVybmV0IGJh Y2tib25lIGFuZC9vciBtdWx0aXBsZSB1bmRlcmx5aW5nIG5ldHdvcmtzLCBidXQgaXQNCiBpcyBk aXN0aW5jdCBmcm9tIHRoZSAmcXVvdDtvcGVuIEludGVybmV0JnF1b3Q7LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+TWFrZSBtb3JlIHNlbnNlIGlmIHRoZSBBTiBjYW4gZW5oYW5jZSAo aWYgbm8gd2F5IHRvIGVuZm9yY2UpIG5vdCB0byBsZWFrIHRoZSBTUnY2IEJTSUQgdG8gSW50ZXJu ZXQgYmFja2JvbmUgb3Igb3RoZXIgVE5zID8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIGNvbnRyb2wg cGxhbmUsIGl0IGlzIHN0aWxsIG5vdCBjbGVhciBpZiBhIGNvbnRyb2xsZXIgaXMgcmVxdWlyZWQs IGJ1dCBvbmUgdGhpbmcgSSBjb25zaWRlcmVkIGlzIHRvIHVzZSBhbiBJRVRGIHN0YW5kYXJkIHBy b3RvY29sIGJlY2F1c2UNCiB0aGUgUEUgbmVlZCB0byBpbXBsZW1lbnQgdGhlIE5QSS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppbmdyb25nPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEd5YW4gTWlzaHJh IFttYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgTWFyY2ggMTMsIDIwMjIgODoyNiBBTTxicj4NCjxiPlRvOjwvYj4gQW5kcmV3IEFsc3RvbiAt IElFVEYgJmx0O2FuZHJldy1pZXRmQGxpcXVpZC50ZWNoJmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9t IEhpbGwgJmx0O3RvbUBuaW5qYWJhZGdlci5uZXQmZ3Q7OyBYaWVqaW5ncm9uZyAoSmluZ3Jvbmcp ICZsdDt4aWVqaW5ncm9uZ0BodWF3ZWkuY29tJmd0Ozsgc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIEludGVyZmFjZSBm b3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkgTmV0d29ya3Mg VXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBKaW5ncm9uZyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSByZWFkcyB0aGUgZHJhZnQgYW5kIHdhcyB0 cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYXMgd2VsbCBhcyB0aGUg c29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TbyBJIGJlbGlldmUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGlzIGhvdyB0byBpbnRlcmNvbm5l Y3QgZGVzcGVyYXRlIHNpdGVzIG92ZXIgdGhlIGludGVybmV0IHVzaW5nIGEgbWFuYWdlZCBJUFNF QyBWUE4gb3IgU0RXQU4gc29sdXRpb24gb3IgbWFuYWdlZCBNUExTIGFuZCBjb21wbGV4aXR5IG9m IHByb3Zpc2lvbmluZyBDRSBhdHRhY2htZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHNvbHV0aW9uIGlzIGFuIGF1dG9tYXRlZCBzb2x1dGlv biB1c2luZyBTUnY2IG92ZXIgdGhlIGludGVybmV0IHVzaW5nIEJTSUQuJm5ic3A7IFRoaXMgaW52 b2x2ZXMgcnVubmluZyBTUnY2IG92ZXIgdGhlIGludGVybmV0LCBob3dldmVyIFNSdjYgaXMgbGlt aXRlZCB0byBjbG9zZWQgZG9tYWlucy4mbmJzcDsgSXQgYXBwZWFycyBhbiBFMkUgcHNldWRvd2ly ZSBpcyB1c2VkIGluIHByb3Zpc2lvbmluZw0KIHRoZSBzZXJ2aWNlLiZuYnNwOyBIYXZlIHlvdSB0 aG91Z2ggb2YgdXNpbmcgTkcgTDIgVlBOIEVWUE4gYWxsIG9yIHNpbmdsZSBhY3RpdmUgbXVsdGkg aG9tZSBvdmVyIFNSdjYuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5Eb2VzIGFsbCB0aGUgcHJvdmlzaW9uaW5nIHVzZSBhIFBDRSAvIFNETiBj b250cm9sbGVyPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R3lhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUaHUsIE1hciAxMCwgMjAy MiBhdCA5OjU5IEFNIEFuZHJldyBBbHN0b24gLSBJRVRGICZsdDthbmRyZXctaWV0Zj08YSBocmVm PSJtYWlsdG86NDBsaXF1aWQudGVjaEBkbWFyYy5pZXRmLm9yZyI+NDBsaXF1aWQudGVjaEBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+SGkgSmluZ3JvbmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SeKAmW0gc3Ry dWdnbGluZyB0byBlbnRpcmVseSB1bmRlcnN0YW5kIHRoaXMuJm5ic3A7IEkgdGhpbmsgdGhlIHF1 ZXN0aW9uIGZvciBtZSBpcyDigJMgaWYgeW91IGFyZSBzZW5kaW5nIHBhY2tldHMgd2l0aCBTSUTi gJlzIG92ZXIgdGhlIG9wZW4gaW50ZXJuZXQg4oCTIGFyZSB5b3UgZW5jYXBzdWxhdGluZw0KIHRo b3NlIHBhY2tldHMgYW5kIGlzIHRoaXMgZW5jYXBzdWxhdGlvbiBjcnlwdG9ncmFwaGljYWxseSBw cm90ZWN0ZWQg4oCTIEkuRSB0aGUgU0lE4oCZcyBhcmUgbm90IHZpc2libGUgb3V0c2lkZSBvZiB0 aGUgZW5jYXBzdWxhdGlvbiwgdG8gcHJlc2VydmUgdGhlIGxpbWl0ZWQgZG9tYWluLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPkxpbWl0ZWQgZG9tYWlucyBhcmUgdHlwaWNhbGx5IGV4dGVuZGVkIHZp YSB0dW5uZWwgbWVjaGFuaXNtcywgdmVyeSBvZnRlbiB3aXRoIGNyeXB0b2dyYXBoaWMgcHJvdGVj dGlvbiwgaGVuY2UgdGhlIHF1ZXN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5kcmV3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHNw cmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9m IDwvYj5YaWVqaW5ncm9uZyAoSmluZ3JvbmcpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBN YXJjaCAxMCwgMjAyMiA5OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBUb20gSGlsbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvbUBuaW5qYWJhZGdlci5uZXQiIHRhcmdldD0iX2JsYW5rIj50b21AbmluamFi YWRnZXIubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NwcmluZ10gTmV0d29yayBQcm9ncmFtbWluZyBJbnRlcmZhY2UgZm9yIFByb3Zpc2lvbmluZyBv ZiBVbmRlcmxheSBTZXJ2aWNlcyB0byBPdmVybGF5IE5ldHdvcmtzIFVzaW5nIFNSdjYgKGRyYWZ0 LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9yLW92ZXJsYXkpPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPkhpIFRvbSw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHJlYWRpbmcgdGhl IGRyYWZ0IGFuZCByYWlzZSBkaXNjdXNzaW9ucy48YnI+DQo8YnI+DQpJbiB0aGUgcHJvcG9zYWwg dGhlIFNSdjYgZG9tYWluIGlzIHRoZSBvdmVybGF5IG5ldHdvcmssIGJlbG9uZ2luZyB0byBvbmUg YWRtaW5pc3RyYXRpdmUgZG9tYWluIC0tIHRoZSBvdmVybGF5IG5ldHdvcmsgb3BlcmF0b3Ioc2F5 IE9OTykuDQo8YnI+DQo8YnI+DQpGb3IgeW91ciBjb25jZXJuIGFib3V0IHVzZSBvZiBTSURzICZx dW90O2Fjcm9zcyZxdW90OyB0aGUgcHVibGljIEludGVybmV0LiBMZXQgbWUgdHJ5IHRvIGV4cGxh aW4gdXNpbmcgZm9sbG93aW5nIGZpZ3VyZSAoaG9wZSBpdCB3b3Jrcyk6PGJyPg0KPGJyPg0KQ1BF MSBDUEUyIENQRTM8YnI+DQomIzQzOyAmIzQzOyAmIzQzOyAmIzQzOzxicj4NCnwgJiM0MzstLS0t LS0tLSYjNDM7IHwgfCAmIzQzOy0tLS0tLS0tLS0mIzQzOyB8PGJyPg0KJiM0MzstLS1bMV0gVE4x IFsxXS0tLSYjNDM7ICYjNDM7LS0tJiM0MzsgSW50ZXJuZXQgfC0tLSYjNDM7PGJyPg0KJiM0Mzst LS0tLS0tLSYjNDM7ICYjNDM7LS0tLS0tLS0tLSYjNDM7IDxicj4NCjxicj4NCkluIHRoZSBwZXJz cGVjdGl2ZSBvZiB0aGUgT05PLCBpdCBoYXMgdGhlIGZvbGxvd2luZyBTSURzOjxicj4NClNJRDEv Mi8zOiBhbGxvY2F0ZWQgb24gQ1BFMS9DUEUyL0NQRTMgYnkgdGhlIE9OTy48YnI+DQpTSUQ0LzU6 IGFsbG9jYXRlZCBieSBUTiBvcGVyYXRvciBidXQgc2VydmVzIGZvciB0aGUgT05PIChUZW5hbnQt MSBvZiBUTiwgbWFya2VkIFsxXSBpbiB0aGUgZmlndXJlKS48YnI+DQpUaGUgT05PIGNhbiB1c2Ug dGhlc2UgU0lEcywgYW5kIEkgd291bGQgdGhpbmsgdGhleSBhcmUgYWxsICZxdW90O2luIHRoZSBv dmVybGF5IG5ldHdvcmsmcXVvdDssIGFuZCBhcmUgcnVubmluZyAmcXVvdDtPdmVyIHRoZSBJbnRl cm5ldCZxdW90Oy4NCjxicj4NCjxicj4NCllvdSBtZW50aW9uZWQgaW4gdGhlIGxhc3Qgc2VudGVu Y2UgJnF1b3Q7dGhlIHVzZSBvZiBTSURzIG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldCZxdW90Oy4g VGhhdCBpcyB3aGF0IEkgYW0gbW9kZWxpbmcgYWJvdmUuPGJyPg0KPGJyPg0KVGhhbmtzPGJyPg0K SmluZ3Jvbmc8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IHNwcmluZyBbPGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIFRvbSBIaWxsPGJyPg0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCA5LCAyMDIyIDEwOjQz IFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIE5ldHdv cmsgUHJvZ3JhbW1pbmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25pbmcgb2YgVW5kZXJsYXkgU2Vy dmljZXMgdG8gT3ZlcmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChkcmFmdC14aWUtc3ByaW5nLXNy djYtbnBpLWZvci1vdmVybGF5KTxicj4NCjxicj4NCkhpIEppbnJvbmcsPGJyPg0KPGJyPg0KT24g MDgvMDMvMjAyMiAwMTo1OCwgWGllamluZ3JvbmcgKEppbmdyb25nKSB3cm90ZTo8YnI+DQomZ3Q7 IEkganVzdCBwb3N0ZWQgYSBkcmFmdCB0aGF0IHNwZWNpZmllcyBhIGZyYW1ld29yayBhbmQgc29t ZSBtb3JlIGRldGFpbCA8YnI+DQomZ3Q7IG9mIHRoZSBpZGVhIGZvciBwcm92aXNpb25pbmcgb2Yg dW5kZXJsYXkgc2VydmljZXM8YnI+DQomZ3Q7IChTbGljZS9TUi1wb2xpY3kvTWNhc3QvZXRjKSB0 byBvdmVybGF5IG5ldHdvcmtzKFNELVdBTi9DRE4vZXRjKSwgdXNpbmcgU1J2Ni48YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1vdiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14aWUtc3ByaW5nLXNydjYt bnBpLWZvci1vdjwvYT48YnI+DQomZ3Q7IGVybGF5IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGllLXNwcmluZy1zcnY2 LW5waS1mb3ItbyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3ItbzwvYT48YnI+DQomZ3Q7IHZl cmxheSZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIGNvbW1lbnQgYW5kIHNlbmQgYW55 IGZlZWRiYWNrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdvdWxkIGxpa2UgdG8gZGlzY3VzcyB0 aGlzIGRvY3VtZW50IG92ZXIgZS1tYWlsL21haWwtbGlzdC48YnI+DQo8YnI+DQo8YnI+DQpJJ20g Y29uY2VybmVkIHRoYXQgdGhpcyBkcmFmdCBpcyBleHBsaWNpdGx5IHZpb2xhdGluZyB0aGUgY29u Y2VwdCBvZjxicj4NClNSdjYgYXMgYSBwcm90b2NvbCB0aGF0IG9wZXJhdGVzIHdpdGhpbiBhIExp bWl0ZWQgRG9tYWluLjxicj4NCjxicj4NCkFzIHBlciBTZWN0aW9uIDMuMiBvZiB0aGlzIGRyYWZ0 LCAmcXVvdDsuLi4gdGhlIG5ldHdvcmsgb3BlcmF0b3Igb2YgQU4sIFROIGFuZCBJbnRlcm5ldCBj YW4gYmUgZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlci4mcXVvdDs8YnI+DQo8YnI+DQpGdXJ0aGVy LCAmcXVvdDtJbiBzb21lIHNjZW5hcmlvcywgdGhlIEFOIGNhbiBiZSBhbiBJbnRlcm5ldCBleGNo YW5nZSBwcm92aWRlcjxicj4NCihJWFApIGluZGVwZW5kZW50IG9mIElTUCBhbmQgTlNQLiBJbiBz b21lIG90aGVyIHNjZW5hcmlvcywgdGhlIEFOIGNhbiBiZSBhbiBJU1AgdGhhdCBydW5uaW5nIElu dGVybmV0IGJhY2tib25lIGFzIHdlbGwuJnF1b3Q7PGJyPg0KPGJyPg0KVGhpcyB3b3VsZCByZWFk IHRvIG1lIHRoYXQgdGhlIHByb3Bvc2FsIGlzIGV4cGxpY2l0bHkgaW50ZW5kZWQgdG8gYmUgaW50 ZXItZG9tYWluLCBhbmQgbm90IGF0IGFsbCBsaW1pdGVkIHRvIGFueSBvbmUgYWRtaW5pc3RyYXRp dmUgZG9tYWluLg0KPGJyPg0KQWRkaXRpb25hbGx5LCBJIGNhbm5vdCBkZXRlcm1pbmUgaWYgdGhl IGRyYWZ0IGltcGxpY2l0bHkgcmVxdWlyZXMgdGhlIHVzZSBvZiBTSURzIGFjcm9zcyB0aGUgcHVi bGljIEludGVybmV0Pzxicj4NCjxicj4NCkNvdWxkIEkgYXNrIGZvciBzb21lIGNsYXJpZmljYXRp b24gb24gdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCwgd2l0aCByZXNwZWN0IHRvIExpbWl0ZWQgRG9t YWlucywgYW5kIGFsc28gdGhlIHVzZSBvZiBTSURzIG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldD88 YnI+DQo8YnI+DQpLaW5kIHJlZ2FyZHMsPGJyPg0KPGJyPg0KLS08YnI+DQpUb208YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNw cmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJp bmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48YSBo cmVmPSJodHRwOi8vd3d3LnZlcml6b24uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjojMTE1NUNDO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNt O3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjgxIiBoZWlnaHQ9 IjE4IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEODM3QjUuRTYy Mzk3MTAiIGFsdD0i5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCIj48L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdDttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5HeWFuIE1pc2hyYTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TmV0 d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tbGluZS1oZWlnaHQtYWx0Ojku NzVwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPkVtYWlsDQo8YSBo cmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmd5 YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4w cHQ7bWFyZ2luLWxlZnQ6MGNtO21zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0Ij4NCjxpPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJp Zjtjb2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_-- --_004_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=356; creation-date="Mon, 14 Mar 2022 07:16:19 GMT"; modification-date="Mon, 14 Mar 2022 07:16:19 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAASAFEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK/9k= --_004_b8627f4a8a6d4cdba18db4f37ee4e219huaweicom_-- From nobody Mon Mar 14 08:08:59 2022 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 8D6813A0A21 for ; Mon, 14 Mar 2022 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquid.tech 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 ksG5jSBVVONZ for ; Mon, 14 Mar 2022 08:08:10 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (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 4CA093A15B8 for ; Mon, 14 Mar 2022 08:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1647270487; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xtqq1JYHZ+HAA10E1B0Z3AOl6m+qTJuaCAk1UO3Cx+w=; b=Id4KWulVGOzrO9ESVfHGZeRrhluWSEVkZePRJC15urbDP6Vg9i8YEJjHFTspJ7rgCTWWGB nwu0YEifTioTJ5kar+B/XM+xbIbzMDzXOFegvQVbeJDQNiSR0j6GDJUUkG2VaDd5s3PYJJ VTY2ybZrUlABK42nyddM5I8rDmjG8gQ= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2106.outbound.protection.outlook.com [104.47.17.106]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id uk-mta-309-qh_I3n2dNP2GRpMX7dKxgg-1; Mon, 14 Mar 2022 15:08:05 +0000 X-MC-Unique: qh_I3n2dNP2GRpMX7dKxgg-1 Received: from AM7PR03MB6451.eurprd03.prod.outlook.com (2603:10a6:20b:1b3::22) by DB6PR0301MB2150.eurprd03.prod.outlook.com (2603:10a6:4:46::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.28; Mon, 14 Mar 2022 15:08:02 +0000 Received: from AM7PR03MB6451.eurprd03.prod.outlook.com ([fe80::e856:ef51:ae22:309b]) by AM7PR03MB6451.eurprd03.prod.outlook.com ([fe80::e856:ef51:ae22:309b%8]) with mapi id 15.20.5061.028; Mon, 14 Mar 2022 15:08:02 +0000 From: Andrew Alston - IETF To: "Ahmed Abdelsalam (ahabdels)" , "spring@ietf.org" , "spring-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-path-tracing-00.txt Thread-Index: AQHYL99cD4laBHfqlECFrXblL/g+Fay3HxwEgAfp/xA= Date: Mon, 14 Mar 2022 15:08:02 +0000 Message-ID: References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f6ff922-a3a2-4a9a-9178-08da05cc6f70 x-ms-traffictypediagnostic: DB6PR0301MB2150:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: CHkFVmaCfeOudDSbIhc98Xr8jEraF3IBkQSv1oZ/epUZeMpDLKleBT+8t0XdShhrOfl9IeO87PBuRClHRuFAvbwilvB63G7s26NF036b9SPPcKCyPdaeAIMe+q0is6vhIEszO6qwOU7/wnSajaOBOM6seTmNVPlCsMGS+FHT2FbFvJ0S8fMKkTfeJhqBCTKoIkXEsnePHRFEKP16UHrv8k6ILW3DHDMQiRTqsYhdtEIrAVYjxgrxY3fBjQPSHz+DtS6ANWmQNysfCXNFNJFkXukrjixIWB5Soe3TAtl3pcTCykrqcqvqGHse0N5JTPhtiHlyNQb5Oq66YiNWptRahyDWXkMiFZDBFZwwCQtaiyEMYwhBUd+YDycZe4vFQCeNzRPW+7E/hSPFFcbK6cd5KBKcIizjht5Aq1HRCgJAwQXDpGC8owDvx29jawvWmhYHWR+XpG//s5JIbFmFBM5EO+5j6gMemEn7vdvcaARMiOhAKqkDibU57MQ5hTTiNUeiTCZtsQ5zXsT6Wg2SlCm+1v+d9WxxG61WifbLMwrqYauWv5wGZa87mtrHIsoxhlwITqyT3ZWDO8Veg5rYfzYGPnsgsAYqE1/XmMM2TqU6KPE07fibyaCwpSWNP7PX8sUi2r0Ei4G74FJAab5JWqP5aTNY/LAhigwx01AsUmdK8id/w1S+wv+R/SoJBQQf37LPmwRemluLSoFAbV1/NQhSCC8Pg0LvYb9ZSc271FfEldhEJKKRRoVPwhrhI81jFHYQC6F8hio5d/W7Ek2Qph3LucIJ8JJ/oVtDgpe7XhrIIXvFuZXHFLxyKJlpvn5cOvIse08hIsIVca3gLbUQFapQ7g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR03MB6451.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(55016003)(508600001)(122000001)(71200400001)(966005)(2906002)(8676002)(66574015)(9326002)(8936002)(38070700005)(15650500001)(6506007)(66446008)(52536014)(186003)(38100700002)(9686003)(83380400001)(5660300002)(76116006)(53546011)(7696005)(66946007)(316002)(33656002)(66556008)(166002)(66476007)(64756008)(110136005)(86362001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CGQ+0moJcgTWJ608xlPxUlxTp2pt3/Hic0EX6xtoR+emRxesa+UtdrEfn67G?= =?us-ascii?Q?B865ZyLW7O6k84OYEQmrB5a/nAlGyoKE8kRUhLfGwlbAAQJJY5sQEQq/OQbF?= =?us-ascii?Q?A6bHAfeSnfBSyQq5qEKgAa/Bvs3trSpDNcr6o922nlIvuwNpGNkog8kabqPT?= =?us-ascii?Q?XX0uNk9luJyUNTooZLTsgO9PE0GIxtnt1qt6bNHB2A3EWN5Ak2MVxQOVAgVn?= =?us-ascii?Q?XGslokKJzdAsJYR6pTZFPqE9C5khu28QjAxObuDFOw+sDlxmieOSZmQD1wOM?= =?us-ascii?Q?aoclzSX0yOyTe4GXzWAxNEHIOt+Bc8lF3BSblEzMlKYNERHBKdNVOemWnSgy?= =?us-ascii?Q?2DbWPhIcicEjzqdPUfDUInBapGmg0CB0rmQCVgnxYE9aiwBSmwib0DLUoGVB?= =?us-ascii?Q?qx+Cafo8ESObcvjU4Kt1hBAcOkYuc9JwqsQXTIL/tVUSdXB0iRLryjjH/ALF?= =?us-ascii?Q?hj39zJ6pkOc9kMVIoo5zjEXUH2Qy4vdcl0bq35oLetQQoN9+dXylQnXAC4Tk?= =?us-ascii?Q?V3Lz7yVUbewBPu2CtA8WudugsUDHiWyEtlfhB7awVQD5Y0iESTILBWhCiSv0?= =?us-ascii?Q?kWkrf3PhVckUqRw19bmPcmJxX5An6Nv/xlzAfkvruknpyM6hkToCW9IKbQhM?= =?us-ascii?Q?jQJ1AxypeMO5vB0Xv9trlZ2aFpXchl5Ndj1v/J5B2O/H4BBfEDg5IMet2Plq?= =?us-ascii?Q?ZXiffONhd0I8ACBgzHzcX0FTrneeQo5RbW+xQxC96PSB7TzIL38axpbtI7kw?= =?us-ascii?Q?igFx8yhRRSzOlPO8jM1caJ1Iw1YPye5pzDakxJAClbZxPNMXuizYjLCEcGLH?= =?us-ascii?Q?9weFZbI2i1t5U0GpRrBGZYOb+x43KR9U2OXWKgoJLRLKz3hBJX/b636jtLZH?= =?us-ascii?Q?nPcU7GhoIPH9qLyXZMe5mH1fTllg68BVfmzoXa55r6sEqRQtoyqKhJBE0ouT?= =?us-ascii?Q?ZUs0mDUmBoYxHrNKSWbgO/h42j80F9k9exf8o+Kave8FB9gvZsA9nD1ufcGG?= =?us-ascii?Q?9RWF5s1XpUxmmABuQlCwvKa2eo4WsGd3gC4CbX7g8as6OcFFUasKhMqQxFN1?= =?us-ascii?Q?4YtY6g0VkMUSYaaayiqAty9lHaS5WSritf/owuC0S1cSDGa4RT7bUBxGuKIq?= =?us-ascii?Q?wDzf7HUhwhL3uI9FffRtC1Rrop3Edo4OTkhdh3t2Jc9WWHgIRxG+dwQij7Vo?= =?us-ascii?Q?JQSiPdQm3yOPXSvRdTvcDc3TvBy+3SCUIWF0Kq4JMUSMRB1k0/akumK0nvX8?= =?us-ascii?Q?P033BVYHM7wU6FkKZMcOODs+bl/xO4culianl7RIumDLm44oFGLEKBkfF+J7?= =?us-ascii?Q?MA8ljPx+VTsmV44XlkpT9CLeZzS8qXesG5YS30O7dKLScdMGQtRi6fIJokXk?= =?us-ascii?Q?JqmhT6k6PsMtVKKvVrU+W5gDCDFZauINsTv0cYpO+0s1TL0ksfZHXl8M4G5K?= =?us-ascii?Q?Fud248Jw7pYyJ58wBWmpelk4+ZPt/+1byVKvdrsRDHIl52gNSc2bSoLwWo+W?= =?us-ascii?Q?k6dnWFk0Xp7uuUD4EV9fOI/j5Kr6t2/Ls0coUC9zbMHfS0NXAy+KmJmEyw?= =?us-ascii?Q?=3D=3D?= MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR03MB6451.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f6ff922-a3a2-4a9a-9178-08da05cc6f70 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2022 15:08:02.6680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HCKqi9lJrWlUlJKZ1PUYeePN8k/ONfIt3+R+iITHkYfMOvoiusMDaZxQkYpj6h1F0BQkUtrWK71oGAsxT0CO57fHaKkvIRYboAYceqCiAig= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0301MB2150 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew-ietf@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM7PR03MB645165728AAB9A311090E1A8EE0F9AM7PR03MB6451eurp_" Archived-At: Subject: Re: [spring] New Version Notification for draft-filsfils-spring-path-tracing-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: Mon, 14 Mar 2022 15:08:19 -0000 --_000_AM7PR03MB645165728AAB9A311090E1A8EE0F9AM7PR03MB6451eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi There, Speaking entirely as a working group participant, I have two substantial concerns with this document at first skim read. Firstly - the 12 bits for an interface ID - I have serious concerns that th= is will be far from sufficient. Keep in mind you have interface specific V= LAN's (that alone can eat 12 bits), you have PWHE terminated interfaces - a= nd I know of several cases where those are used for termination of logical = circuits that would be doing this type of traffic, etc etc, and in effect, = you can very easily exceed the 4096 interface ID's on a single router. Secondly, in the security considerations section of the document, last para= graph of section 11. It states "The HBH-PT option MUST be processed at lin= e rate." I think the wording here probably needs work. Could we not say th= at "A router that cannot process the HBH-PT option in fast path must ignore= said option" Because "line rate" does not actually refer to packets that a= void punt to the CPU - all it means is that the CPU's are fast enough to no= t slow other things down while processing it. Thanks Andrew From: spring On Behalf Of Ahmed Abdelsalam (ahabd= els) Sent: Wednesday, March 9, 2022 5:13 PM To: spring@ietf.org; spring-chairs@ietf.org; ippm@ietf.org Subject: [spring] FW: New Version Notification for draft-filsfils-spring-pa= th-tracing-00.txt Dear SPRING WG, IPPM WG, We have submitted a new I-D for Path Tracing in SRv6 networks (https://data= tracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG. We are looking for your feedback and comments. Path Tracing provides a record of the packet path as a sequence of interfac= e ids. In addition, it provides a record of end-to-end delay, per-hop delay= , and load on each egress interface along the packet delivery path to facil= itate operation of SR networks. Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop e= xtension header. We will present Path Tracing to the SPRING WG at next IETF (https://datatra= cker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) Thanks, Ahmed From: internet-drafts@ietf.org Date: Friday, 4 March 2022 at 16:48 To: Ahmed Abdelsalam (ahabdels) , cf(mailer list) , Mark Yufit , Pablo Camarillo (pcamaril)= , Pablo Camarillo (pcamaril) , Sat= oru Matsushima , Thomas.Graf , Yuanchao Su Subject: New Version Notification for draft-filsfils-spring-path-tracing-00= .txt A new version of I-D, draft-filsfils-spring-path-tracing-00.txt has been successfully submitted by Pablo Camarillo Garvia and posted to the IETF repository. Name: draft-filsfils-spring-path-tracing Revision: 00 Title: Path Tracing in SRv6 networks Document date: 2022-03-04 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-filsfils-spring-path-= tracing-00.txt Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-path= -tracing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-filsfils-spring= -path-tracing Abstract: Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. The IETF Secretariat --_000_AM7PR03MB645165728AAB9A311090E1A8EE0F9AM7PR03MB6451eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi There,

 

Speaking entirely a= s a working group participant,

 

I have two substant= ial concerns with this document at first skim read.

 

Firstly – the= 12 bits for an interface ID – I have serious concerns that this will= be far from sufficient.  Keep in mind you have interface specific VLA= N’s (that alone can eat 12 bits), you have PWHE terminated interfaces – and I know of several cases where those are used for te= rmination of logical circuits that would be doing this type of traffic, etc= etc, and in effect, you can very easily exceed the 4096 interface ID’= ;s on a single router.

 

Secondly, in the se= curity considerations section of the document, last paragraph of section 11= .  It states “The HBH-PT option MUST be processed at line rate.&= #8221; I think the wording here probably needs work.  Could we not say that “A router that cannot process the HBH-PT optio= n in fast path must ignore said option” Because “line rate̶= 1; does not actually refer to packets that avoid punt to the CPU – al= l it means is that the CPU’s are fast enough to not slow other things down while processing it.

 

Thanks

 

Andrew

 

 

 

 

From:= spring <spring-bounces@ietf.org> On Behalf Of Ahmed Abdelsalam (ahabdels)
Sent: Wednesday, March 9, 2022 5:13 PM
To: spring@ietf.org; spring-chairs@ietf.org; ippm@ietf.org
Subject: [spring] FW: New Version Notification for draft-filsfils-sp= ring-path-tracing-00.txt

 

Dear SPRING WG,&nbs= p; IPPM WG,

 

We have submitted a= new I-D for Path Tracing in SRv6 networks (https://datatracker.i= etf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG.

 

We are looking for = your feedback and comments.

 

Path Tracing provid= es a record of the packet path as a sequence of interface ids. In addition,= it provides a record of end-to-end delay, per-hop delay, and load on each = egress interface along the packet delivery path to facilitate operation of SR networks.

 

Path Tracing allows= to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop extension header.

 

We will present Pat= h Tracing to the SPRING WG at next IETF (https://datatracker.i= etf.org/meeting/113/materials/agenda-113-spring-00.txt)

 

Thanks,<= /span>

Ahmed

 

From: internet-drafts@iet= f.org <internet-drafts@ietf.org>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, cf(maile= r list) <cf@cisco.com>, Mark Yufit <mark.yufit@broadcom.com>, P= ablo Camarillo (pcamaril) <pcamaril@cisco.com>, Pablo Camarillo (pcam= aril) <pcamaril@cisco.com>, Satoru Matsushima <satoru.matsushima@g= .softbank.co.jp>, Thomas.Graf <Thomas.Graf@swisscom.com>, Yuanchao Su <yitai.syc@al= ibaba-inc.com>
Subject: New Version Notification for draft-filsfils-spring-path-tra= cing-00.txt


A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the=
IETF repository.

Name:           draft-fil= sfils-spring-path-tracing
Revision:       00
Title:          Path Tracing i= n SRv6 networks
Document date:  2022-03-04
Group:          Individual Sub= mission
Pages:          15
URL:            https://www.ietf.org/archive= /id/draft-filsfils-spring-path-tracing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-filsfils-= spring-path-tracing/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-filsfils-= spring-path-tracing


Abstract:
   Path Tracing provides a record of the packet path as a sequenc= e of
   interface ids.  In addition, it provides a record of end-= to-end
   delay, per-hop delay, and load on each egress interface along = the
   packet delivery path.

   Path Tracing allows to trace 14 hops with only a 40-bytes IPv6= Hop-
   by-Hop extension header.

   Path Tracing supports fine grained timestamp.  It has bee= n designed
   for linerate hardware implementation in the base pipeline.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

--_000_AM7PR03MB645165728AAB9A311090E1A8EE0F9AM7PR03MB6451eurp_-- From nobody Mon Mar 14 08:18:08 2022 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 444A33A15D1 for ; Mon, 14 Mar 2022 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=liquid.tech 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 xoRYv_PPNWr8 for ; Mon, 14 Mar 2022 08:16:34 -0700 (PDT) Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (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 5FFD93A16FE for ; Mon, 14 Mar 2022 08:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1647270991; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Cr4f3Zad1ML5DpeO7RViBFnNn49nPEw3jXSyF+UX5Mw=; b=LR7feiZhWaYr13iZiTR/ECxgFHwAWguj9oV1tlDNk0VJ+VjLBSy1qMdX73Lq0BFSZ3eXPe vIjJMw5wFRKZv/wbh31SI1CTVLlACCab3kNm6t6+RBIoa9OTdR0EDNs5oOBJqRC1BQdLHy Mog66dtNcUSJY8RHjS/DXzwCbxZKCEc= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2111.outbound.protection.outlook.com [104.47.17.111]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id uk-mtapsc-3-Q8mFUqD9MZqz1Ed2MDwsAA-1; Mon, 14 Mar 2022 15:16:27 +0000 X-MC-Unique: Q8mFUqD9MZqz1Ed2MDwsAA-1 Received: from AM7PR03MB6451.eurprd03.prod.outlook.com (2603:10a6:20b:1b3::22) by PA4PR03MB7471.eurprd03.prod.outlook.com (2603:10a6:102:10f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.28; Mon, 14 Mar 2022 15:16:26 +0000 Received: from AM7PR03MB6451.eurprd03.prod.outlook.com ([fe80::e856:ef51:ae22:309b]) by AM7PR03MB6451.eurprd03.prod.outlook.com ([fe80::e856:ef51:ae22:309b%8]) with mapi id 15.20.5061.028; Mon, 14 Mar 2022 15:16:26 +0000 From: Andrew Alston - IETF To: "Xiejingrong (Jingrong)" , Gyan Mishra , Andrew Alston - IETF CC: "spring@ietf.org" , Tom Hill Thread-Topic: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) Thread-Index: Adgyj2pEDTIYoRv+Rwm6VOp4IGlK2wBNJauAACFuVoAAEUkkQAB4hyWAAECazYAAEHweIA== Date: Mon, 14 Mar 2022 15:16:26 +0000 Message-ID: References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6bc99648-6d4b-440c-93b2-08da05cd9b92 x-ms-traffictypediagnostic: PA4PR03MB7471:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: oy87kZRRQM+u8fNmxsj82617nK1XGS8cdADRAwhproSnoYaJap99p1EqH+IPKjDfuxtcDmKFFhVeHQR/9PPs7zNpWFuXUuYYGq9k6QsjOOPRiAn+/3w41P8ExFAQtV3VWFWWOIdIcFTVrchyrWj+JjuglqPebrs9Jh9vZuU8WhqA+h18m8jM1jmY9kzKT0cVoOpRPRwiTIk+R08EelLAW4A79hWt0+T8xejbKHiAyUre0KytVVvjZJbo+MS0TSZys1qu/cttxx6qZCMWqAhJZVr+p3XwTEQ0mYkpKulM9TJbZHm3E2vQLA593qulQlTmGV5oPDwsUlQFP5FQ6JLqaiDCkyL94sdVS8Wck/pDFVA/MZkKHawtizM19IaBhiQrU8eqqZUHGUCDb6rnnxi6I9klWlhZivCR61B81zjAhiR7pajU/HYcHSkw8zNVoqy5ogrzveJQWP1cE/KDwXywHiknWGLja0Jhy1AC/A61omqBovYH7y3Pg35FqMqO9AizBniIkaq0ByBL5G71azuXuLM6o0wMnMnup0kbdNBfN7L2f5CBsg+ZmkSZEppgQRNAcIHmKCzektnUA8LPH+XexsaZO1Jk/TJYBqdaaR8qD6p/8SwM9RRBUBPmGbBe39YAFhIvHL1QGBQmgnQpd7sweRqSB1N+n+5jvV0BNPzu7bLLvKrd+5CBddXhu9m4fnNz+Y4ahGwZ9ola7TOvK26QKeutBcuIjMwR1bYTZO2oGjD9uFIAd5NcRlD94KlfCxehvNouQlXIbkbCuie8u1EGjva+6TXqgMQvNlHV6FVscE5O+Y0GqLWD6ZkcZu6AxAqUtGSTWGRS6uxSavKwFqRirw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR03MB6451.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(55016003)(99936003)(7696005)(53546011)(9686003)(6506007)(166002)(122000001)(38100700002)(40140700001)(966005)(508600001)(33656002)(2906002)(83380400001)(71200400001)(8936002)(52536014)(110136005)(54906003)(5660300002)(38070700005)(66574015)(66446008)(186003)(8676002)(316002)(76116006)(86362001)(4326008)(64756008)(66476007)(66556008)(66946007); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L3ZDK1V0TVF2U3gvbGwrY0RyellQb2pER0RUSnB2dEhRbXFDNCt4TDlsb2k0?= =?utf-8?B?NVpaZmttOHA2M29zRDhkSFB1TzFuNVVVaVdha2JKUWQyK2dQbkVCMW9JWWtS?= =?utf-8?B?UUk0WWhMQVR1K1J3ZzBVZVR2SXJ4L2xLRnVoQXQwZmF6RjBJamFDR1F3TnJL?= =?utf-8?B?c0VyZC9lUmw5eDNIR2V2V0pPWmdRVGpaUjJ4czFSQjNSTFR0aGQ4MVF0WkFi?= =?utf-8?B?dS91QmdmanlKWlhjalE5QWV1NkxmZnJBelM2MUE5ckJaOU56ZUF3Y2lFaEpn?= =?utf-8?B?UVUxWFl6WWlxYTV2aEtSajVPditaQ2dLTzFVMlN5YUF2SXg1OEk5VWc5Z2pk?= =?utf-8?B?aVVRR1JZcnFjN0N2d20zWkFzUXBrWXU5Rk5WWUNtNWZrNlE1Y1dyQjRtNTh6?= =?utf-8?B?Qk9KOFNmb080THg5M01VaUVDN0pUTmdRYW9EN05xVXJqV0JZcEI5QWR1NUZm?= =?utf-8?B?SG1kM0xOenBsbGtpVy96TVFZQVN6elFxQzU2Sk1Mc3JvMzZBcVpUdFNXZzhL?= =?utf-8?B?WUVjR0FUNUYyV0pzT01uN1gzbnNRcFBRblBpSDBqSVFNenp0Nk8wK0JsYTNU?= =?utf-8?B?M2pSMXdwQWNsL05CUVNwWHlhMTdpcS9DcFJENlFvczgrRjNkcXRXMmtPam9t?= =?utf-8?B?TnlGVk5CUWt2WFdiSDdXajZad3ZCVy94ZmhGbHF6ejBIYWdWK2F4TWVZTWd1?= =?utf-8?B?Ty9oQWhRREJLb240WjNTSHRXblc5NzdsTTlRWVVpSWV3YzR3OHJiVWFtUjla?= =?utf-8?B?TDZuaUpqQTV6ZjhCZCs0bTJTSTNnQWgzUldGYTVwU08rc014bUhDdDVpUjNY?= =?utf-8?B?aW9PcWZUVlF6V2RTRWl5WXduMVBuWWg3VzlxNUR6eHFLRStxUE9qLyttcmFI?= =?utf-8?B?VXdZb0NnamJOZW9OU2FVd3FraTY5NUxlYVlRY3lGVHFXWk5sSy9Mb3h5em82?= =?utf-8?B?NW1sQ3ArYlpOVExwWkNIR3MvcWhMTjZQdVpsallneGpaaklObzNIaHJuU2NN?= =?utf-8?B?aVd2UDRzaExMRzdPa0I3UkpsNlozaHU4Zk9RNUd0dGdlTVY1YVo0Qm9iTGVT?= =?utf-8?B?aVRadEZobXFGWWNzYlcvVmdzbG5MOUhYdklwR2wzMUZXUktyMGJCME5EUkRx?= =?utf-8?B?dlFlYUhCNUx1dFFOL0oyREV6RFpCalZEUmdwcUlFZWVjU0ZUQzcwclNqN05j?= =?utf-8?B?YWNEMFVhY09VV2tzWndVSitSZGRZZjBTSFQyK2syY0FVS1VSYVpEMUh2L0ZQ?= =?utf-8?B?eisrV0J6MG0vQUsyeG80cUg2ckFvUGIyamkwcGJhSWhFbXpHODI2dE1lSGdT?= =?utf-8?B?cDBmeXBCdDhPYzVBQVdyUHZ6MktBemdSOXJTS2FYRHlRREVHdFAzNFBYWi91?= =?utf-8?B?OGZReGtTODE5VEN0L0hZdlB2Ym53Q1pIWXJ0WWtqT1ZuUnZERDAzWG55NnhX?= =?utf-8?B?ZkZMYi85aS95Y1h5M0VVNFFuci9acVZ2YzEvSExKZTY5U25FNTJzYzFFd0pP?= =?utf-8?B?eVpFYWFpMlNSUHRSRnl2T05RSUQ1a3JoSmR6T3E3d3hjZ3dXWGtEV0p6L3hO?= =?utf-8?B?ZDY4OGdwRW5pV2w0NEVUd3dXWGF0ZGF3K2Y4ckNkUFNGR245dmN0OGdRdG9U?= =?utf-8?B?YVQwSEZNRDJOQjVvWTk4ak1FejdMdzdiV2dXSUgzRUJVTHFBamlUdUZsNmRV?= =?utf-8?B?akhoakFoMDFObmxPODNVSXUwcUZybnJodEdKMmVIRjhwV2l6MFF5d0gwOU5o?= =?utf-8?B?dlBrTzk0WmVVWEwrWTk1S2tNNllIdGd3cllyN1dSbDZGSXkxamJNVjE5Zm4y?= =?utf-8?B?SG5VSEMvQzFJR2VWWXNFeDloQ0dwNGczczdrN3A5TlpGYUN1cE1hdW1BZk5W?= =?utf-8?B?TFVtaU5lWHNCWDFISU9ZWTlabFYwSVpXZ3hMZkNGWXhBV3h1K2xxMFhoN3lV?= =?utf-8?B?RTRDUzdSdkQ0SlFPeGdOQURVaEdyM2pQUFh0S05ldDZBb3lNTnJLVHZFeDhO?= =?utf-8?B?SlBjbzgwM1ZJaUFBRU1oc09TeFlqQUlObVhyZHcvVTJJblRWWVIvbTRYR3l1?= =?utf-8?B?bDZjNXhLTVhMNTkrYldETFFhYk5LWmNBS010Zz09?= MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR03MB6451.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bc99648-6d4b-440c-93b2-08da05cd9b92 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2022 15:16:26.2230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dq6/1EUWl+kQQkUfFf8/8Ww0MZDzILL/7mWMSctfarbqt3sg/+uCDwvemfVcLZV4ri8sZqw9VxYw+7sqBorfF5DTa5sEao1golnUL+I2jlk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR03MB7471 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew-ietf@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-US Content-Type: multipart/related; boundary="_004_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_"; type="multipart/alternative" Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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, 14 Mar 2022 15:16:54 -0000 --_004_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_ Content-Type: multipart/alternative; boundary="_000_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_" --_000_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SmluZ3JvbmcsDQoNCkxpbWl0ZWQgRG9tYWluIChpbiBteSB2aWV3KSByZWZlcnMgdG8gYSBkb21h aW4gd2hlcmUgYWxsIHBvaW50cyBhcmUgdW5kZXIgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGNvbnRy b2wuICBJLkUgdGhlIHNvdXJjZSwgZGVzdGluYXRpb24gYW5kIGFueXRoaW5nIGluIHRoZSBtaWRk bGUgbXVzdCBmYWxsIHVuZGVyIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wsIG90aGVy d2lzZSwgeW91IGFyZSBub3Qgd2l0aGluIHRoZSBsaW1pdGVkIGRvbWFpbi4gIFRoaXMgY2FuIGJl IGV4dGVuZGVkIHVzaW5nIGVuY2Fwc3VsYXRpb24gKHR1bm5lbGluZykgd2hlcmUgdGhlIHBhY2tl dCBpcyBlbmNhcHN1bGF0ZWQgYW5kIHByZWZlcmFibHkgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVj dGVkLCBzdWNoIHRoYXQgYW55IGludGVybWVkaWF0ZSBuZXR3b3JrcyBvdXRzaWRlIG9mIHRoZSBz YW1lIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wgY2Fubm90LCBlaXRoZXIgYnkgZXJyb3Igb3IgZGVs aWJlcmF0ZSBhY3Rpb24sIGFjdCBvbiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIHdpdGhpbiB0 aGUgcm91dGluZyBoZWFkZXJzLg0KDQpBbnl0aGluZyBlbHNlIHdvdWxkIHJ1biBpbnRvIGlzc3Vl cyB3aXRoIHNlY3Rpb24gOC4yIG9mIFJGQzg0MDIuDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpG cm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgWGllamlu Z3JvbmcgKEppbmdyb25nKQ0KU2VudDogTW9uZGF5LCBNYXJjaCAxNCwgMjAyMiAxMDoxNiBBTQ0K VG86IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+OyBBbmRyZXcgQWxzdG9uIC0g SUVURiA8YW5kcmV3LWlldGZAbGlxdWlkLnRlY2g+DQpDYzogc3ByaW5nQGlldGYub3JnOyBUb20g SGlsbCA8dG9tQG5pbmphYmFkZ2VyLm5ldD4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBOZXR3b3Jr IFByb2dyYW1taW5nIEludGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZp Y2VzIHRvIE92ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2 LW5waS1mb3Itb3ZlcmxheSkNCg0KSGksDQoNCkkgdGhpbmsgSSBub3cgdW5kZXJzdGFuZCBiZXR0 ZXIgdGhlIGNvbmNlcm4gYWJvdXQgInRoZSB1c2Ugb2YgU0lEcyBvdmVyIHRoZSBwdWJsaWMgSW50 ZXJuZXQiLg0KSW4gbXkgcHJldmlvdXMgbWFpbCwgdGhlIFNJRDIvU0lEMyB1c2VkIGJldHdlZW4g Q1BFMi1JbnRlcm5ldC1DUEUzIGlzIHRvIGV4cGxhaW4gdGhlIGxheWVyaW5nIG1vZGVsIChvdmVy IHZzIGFjcm9zcyksIGJ1dCBpdCBpcyBub3QgdGhlIHByb3Bvc2FsIG9mIHRoZSBkcmFmdC4NClRo ZSBkcmFmdCBpcyB0YWxraW5nIGFib3V0IHRoZSBpbnRlcmZhY2UgKG5hbWUgTlBJKSB0aGF0IG92 ZXJsYXkgbmV0d29ya3MgdXNlIHRvIGFjY2VzcyB0aGUgdW5kZXJseWluZyBuZXR3b3JrIGluIHRo ZSBsYXN0IG1pbGUuDQpUaGVyZSBtYXkgYmUgYW4gQWNjZXNzIE5ldHdvcmsgKEFOKSBpbiB0aGUg bGFzdCBtaWxlLCBhbmQgdGhlIEFOIG1heSBhbHNvIGNvbm5lY3QgdG8gSW50ZXJuZXQgYmFja2Jv bmUgYW5kL29yIG11bHRpcGxlIHVuZGVybHlpbmcgbmV0d29ya3MsIGJ1dCBpdCBpcyBkaXN0aW5j dCBmcm9tIHRoZSAib3BlbiBJbnRlcm5ldCIuDQpNYWtlIG1vcmUgc2Vuc2UgaWYgdGhlIEFOIGNh biBlbmhhbmNlIChpZiBubyB3YXkgdG8gZW5mb3JjZSkgbm90IHRvIGxlYWsgdGhlIFNSdjYgQlNJ RCB0byBJbnRlcm5ldCBiYWNrYm9uZSBvciBvdGhlciBUTnMgPw0KDQpGb3IgdGhlIGNvbnRyb2wg cGxhbmUsIGl0IGlzIHN0aWxsIG5vdCBjbGVhciBpZiBhIGNvbnRyb2xsZXIgaXMgcmVxdWlyZWQs IGJ1dCBvbmUgdGhpbmcgSSBjb25zaWRlcmVkIGlzIHRvIHVzZSBhbiBJRVRGIHN0YW5kYXJkIHBy b3RvY29sIGJlY2F1c2UgdGhlIFBFIG5lZWQgdG8gaW1wbGVtZW50IHRoZSBOUEkuDQoNClJlZ2Fy ZHMsDQpKaW5ncm9uZw0KDQpGcm9tOiBHeWFuIE1pc2hyYSBbbWFpbHRvOmhheWFidXNhZ3NtQGdt YWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgTWFyY2ggMTMsIDIwMjIgODoyNiBBTQ0KVG86IEFuZHJl dyBBbHN0b24gLSBJRVRGIDxhbmRyZXctaWV0ZkBsaXF1aWQudGVjaDxtYWlsdG86YW5kcmV3LWll dGZAbGlxdWlkLnRlY2g+Pg0KQ2M6IFRvbSBIaWxsIDx0b21AbmluamFiYWRnZXIubmV0PG1haWx0 bzp0b21AbmluamFiYWRnZXIubmV0Pj47IFhpZWppbmdyb25nIChKaW5ncm9uZykgPHhpZWppbmdy b25nQGh1YXdlaS5jb208bWFpbHRvOnhpZWppbmdyb25nQGh1YXdlaS5jb20+Pjsgc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gTmV0 d29yayBQcm9ncmFtbWluZyBJbnRlcmZhY2UgZm9yIFByb3Zpc2lvbmluZyBvZiBVbmRlcmxheSBT ZXJ2aWNlcyB0byBPdmVybGF5IE5ldHdvcmtzIFVzaW5nIFNSdjYgKGRyYWZ0LXhpZS1zcHJpbmct c3J2Ni1ucGktZm9yLW92ZXJsYXkpDQoNCkhpIEppbmdyb25nDQoNCkkgcmVhZHMgdGhlIGRyYWZ0 IGFuZCB3YXMgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFzIHdl bGwgYXMgdGhlIHNvbHV0aW9uLg0KDQpTbyBJIGJlbGlldmUgdGhlIHByb2JsZW0gc3RhdGVtZW50 IGlzIGhvdyB0byBpbnRlcmNvbm5lY3QgZGVzcGVyYXRlIHNpdGVzIG92ZXIgdGhlIGludGVybmV0 IHVzaW5nIGEgbWFuYWdlZCBJUFNFQyBWUE4gb3IgU0RXQU4gc29sdXRpb24gb3IgbWFuYWdlZCBN UExTIGFuZCBjb21wbGV4aXR5IG9mIHByb3Zpc2lvbmluZyBDRSBhdHRhY2htZW50Lg0KDQpUaGUg c29sdXRpb24gaXMgYW4gYXV0b21hdGVkIHNvbHV0aW9uIHVzaW5nIFNSdjYgb3ZlciB0aGUgaW50 ZXJuZXQgdXNpbmcgQlNJRC4gIFRoaXMgaW52b2x2ZXMgcnVubmluZyBTUnY2IG92ZXIgdGhlIGlu dGVybmV0LCBob3dldmVyIFNSdjYgaXMgbGltaXRlZCB0byBjbG9zZWQgZG9tYWlucy4gIEl0IGFw cGVhcnMgYW4gRTJFIHBzZXVkb3dpcmUgaXMgdXNlZCBpbiBwcm92aXNpb25pbmcgdGhlIHNlcnZp Y2UuICBIYXZlIHlvdSB0aG91Z2ggb2YgdXNpbmcgTkcgTDIgVlBOIEVWUE4gYWxsIG9yIHNpbmds ZSBhY3RpdmUgbXVsdGkgaG9tZSBvdmVyIFNSdjYuDQoNCkRvZXMgYWxsIHRoZSBwcm92aXNpb25p bmcgdXNlIGEgUENFIC8gU0ROIGNvbnRyb2xsZXI/DQoNCg0KVGhhbmtzDQoNCkd5YW4NCg0KT24g VGh1LCBNYXIgMTAsIDIwMjIgYXQgOTo1OSBBTSBBbmRyZXcgQWxzdG9uIC0gSUVURiA8YW5kcmV3 LWlldGY9NDBsaXF1aWQudGVjaEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBsaXF1aWQudGVjaEBk bWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSGkgSmluZ3JvbmcsDQoNCknigJltIHN0cnVnZ2xpbmcg dG8gZW50aXJlbHkgdW5kZXJzdGFuZCB0aGlzLiAgSSB0aGluayB0aGUgcXVlc3Rpb24gZm9yIG1l IGlzIOKAkyBpZiB5b3UgYXJlIHNlbmRpbmcgcGFja2V0cyB3aXRoIFNJROKAmXMgb3ZlciB0aGUg b3BlbiBpbnRlcm5ldCDigJMgYXJlIHlvdSBlbmNhcHN1bGF0aW5nIHRob3NlIHBhY2tldHMgYW5k IGlzIHRoaXMgZW5jYXBzdWxhdGlvbiBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQg4oCTIEku RSB0aGUgU0lE4oCZcyBhcmUgbm90IHZpc2libGUgb3V0c2lkZSBvZiB0aGUgZW5jYXBzdWxhdGlv biwgdG8gcHJlc2VydmUgdGhlIGxpbWl0ZWQgZG9tYWluLg0KDQpMaW1pdGVkIGRvbWFpbnMgYXJl IHR5cGljYWxseSBleHRlbmRlZCB2aWEgdHVubmVsIG1lY2hhbmlzbXMsIHZlcnkgb2Z0ZW4gd2l0 aCBjcnlwdG9ncmFwaGljIHByb3RlY3Rpb24sIGhlbmNlIHRoZSBxdWVzdGlvbg0KDQpUaGFua3MN Cg0KQW5kcmV3DQoNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgWGllamluZ3JvbmcgKEpp bmdyb25nKQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEwLCAyMDIyIDk6NDAgQU0NClRvOiBUb20g SGlsbCA8dG9tQG5pbmphYmFkZ2VyLm5ldDxtYWlsdG86dG9tQG5pbmphYmFkZ2VyLm5ldD4+OyBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3By aW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIEludGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVu ZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGll LXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheSkNCg0KSGkgVG9tLA0KDQpUaGFua3MgZm9yIHJl YWRpbmcgdGhlIGRyYWZ0IGFuZCByYWlzZSBkaXNjdXNzaW9ucy4NCg0KSW4gdGhlIHByb3Bvc2Fs IHRoZSBTUnY2IGRvbWFpbiBpcyB0aGUgb3ZlcmxheSBuZXR3b3JrLCBiZWxvbmdpbmcgdG8gb25l IGFkbWluaXN0cmF0aXZlIGRvbWFpbiAtLSB0aGUgb3ZlcmxheSBuZXR3b3JrIG9wZXJhdG9yKHNh eSBPTk8pLg0KDQpGb3IgeW91ciBjb25jZXJuIGFib3V0IHVzZSBvZiBTSURzICJhY3Jvc3MiIHRo ZSBwdWJsaWMgSW50ZXJuZXQuIExldCBtZSB0cnkgdG8gZXhwbGFpbiB1c2luZyBmb2xsb3dpbmcg ZmlndXJlIChob3BlIGl0IHdvcmtzKToNCg0KQ1BFMSBDUEUyIENQRTMNCisgKyArICsNCnwgKy0t LS0tLS0tKyB8IHwgKy0tLS0tLS0tLS0rIHwNCistLS1bMV0gVE4xIFsxXS0tLSsgKy0tLSsgSW50 ZXJuZXQgfC0tLSsNCistLS0tLS0tLSsgKy0tLS0tLS0tLS0rDQoNCkluIHRoZSBwZXJzcGVjdGl2 ZSBvZiB0aGUgT05PLCBpdCBoYXMgdGhlIGZvbGxvd2luZyBTSURzOg0KU0lEMS8yLzM6IGFsbG9j YXRlZCBvbiBDUEUxL0NQRTIvQ1BFMyBieSB0aGUgT05PLg0KU0lENC81OiBhbGxvY2F0ZWQgYnkg VE4gb3BlcmF0b3IgYnV0IHNlcnZlcyBmb3IgdGhlIE9OTyAoVGVuYW50LTEgb2YgVE4sIG1hcmtl ZCBbMV0gaW4gdGhlIGZpZ3VyZSkuDQpUaGUgT05PIGNhbiB1c2UgdGhlc2UgU0lEcywgYW5kIEkg d291bGQgdGhpbmsgdGhleSBhcmUgYWxsICJpbiB0aGUgb3ZlcmxheSBuZXR3b3JrIiwgYW5kIGFy ZSBydW5uaW5nICJPdmVyIHRoZSBJbnRlcm5ldCIuDQoNCllvdSBtZW50aW9uZWQgaW4gdGhlIGxh c3Qgc2VudGVuY2UgInRoZSB1c2Ugb2YgU0lEcyBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQiLiBU aGF0IGlzIHdoYXQgSSBhbSBtb2RlbGluZyBhYm92ZS4NCg0KVGhhbmtzDQpKaW5ncm9uZw0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbSBIaWxsDQpTZW50OiBXZWRuZXNkYXks IE1hcmNoIDksIDIwMjIgMTA6NDMgUE0NClRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIElu dGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkg TmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3Zlcmxh eSkNCg0KSGkgSmlucm9uZywNCg0KT24gMDgvMDMvMjAyMiAwMTo1OCwgWGllamluZ3JvbmcgKEpp bmdyb25nKSB3cm90ZToNCj4gSSBqdXN0IHBvc3RlZCBhIGRyYWZ0IHRoYXQgc3BlY2lmaWVzIGEg ZnJhbWV3b3JrIGFuZCBzb21lIG1vcmUgZGV0YWlsDQo+IG9mIHRoZSBpZGVhIGZvciBwcm92aXNp b25pbmcgb2YgdW5kZXJsYXkgc2VydmljZXMNCj4gKFNsaWNlL1NSLXBvbGljeS9NY2FzdC9ldGMp IHRvIG92ZXJsYXkgbmV0d29ya3MoU0QtV0FOL0NETi9ldGMpLCB1c2luZyBTUnY2Lg0KPg0KPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1zcHJpbmctc3J2 Ni1ucGktZm9yLW92PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt eGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3Y+DQo+IGVybGF5DQo+IDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9yLW88aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14aWUtc3ByaW5nLXNydjYt bnBpLWZvci1vPg0KPiB2ZXJsYXk+DQo+DQo+IFBsZWFzZSBjb21tZW50IGFuZCBzZW5kIGFueSBm ZWVkYmFjay4NCj4NCj4gSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhpcyBkb2N1bWVudCBvdmVy IGUtbWFpbC9tYWlsLWxpc3QuDQoNCg0KSSdtIGNvbmNlcm5lZCB0aGF0IHRoaXMgZHJhZnQgaXMg ZXhwbGljaXRseSB2aW9sYXRpbmcgdGhlIGNvbmNlcHQgb2YNClNSdjYgYXMgYSBwcm90b2NvbCB0 aGF0IG9wZXJhdGVzIHdpdGhpbiBhIExpbWl0ZWQgRG9tYWluLg0KDQpBcyBwZXIgU2VjdGlvbiAz LjIgb2YgdGhpcyBkcmFmdCwgIi4uLiB0aGUgbmV0d29yayBvcGVyYXRvciBvZiBBTiwgVE4gYW5k IEludGVybmV0IGNhbiBiZSBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLiINCg0KRnVydGhlciwg IkluIHNvbWUgc2NlbmFyaW9zLCB0aGUgQU4gY2FuIGJlIGFuIEludGVybmV0IGV4Y2hhbmdlIHBy b3ZpZGVyDQooSVhQKSBpbmRlcGVuZGVudCBvZiBJU1AgYW5kIE5TUC4gSW4gc29tZSBvdGhlciBz Y2VuYXJpb3MsIHRoZSBBTiBjYW4gYmUgYW4gSVNQIHRoYXQgcnVubmluZyBJbnRlcm5ldCBiYWNr Ym9uZSBhcyB3ZWxsLiINCg0KVGhpcyB3b3VsZCByZWFkIHRvIG1lIHRoYXQgdGhlIHByb3Bvc2Fs IGlzIGV4cGxpY2l0bHkgaW50ZW5kZWQgdG8gYmUgaW50ZXItZG9tYWluLCBhbmQgbm90IGF0IGFs bCBsaW1pdGVkIHRvIGFueSBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KQWRkaXRpb25hbGx5 LCBJIGNhbm5vdCBkZXRlcm1pbmUgaWYgdGhlIGRyYWZ0IGltcGxpY2l0bHkgcmVxdWlyZXMgdGhl IHVzZSBvZiBTSURzIGFjcm9zcyB0aGUgcHVibGljIEludGVybmV0Pw0KDQpDb3VsZCBJIGFzayBm b3Igc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQsIHdpdGggcmVz cGVjdCB0byBMaW1pdGVkIERvbWFpbnMsIGFuZCBhbHNvIHRoZSB1c2Ugb2YgU0lEcyBvdmVyIHRo ZSBwdWJsaWMgSW50ZXJuZXQ/DQoNCktpbmQgcmVnYXJkcywNCg0KLS0NClRvbQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcg bGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmc8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5n IG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZz4NCi0tDQoNClvlm77lg4/lt7Looqvlj5Hk u7bkurrliKDpmaTjgIJdPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KDQpHeWFuIE1pc2hyYQ0K DQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0KRW1haWwgZ3lhbi5zLm1pc2hyYUB2ZXJp em9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4NCg0KTSAzMDEgNTAyLTEz NDcNCg0K --_000_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmluZ3Jv bmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkxpbWl0ZWQgRG9tYWluIChpbiBteSB2aWV3KSByZWZlcnMgdG8g YSBkb21haW4gd2hlcmUgYWxsIHBvaW50cyBhcmUgdW5kZXIgc2luZ2xlIGFkbWluaXN0cmF0aXZl IGNvbnRyb2wuJm5ic3A7IEkuRSB0aGUgc291cmNlLCBkZXN0aW5hdGlvbiBhbmQgYW55dGhpbmcg aW4gdGhlIG1pZGRsZSBtdXN0IGZhbGwgdW5kZXINCiB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBj b250cm9sLCBvdGhlcndpc2UsIHlvdSBhcmUgbm90IHdpdGhpbiB0aGUgbGltaXRlZCBkb21haW4u Jm5ic3A7IFRoaXMgY2FuIGJlIGV4dGVuZGVkIHVzaW5nIGVuY2Fwc3VsYXRpb24gKHR1bm5lbGlu Zykgd2hlcmUgdGhlIHBhY2tldCBpcyBlbmNhcHN1bGF0ZWQgYW5kIHByZWZlcmFibHkgY3J5cHRv Z3JhcGhpY2FsbHkgcHJvdGVjdGVkLCBzdWNoIHRoYXQgYW55IGludGVybWVkaWF0ZSBuZXR3b3Jr cyBvdXRzaWRlDQogb2YgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBjYW5ub3QsIGVp dGhlciBieSBlcnJvciBvciBkZWxpYmVyYXRlIGFjdGlvbiwgYWN0IG9uIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgd2l0aGluIHRoZSByb3V0aW5nIGhlYWRlcnMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFu eXRoaW5nIGVsc2Ugd291bGQgcnVuIGludG8gaXNzdWVzIHdpdGggc2VjdGlvbiA4LjIgb2YgUkZD ODQwMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJldzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc3ByaW5nICZsdDtzcHJpbmctYm91bmNl c0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+WGllamluZ3JvbmcgKEppbmdyb25n KTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDE0LCAyMDIyIDEwOjE2IEFNPGJyPg0K PGI+VG86PC9iPiBHeWFuIE1pc2hyYSAmbHQ7aGF5YWJ1c2Fnc21AZ21haWwuY29tJmd0OzsgQW5k cmV3IEFsc3RvbiAtIElFVEYgJmx0O2FuZHJldy1pZXRmQGxpcXVpZC50ZWNoJmd0Ozxicj4NCjxi PkNjOjwvYj4gc3ByaW5nQGlldGYub3JnOyBUb20gSGlsbCAmbHQ7dG9tQG5pbmphYmFkZ2VyLm5l dCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIE5ldHdvcmsgUHJvZ3JhbW1p bmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25pbmcgb2YgVW5kZXJsYXkgU2VydmljZXMgdG8gT3Zl cmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChkcmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1v dmVybGF5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgdGhpbmsgSSBub3cg dW5kZXJzdGFuZCBiZXR0ZXIgdGhlIGNvbmNlcm4gYWJvdXQgJnF1b3Q7dGhlIHVzZSBvZiBTSURz IG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldCZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+SW4gbXkgcHJldmlvdXMgbWFpbCwgdGhlIFNJRDIvU0lEMyB1 c2VkIGJldHdlZW4gQ1BFMi1JbnRlcm5ldC1DUEUzIGlzIHRvIGV4cGxhaW4gdGhlIGxheWVyaW5n IG1vZGVsIChvdmVyIHZzIGFjcm9zcyksIGJ1dCBpdCBpcyBub3QNCiB0aGUgcHJvcG9zYWwgb2Yg dGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5U aGUgZHJhZnQgaXMgdGFsa2luZyBhYm91dCB0aGUgaW50ZXJmYWNlIChuYW1lIE5QSSkgdGhhdCBv dmVybGF5IG5ldHdvcmtzIHVzZSB0byBhY2Nlc3MgdGhlIHVuZGVybHlpbmcgbmV0d29yayBpbiB0 aGUgbGFzdCBtaWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5UaGVyZSBtYXkgYmUgYW4gQWNjZXNzIE5ldHdvcmsgKEFOKSBpbiB0aGUgbGFzdCBtaWxlLCBh bmQgdGhlIEFOIG1heSBhbHNvIGNvbm5lY3QgdG8gSW50ZXJuZXQgYmFja2JvbmUgYW5kL29yIG11 bHRpcGxlIHVuZGVybHlpbmcgbmV0d29ya3MsDQogYnV0IGl0IGlzIGRpc3RpbmN0IGZyb20gdGhl ICZxdW90O29wZW4gSW50ZXJuZXQmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPk1ha2UgbW9yZSBzZW5zZSBpZiB0aGUgQU4gY2FuIGVuaGFuY2UgKGlm IG5vIHdheSB0byBlbmZvcmNlKSBub3QgdG8gbGVhayB0aGUgU1J2NiBCU0lEIHRvIEludGVybmV0 IGJhY2tib25lIG9yIG90aGVyIFROcyA/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkZvciB0aGUgY29udHJvbCBwbGFuZSwgaXQgaXMgc3RpbGwgbm90IGNsZWFyIGlm IGEgY29udHJvbGxlciBpcyByZXF1aXJlZCwgYnV0IG9uZSB0aGluZyBJIGNvbnNpZGVyZWQgaXMg dG8gdXNlIGFuIElFVEYgc3RhbmRhcmQgcHJvdG9jb2wNCiBiZWNhdXNlIHRoZSBQRSBuZWVkIHRv IGltcGxlbWVudCB0aGUgTlBJLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ SmluZ3Jvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4gR3lhbiBNaXNocmEgWzxh IGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iPm1haWx0bzpoYXlhYnVzYWdzbUBn bWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWFyY2ggMTMsIDIwMjIg ODoyNiBBTTxicj4NCjxiPlRvOjwvYj4gQW5kcmV3IEFsc3RvbiAtIElFVEYgJmx0OzxhIGhyZWY9 Im1haWx0bzphbmRyZXctaWV0ZkBsaXF1aWQudGVjaCI+YW5kcmV3LWlldGZAbGlxdWlkLnRlY2g8 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9tIEhpbGwgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21A bmluamFiYWRnZXIubmV0Ij50b21AbmluamFiYWRnZXIubmV0PC9hPiZndDs7IFhpZWppbmdyb25n IChKaW5ncm9uZykgJmx0OzxhIGhyZWY9Im1haWx0bzp4aWVqaW5ncm9uZ0BodWF3ZWkuY29tIj54 aWVqaW5ncm9uZ0BodWF3ZWkuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3By aW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIEludGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVu ZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGll LXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIEppbmdyb25nJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgcmVhZHMgdGhlIGRyYWZ0 IGFuZCB3YXMgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFzIHdl bGwgYXMgdGhlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5T byBJIGJlbGlldmUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGlzIGhvdyB0byBpbnRlcmNvbm5lY3Qg ZGVzcGVyYXRlIHNpdGVzIG92ZXIgdGhlIGludGVybmV0IHVzaW5nIGEgbWFuYWdlZCBJUFNFQyBW UE4gb3IgU0RXQU4gc29sdXRpb24gb3IgbWFuYWdlZCBNUExTIGFuZCBjb21wbGV4aXR5IG9mIHBy b3Zpc2lvbmluZyBDRSBhdHRhY2htZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5UaGUgc29sdXRpb24gaXMgYW4gYXV0b21hdGVkIHNvbHV0aW9uIHVzaW5nIFNSdjYgb3Zl ciB0aGUgaW50ZXJuZXQgdXNpbmcgQlNJRC4mbmJzcDsgVGhpcyBpbnZvbHZlcyBydW5uaW5nIFNS djYgb3ZlciB0aGUgaW50ZXJuZXQsIGhvd2V2ZXIgU1J2NiBpcyBsaW1pdGVkIHRvIGNsb3NlZCBk b21haW5zLiZuYnNwOyBJdCBhcHBlYXJzIGFuIEUyRSBwc2V1ZG93aXJlDQogaXMgdXNlZCBpbiBw cm92aXNpb25pbmcgdGhlIHNlcnZpY2UuJm5ic3A7IEhhdmUgeW91IHRob3VnaCBvZiB1c2luZyBO RyBMMiBWUE4gRVZQTiBhbGwgb3Igc2luZ2xlIGFjdGl2ZSBtdWx0aSBob21lIG92ZXIgU1J2Ni4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RG9lcyBhbGwgdGhlIHBy b3Zpc2lvbmluZyB1c2UgYSBQQ0UgLyBTRE4gY29udHJvbGxlcj8mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5UaGFua3MmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+R3lhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9uIFRodSwg TWFyIDEwLCAyMDIyIGF0IDk6NTkgQU0gQW5kcmV3IEFsc3RvbiAtIElFVEYgJmx0O2FuZHJldy1p ZXRmPTxhIGhyZWY9Im1haWx0bzo0MGxpcXVpZC50ZWNoQGRtYXJjLmlldGYub3JnIj40MGxpcXVp ZC50ZWNoQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIEppbmdyb25nLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+STxzcGFuIGxh bmc9IlpILUNOIj7igJk8L3NwYW4+bSBzdHJ1Z2dsaW5nIHRvIGVudGlyZWx5IHVuZGVyc3RhbmQg dGhpcy4mbmJzcDsgSSB0aGluayB0aGUgcXVlc3Rpb24gZm9yIG1lIGlzDQo8c3BhbiBsYW5nPSJa SC1DTiI+4oCTPC9zcGFuPiBpZiB5b3UgYXJlIHNlbmRpbmcgcGFja2V0cyB3aXRoIFNJRDxzcGFu IGxhbmc9IlpILUNOIj7igJk8L3NwYW4+cyBvdmVyIHRoZSBvcGVuIGludGVybmV0DQo8c3BhbiBs YW5nPSJaSC1DTiI+4oCTPC9zcGFuPiBhcmUgeW91IGVuY2Fwc3VsYXRpbmcgdGhvc2UgcGFja2V0 cyBhbmQgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIGNyeXB0b2dyYXBoaWNhbGx5IHByb3RlY3RlZA0K PHNwYW4gbGFuZz0iWkgtQ04iPuKAkzwvc3Bhbj4gSS5FIHRoZSBTSUQ8c3BhbiBsYW5nPSJaSC1D TiI+4oCZPC9zcGFuPnMgYXJlIG5vdCB2aXNpYmxlIG91dHNpZGUgb2YgdGhlIGVuY2Fwc3VsYXRp b24sIHRvIHByZXNlcnZlIHRoZSBsaW1pdGVkIGRvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkxpbWl0ZWQgZG9t YWlucyBhcmUgdHlwaWNhbGx5IGV4dGVuZGVkIHZpYSB0dW5uZWwgbWVjaGFuaXNtcywgdmVyeSBv ZnRlbiB3aXRoIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiwgaGVuY2UgdGhlIHF1ZXN0aW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFu ZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4gc3ByaW5nICZsdDs8YSBocmVmPSJtYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlhpZWppbmdyb25nIChKaW5n cm9uZyk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDEwLCAyMDIyIDk6NDAgQU08 YnI+DQo8Yj5Ubzo8L2I+IFRvbSBIaWxsICZsdDs8YSBocmVmPSJtYWlsdG86dG9tQG5pbmphYmFk Z2VyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvbUBuaW5qYWJhZGdlci5uZXQ8L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dy YW1taW5nIEludGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRv IE92ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1m b3Itb3ZlcmxheSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5IaSBUb20sPGJyPg0KPGJyPg0K VGhhbmtzIGZvciByZWFkaW5nIHRoZSBkcmFmdCBhbmQgcmFpc2UgZGlzY3Vzc2lvbnMuPGJyPg0K PGJyPg0KSW4gdGhlIHByb3Bvc2FsIHRoZSBTUnY2IGRvbWFpbiBpcyB0aGUgb3ZlcmxheSBuZXR3 b3JrLCBiZWxvbmdpbmcgdG8gb25lIGFkbWluaXN0cmF0aXZlIGRvbWFpbiAtLSB0aGUgb3Zlcmxh eSBuZXR3b3JrIG9wZXJhdG9yKHNheSBPTk8pLg0KPGJyPg0KPGJyPg0KRm9yIHlvdXIgY29uY2Vy biBhYm91dCB1c2Ugb2YgU0lEcyAmcXVvdDthY3Jvc3MmcXVvdDsgdGhlIHB1YmxpYyBJbnRlcm5l dC4gTGV0IG1lIHRyeSB0byBleHBsYWluIHVzaW5nIGZvbGxvd2luZyBmaWd1cmUgKGhvcGUgaXQg d29ya3MpOjxicj4NCjxicj4NCkNQRTEgQ1BFMiBDUEUzPGJyPg0KKyArICsgKzxicj4NCnwgKy0t LS0tLS0tKyB8IHwgKy0tLS0tLS0tLS0rIHw8YnI+DQorLS0tWzFdIFROMSBbMV0tLS0rICstLS0r IEludGVybmV0IHwtLS0rPGJyPg0KKy0tLS0tLS0tKyArLS0tLS0tLS0tLSsgPGJyPg0KPGJyPg0K SW4gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBPTk8sIGl0IGhhcyB0aGUgZm9sbG93aW5nIFNJRHM6 PGJyPg0KU0lEMS8yLzM6IGFsbG9jYXRlZCBvbiBDUEUxL0NQRTIvQ1BFMyBieSB0aGUgT05PLjxi cj4NClNJRDQvNTogYWxsb2NhdGVkIGJ5IFROIG9wZXJhdG9yIGJ1dCBzZXJ2ZXMgZm9yIHRoZSBP Tk8gKFRlbmFudC0xIG9mIFROLCBtYXJrZWQgWzFdIGluIHRoZSBmaWd1cmUpLjxicj4NClRoZSBP Tk8gY2FuIHVzZSB0aGVzZSBTSURzLCBhbmQgSSB3b3VsZCB0aGluayB0aGV5IGFyZSBhbGwgJnF1 b3Q7aW4gdGhlIG92ZXJsYXkgbmV0d29yayZxdW90OywgYW5kIGFyZSBydW5uaW5nICZxdW90O092 ZXIgdGhlIEludGVybmV0JnF1b3Q7Lg0KPGJyPg0KPGJyPg0KWW91IG1lbnRpb25lZCBpbiB0aGUg bGFzdCBzZW50ZW5jZSAmcXVvdDt0aGUgdXNlIG9mIFNJRHMgb3ZlciB0aGUgcHVibGljIEludGVy bmV0JnF1b3Q7LiBUaGF0IGlzIHdoYXQgSSBhbSBtb2RlbGluZyBhYm92ZS48YnI+DQo8YnI+DQpU aGFua3M8YnI+DQpKaW5ncm9uZzxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KRnJvbTogc3ByaW5nIFs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgVG9tIEhpbGw8YnI+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDks IDIwMjIgMTA6NDMgUE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW3Nw cmluZ10gTmV0d29yayBQcm9ncmFtbWluZyBJbnRlcmZhY2UgZm9yIFByb3Zpc2lvbmluZyBvZiBV bmRlcmxheSBTZXJ2aWNlcyB0byBPdmVybGF5IE5ldHdvcmtzIFVzaW5nIFNSdjYgKGRyYWZ0LXhp ZS1zcHJpbmctc3J2Ni1ucGktZm9yLW92ZXJsYXkpPGJyPg0KPGJyPg0KSGkgSmlucm9uZyw8YnI+ DQo8YnI+DQpPbiAwOC8wMy8yMDIyIDAxOjU4LCBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpIHdyb3Rl Ojxicj4NCiZndDsgSSBqdXN0IHBvc3RlZCBhIGRyYWZ0IHRoYXQgc3BlY2lmaWVzIGEgZnJhbWV3 b3JrIGFuZCBzb21lIG1vcmUgZGV0YWlsIDxicj4NCiZndDsgb2YgdGhlIGlkZWEgZm9yIHByb3Zp c2lvbmluZyBvZiB1bmRlcmxheSBzZXJ2aWNlczxicj4NCiZndDsgKFNsaWNlL1NSLXBvbGljeS9N Y2FzdC9ldGMpIHRvIG92ZXJsYXkgbmV0d29ya3MoU0QtV0FOL0NETi9ldGMpLCB1c2luZyBTUnY2 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9yLW92IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1z cHJpbmctc3J2Ni1ucGktZm9yLW92PC9hPjxicj4NCiZndDsgZXJsYXkgPGJyPg0KJmd0OyAmbHQ7 PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14aWUt c3ByaW5nLXNydjYtbnBpLWZvci1vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1vPC9hPjxi cj4NCiZndDsgdmVybGF5Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgY29tbWVudCBh bmQgc2VuZCBhbnkgZmVlZGJhY2suPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0 byBkaXNjdXNzIHRoaXMgZG9jdW1lbnQgb3ZlciBlLW1haWwvbWFpbC1saXN0Ljxicj4NCjxicj4N Cjxicj4NCkknbSBjb25jZXJuZWQgdGhhdCB0aGlzIGRyYWZ0IGlzIGV4cGxpY2l0bHkgdmlvbGF0 aW5nIHRoZSBjb25jZXB0IG9mPGJyPg0KU1J2NiBhcyBhIHByb3RvY29sIHRoYXQgb3BlcmF0ZXMg d2l0aGluIGEgTGltaXRlZCBEb21haW4uPGJyPg0KPGJyPg0KQXMgcGVyIFNlY3Rpb24gMy4yIG9m IHRoaXMgZHJhZnQsICZxdW90Oy4uLiB0aGUgbmV0d29yayBvcGVyYXRvciBvZiBBTiwgVE4gYW5k IEludGVybmV0IGNhbiBiZSBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLiZxdW90Ozxicj4NCjxi cj4NCkZ1cnRoZXIsICZxdW90O0luIHNvbWUgc2NlbmFyaW9zLCB0aGUgQU4gY2FuIGJlIGFuIElu dGVybmV0IGV4Y2hhbmdlIHByb3ZpZGVyPGJyPg0KKElYUCkgaW5kZXBlbmRlbnQgb2YgSVNQIGFu ZCBOU1AuIEluIHNvbWUgb3RoZXIgc2NlbmFyaW9zLCB0aGUgQU4gY2FuIGJlIGFuIElTUCB0aGF0 IHJ1bm5pbmcgSW50ZXJuZXQgYmFja2JvbmUgYXMgd2VsbC4mcXVvdDs8YnI+DQo8YnI+DQpUaGlz IHdvdWxkIHJlYWQgdG8gbWUgdGhhdCB0aGUgcHJvcG9zYWwgaXMgZXhwbGljaXRseSBpbnRlbmRl ZCB0byBiZSBpbnRlci1kb21haW4sIGFuZCBub3QgYXQgYWxsIGxpbWl0ZWQgdG8gYW55IG9uZSBh ZG1pbmlzdHJhdGl2ZSBkb21haW4uDQo8YnI+DQpBZGRpdGlvbmFsbHksIEkgY2Fubm90IGRldGVy bWluZSBpZiB0aGUgZHJhZnQgaW1wbGljaXRseSByZXF1aXJlcyB0aGUgdXNlIG9mIFNJRHMgYWNy b3NzIHRoZSBwdWJsaWMgSW50ZXJuZXQ/PGJyPg0KPGJyPg0KQ291bGQgSSBhc2sgZm9yIHNvbWUg Y2xhcmlmaWNhdGlvbiBvbiB0aGUgc2NvcGUgb2YgdGhlIGRyYWZ0LCB3aXRoIHJlc3BlY3QgdG8g TGltaXRlZCBEb21haW5zLCBhbmQgYWxzbyB0aGUgdXNlIG9mIFNJRHMgb3ZlciB0aGUgcHVibGlj IEludGVybmV0Pzxicj4NCjxicj4NCktpbmQgcmVnYXJkcyw8YnI+DQo8YnI+DQotLTxicj4NClRv bTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxhIGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0M7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzowaW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047dGV4dC1kZWNvcmF0aW9u Om5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iODEiIGhlaWdodD0iMTgiIHN0eWxlPSJ3aWR0 aDouODQwMmluO2hlaWdodDouMTg3NWluIiBpZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDpp bWFnZTAwMS5qcGdAMDFEODM3Q0UuRUFENTdEMDAiIGFsdD0i5Zu+5YOP5bey6KKr5Y+R5Lu25Lq6 5Yig6Zmk44CCIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPkd5YW4gTWlzaHJhPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxpPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5OZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QmbmJzcDs8L3NwYW4+ PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttc28tbGluZS1o ZWlnaHQtYWx0OjkuNzVwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+RW1haWwNCjxhIGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6 b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwvYT48L3Nw YW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBp bjttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+TSAzMDEgNTAyLTEzNDc8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_-- --_004_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=356; creation-date="Mon, 14 Mar 2022 15:16:25 GMT"; modification-date="Mon, 14 Mar 2022 15:16:25 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAASAFEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK/9k= --_004_AM7PR03MB6451A51344B38A670D4A8AF9EE0F9AM7PR03MB6451eurp_-- From nobody Mon Mar 14 10:22:54 2022 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 045523A0D34 for ; Mon, 14 Mar 2022 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=ciena.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 QJR828RXvREt for ; Mon, 14 Mar 2022 10:22:46 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 25FD33A0D2D for ; Mon, 14 Mar 2022 10:22:43 -0700 (PDT) Received: from pps.filterd (m0222748.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22ECrR87018970; Mon, 14 Mar 2022 13:22:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=06252019; bh=YBKhh9SIU3gZVeyoCBS7n/Zmp5BIosG58JyRl4VTyO4=; b=h6u+zESGszc5ipMYQfWGlK32vuE9rQcH70rlialL2qBL0ADSo2mG26Plu6z7yRzNrTBz cycuccgzzlbufgyJX/Y7Xn+uOiv7unDrKe9vURxx1xlXxQIaVXUQWoO1hVu1jlymK4LM 9Xv3GwFau3jiNZS0uaY+WfB6bEwbxeqtvHavcwsM5HzIqGWK+y7navA31BSNyHO/OAIy +aDO9lslPZUh8F2DabisEJ9wkDkWridBLBdCw5whKNu0LBcuUk7tDn4IX3u7qeOKifH9 V6zjezs0/F+pJ8g+qLlIk8dhvacQ0XHJ28WKfWDAgSiA03tcBhiCbjw87XmydrzByOZX yA== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2109.outbound.protection.outlook.com [104.47.55.109]) by mx0a-00103a01.pphosted.com (PPS) with ESMTPS id 3et63q0seg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Mar 2022 13:22:40 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RpistJYyXK/PxZmJldrWh04QrefwvUxzKSjjFWo9J5lCnPa2d3CI5gGpMLSsqMdP5UMNJq1TbvKUBLYB+qZUFR6uPgPPq59HeH9U5plfZPQbs0Nu7a0pXO513m+jm+nn8HSm0GWphsnPk+KV2taCxt+T9WfHwOvCfzaUqlGCHQC0qxcrmYXbR6zufec+AYOhWcUOgszBfzpI7rzlC2Rr6XVQ5JZFrS/0CtUnkPBJw/yCrZC5YrjHHunj5a3DtQcvl6wRaxI854bvdgD5Fh73EC/xhgLjwX2asDTOMl8yq+Rek8W73B7Z36d8Q587KfgWAz+EyuTydQFkpvqjuhTrNg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YBKhh9SIU3gZVeyoCBS7n/Zmp5BIosG58JyRl4VTyO4=; b=Qgl02+fGLKvjEUIJbPNnVLI084cLwJDHsKQLq4vEeiNTgpSyzSt4OaO8NaBfCjEGk+o6QeIW1nIpcMjvniviPdDLtqNrHznqybElK37dcscBqmR4TIVM5KIcq3+S7ejiHbxOvRPQMvQ9T8Utdv4Ub7vsAS2++Bltm/tPazBb0CQMMCvFId+Yx1d7UfZ5eJw4ZVsCS9odwutG+ZuIatgl/W4ydaKZxHhlDUIL3WlX+7YvICA1pR4DDm/3WMBDmlHWxbBjxW+UV1zPOmiZPipLjkAjhRCeI0kRP5RmtGDDB2DtW3SSCesxa1PF0F5nwJG9WjF0Sln/KDupk/xSrKBU0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none Received: from BYAPR04MB4581.namprd04.prod.outlook.com (2603:10b6:a03:15::20) by CY4PR0401MB3602.namprd04.prod.outlook.com (2603:10b6:910:91::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.25; Mon, 14 Mar 2022 17:22:38 +0000 Received: from BYAPR04MB4581.namprd04.prod.outlook.com ([fe80::ccef:ca82:8cef:4cbf]) by BYAPR04MB4581.namprd04.prod.outlook.com ([fe80::ccef:ca82:8cef:4cbf%5]) with mapi id 15.20.5061.026; Mon, 14 Mar 2022 17:22:38 +0000 From: "Boutros, Sami" To: "bruno.decraene@orange.com" , James Guichard , Joel Halpern Direct CC: "spring@ietf.org" Thread-Topic: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Thread-Index: AQHYN8d9qsvIv4XmqkeeKayn8L1mKQ== Date: Mon, 14 Mar 2022 17:22:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4821e60-00bf-416f-f866-08da05df3cd8 x-ms-traffictypediagnostic: CY4PR0401MB3602:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xgiXf++66zGSmtmeiZ02DJ6qQCUz94GyxNzFZDeTMDEPj+poLFHi1HRIOwnxvZW9g/ZZ5BhnNmF6w1NABzvkRbG0ALY6uAcHFQZixBetuMN11OxDnvfXiTvo+tRFUuaSXk8EE6AjoQ72waBjZjGbYlqzhNKljjfKFbTyYlrf/bPvuJoCe/kCe9/pf0UCIqNvkDvcMcY/jZ55Ja1yOEjrgOWSg9EbEbw2bnPDtc3pHXAHcqn3jCUZGZoL9Sd40Rk2+MhUr76EC3R8n1x20btXehKNU423JLuGx0XE+ddBUw+J7mCocJDTGyDzaE+RLZQzIgiJFRg/9aQeyydzYeitqwf1DX+cw51EIm3wv1kT4hwmQc7Z8i0EG9g00i0TH8Dhz0iWpk3fb02F9b6DdGdGx+NGInZwi6IiL25LjWPO46XVLwoEwWl7IFWJ2yeScjGDbVMDwUWBipsbtt1x3eSkIM3BJd8+0yciorhRUjUe6l7s7m/tinHEwHE/bpio5sSoKAMiKmZ64NZuPOza1oGZJNIfDtmGM89cHWwR/v8XtMqwBGl3sgUoQa8Ysa5ljzF0A8M28CFKZy2U51+3qImF6Jmdlg2rWlTQZkRecpla7iFMTe+ZeoACED+2xwqb6197WsK6AST+R4PzU6ahT6D+CsTxLsuza3Aj88RO3uhEzFeAS+ITqV+hq8ky4fsq4WVjPf6qwSNGnLfa0CI660q/uA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4581.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6506007)(7696005)(8676002)(8936002)(33656002)(55236004)(9686003)(64756008)(66476007)(66556008)(66446008)(66946007)(4326008)(86362001)(76116006)(558084003)(71200400001)(122000001)(316002)(38100700002)(55016003)(110136005)(52536014)(5660300002)(508600001)(83380400001)(2906002)(38070700005)(26005)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9O13/gKHHdF0Mt3/q/WnuVlFUsgH+fMRz4FjQ2LrNjnjBwp61AcCcyhgfZN1?= =?us-ascii?Q?ShrbmB5jYxRZg6uIgP+MTXHY9VB2nH5sb+m9EEvM33VEiby+1X+MSyNU7874?= =?us-ascii?Q?tU3JR4RaB1BM1cZJg+BDfgl6xrDD91rlfmIS7PV60mIld3JAuaGBUZRybOTX?= =?us-ascii?Q?QGQlcAI3pnWup0l0hgXXRMnFiZmbtjbMSI58aKfyP51affh8MaAe6PVns529?= =?us-ascii?Q?hH3JWuOtEFnnRmlNG+IJlh830oxXqlqg7t63xopbUujnecPS8qhGqHEazG2X?= =?us-ascii?Q?OS+4nNjobtxsRxfFFhl6TiVaR/yMK246dPRtgOYCF8LheMnZ8RQr3unFzkhv?= =?us-ascii?Q?NxPwdLfM7vLb2l5coYwoqmQFT4+sXJ5t6nF20vS6Xl9ITOXxnn6pDwjRGY1P?= =?us-ascii?Q?sMZDrsxdfMJyy19ASQmKSUgZqmcwypV4B9vPajLj4NXbIR/9LvTzhfe1Fwjm?= =?us-ascii?Q?cD1DaA+1yUvNVOGfDl7vp3qG1NCvUQCKS0JNeiB/5HPjkitZi0Fokszagymv?= =?us-ascii?Q?1DaMSsLHGpdXVcssOaj3q/D9H4rI9JXL/jINfeHLnoJLbLQe+rb3gZ9vHV0a?= =?us-ascii?Q?oIfe/OEL4PLX+tVYQlKnLnAkoqXps+BqBDv8gOvO50BzGzYomIfebz9SGMJY?= =?us-ascii?Q?ruCv/sJBbzHXiDOpHJ41ny3Z6oIlw+pAanB4JPhPzLms735UOS030VcgQiCX?= =?us-ascii?Q?Eqgp5efzhbZhsk4SoWwXpNLWRFIqjg4ZZidTFjUn82W7fOi7YIspJqsWfX9g?= =?us-ascii?Q?dhv8dSct1chHB/x8BWUbtgOQMPK4WO2KZG93jtDkuNQbRa0fmfLg3b/q/sdC?= =?us-ascii?Q?B0ChJN1KOHBJcKMl4ATWnirGVEmxVWSRa9URYnB8srnitalkEetXV5yDDVyh?= =?us-ascii?Q?m3iZ/bKfgk2PAZjlU+qur9I3ENx9i1T6LNgMEQeTlYC2i91Q9xjJ3Yq+zTZo?= =?us-ascii?Q?xOOolfELZaDUiz6ena5dlBQ0HzRMW4M094HEQqMVt0IRZR4hzTVs4WScSyBE?= =?us-ascii?Q?CLLi+7x50NK0fSDWjJXLeF15FKMiLd7djwq1Wl/J3PbnxuFsRXtnwCuBXsnZ?= =?us-ascii?Q?tWOk9/W26pK8+iwu5/r9JLgS0Ty/scbqSMEPcbeY4QD21WiNv4HID5sI7UJL?= =?us-ascii?Q?3XwmFs8rEv4qa9ya3nRwlR5AdS2RorPaVHYOJjkDS6/0wIxe6f5mJzgfObVy?= =?us-ascii?Q?3PduCAFVdg9hbL+MpOm6kwLJHQo5fh3J86ylx4a3aPYEsZOFKJURrDqTYzSt?= =?us-ascii?Q?5AtNe40hpY2fn99CwelNyl5D9sjgNrxLcNhOJic/b+KN6wmRC3itL5mF+ilF?= =?us-ascii?Q?cuFLEHFUFwM5MuehjE98/dj5G1xLdP8xf5wyFhfXL2kQt7LKY+ZYoeLkQGWA?= =?us-ascii?Q?45CSLcpjsgU/6RTSMiDCB0/DgEOgrvTzDled23FPsINdZ2fEsGjSJ79pO2mZ?= =?us-ascii?Q?pbbNziLT9nZG/wPoHnEPpFkB3qPww2SDDrMhslLJUsiccCtH4xtKoA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BYAPR04MB4581C68B65460C1F46D9EEA2C40F9BYAPR04MB4581namp_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4581.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4821e60-00bf-416f-f866-08da05df3cd8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2022 17:22:38.2575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4hOZDggH8983+aXxVF9Vl9L+e35QmImTh8za10CS/4bI8gD8Y4QbFT0GP7s2odJx9MTZRV4rFp45aXENPgNnNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0401MB3602 X-Proofpoint-GUID: xT0PWk6LQVNPHVUJ5GY8GgHVtywFxKly X-Proofpoint-ORIG-GUID: xT0PWk6LQVNPHVUJ5GY8GgHVtywFxKly X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-14_12,2022-03-14_02,2022-02-23_01 Archived-At: Subject: [spring] WG adoption for draft-boutros-spring-elan-services-over-sr-00 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, 14 Mar 2022 17:22:52 -0000 --_000_BYAPR04MB4581C68B65460C1F46D9EEA2C40F9BYAPR04MB4581namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG Chairs, The authors would like to request a WG adoption for this draft, the draft w= as presented at last IETF. We could present the draft at this IETF too, if you folks like. Thanks, Sami --_000_BYAPR04MB4581C68B65460C1F46D9EEA2C40F9BYAPR04MB4581namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG Chairs,

 

The authors would l= ike to request a WG adoption for this draft, the draft was presented at las= t IETF.

 

We could present th= e draft at this IETF too, if you folks like.

 

Thanks,<= /span>

 

Sami

--_000_BYAPR04MB4581C68B65460C1F46D9EEA2C40F9BYAPR04MB4581namp_-- From nobody Mon Mar 14 13:14:51 2022 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 E28193A14FE for ; Mon, 14 Mar 2022 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=joelhalpern.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 WUG5Nx6zw5MY for ; Mon, 14 Mar 2022 13:14:45 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 41DF73A14F8 for ; Mon, 14 Mar 2022 13:14:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4KHSSN4ng9z1pNDJ for ; Mon, 14 Mar 2022 13:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1647288884; bh=g0ShgouO8GKv8QTjAx+R755hlQ/ByJxSHVOJ2Hp+syA=; h=Date:From:Subject:To:From; b=dCh5HOIK0zeAvwxC+4aoVsCYwK8Ck3BY2d17vzyLaaP2XCwX/ti7yg2Dyiz5GCf/X cujCJJmmo0EDpT1AeURnxuFPX6cLn3qZo0nLf9SfZ7ysMnHRDxlgF2wKX5jifuMyJp rZDCLeUds2GW10mIBgQI5hMSFirKP5Q5jtEe28fo= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.21.218] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4KHSSN1dQvz1pMJs for ; Mon, 14 Mar 2022 13:14:43 -0700 (PDT) Message-ID: Date: Mon, 14 Mar 2022 16:14:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 From: "Joel M. Halpern" To: "spring@ietf.org" Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] SPRING Chairs observation on WG calls for consensus 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, 14 Mar 2022 20:14:50 -0000 In discussion with chairs of other routing working groups, it was noted that there is sometimes confusion or misunderstanding about what is sought when the chairs conduct adoption calls and WG last calls. The top line is that we are looking for working group support and review. In the case of adoption we are looking for whether the working group considers the document a good starting point for the problem, whether working group participants want to work on the problem, and whether there is enough active participation to support and review the work. This is also why we find "+1" response to be unhelpful in judging this. For working group last call, we are looking for whether the working group thinks the document is in good enough shape to be sent to the IESG and the IETF community. In particular, we assume that the authors of a document are in support of it. What is of interest to us when we issue these calls is about the opinion of the rest of the working group. Working group adoption and completion requires that more than just the author team supports the work. It needs broad working group support and review. Yours, Bruno, Jim, and Joel From nobody Mon Mar 14 18:25:24 2022 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 15D263A1588; Mon, 14 Mar 2022 18:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_SCC_BODY_TEXT_LINE=-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 Wb2hX4DLlChp; Mon, 14 Mar 2022 18:25:17 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 5CAB63A158C; Mon, 14 Mar 2022 18:25:14 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id y15so5357819qta.13; Mon, 14 Mar 2022 18:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5hyVnaRMmdfE//0IL+QN8b2hgqPiTLvbYYPhCLBASiw=; b=q09W98Bf+Tss9l6zpaC40PG30Qx8H6pydKqjHFWyrYHIvEW6Vbn9uorgnSEVyQQyhW xMDoJcXN2+vrdOWfoM65K1fjGltGH4H7/bq1ClLrsm0tUuOATZw/6QQZMh2p+cI54JBa QMnXmzcUTyq0FZv02cg7pOOEQ+uI0UQCU29dV/csycGyTFsbZc77TMeRzRTqJpfErVW8 XfmBGci9Eh1TJOFImXb2F2+pG8eQlaY6KSd0YOxmHa23OFREF8MKjNLl/dQAxR9oGkMj SawRm/S8/knJu4K5v//CRCK1V5++cklXYTfK/syMYHfowHCJI/7AGm4zrB0lSIRfGC7a beqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5hyVnaRMmdfE//0IL+QN8b2hgqPiTLvbYYPhCLBASiw=; b=IMDRXmHbF6q8bUVXZqUbPaulPtyAJs7TmXUnLmTWOqeJJaXs55yGOKFw/EX/Mlneiw SmFb55whdMJ9ScKn8piA7fIwXfypPpjJK9SWjt7wTHcWtr1p20Cx+jcYuwwTvZ3AYvPW i4UheE4PMZ4JZ1T4XYFB6hI2Mhjnj+p0dnc/nmdew6CLLHOLXH5/mT6O/MYzR66Q6OS2 QKeWt/pZGmVpr033UjixZxaLeHV8IDl3stcGIgJW9oaiOq89hQZT/3zJu64CM37W3znH TI9UD4mpDVj/p1mf6v3cgZHZpchYwAoGZHHzXqwXWlWCSoaQK0WrUdAHkx+UpB3B0Fjl 26/w== X-Gm-Message-State: AOAM5300tds6yKWWbQsGlVp1QUgzsbdIRUVG+MpT5cNo1YrNPu2PlgQI B7cvHoo7SZ4pFkn9EV07VOkYaQ4oOyWIi2E6ICTuFCFCQ9M= X-Google-Smtp-Source: ABdhPJy8K0j8ia3VzV27EXfUDhr9J/8EFha7DLojFwV1wos4A+D/kO5RkUQr+GpmcZlsAjoxYUr8JK3TBGqTLraNSVI= X-Received: by 2002:a05:622a:189e:b0:2e1:dcd4:d01c with SMTP id v30-20020a05622a189e00b002e1dcd4d01cmr3122549qtc.1.1647307512806; Mon, 14 Mar 2022 18:25:12 -0700 (PDT) MIME-Version: 1.0 References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Mon, 14 Mar 2022 18:25:01 -0700 Message-ID: To: "Ahmed Abdelsalam (ahabdels)" , draft-filsfils-spring-path-tracing@ietf.org Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000023015c05da37abca" Archived-At: Subject: Re: [spring] [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-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, 15 Mar 2022 01:25:22 -0000 --00000000000023015c05da37abca Content-Type: text/plain; charset="UTF-8" Hi Ahmed and the Authors, thank you for sharing this information. I've read the draft and have several questions and comments: - It is not clear if you propose a new active measurement protocol or view it as a hybrid method (based on RFC 7799 classification). On one hand, packets are referred to as probes, but I don't see why the new Hb H option cannot be applied to a data packet. - Resemblance with IOAM is very strong and it seems that the only advantage of PT over IOAM seems in the introduction of a Truncated Timestamp IE for a Midpoint node. If the same IE is added in IOAM, what do you see as the benefit of using PT compared to IOAM? - In the draft you describe how to use PT to collect timestamps along a path. T64 is recorded in PTP 64 bit-long format. What is the format used to record a Truncated Timestamp? Also, I couldn't find an explanation why PT uses only one timestamp format and, for example, does not allow using NTP 64 bit-long timestamp format. - Furthermore, one-way delay measurement requires clock synchronization. OIj the draft you use two use cases for PT, intercontinental and DC, what should be the accuracy of the clock synchronization in the domain to ensure the PT produces useful measurement data? - As I understand the process of collecting truncated timestamps at a midpoint system, it records the value into the HbH IPv6 EH. You suggest that the time value is "the time at which the packet egress the router". But since a new value is written in the packet, should the checksum be re-calculated? And if that is the case, would that cause a variable delay that affects the accuracy of the measurement provided by the PT method? - Related to the above mentioned scenario, I find that IOAM has an advantage compared with the PT method as a process of generating telemetry data can be separated from transporting that telemetry information for processing. For example, using IOAM Direct Export or Hybrid Two-Step mechanisms. Such separation allows for more accurate measurements and also can be conducted out-of-band relative to the monitored data flow. I greatly appreciate your kind consideration of my comments and questions and looking forward to an interesting discussion. Regards, Greg On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahabdels) wrote: > Dear SPRING WG, IPPM WG, > > > > We have submitted a new I-D for Path Tracing in SRv6 networks ( > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) > to SPRING WG. > > > > We are looking for your feedback and comments. > > > > Path Tracing provides a record of the packet path as a sequence of > interface ids. In addition, it provides a record of end-to-end delay, > per-hop delay, and load on each egress interface along the packet delivery > path to facilitate operation of SR networks. > > > > Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop > extension header. > > > > We will present Path Tracing to the SPRING WG at next IETF ( > https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) > > > > > Thanks, > > Ahmed > > > > *From: *internet-drafts@ietf.org > *Date: *Friday, 4 March 2022 at 16:48 > *To: *Ahmed Abdelsalam (ahabdels) , cf(mailer list) < > cf@cisco.com>, Mark Yufit , Pablo Camarillo > (pcamaril) , Pablo Camarillo (pcamaril) < > pcamaril@cisco.com>, Satoru Matsushima , > Thomas.Graf , Yuanchao Su < > yitai.syc@alibaba-inc.com> > *Subject: *New Version Notification for > draft-filsfils-spring-path-tracing-00.txt > > > A new version of I-D, draft-filsfils-spring-path-tracing-00.txt > has been successfully submitted by Pablo Camarillo Garvia and posted to the > IETF repository. > > Name: draft-filsfils-spring-path-tracing > Revision: 00 > Title: Path Tracing in SRv6 networks > Document date: 2022-03-04 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt > Status: > https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing > > > Abstract: > Path Tracing provides a record of the packet path as a sequence of > interface ids. In addition, it provides a record of end-to-end > delay, per-hop delay, and load on each egress interface along the > packet delivery path. > > Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- > by-Hop extension header. > > Path Tracing supports fine grained timestamp. It has been designed > for linerate hardware implementation in the base pipeline. > > > > > > The IETF Secretariat > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --00000000000023015c05da37abca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ahmed and the Authors,
thank you f= or sharing this=C2=A0information. I've read the draft and have several = questions and comments:
  • It is not clear if you propose a = new active measurement protocol or view it as a hybrid method (based on RFC= 7799 classification). On one hand, packets are referred to as probes, but = I don't see why the new Hb H option cannot be applied to a data packet.=
  • Resemblance with IOAM is very strong and it seems that the only ad= vantage of PT over IOAM seems in the introduction of a Truncated Timestamp = IE=C2=A0 for a Midpoint node. If the same IE is added in IOAM, what do you = see as the benefit of using PT compared to IOAM?
  • In the draft you d= escribe how to use PT to collect timestamps along a path. T64 is recorded i= n PTP 64 bit-long format. What is the format used to record a Truncated Tim= estamp? Also, I couldn't find an explanation why PT uses only one times= tamp format and, for example, does not allow using NTP 64 bit-long timestam= p format.
  • Furthermore, one-way delay measurement requires clock syn= chronization. OIj the draft you use two use cases for PT, intercontinental = and DC, what should be the accuracy of the clock synchronization=C2=A0in th= e domain to ensure the PT produces useful measurement data?
  • As I un= derstand the process of collecting truncated timestamps at a midpoint syste= m, it records the value into the HbH IPv6 EH. You suggest that the time val= ue is "the time at which the packet egress the router". But since= a new value is written in the packet, should the checksum be re-calculated= ? And if that is the case, would that cause a variable delay that affects t= he accuracy of the measurement provided by the PT method?
  • Related t= o the above mentioned scenario, I find that IOAM has an advantage compared = with the PT method as a process of generating telemetry data can be separat= ed from transporting that telemetry information for processing. For example= , using IOAM Direct Export or Hybrid Two-Step mechanisms. Such separation a= llows for more accurate measurements and also can be conducted out-of-band = relative to the monitored data flow.
I greatly appreciate=C2= =A0your kind consideration of my comments and questions and looking forward= to an interesting discussion.

Regards,
Greg

On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahab= dels) <ahabdels=3D40cisco.= com@dmarc.ietf.org> wrote:

Dear SPRING WG,=C2=A0= IPPM WG,

=C2=A0<= /span>

We have submitted a n= ew I-D for Path Tracing in SRv6 networks (https= ://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG.

=C2=A0<= /span>

We are looking for yo= ur feedback and comments.

=C2=A0<= /span>

Path Tracing provides= a record of the packet path as a sequence of interface ids. In addition, i= t provides a record of end-to-end delay, per-hop delay, and load on each eg= ress interface along the packet delivery path to facilitate operation of SR networks.<= /u>

=C2=A0<= /span>

Path Tracing allows t= o trace 14 hops with only a 40-octet IPv6 Hop-by-Hop extension header.

=C2=A0<= /span>

We will present Path = Tracing to the SPRING WG at next IETF (https= ://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt)

=C2=A0<= /span>

Thanks,=

Ahmed

=C2=A0<= /span>

From: internet-drafts@ietf.org <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, cf(mailer list) <cf@cisco.com>, Mark Y= ufit <mark.= yufit@broadcom.com>, Pablo Camarillo (pcamaril) <pcamaril@cisco.com>, Pablo C= amarillo (pcamaril) <pcamaril@cisco.com>, Satoru Matsushima <satoru.matsushima@g.sof= tbank.co.jp>, Thomas.Graf <Thomas.Graf@swisscom.com>, Yuanchao Su <yitai.syc@alibaba-inc.com>=
Subject: New Version Notification for draft-filsfils-spring-path-tra= cing-00.txt


A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the=
IETF repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-fil= sfils-spring-path-tracing
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Path Tracing i= n SRv6 networks
Document date:=C2=A0 2022-03-04
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Sub= mission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 15
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.= ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc= /draft-filsfils-spring-path-tracing/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/= draft-filsfils-spring-path-tracing


Abstract:
=C2=A0=C2=A0 Path Tracing provides a record of the packet path as a sequenc= e of
=C2=A0=C2=A0 interface ids.=C2=A0 In addition, it provides a record of end-= to-end
=C2=A0=C2=A0 delay, per-hop delay, and load on each egress interface along = the
=C2=A0=C2=A0 packet delivery path.

=C2=A0=C2=A0 Path Tracing allows to trace 14 hops with only a 40-bytes IPv6= Hop-
=C2=A0=C2=A0 by-Hop extension header.

=C2=A0=C2=A0 Path Tracing supports fine grained timestamp.=C2=A0 It has bee= n designed
=C2=A0=C2=A0 for linerate hardware implementation in the base pipeline.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0


The IETF Secretariat

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--00000000000023015c05da37abca-- From nobody Tue Mar 15 03:28:10 2022 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 735FC3A1B9D; Tue, 15 Mar 2022 03:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 2Rzy3GUOLveM; Tue, 15 Mar 2022 03:27:48 -0700 (PDT) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (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 67AB03A1B9C; Tue, 15 Mar 2022 03:27:32 -0700 (PDT) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-2e5757b57caso39726967b3.4; Tue, 15 Mar 2022 03:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=qiYGAhIoP72te+lpmEoA9ZCebtlVo+plHRAP1rhzNiM=; b=BVULhlfzc6SwtxSyXo2tOxXtQ8MNPV+Vb8vkqP+HldgdVQilyJ4Oi18ecQrUbXSFqF TPUqH3v3GkvF3RBUg9LZOeXZ4OF5osEzivjbklaORYYgAK8sTULoOfaCDmUjndutdyXs wi2e7LD9tsDLHL0mJfZGancrwOEOmezQMhQwh2Hnse5e1HaloyUlrTvltdkaeRRUcgUt JFV/QeBAoEC3rRYydTwkHjEuI8EfDGjxLf7mN8b87RVBgsL165CBEimkSB4NLp0EiisQ ZYW0I8i/THSGscXEHn214UTANy1pkw3jIYU1WeSRXsAsBYXwnWOxOOsXMLzZdLLKGIwn Pf/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=qiYGAhIoP72te+lpmEoA9ZCebtlVo+plHRAP1rhzNiM=; b=lu5VbRQgVHpnn6rmBplTIDazS9oPBLczpEHJPcgiAQHK09s4pNfB73zttIs0J+4BsE OZYVVwejiVV0qWxHJAaQB5qnpIR93+sfv1KI7SrVtKnJP4HvAXJFd7AYvArIVuGhHUVJ y1kXqu8zFczEupe12dSFqhgNp4v271Jlk5cDvrvIv11oYQd35/BptU+ydA3Kb8Ob9PAN VjOk9acrbTVAJ73TjMeJSvTPP3biAlc8HyfJ9CNiw/6JnJ1ueNusNxyhdu5jIzBRe+GY JZlbqnNrxOa5i8jykbQywH5RM0AYRRLy5jVQYcLtcKi/5w1c8iiZ3gbCztVdvH90ZFox xFjw== X-Gm-Message-State: AOAM530N+oel2mr6PFv4AOhcEPddeB108of+/pDwgF7eq+/c6QnSBAGY 9mYouLZLWgAM4I17bkVX+cJi1IXAyJ6ogAvXt6s= X-Google-Smtp-Source: ABdhPJyiQAnCME9UJCIAqyeX0Vz/MnjLJxTuxCXstaou48VuSjTiziy5qFN1K1SUwTQGfxEyij0sTwUgltO4Vhccl/M= X-Received: by 2002:a81:a882:0:b0:2ca:287c:6bc4 with SMTP id f124-20020a81a882000000b002ca287c6bc4mr24118482ywh.105.1647340046302; Tue, 15 Mar 2022 03:27:26 -0700 (PDT) MIME-Version: 1.0 References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: From: Tal Mizrahi Date: Tue, 15 Mar 2022 12:27:15 +0200 Message-ID: To: "Ahmed Abdelsalam (ahabdels)" , "spring@ietf.org" , "ippm@ietf.org" , draft-filsfils-spring-path-tracing@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-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, 15 Mar 2022 10:28:02 -0000 Dear authors, Thanks for sharing this interesting draft. Per-hop measurement and reporting is a very important OAM tool, and there is quite a bit of ongoing / previously proposed work in the IETF about this topic. A few comments: 1. It looks like the draft defines two aspects: (a) the path tracing IPv6 option, which is not specific to segment routing, but is actually applicable to IPv6 routers in general, and (b) an SRH TLV. It seems like the SRH TLV could alternatively be defined as a generic IPv6 destination option. Is there anything that functionally limits this feature to networks that use segment routing? 2. As Greg pointed out in a previous email, the functionality here seems very similar to IOAM. The PT option could actually be implemented by using an IOAM trace option: by defining a couple of new data fields you could get an equally compact number of bits as the PT option in the current draft. The SRH TLV could alternatively be defined as an IOAM Edge-to-edge option (again, maybe with a couple of new data fields). Is there a reason why this is a new protocol, rather than just defining new data field types in IOAM? 3. Time synchronization is defined as a 'MUST' in the draft, but it seems like you can benefit from path tracing even in cases where synchronization is not possible. Have you considered such use cases? 4. Regarding 'MCD.TTS (Truncated Timestamp)': rather than defining some of the bits to represent milliseconds and other bits to represent microseconds, it may be more hardware-friendly to define a subset of the bits of timestamp formats that are commonly implemented in hardware, such as the PTP timestamp format or the NTP timestamp format. Cheers, Tal. On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels) wrote: > > Dear SPRING WG, IPPM WG, > > > > We have submitted a new I-D for Path Tracing in SRv6 networks (https://da= tatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING W= G. > > > > We are looking for your feedback and comments. > > > > Path Tracing provides a record of the packet path as a sequence of interf= ace ids. In addition, it provides a record of end-to-end delay, per-hop del= ay, and load on each egress interface along the packet delivery path to fac= ilitate operation of SR networks. > > > > Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop= extension header. > > > > We will present Path Tracing to the SPRING WG at next IETF (https://datat= racker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) > > > > Thanks, > > Ahmed > > > > From: internet-drafts@ietf.org > Date: Friday, 4 March 2022 at 16:48 > To: Ahmed Abdelsalam (ahabdels) , cf(mailer list) , Mark Yufit , Pablo Camarillo (pcamari= l) , Pablo Camarillo (pcamaril) , S= atoru Matsushima , Thomas.Graf , Yuanchao Su > Subject: New Version Notification for draft-filsfils-spring-path-tracing-= 00.txt > > > A new version of I-D, draft-filsfils-spring-path-tracing-00.txt > has been successfully submitted by Pablo Camarillo Garvia and posted to t= he > IETF repository. > > Name: draft-filsfils-spring-path-tracing > Revision: 00 > Title: Path Tracing in SRv6 networks > Document date: 2022-03-04 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/archive/id/draft-filsfils-spring-pat= h-tracing-00.txt > Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-pa= th-tracing/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-filsfils-spri= ng-path-tracing > > > Abstract: > Path Tracing provides a record of the packet path as a sequence of > interface ids. In addition, it provides a record of end-to-end > delay, per-hop delay, and load on each egress interface along the > packet delivery path. > > Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- > by-Hop extension header. > > Path Tracing supports fine grained timestamp. It has been designed > for linerate hardware implementation in the base pipeline. > > > > > The IETF Secretariat > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Mar 15 06:03:20 2022 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 5546E3A1BBF for ; Tue, 15 Mar 2022 06:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 dyD_PEq__hZf for ; Tue, 15 Mar 2022 06:03:11 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 221CF3A1BC5 for ; Tue, 15 Mar 2022 06:02:39 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id j2so37257019ybu.0 for ; Tue, 15 Mar 2022 06:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YrFIam4jtd7Xnr6E5gLB+sjVp1desxpIdrZEwNxTqD0=; b=f7KD1HHy14SWexrull/ajG6frBMoX1I8Op60cnDk5+iUgglnr8rltYjKP6e2Q+Cwgo BD6zNf8yNNeSfs4oBavc/cLejLs+kqVtcgNHAtmCj3xjf5a/AOPHTd2WmUrf2hq9tH/S 4am0ydTa+UteZn1+A4YXBtjfFuLBf5mRXD7/taAv90TytURBZGuyGdduu5aH7wjsHSDj UgowS90VI+tru7d+26Uvb4Rh99cCBR/XS8WP8DGDSvkhOHpSoAvOKrfO/1p/UNWN4Nfi wa3ejPM2N6eILRCBzu+jKFm6KhQYX/pCEPCTQ/GXW0K9HPMQlcecmFbhr0WkM00tmTet 1ZBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YrFIam4jtd7Xnr6E5gLB+sjVp1desxpIdrZEwNxTqD0=; b=bA16TQempULg4NeavwVAllPoZztUJ7/9vPUwFtEb/GT3kk8sM7Er6EEAkpwL2lcKSD mggSOBkqS8ItwM2TozpdkYRrv6+134hhi35awM/F5wfUjWF/ffjZTFozv95Ekptox1RO OiWZptVlL7Xhy5indxtso1rb+PX7OWUvobVong5Fhg7cpZJXksIUysK2a3qPnm4XDGDF xzZMSZCAIgSBkMghI1Ojn7ases0thXF/xD7lExxcYBfEAgaZzMEyk6L3Lpz7bpiwyOti T1l+vscsHe6hAuRCwW1qoDcVOgGDAVB/1a985+1/Veeprw31mowZKPmMC3N2Fjhvh+wW GwNg== X-Gm-Message-State: AOAM5322amygtqX/nitDO+TyBoaRRgocCSJ8UeFQ8+u8m1mFE+hn5Mtx kOA6KTVB+PoCbkbbrZ1L9BhsukfrLGd3P6hhESE= X-Google-Smtp-Source: ABdhPJy9XZlI/rEv8US3tM3rL/eZSJ6H+Wvkw9pwUpufVq4d+xRWWQTbJOB1rO2gJ2di1HCWpgBFLt9iCgbkJdFo0m0= X-Received: by 2002:a5b:20f:0:b0:628:6a2b:ee2c with SMTP id z15-20020a5b020f000000b006286a2bee2cmr23579652ybl.175.1647349357994; Tue, 15 Mar 2022 06:02:37 -0700 (PDT) MIME-Version: 1.0 References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: From: Eduard Metz Date: Tue, 15 Mar 2022 14:02:27 +0100 Message-ID: To: Andrew Alston - IETF Cc: "Xiejingrong (Jingrong)" , Gyan Mishra , Andrew Alston - IETF , "spring@ietf.org" , Tom Hill Content-Type: multipart/related; boundary="0000000000004dfcb005da416966" Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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 Mar 2022 13:03:17 -0000 --0000000000004dfcb005da416966 Content-Type: multipart/alternative; boundary="0000000000004dfcae05da416965" --0000000000004dfcae05da416965 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jingrong, I haven't read your draft in detail yet, but the question of how to expose SRv6 based transport service / capabilities for consumption by overlay networks I think is an interesting one. I'm not sure whether the reference figure (5) already conflicts with "limited domain", assuming one would expose such services only to a controlled set of CPE I would say it doesn't. I have to agree with others who commented that the scope of the draft is not fully clear though. It suggests to aim to solve "interdomain" cases, while in the solution part the focus seems to be again on the question of how to expose services. It would help if the scope is clarified. By the way, I interpreted the scope as described in the first sentence above, is this correct? cheers, Eduard On Mon, Mar 14, 2022 at 4:17 PM Andrew Alston - IETF wrote: > Jingrong, > > > > Limited Domain (in my view) refers to a domain where all points are under > single administrative control. I.E the source, destination and anything = in > the middle must fall under the same administrative control, otherwise, yo= u > are not within the limited domain. This can be extended using > encapsulation (tunneling) where the packet is encapsulated and preferably > cryptographically protected, such that any intermediate networks outside = of > the same administrative control cannot, either by error or deliberate > action, act on the information contained within the routing headers. > > > > Anything else would run into issues with section 8.2 of RFC8402. > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Xiejingrong > (Jingrong) > *Sent:* Monday, March 14, 2022 10:16 AM > *To:* Gyan Mishra ; Andrew Alston - IETF > > *Cc:* spring@ietf.org; Tom Hill > *Subject:* Re: [spring] Network Programming Interface for Provisioning of > Underlay Services to Overlay Networks Using SRv6 > (draft-xie-spring-srv6-npi-for-overlay) > > > > Hi, > > > > I think I now understand better the concern about "the use of SIDs over > the public Internet". > > In my previous mail, the SID2/SID3 used between CPE2-Internet-CPE3 is to > explain the layering model (over vs across), but it is not the proposal o= f > the draft. > > The draft is talking about the interface (name NPI) that overlay networks > use to access the underlying network in the last mile. > > There may be an Access Network (AN) in the last mile, and the AN may also > connect to Internet backbone and/or multiple underlying networks, but it = is > distinct from the "open Internet". > > Make more sense if the AN can enhance (if no way to enforce) not to leak > the SRv6 BSID to Internet backbone or other TNs ? > > > > For the control plane, it is still not clear if a controller is required, > but one thing I considered is to use an IETF standard protocol because th= e > PE need to implement the NPI. > > > > Regards, > > Jingrong > > > > *From:* Gyan Mishra [mailto:hayabusagsm@gmail.com = ] > > *Sent:* Sunday, March 13, 2022 8:26 AM > *To:* Andrew Alston - IETF > *Cc:* Tom Hill ; Xiejingrong (Jingrong) < > xiejingrong@huawei.com>; spring@ietf.org > *Subject:* Re: [spring] Network Programming Interface for Provisioning of > Underlay Services to Overlay Networks Using SRv6 > (draft-xie-spring-srv6-npi-for-overlay) > > > > Hi Jingrong > > > > I reads the draft and was trying to understand the problem statement as > well as the solution. > > > > So I believe the problem statement is how to interconnect desperate sites > over the internet using a managed IPSEC VPN or SDWAN solution or managed > MPLS and complexity of provisioning CE attachment. > > > > The solution is an automated solution using SRv6 over the internet using > BSID. This involves running SRv6 over the internet, however SRv6 is > limited to closed domains. It appears an E2E pseudowire is used in > provisioning the service. Have you though of using NG L2 VPN EVPN all or > single active multi home over SRv6. > > > > Does all the provisioning use a PCE / SDN controller? > > > > > > Thanks > > > > Gyan > > > > On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston - IETF 40liquid.tech@dmarc.ietf.org> wrote: > > Hi Jingrong, > > > > I=E2=80=99m struggling to entirely understand this. I think the question= for me > is =E2=80=93 if you are sending packets with SID=E2=80=99s over the open = internet =E2=80=93 are > you encapsulating those packets and is this encapsulation cryptographical= ly > protected =E2=80=93 I.E the SID=E2=80=99s are not visible outside of the = encapsulation, > to preserve the limited domain. > > > > Limited domains are typically extended via tunnel mechanisms, very often > with cryptographic protection, hence the question > > > > Thanks > > > > Andrew > > > > > > *From:* spring *On Behalf Of *Xiejingrong > (Jingrong) > *Sent:* Thursday, March 10, 2022 9:40 AM > *To:* Tom Hill ; spring@ietf.org > *Subject:* Re: [spring] Network Programming Interface for Provisioning of > Underlay Services to Overlay Networks Using SRv6 > (draft-xie-spring-srv6-npi-for-overlay) > > > > Hi Tom, > > Thanks for reading the draft and raise discussions. > > In the proposal the SRv6 domain is the overlay network, belonging to one > administrative domain -- the overlay network operator(say ONO). > > For your concern about use of SIDs "across" the public Internet. Let me > try to explain using following figure (hope it works): > > CPE1 CPE2 CPE3 > + + + + > | +--------+ | | +----------+ | > +---[1] TN1 [1]---+ +---+ Internet |---+ > +--------+ +----------+ > > In the perspective of the ONO, it has the following SIDs: > SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO. > SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, > marked [1] in the figure). > The ONO can use these SIDs, and I would think they are all "in the overla= y > network", and are running "Over the Internet". > > You mentioned in the last sentence "the use of SIDs over the public > Internet". That is what I am modeling above. > > Thanks > Jingrong > > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org ] > On Behalf Of Tom Hill > Sent: Wednesday, March 9, 2022 10:43 PM > To: spring@ietf.org > Subject: Re: [spring] Network Programming Interface for Provisioning of > Underlay Services to Overlay Networks Using SRv6 > (draft-xie-spring-srv6-npi-for-overlay) > > Hi Jinrong, > > On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote: > > I just posted a draft that specifies a framework and some more detail > > of the idea for provisioning of underlay services > > (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using > SRv6. > > > > https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov > > erlay > > > verlay> > > > > Please comment and send any feedback. > > > > I would like to discuss this document over e-mail/mail-list. > > > I'm concerned that this draft is explicitly violating the concept of > SRv6 as a protocol that operates within a Limited Domain. > > As per Section 3.2 of this draft, "... the network operator of AN, TN and > Internet can be different from each other." > > Further, "In some scenarios, the AN can be an Internet exchange provider > (IXP) independent of ISP and NSP. In some other scenarios, the AN can be > an ISP that running Internet backbone as well." > > This would read to me that the proposal is explicitly intended to be > inter-domain, and not at all limited to any one administrative domain. > Additionally, I cannot determine if the draft implicitly requires the use > of SIDs across the public Internet? > > Could I ask for some clarification on the scope of the draft, with respec= t > to Limited Domains, and also the use of SIDs over the public Internet? > > Kind regards, > > -- > Tom > > _______________________________________________ > 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 > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -- > > [image: =E5=9B=BE=E5=83=8F=E5=B7=B2=E8=A2=AB=E5=8F=91=E4=BB=B6=E4=BA=BA= =E5=88=A0=E9=99=A4=E3=80=82] > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000004dfcae05da416965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jingrong,

I haven't read your= draft in detail yet, but the question of how to expose SRv6 based transpor= t service / capabilities for consumption by overlay networks I think is an = interesting=C2=A0one.=C2=A0

I'm not sure wheth= er the reference figure (5) already conflicts with "limited domain&quo= t;, assuming one would expose=C2=A0such services only to a controlled set o= f CPE I would say it doesn't. I have to agree with others who commented= that the scope of the draft is not fully clear though. It suggests to aim = to solve "interdomain" cases, while in the solution part the focu= s=C2=A0seems to be again on the question of how to expose services.

It would help if the scope=C2=A0is clarified.
B= y the way, I interpreted the scope as described in the first sentence above= , is this correct?

cheers,
=C2=A0 Eduard=

=C2=A0

=
On Mon, Mar 14, 2022 at 4:17 PM Andre= w Alston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org> wrote:

Jingrong,

=C2=A0

Limited Domain (in my view) refers to a domain where all points a= re under single administrative control.=C2=A0 I.E the source, destination a= nd anything in the middle must fall under the same administrative control, otherwise, you are not within the limited= domain.=C2=A0 This can be extended using encapsulation (tunneling) where t= he packet is encapsulated and preferably cryptographically protected, such = that any intermediate networks outside of the same administrative control cannot, either by error or deliberate a= ction, act on the information contained within the routing headers.<= u>

=C2=A0

Anything else would run into issues with section 8.2 of RFC8402.<= u>

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

From: spring <spring-bounces@ietf.org> On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, March 14, 2022 10:16 AM
To: Gyan Mishra <hayabusagsm@gmail.com>; Andrew Alston - IETF <andrew-= ietf@liquid.tech>
Cc: spring@ietf= .org; Tom Hill <tom@ninjabadger.net>
Subject: Re: [spring] Network Programming Interface for Provisioning= of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6= -npi-for-overlay)

=C2=A0

Hi,

=C2=A0

I think I now understand better the concer= n about "the use of SIDs over the public Internet".=

In my previous mail, the SID2/SID3 used be= tween CPE2-Internet-CPE3 is to explain the layering model (over vs across),= but it is not the proposal of the draft.

The draft is talking about the interface (= name NPI) that overlay networks use to access the underlying network in the= last mile.

There may be an Access Network (AN) in the= last mile, and the AN may also connect to Internet backbone and/or multipl= e underlying networks, but it is distinct from the "open Internet".

Make more sense if the AN can enhance (if = no way to enforce) not to leak the SRv6 BSID to Internet backbone or other = TNs ?

=C2=A0

For the control plane, it is still not cle= ar if a controller is required, but one thing I considered is to use an IET= F standard protocol because the PE need to implement the NPI.

=C2=A0

Regards,

Jingrong

=C2=A0

From: Gyan Mishra [mailto:hayabusagsm@gmail.com]
Sent: Sunday, March 13, 2022 8:26 AM
To: Andrew Alston - IETF <andrew-ietf@liquid.tech>
Cc: Tom Hill <tom@ninjabadger.net>; Xiejingrong (Jingrong) <xiejingrong@huawei.com&g= t;; spring@ietf.org Subject: Re: [spring] Network Programming Interface for Provisioning= of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6= -npi-for-overlay)

=C2=A0

Hi Jingrong=C2=A0

=C2=A0

I reads the draft and was trying to understand= the problem statement as well as the solution.

=C2=A0

So I believe the problem statement is how to i= nterconnect desperate sites over the internet using a managed IPSEC VPN or = SDWAN solution or managed MPLS and complexity of provisioning CE attachment= .

=C2=A0

The solution is an automated solution using SR= v6 over the internet using BSID.=C2=A0 This involves running SRv6 over the = internet, however SRv6 is limited to closed domains.=C2=A0 It appears an E2= E pseudowire is used in provisioning the service.=C2=A0 Have you though of using NG L2 = VPN EVPN all or single active multi home over SRv6.=C2=A0

=C2=A0

Does all the provisioning use a PCE / SDN cont= roller?=C2=A0

=C2=A0

=C2=A0

Thanks=C2=A0

=C2=A0

Gyan

=C2=A0

On Thu, Mar 10, 2022 at 9:59 AM Andrew Alston = - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org> wrote:

Hi Jingrong,

=C2=A0

I=E2=80=99m strugg= ling to entirely understand this.=C2=A0 I think the question for me is =E2=80=93 if you are sending packets with SID=E2=80=99s over the open internet =E2=80=93 are you encapsulating those packets a= nd is this encapsulation cryptographically protected =E2=80=93 I.E the SID=E2= =80=99s are not visible outside of the encapsulation, to preserve th= e limited domain.

=C2=A0

Limited domains are typically extended via tun= nel mechanisms, very often with cryptographic protection, hence the questio= n

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

From: spring <spring-bounces@ietf.o= rg> On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, March 10, 2022 9:40 AM
To: Tom Hill <tom@ninjabadger.net>; spring@ietf.org Subject: Re: [spring] Network Programming Interface for Provisioning= of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6= -npi-for-overlay)

=C2=A0

Hi Tom,

Thanks for reading the draft and raise discussions.

In the proposal the SRv6 domain is the overlay network, belonging to one ad= ministrative domain -- the overlay network operator(say ONO).

For your concern about use of SIDs "across" the public Internet. = Let me try to explain using following figure (hope it works):

CPE1 CPE2 CPE3
+ + + +
| +--------+ | | +----------+ |
+---[1] TN1 [1]---+ +---+ Internet |---+
+--------+ +----------+

In the perspective of the ONO, it has the following SIDs:
SID1/2/3: allocated on CPE1/CPE2/CPE3 by the ONO.
SID4/5: allocated by TN operator but serves for the ONO (Tenant-1 of TN, ma= rked [1] in the figure).
The ONO can use these SIDs, and I would think they are all "in the ove= rlay network", and are running "Over the Internet".

You mentioned in the last sentence "the use of SIDs over the public In= ternet". That is what I am modeling above.

Thanks
Jingrong


-----Original Message-----
From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Tom Hill
Sent: Wednesday, March 9, 2022 10:43 PM
To: spring@ietf.org
Subject: Re: [spring] Network Programming Interface for Provisioning of Und= erlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-fo= r-overlay)

Hi Jinrong,

On 08/03/2022 01:58, Xiejingrong (Jingrong) wrote:
> I just posted a draft that specifies a framework and some more detail =
> of the idea for provisioning of underlay services
> (Slice/SR-policy/Mcast/etc) to overlay networks(SD-WAN/CDN/etc), using= SRv6.
>
> https://datatracker.ietf.org/doc/html/draft-xie-spring-srv6-npi-for-ov<= br> > erlay
> <https://datatracker.ietf.org/doc/html/dra= ft-xie-spring-srv6-npi-for-o
> verlay>
>
> Please comment and send any feedback.
>
> I would like to discuss this document over e-mail/mail-list.


I'm concerned that this draft is explicitly violating the concept of SRv6 as a protocol that operates within a Limited Domain.

As per Section 3.2 of this draft, "... the network operator of AN, TN = and Internet can be different from each other."

Further, "In some scenarios, the AN can be an Internet exchange provid= er
(IXP) independent of ISP and NSP. In some other scenarios, the AN can be an= ISP that running Internet backbone as well."

This would read to me that the proposal is explicitly intended to be inter-= domain, and not at all limited to any one administrative domain.
Additionally, I cannot determine if the draft implicitly requires the use o= f SIDs across the public Internet?

Could I ask for some clarification on the scope of the draft, with respect = to Limited Domains, and also the use of SIDs over the public Internet?

Kind regards,

--
Tom

_______________________________________________
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

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

--

3D"=E5=9B=BE=E5=83=8F=E5=B7=B2=E8=A2=AB=E5=

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com<= /u>

M 301 502-1347

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000004dfcae05da416965-- --0000000000004dfcb005da416966 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <17f8d931a0e4ce8e91> X-Attachment-Id: 17f8d931a0e4ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAASAFEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK/9k= --0000000000004dfcb005da416966-- From nobody Wed Mar 16 00:31:20 2022 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 10B273A0D3D for ; Wed, 16 Mar 2022 00:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 i6fpMATmXVSH for ; Wed, 16 Mar 2022 00:31:12 -0700 (PDT) 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 DB62C3A0D34 for ; Wed, 16 Mar 2022 00:31:11 -0700 (PDT) Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KJMPT54s8z67NN6; Wed, 16 Mar 2022 15:30:21 +0800 (CST) Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 16 Mar 2022 08:31:07 +0100 Received: from kwepeml500002.china.huawei.com (7.221.188.128) by kwepeml100004.china.huawei.com (7.221.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Mar 2022 15:31:06 +0800 Received: from kwepeml500002.china.huawei.com ([7.221.188.128]) by kwepeml500002.china.huawei.com ([7.221.188.128]) with mapi id 15.01.2308.021; Wed, 16 Mar 2022 15:31:06 +0800 From: "Xiejingrong (Jingrong)" To: Eduard Metz , Andrew Alston - IETF CC: Gyan Mishra , Andrew Alston - IETF , "spring@ietf.org" , Tom Hill Thread-Topic: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) Thread-Index: Adgyj2pEDTIYoRv+Rwm6VOp4IGlK2wA8YiOAADHZrvAAAP1xAAB4Z3+AAFEevQAAAECkAAAtnLOAADbs0qA= Date: Wed, 16 Mar 2022 07:31:06 +0000 Message-ID: <506fb082c84148d086d83d58de654cb5@huawei.com> References: <5138b23393b7434fa674eefd1886385d@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.112.232.176] Content-Type: multipart/related; boundary="_004_506fb082c84148d086d83d58de654cb5huaweicom_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Network Programming Interface for Provisioning of Underlay Services to Overlay Networks Using SRv6 (draft-xie-spring-srv6-npi-for-overlay) 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 Mar 2022 07:31:18 -0000 --_004_506fb082c84148d086d83d58de654cb5huaweicom_ Content-Type: multipart/alternative; boundary="_000_506fb082c84148d086d83d58de654cb5huaweicom_" --_000_506fb082c84148d086d83d58de654cb5huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRWR1YXJkLA0KDQpUaGFuayB5b3UgZm9yIHJlYWRpbmcgYW5kIHRoZSBwb3NpdGl2ZSBm ZWVkYmFjayBvbiB0aGlzIGRyYWZ0Lg0KWW91ciBpbnRlcnByZXRhdGlvbiBpbiB0aGUgZmlyc3Qg c2VudGVuY2UgaXMgYmFzaWNhbGx5IGNvcnJlY3QgYnV0IGluY29tcGxldGUuDQpUaGlzIGRyYWZ0 IGlzIGFib3V0IGhvdyB0byBleHBvc2UgdHJhbnNwb3J0IHNlcnZpY2UgLyBjYXBhYmlsaXRpZXMg Zm9yIGNvbnN1bXB0aW9uIGJ5IG92ZXJsYXkgbmV0d29ya3MsIGFuZCB0aGlzIHBvaW50IGlzIHZl cnkgcHJlY2lzZWx5IGNhdWdodCh0d2ljZSkgaW4geW91ciBtYWlsLg0KVGhlIGV4cG9zaW5nIG9m IHRoZSB0cmFuc3BvcnQgc2VydmljZSB0byBvdmVybGF5IG5ldHdvcmsgb3V0c2lkZSBpcyBhYnN0 cmFjdGVkIGFzIGFuICJJbnRlcmZhY2UiLCBhbmQgaXMgcHJvcG9zZWQgdG8gdXNlIFNSdjYgaW4g dGhpcyBkcmFmdC4NCkhvd2V2ZXIsIHRoZSB0cmFuc3BvcnQgc2VydmljZSBpcyBub3QgbGltaXRl ZCB0byBTUnY2LWJhc2VkIHRyYW5zcG9ydCBzZXJ2aWNlLCBidXQgY2FuIGJlIGltcGxlbWVudGVk IGluZGVwZW5kZW50bHkgb2YgdGhlIEludGVyZmFjZSBzcGVjLCBmb3IgZXhhbXBsZSwgY2FuIGJl IGltcGxlbWVudGVkIHVzaW5nIFNSdjYgb3IgTVBMUy4NCg0KRm9yIHRoZSBzdWdnZXN0aW9uIHRv IGNsYXJpZnkgdGhlIHNjb3BlLCBJIHdvdWxkIHRoaW5rIGFib3V0IGhvdyB0byBjbGFyaWZ5LCBh bmQgc2VuZCB0aGUgcHJvcG9zZWQgdGV4dCB0byBtYWlsaW5nLWxpc3QgZm9yIGRpc2N1c3Npb24u DQoNCkJlZm9yZSB0aGlzLCBJIHdvdWxkIGxpa2UgdG8gc2hhcmUgbXkgcG9pbnRzIGFuZCBob3Bl IGl0IHVzZWZ1bCB0byB1bmRlcnN0YW5kIHRoZSBkcmFmdCBmb3IgeW91IGFsbC4NCg0KMSkgQ3Vy cmVudGx5IFNSdjYgU0lEcyBhcmUgbWFpbmx5IHVzZWQgaW5zaWRlIGEgVE4sIGFuZCBoZW5jZSB0 aGUgIk5ldC1QR00gSW5zdHJ1Y3Rpb24iIGlzIGFuIGFwcHJvcHJpYXRlIGRlc2NyaXB0aW9uLCBh bmQgaXQgaXMgZWFzeSB0byB1bmRlcnN0YW5kIGFzIHRoZSBsaW1pdGVkLWRvbWFpbiBpcyBUTi4N Cg0KMikgVGhlIGRyYWZ0IGlzIGRlc2NyaWJpbmcgYW4gIk5ldC1QR00gSW50ZXJmYWNlIiB0aGF0 IGlzIGV4cG9zZWQgb3V0c2lkZSBhIFROLiBPbmNlIGV4cG9zZWQsIHRoZSB1c2Ugb2YgdGhlIFNS djYgU0lEIGlzIGluIHRoZSAiT3ZlcmxheSBuZXR3b3JrIiwgYW5kIGhlbmNlIHRoZSBsaW1pdGVk LWRvbWFpbiBpcyB0aGUgT3ZlcmxheSBuZXR3b3JrLg0KDQozKSBUaGUgT3ZlcmxheSBuZXR3b3Jr IGlzIGFuIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgYW5kIHRoZSBTUnY2IGRvbWFpbiBpcyBvbmx5 IHBhcnQgb2YgdGhlIE92ZXJsYXkgbmV0d29yay4NCiAgIEZvciBleGFtcGxlLCBpbiB0aGUgZmln dXJlIGluIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL1kyMXl2 Sk8tSTJleC04Vk5Tam9EYldBOXFDay8gLCB0aGUgQ1BFMSwgQ1BFMiBhbmQgdGhlIGV4cG9zZWQg SW50ZXJmYWNlIG9mIFROMSBpcyBhbiBTUnY2IGRvbWFpbiwgYnV0IENQRTMgaXMgbm90IHRoZSBT UnY2IGRvbWFpbi4NCg0KNCkgQW4gT3ZlcmxheSBuZXR3b3JrIG1heSB1c2VzIE4gVHJhbnNwb3J0 LU5ldHdvcmtzLCBhbmQgdGhlcmUgY291bGQgYmUgTiBTUnY2IGRvbWFpbnMsIGVhY2ggc3Vycm91 bmRpbmcgYSBUTi4NCg0KDQpSZWdhcmRzLA0KSmluZ3JvbmcNCg0KRnJvbTogRWR1YXJkIE1ldHog W21haWx0bzpldG1ldHpAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTUsIDIwMjIg OTowMiBQTQ0KVG86IEFuZHJldyBBbHN0b24gLSBJRVRGIDxhbmRyZXctaWV0ZkBsaXF1aWQudGVj aD4NCkNjOiBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpIDx4aWVqaW5ncm9uZ0BodWF3ZWkuY29tPjsg R3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT47IEFuZHJldyBBbHN0b24gLSBJRVRG IDxhbmRyZXctaWV0ZkBsaXF1aWQudGVjaD47IHNwcmluZ0BpZXRmLm9yZzsgVG9tIEhpbGwgPHRv bUBuaW5qYWJhZGdlci5uZXQ+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gTmV0d29yayBQcm9ncmFt bWluZyBJbnRlcmZhY2UgZm9yIFByb3Zpc2lvbmluZyBvZiBVbmRlcmxheSBTZXJ2aWNlcyB0byBP dmVybGF5IE5ldHdvcmtzIFVzaW5nIFNSdjYgKGRyYWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9y LW92ZXJsYXkpDQoNCkhlbGxvIEppbmdyb25nLA0KDQpJIGhhdmVuJ3QgcmVhZCB5b3VyIGRyYWZ0 IGluIGRldGFpbCB5ZXQsIGJ1dCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGV4cG9zZSBTUnY2IGJh c2VkIHRyYW5zcG9ydCBzZXJ2aWNlIC8gY2FwYWJpbGl0aWVzIGZvciBjb25zdW1wdGlvbiBieSBv dmVybGF5IG5ldHdvcmtzIEkgdGhpbmsgaXMgYW4gaW50ZXJlc3Rpbmcgb25lLg0KDQpJJ20gbm90 IHN1cmUgd2hldGhlciB0aGUgcmVmZXJlbmNlIGZpZ3VyZSAoNSkgYWxyZWFkeSBjb25mbGljdHMg d2l0aCAibGltaXRlZCBkb21haW4iLCBhc3N1bWluZyBvbmUgd291bGQgZXhwb3NlIHN1Y2ggc2Vy dmljZXMgb25seSB0byBhIGNvbnRyb2xsZWQgc2V0IG9mIENQRSBJIHdvdWxkIHNheSBpdCBkb2Vz bid0LiBJIGhhdmUgdG8gYWdyZWUgd2l0aCBvdGhlcnMgd2hvIGNvbW1lbnRlZCB0aGF0IHRoZSBz Y29wZSBvZiB0aGUgZHJhZnQgaXMgbm90IGZ1bGx5IGNsZWFyIHRob3VnaC4gSXQgc3VnZ2VzdHMg dG8gYWltIHRvIHNvbHZlICJpbnRlcmRvbWFpbiIgY2FzZXMsIHdoaWxlIGluIHRoZSBzb2x1dGlv biBwYXJ0IHRoZSBmb2N1cyBzZWVtcyB0byBiZSBhZ2FpbiBvbiB0aGUgcXVlc3Rpb24gb2YgaG93 IHRvIGV4cG9zZSBzZXJ2aWNlcy4NCg0KSXQgd291bGQgaGVscCBpZiB0aGUgc2NvcGUgaXMgY2xh cmlmaWVkLg0KQnkgdGhlIHdheSwgSSBpbnRlcnByZXRlZCB0aGUgc2NvcGUgYXMgZGVzY3JpYmVk IGluIHRoZSBmaXJzdCBzZW50ZW5jZSBhYm92ZSwgaXMgdGhpcyBjb3JyZWN0Pw0KDQpjaGVlcnMs DQogIEVkdWFyZA0KDQoNCg0KT24gTW9uLCBNYXIgMTQsIDIwMjIgYXQgNDoxNyBQTSBBbmRyZXcg QWxzdG9uIC0gSUVURiA8YW5kcmV3LWlldGY9NDBsaXF1aWQudGVjaEBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBsaXF1aWQudGVjaEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSmluZ3JvbmcsDQoN CkxpbWl0ZWQgRG9tYWluIChpbiBteSB2aWV3KSByZWZlcnMgdG8gYSBkb21haW4gd2hlcmUgYWxs IHBvaW50cyBhcmUgdW5kZXIgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wuICBJLkUgdGhl IHNvdXJjZSwgZGVzdGluYXRpb24gYW5kIGFueXRoaW5nIGluIHRoZSBtaWRkbGUgbXVzdCBmYWxs IHVuZGVyIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wsIG90aGVyd2lzZSwgeW91IGFy ZSBub3Qgd2l0aGluIHRoZSBsaW1pdGVkIGRvbWFpbi4gIFRoaXMgY2FuIGJlIGV4dGVuZGVkIHVz aW5nIGVuY2Fwc3VsYXRpb24gKHR1bm5lbGluZykgd2hlcmUgdGhlIHBhY2tldCBpcyBlbmNhcHN1 bGF0ZWQgYW5kIHByZWZlcmFibHkgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdGVkLCBzdWNoIHRo YXQgYW55IGludGVybWVkaWF0ZSBuZXR3b3JrcyBvdXRzaWRlIG9mIHRoZSBzYW1lIGFkbWluaXN0 cmF0aXZlIGNvbnRyb2wgY2Fubm90LCBlaXRoZXIgYnkgZXJyb3Igb3IgZGVsaWJlcmF0ZSBhY3Rp b24sIGFjdCBvbiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIHdpdGhpbiB0aGUgcm91dGluZyBo ZWFkZXJzLg0KDQpBbnl0aGluZyBlbHNlIHdvdWxkIHJ1biBpbnRvIGlzc3VlcyB3aXRoIHNlY3Rp b24gOC4yIG9mIFJGQzg0MDIuDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpGcm9tOiBzcHJpbmcg PHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpDQpTZW50OiBNb25kYXksIE1hcmNo IDE0LCAyMDIyIDEwOjE2IEFNDQpUbzogR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNv bTxtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPj47IEFuZHJldyBBbHN0b24gLSBJRVRGIDxh bmRyZXctaWV0ZkBsaXF1aWQudGVjaDxtYWlsdG86YW5kcmV3LWlldGZAbGlxdWlkLnRlY2g+Pg0K Q2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsgVG9tIEhpbGwgPHRv bUBuaW5qYWJhZGdlci5uZXQ8bWFpbHRvOnRvbUBuaW5qYWJhZGdlci5uZXQ+Pg0KU3ViamVjdDog UmU6IFtzcHJpbmddIE5ldHdvcmsgUHJvZ3JhbW1pbmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25p bmcgb2YgVW5kZXJsYXkgU2VydmljZXMgdG8gT3ZlcmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChk cmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1vdmVybGF5KQ0KDQpIaSwNCg0KSSB0aGluayBJ IG5vdyB1bmRlcnN0YW5kIGJldHRlciB0aGUgY29uY2VybiBhYm91dCAidGhlIHVzZSBvZiBTSURz IG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldCIuDQpJbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgU0lE Mi9TSUQzIHVzZWQgYmV0d2VlbiBDUEUyLUludGVybmV0LUNQRTMgaXMgdG8gZXhwbGFpbiB0aGUg bGF5ZXJpbmcgbW9kZWwgKG92ZXIgdnMgYWNyb3NzKSwgYnV0IGl0IGlzIG5vdCB0aGUgcHJvcG9z YWwgb2YgdGhlIGRyYWZ0Lg0KVGhlIGRyYWZ0IGlzIHRhbGtpbmcgYWJvdXQgdGhlIGludGVyZmFj ZSAobmFtZSBOUEkpIHRoYXQgb3ZlcmxheSBuZXR3b3JrcyB1c2UgdG8gYWNjZXNzIHRoZSB1bmRl cmx5aW5nIG5ldHdvcmsgaW4gdGhlIGxhc3QgbWlsZS4NClRoZXJlIG1heSBiZSBhbiBBY2Nlc3Mg TmV0d29yayAoQU4pIGluIHRoZSBsYXN0IG1pbGUsIGFuZCB0aGUgQU4gbWF5IGFsc28gY29ubmVj dCB0byBJbnRlcm5ldCBiYWNrYm9uZSBhbmQvb3IgbXVsdGlwbGUgdW5kZXJseWluZyBuZXR3b3Jr cywgYnV0IGl0IGlzIGRpc3RpbmN0IGZyb20gdGhlICJvcGVuIEludGVybmV0Ii4NCk1ha2UgbW9y ZSBzZW5zZSBpZiB0aGUgQU4gY2FuIGVuaGFuY2UgKGlmIG5vIHdheSB0byBlbmZvcmNlKSBub3Qg dG8gbGVhayB0aGUgU1J2NiBCU0lEIHRvIEludGVybmV0IGJhY2tib25lIG9yIG90aGVyIFROcyA/ DQoNCkZvciB0aGUgY29udHJvbCBwbGFuZSwgaXQgaXMgc3RpbGwgbm90IGNsZWFyIGlmIGEgY29u dHJvbGxlciBpcyByZXF1aXJlZCwgYnV0IG9uZSB0aGluZyBJIGNvbnNpZGVyZWQgaXMgdG8gdXNl IGFuIElFVEYgc3RhbmRhcmQgcHJvdG9jb2wgYmVjYXVzZSB0aGUgUEUgbmVlZCB0byBpbXBsZW1l bnQgdGhlIE5QSS4NCg0KUmVnYXJkcywNCkppbmdyb25nDQoNCkZyb206IEd5YW4gTWlzaHJhIFtt YWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tXQ0KU2VudDogU3VuZGF5LCBNYXJjaCAxMywgMjAy MiA4OjI2IEFNDQpUbzogQW5kcmV3IEFsc3RvbiAtIElFVEYgPGFuZHJldy1pZXRmQGxpcXVpZC50 ZWNoPG1haWx0bzphbmRyZXctaWV0ZkBsaXF1aWQudGVjaD4+DQpDYzogVG9tIEhpbGwgPHRvbUBu aW5qYWJhZGdlci5uZXQ8bWFpbHRvOnRvbUBuaW5qYWJhZGdlci5uZXQ+PjsgWGllamluZ3Jvbmcg KEppbmdyb25nKSA8eGllamluZ3JvbmdAaHVhd2VpLmNvbTxtYWlsdG86eGllamluZ3JvbmdAaHVh d2VpLmNvbT4+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIEludGVyZmFjZSBmb3IgUHJvdmlz aW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2 NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheSkNCg0KSGkgSmluZ3JvbmcN Cg0KSSByZWFkcyB0aGUgZHJhZnQgYW5kIHdhcyB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgYXMgd2VsbCBhcyB0aGUgc29sdXRpb24uDQoNClNvIEkgYmVsaWV2ZSB0 aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgaG93IHRvIGludGVyY29ubmVjdCBkZXNwZXJhdGUgc2l0 ZXMgb3ZlciB0aGUgaW50ZXJuZXQgdXNpbmcgYSBtYW5hZ2VkIElQU0VDIFZQTiBvciBTRFdBTiBz b2x1dGlvbiBvciBtYW5hZ2VkIE1QTFMgYW5kIGNvbXBsZXhpdHkgb2YgcHJvdmlzaW9uaW5nIENF IGF0dGFjaG1lbnQuDQoNClRoZSBzb2x1dGlvbiBpcyBhbiBhdXRvbWF0ZWQgc29sdXRpb24gdXNp bmcgU1J2NiBvdmVyIHRoZSBpbnRlcm5ldCB1c2luZyBCU0lELiAgVGhpcyBpbnZvbHZlcyBydW5u aW5nIFNSdjYgb3ZlciB0aGUgaW50ZXJuZXQsIGhvd2V2ZXIgU1J2NiBpcyBsaW1pdGVkIHRvIGNs b3NlZCBkb21haW5zLiAgSXQgYXBwZWFycyBhbiBFMkUgcHNldWRvd2lyZSBpcyB1c2VkIGluIHBy b3Zpc2lvbmluZyB0aGUgc2VydmljZS4gIEhhdmUgeW91IHRob3VnaCBvZiB1c2luZyBORyBMMiBW UE4gRVZQTiBhbGwgb3Igc2luZ2xlIGFjdGl2ZSBtdWx0aSBob21lIG92ZXIgU1J2Ni4NCg0KRG9l cyBhbGwgdGhlIHByb3Zpc2lvbmluZyB1c2UgYSBQQ0UgLyBTRE4gY29udHJvbGxlcj8NCg0KDQpU aGFua3MNCg0KR3lhbg0KDQpPbiBUaHUsIE1hciAxMCwgMjAyMiBhdCA5OjU5IEFNIEFuZHJldyBB bHN0b24gLSBJRVRGIDxhbmRyZXctaWV0Zj00MGxpcXVpZC50ZWNoQGRtYXJjLmlldGYub3JnPG1h aWx0bzo0MGxpcXVpZC50ZWNoQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIaSBKaW5ncm9uZywN Cg0KSeKAmW0gc3RydWdnbGluZyB0byBlbnRpcmVseSB1bmRlcnN0YW5kIHRoaXMuICBJIHRoaW5r IHRoZSBxdWVzdGlvbiBmb3IgbWUgaXMg4oCTIGlmIHlvdSBhcmUgc2VuZGluZyBwYWNrZXRzIHdp dGggU0lE4oCZcyBvdmVyIHRoZSBvcGVuIGludGVybmV0IOKAkyBhcmUgeW91IGVuY2Fwc3VsYXRp bmcgdGhvc2UgcGFja2V0cyBhbmQgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIGNyeXB0b2dyYXBoaWNh bGx5IHByb3RlY3RlZCDigJMgSS5FIHRoZSBTSUTigJlzIGFyZSBub3QgdmlzaWJsZSBvdXRzaWRl IG9mIHRoZSBlbmNhcHN1bGF0aW9uLCB0byBwcmVzZXJ2ZSB0aGUgbGltaXRlZCBkb21haW4uDQoN CkxpbWl0ZWQgZG9tYWlucyBhcmUgdHlwaWNhbGx5IGV4dGVuZGVkIHZpYSB0dW5uZWwgbWVjaGFu aXNtcywgdmVyeSBvZnRlbiB3aXRoIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiwgaGVuY2UgdGhl IHF1ZXN0aW9uDQoNClRoYW5rcw0KDQpBbmRyZXcNCg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFs ZiBPZiBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTAsIDIw MjIgOTo0MCBBTQ0KVG86IFRvbSBIaWxsIDx0b21AbmluamFiYWRnZXIubmV0PG1haWx0bzp0b21A bmluamFiYWRnZXIubmV0Pj47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtzcHJpbmddIE5ldHdvcmsgUHJvZ3JhbW1pbmcgSW50ZXJmYWNlIGZv ciBQcm92aXNpb25pbmcgb2YgVW5kZXJsYXkgU2VydmljZXMgdG8gT3ZlcmxheSBOZXR3b3JrcyBV c2luZyBTUnY2IChkcmFmdC14aWUtc3ByaW5nLXNydjYtbnBpLWZvci1vdmVybGF5KQ0KDQpIaSBU b20sDQoNClRoYW5rcyBmb3IgcmVhZGluZyB0aGUgZHJhZnQgYW5kIHJhaXNlIGRpc2N1c3Npb25z Lg0KDQpJbiB0aGUgcHJvcG9zYWwgdGhlIFNSdjYgZG9tYWluIGlzIHRoZSBvdmVybGF5IG5ldHdv cmssIGJlbG9uZ2luZyB0byBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIC0tIHRoZSBvdmVybGF5 IG5ldHdvcmsgb3BlcmF0b3Ioc2F5IE9OTykuDQoNCkZvciB5b3VyIGNvbmNlcm4gYWJvdXQgdXNl IG9mIFNJRHMgImFjcm9zcyIgdGhlIHB1YmxpYyBJbnRlcm5ldC4gTGV0IG1lIHRyeSB0byBleHBs YWluIHVzaW5nIGZvbGxvd2luZyBmaWd1cmUgKGhvcGUgaXQgd29ya3MpOg0KDQpDUEUxIENQRTIg Q1BFMw0KKyArICsgKw0KfCArLS0tLS0tLS0rIHwgfCArLS0tLS0tLS0tLSsgfA0KKy0tLVsxXSBU TjEgWzFdLS0tKyArLS0tKyBJbnRlcm5ldCB8LS0tKw0KKy0tLS0tLS0tKyArLS0tLS0tLS0tLSsN Cg0KSW4gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBPTk8sIGl0IGhhcyB0aGUgZm9sbG93aW5nIFNJ RHM6DQpTSUQxLzIvMzogYWxsb2NhdGVkIG9uIENQRTEvQ1BFMi9DUEUzIGJ5IHRoZSBPTk8uDQpT SUQ0LzU6IGFsbG9jYXRlZCBieSBUTiBvcGVyYXRvciBidXQgc2VydmVzIGZvciB0aGUgT05PIChU ZW5hbnQtMSBvZiBUTiwgbWFya2VkIFsxXSBpbiB0aGUgZmlndXJlKS4NClRoZSBPTk8gY2FuIHVz ZSB0aGVzZSBTSURzLCBhbmQgSSB3b3VsZCB0aGluayB0aGV5IGFyZSBhbGwgImluIHRoZSBvdmVy bGF5IG5ldHdvcmsiLCBhbmQgYXJlIHJ1bm5pbmcgIk92ZXIgdGhlIEludGVybmV0Ii4NCg0KWW91 IG1lbnRpb25lZCBpbiB0aGUgbGFzdCBzZW50ZW5jZSAidGhlIHVzZSBvZiBTSURzIG92ZXIgdGhl IHB1YmxpYyBJbnRlcm5ldCIuIFRoYXQgaXMgd2hhdCBJIGFtIG1vZGVsaW5nIGFib3ZlLg0KDQpU aGFua3MNCkppbmdyb25nDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNw cmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9tIEhp bGwNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggOSwgMjAyMiAxMDo0MyBQTQ0KVG86IHNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIE5l dHdvcmsgUHJvZ3JhbW1pbmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25pbmcgb2YgVW5kZXJsYXkg U2VydmljZXMgdG8gT3ZlcmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChkcmFmdC14aWUtc3ByaW5n LXNydjYtbnBpLWZvci1vdmVybGF5KQ0KDQpIaSBKaW5yb25nLA0KDQpPbiAwOC8wMy8yMDIyIDAx OjU4LCBYaWVqaW5ncm9uZyAoSmluZ3JvbmcpIHdyb3RlOg0KPiBJIGp1c3QgcG9zdGVkIGEgZHJh ZnQgdGhhdCBzcGVjaWZpZXMgYSBmcmFtZXdvcmsgYW5kIHNvbWUgbW9yZSBkZXRhaWwNCj4gb2Yg dGhlIGlkZWEgZm9yIHByb3Zpc2lvbmluZyBvZiB1bmRlcmxheSBzZXJ2aWNlcw0KPiAoU2xpY2Uv U1ItcG9saWN5L01jYXN0L2V0YykgdG8gb3ZlcmxheSBuZXR3b3JrcyhTRC1XQU4vQ0ROL2V0Yyks IHVzaW5nIFNSdjYuDQo+DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3YNCj4gZXJsYXkNCj4gPGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3It bw0KPiB2ZXJsYXk+DQo+DQo+IFBsZWFzZSBjb21tZW50IGFuZCBzZW5kIGFueSBmZWVkYmFjay4N Cj4NCj4gSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhpcyBkb2N1bWVudCBvdmVyIGUtbWFpbC9t YWlsLWxpc3QuDQoNCg0KSSdtIGNvbmNlcm5lZCB0aGF0IHRoaXMgZHJhZnQgaXMgZXhwbGljaXRs eSB2aW9sYXRpbmcgdGhlIGNvbmNlcHQgb2YNClNSdjYgYXMgYSBwcm90b2NvbCB0aGF0IG9wZXJh dGVzIHdpdGhpbiBhIExpbWl0ZWQgRG9tYWluLg0KDQpBcyBwZXIgU2VjdGlvbiAzLjIgb2YgdGhp cyBkcmFmdCwgIi4uLiB0aGUgbmV0d29yayBvcGVyYXRvciBvZiBBTiwgVE4gYW5kIEludGVybmV0 IGNhbiBiZSBkaWZmZXJlbnQgZnJvbSBlYWNoIG90aGVyLiINCg0KRnVydGhlciwgIkluIHNvbWUg c2NlbmFyaW9zLCB0aGUgQU4gY2FuIGJlIGFuIEludGVybmV0IGV4Y2hhbmdlIHByb3ZpZGVyDQoo SVhQKSBpbmRlcGVuZGVudCBvZiBJU1AgYW5kIE5TUC4gSW4gc29tZSBvdGhlciBzY2VuYXJpb3Ms IHRoZSBBTiBjYW4gYmUgYW4gSVNQIHRoYXQgcnVubmluZyBJbnRlcm5ldCBiYWNrYm9uZSBhcyB3 ZWxsLiINCg0KVGhpcyB3b3VsZCByZWFkIHRvIG1lIHRoYXQgdGhlIHByb3Bvc2FsIGlzIGV4cGxp Y2l0bHkgaW50ZW5kZWQgdG8gYmUgaW50ZXItZG9tYWluLCBhbmQgbm90IGF0IGFsbCBsaW1pdGVk IHRvIGFueSBvbmUgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KQWRkaXRpb25hbGx5LCBJIGNhbm5v dCBkZXRlcm1pbmUgaWYgdGhlIGRyYWZ0IGltcGxpY2l0bHkgcmVxdWlyZXMgdGhlIHVzZSBvZiBT SURzIGFjcm9zcyB0aGUgcHVibGljIEludGVybmV0Pw0KDQpDb3VsZCBJIGFzayBmb3Igc29tZSBj bGFyaWZpY2F0aW9uIG9uIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQsIHdpdGggcmVzcGVjdCB0byBM aW1pdGVkIERvbWFpbnMsIGFuZCBhbHNvIHRoZSB1c2Ugb2YgU0lEcyBvdmVyIHRoZSBwdWJsaWMg SW50ZXJuZXQ/DQoNCktpbmQgcmVnYXJkcywNCg0KLS0NClRvbQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3Jn PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcN Ci0tDQoNClvlm77lg4/lt7Looqvlj5Hku7bkurrliKDpmaTjgIJdPGh0dHA6Ly93d3cudmVyaXpv bi5jb20vPg0KDQpHeWFuIE1pc2hyYQ0KDQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0K RW1haWwgZ3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJp em9uLmNvbT4NCg0KTSAzMDEgNTAyLTEzNDcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmcNCg== --_000_506fb082c84148d086d83d58de654cb5huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGVsbG8gRWR1YXJkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHJlYWRpbmcgYW5k IHRoZSBwb3NpdGl2ZSBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+WW91ciBpbnRlcnByZXRhdGlvbiBpbiB0aGUgZmlyc3Qgc2VudGVuY2UgaXMg YmFzaWNhbGx5IGNvcnJlY3QgYnV0IGluY29tcGxldGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGlzIGRyYWZ0IGlzIGFib3V0IGhvdyB0byBleHBvc2UgdHJhbnNwb3J0IHNlcnZp Y2UgLyBjYXBhYmlsaXRpZXMgZm9yIGNvbnN1bXB0aW9uIGJ5IG92ZXJsYXkgbmV0d29ya3MsIGFu ZCB0aGlzIHBvaW50IGlzIHZlcnkgcHJlY2lzZWx5IGNhdWdodCh0d2ljZSkNCiBpbiB5b3VyIG1h aWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZXhwb3Npbmcgb2YgdGhlIHRy YW5zcG9ydCBzZXJ2aWNlIHRvIG92ZXJsYXkgbmV0d29yayBvdXRzaWRlIGlzIGFic3RyYWN0ZWQg YXMgYW4gJnF1b3Q7SW50ZXJmYWNlJnF1b3Q7LCBhbmQgaXMgcHJvcG9zZWQgdG8gdXNlIFNSdjYg aW4gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHRo ZSB0cmFuc3BvcnQgc2VydmljZSBpcyBub3QgbGltaXRlZCB0byBTUnY2LWJhc2VkIHRyYW5zcG9y dCBzZXJ2aWNlLCBidXQgY2FuIGJlIGltcGxlbWVudGVkIGluZGVwZW5kZW50bHkgb2YgdGhlIElu dGVyZmFjZSBzcGVjLCBmb3IgZXhhbXBsZSwNCiBjYW4gYmUgaW1wbGVtZW50ZWQgdXNpbmcgU1J2 NiBvciBNUExTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIHN1Z2dlc3Rpb24gdG8gY2xhcmlmeSB0aGUg c2NvcGUsIEkgd291bGQgdGhpbmsgYWJvdXQgaG93IHRvIGNsYXJpZnksIGFuZCBzZW5kIHRoZSBw cm9wb3NlZCB0ZXh0IHRvIG1haWxpbmctbGlzdCBmb3IgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QmVmb3JlIHRoaXMsIEkgd291bGQgbGlrZSB0byBzaGFyZSBteSBwb2ludHMgYW5kIGhvcGUgaXQg dXNlZnVsIHRvIHVuZGVyc3RhbmQgdGhlIGRyYWZ0IGZvciB5b3UgYWxsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4x KSBDdXJyZW50bHkgU1J2NiBTSURzIGFyZSBtYWlubHkgdXNlZCBpbnNpZGUgYSBUTiwgYW5kIGhl bmNlIHRoZSAmcXVvdDtOZXQtUEdNIEluc3RydWN0aW9uJnF1b3Q7IGlzIGFuIGFwcHJvcHJpYXRl IGRlc2NyaXB0aW9uLCBhbmQgaXQgaXMgZWFzeSB0byB1bmRlcnN0YW5kDQogYXMgdGhlIGxpbWl0 ZWQtZG9tYWluIGlzIFROLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yKSBUaGUgZHJhZnQgaXMgZGVzY3JpYmluZyBh biAmcXVvdDtOZXQtUEdNIEludGVyZmFjZSZxdW90OyB0aGF0IGlzIGV4cG9zZWQgb3V0c2lkZSBh IFROLiBPbmNlIGV4cG9zZWQsIHRoZSB1c2Ugb2YgdGhlIFNSdjYgU0lEIGlzIGluIHRoZSAmcXVv dDtPdmVybGF5IG5ldHdvcmsmcXVvdDssDQogYW5kIGhlbmNlIHRoZSBsaW1pdGVkLWRvbWFpbiBp cyB0aGUgT3ZlcmxheSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4zKSBUaGUgT3ZlcmxheSBuZXR3b3Jr IGlzIGFuIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgYW5kIHRoZSBTUnY2IGRvbWFpbiBpcyBvbmx5 IHBhcnQgb2YgdGhlIE92ZXJsYXkgbmV0d29yay4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Rm9yIGV4YW1wbGUsIGluIHRoZSBmaWd1cmUgaW4NCjxh IGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL1kyMXl2 Sk8tSTJleC04Vk5Tam9EYldBOXFDay8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9zcHJpbmcvWTIxeXZKTy1JMmV4LThWTlNqb0RiV0E5cUNrLzwvYT48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ LCB0aGUgQ1BFMSwgQ1BFMiBhbmQgdGhlIGV4cG9zZWQgSW50ZXJmYWNlIG9mIFROMSBpcyBhbiBT UnY2IGRvbWFpbiwgYnV0IENQRTMgaXMgbm90IHRoZSBTUnY2IGRvbWFpbi48bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjQpIEFuIE92ZXJsYXkgbmV0d29yayBtYXkgdXNlcyBOIFRyYW5zcG9ydC1OZXR3b3Jr cywgYW5kIHRoZXJlIGNvdWxkIGJlIE4gU1J2NiBkb21haW5zLCBlYWNoIHN1cnJvdW5kaW5nIGEg VE4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppbmdyb25nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVkdWFyZCBNZXR6IFttYWlsdG86 ZXRtZXR6QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAxNSwg MjAyMiA5OjAyIFBNPGJyPg0KPGI+VG86PC9iPiBBbmRyZXcgQWxzdG9uIC0gSUVURiAmbHQ7YW5k cmV3LWlldGZAbGlxdWlkLnRlY2gmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBYaWVqaW5ncm9uZyAoSmlu Z3JvbmcpICZsdDt4aWVqaW5ncm9uZ0BodWF3ZWkuY29tJmd0OzsgR3lhbiBNaXNocmEgJmx0O2hh eWFidXNhZ3NtQGdtYWlsLmNvbSZndDs7IEFuZHJldyBBbHN0b24gLSBJRVRGICZsdDthbmRyZXct aWV0ZkBsaXF1aWQudGVjaCZndDs7IHNwcmluZ0BpZXRmLm9yZzsgVG9tIEhpbGwgJmx0O3RvbUBu aW5qYWJhZGdlci5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBOZXR3 b3JrIFByb2dyYW1taW5nIEludGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNl cnZpY2VzIHRvIE92ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1z cnY2LW5waS1mb3Itb3ZlcmxheSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBKaW5n cm9uZyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmVuJ3Qg cmVhZCB5b3VyIGRyYWZ0IGluIGRldGFpbCB5ZXQsIGJ1dCB0aGUgcXVlc3Rpb24gb2YgaG93IHRv IGV4cG9zZSBTUnY2IGJhc2VkIHRyYW5zcG9ydCBzZXJ2aWNlIC8gY2FwYWJpbGl0aWVzIGZvciBj b25zdW1wdGlvbiBieSBvdmVybGF5IG5ldHdvcmtzIEkgdGhpbmsgaXMgYW4gaW50ZXJlc3Rpbmcm bmJzcDtvbmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JJ20gbm90IHN1cmUgd2hldGhlciB0aGUgcmVmZXJlbmNlIGZpZ3VyZSAoNSkgYWxy ZWFkeSBjb25mbGljdHMgd2l0aCAmcXVvdDtsaW1pdGVkIGRvbWFpbiZxdW90OywgYXNzdW1pbmcg b25lIHdvdWxkIGV4cG9zZSZuYnNwO3N1Y2ggc2VydmljZXMgb25seSB0byBhIGNvbnRyb2xsZWQg c2V0IG9mIENQRSBJIHdvdWxkIHNheSBpdCBkb2Vzbid0LiBJIGhhdmUgdG8gYWdyZWUgd2l0aCBv dGhlcnMgd2hvIGNvbW1lbnRlZA0KIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBpcyBub3Qg ZnVsbHkgY2xlYXIgdGhvdWdoLiBJdCBzdWdnZXN0cyB0byBhaW0gdG8gc29sdmUgJnF1b3Q7aW50 ZXJkb21haW4mcXVvdDsgY2FzZXMsIHdoaWxlIGluIHRoZSBzb2x1dGlvbiBwYXJ0IHRoZSBmb2N1 cyZuYnNwO3NlZW1zIHRvIGJlIGFnYWluIG9uIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8gZXhwb3Nl IHNlcnZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SXQgd291bGQgaGVscCBpZiB0aGUgc2NvcGUmbmJzcDtpcyBjbGFyaWZpZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkJ5IHRoZSB3YXksIEkgaW50ZXJwcmV0ZWQgdGhlIHNjb3BlIGFzIGRlc2Ny aWJlZCBpbiB0aGUgZmlyc3Qgc2VudGVuY2UgYWJvdmUsIGlzIHRoaXMgY29ycmVjdD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7IEVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24sIE1hciAxNCwgMjAyMiBhdCA0OjE3IFBNIEFuZHJl dyBBbHN0b24gLSBJRVRGICZsdDthbmRyZXctaWV0Zj08YSBocmVmPSJtYWlsdG86NDBsaXF1aWQu dGVjaEBkbWFyYy5pZXRmLm9yZyI+NDBsaXF1aWQudGVjaEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5KaW5ncm9uZyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkxp bWl0ZWQgRG9tYWluIChpbiBteSB2aWV3KSByZWZlcnMgdG8gYSBkb21haW4gd2hlcmUgYWxsIHBv aW50cyBhcmUgdW5kZXIgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGNvbnRyb2wuJm5ic3A7DQogSS5F IHRoZSBzb3VyY2UsIGRlc3RpbmF0aW9uIGFuZCBhbnl0aGluZyBpbiB0aGUgbWlkZGxlIG11c3Qg ZmFsbCB1bmRlciB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLCBvdGhlcndpc2UsIHlv dSBhcmUgbm90IHdpdGhpbiB0aGUgbGltaXRlZCBkb21haW4uJm5ic3A7IFRoaXMgY2FuIGJlIGV4 dGVuZGVkIHVzaW5nIGVuY2Fwc3VsYXRpb24gKHR1bm5lbGluZykgd2hlcmUgdGhlIHBhY2tldCBp cyBlbmNhcHN1bGF0ZWQgYW5kIHByZWZlcmFibHkNCiBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0 ZWQsIHN1Y2ggdGhhdCBhbnkgaW50ZXJtZWRpYXRlIG5ldHdvcmtzIG91dHNpZGUgb2YgdGhlIHNh bWUgYWRtaW5pc3RyYXRpdmUgY29udHJvbCBjYW5ub3QsIGVpdGhlciBieSBlcnJvciBvciBkZWxp YmVyYXRlIGFjdGlvbiwgYWN0IG9uIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgd2l0aGluIHRo ZSByb3V0aW5nIGhlYWRlcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Bbnl0aGluZyBlbHNlIHdvdWxkIHJ1biBpbnRvIGlzc3VlcyB3aXRoIHNlY3Rpb24gOC4yIG9m IFJGQzg0MDIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3M8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJldzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNwcmlu Zw0KICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlhpZWppbmdyb25nIChKaW5ncm9uZyk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJj aCAxNCwgMjAyMiAxMDoxNiBBTTxicj4NCjxiPlRvOjwvYj4gR3lhbiBNaXNocmEgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5oYXlhYnVz YWdzbUBnbWFpbC5jb208L2E+Jmd0OzsgQW5kcmV3IEFsc3RvbiAtIElFVEYgJmx0OzxhIGhyZWY9 Im1haWx0bzphbmRyZXctaWV0ZkBsaXF1aWQudGVjaCI+YW5kcmV3LWlldGZAbGlxdWlkLnRlY2g8 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IFRvbSBIaWxsICZsdDs8YSBocmVm PSJtYWlsdG86dG9tQG5pbmphYmFkZ2VyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvbUBuaW5qYWJh ZGdlci5uZXQ8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gTmV0d29y ayBQcm9ncmFtbWluZyBJbnRlcmZhY2UgZm9yIFByb3Zpc2lvbmluZyBvZiBVbmRlcmxheSBTZXJ2 aWNlcyB0byBPdmVybGF5IE5ldHdvcmtzIFVzaW5nIFNSdjYgKGRyYWZ0LXhpZS1zcHJpbmctc3J2 Ni1ucGktZm9yLW92ZXJsYXkpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgdGhpbmsgSSBub3cgdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIGNvbmNlcm4gYWJv dXQgJnF1b3Q7dGhlIHVzZSBvZiBTSURzIG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldCZxdW90Oy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JbiBteSBwcmV2aW91cyBtYWlsLCB0aGUgU0lEMi9TSUQzIHVzZWQgYmV0d2VlbiBDUEUyLUlu dGVybmV0LUNQRTMgaXMgdG8gZXhwbGFpbiB0aGUgbGF5ZXJpbmcNCiBtb2RlbCAob3ZlciB2cyBh Y3Jvc3MpLCBidXQgaXQgaXMgbm90IHRoZSBwcm9wb3NhbCBvZiB0aGUgZHJhZnQuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRy YWZ0IGlzIHRhbGtpbmcgYWJvdXQgdGhlIGludGVyZmFjZSAobmFtZSBOUEkpIHRoYXQgb3Zlcmxh eSBuZXR3b3JrcyB1c2UgdG8gYWNjZXNzDQogdGhlIHVuZGVybHlpbmcgbmV0d29yayBpbiB0aGUg bGFzdCBtaWxlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoZXJlIG1heSBiZSBhbiBBY2Nlc3MgTmV0d29yayAoQU4pIGluIHRoZSBs YXN0IG1pbGUsIGFuZCB0aGUgQU4gbWF5IGFsc28gY29ubmVjdCB0byBJbnRlcm5ldA0KIGJhY2ti b25lIGFuZC9vciBtdWx0aXBsZSB1bmRlcmx5aW5nIG5ldHdvcmtzLCBidXQgaXQgaXMgZGlzdGlu Y3QgZnJvbSB0aGUgJnF1b3Q7b3BlbiBJbnRlcm5ldCZxdW90Oy48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYWtlIG1vcmUgc2Vuc2Ug aWYgdGhlIEFOIGNhbiBlbmhhbmNlIChpZiBubyB3YXkgdG8gZW5mb3JjZSkgbm90IHRvIGxlYWsg dGhlIFNSdjYgQlNJRA0KIHRvIEludGVybmV0IGJhY2tib25lIG9yIG90aGVyIFROcyA/IDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkZvciB0aGUgY29udHJvbCBwbGFuZSwgaXQgaXMgc3RpbGwgbm90IGNsZWFyIGlmIGEg Y29udHJvbGxlciBpcyByZXF1aXJlZCwgYnV0IG9uZSB0aGluZw0KIEkgY29uc2lkZXJlZCBpcyB0 byB1c2UgYW4gSUVURiBzdGFuZGFyZCBwcm90b2NvbCBiZWNhdXNlIHRoZSBQRSBuZWVkIHRvIGlt cGxlbWVudCB0aGUgTlBJLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmluZ3Jvbmc8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBHeWFuDQogTWlzaHJhIFs8YSBo cmVmPSJtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OmhheWFidXNhZ3NtQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBN YXJjaCAxMywgMjAyMiA4OjI2IEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZXcgQWxzdG9uIC0gSUVU RiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy1pZXRmQGxpcXVpZC50ZWNoIiB0YXJnZXQ9Il9i bGFuayI+YW5kcmV3LWlldGZAbGlxdWlkLnRlY2g8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9t IEhpbGwgJmx0OzxhIGhyZWY9Im1haWx0bzp0b21AbmluamFiYWRnZXIubmV0IiB0YXJnZXQ9Il9i bGFuayI+dG9tQG5pbmphYmFkZ2VyLm5ldDwvYT4mZ3Q7OyBYaWVqaW5ncm9uZyAoSmluZ3Jvbmcp ICZsdDs8YSBocmVmPSJtYWlsdG86eGllamluZ3JvbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnhpZWppbmdyb25nQGh1YXdlaS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dyYW1taW5nIEludGVyZmFjZSBm b3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRvIE92ZXJsYXkgTmV0d29ya3Mg VXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3ZlcmxheSk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBKaW5n cm9uZyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkkgcmVhZHMgdGhlIGRyYWZ0IGFuZCB3YXMgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhl IHByb2JsZW0gc3RhdGVtZW50IGFzIHdlbGwgYXMgdGhlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvIEkgYmVsaWV2ZSB0aGUg cHJvYmxlbSBzdGF0ZW1lbnQgaXMgaG93IHRvIGludGVyY29ubmVjdCBkZXNwZXJhdGUgc2l0ZXMg b3ZlciB0aGUgaW50ZXJuZXQgdXNpbmcgYSBtYW5hZ2VkIElQU0VDIFZQTiBvciBTRFdBTiBzb2x1 dGlvbiBvciBtYW5hZ2VkIE1QTFMgYW5kIGNvbXBsZXhpdHkNCiBvZiBwcm92aXNpb25pbmcgQ0Ug YXR0YWNobWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGUgc29sdXRpb24gaXMgYW4gYXV0b21hdGVkIHNvbHV0aW9uIHVzaW5nIFNSdjYg b3ZlciB0aGUgaW50ZXJuZXQgdXNpbmcgQlNJRC4mbmJzcDsgVGhpcyBpbnZvbHZlcyBydW5uaW5n IFNSdjYgb3ZlciB0aGUgaW50ZXJuZXQsIGhvd2V2ZXIgU1J2NiBpcyBsaW1pdGVkIHRvIGNsb3Nl ZA0KIGRvbWFpbnMuJm5ic3A7IEl0IGFwcGVhcnMgYW4gRTJFIHBzZXVkb3dpcmUgaXMgdXNlZCBp biBwcm92aXNpb25pbmcgdGhlIHNlcnZpY2UuJm5ic3A7IEhhdmUgeW91IHRob3VnaCBvZiB1c2lu ZyBORyBMMiBWUE4gRVZQTiBhbGwgb3Igc2luZ2xlIGFjdGl2ZSBtdWx0aSBob21lIG92ZXIgU1J2 Ni4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5Eb2VzIGFsbCB0aGUgcHJvdmlzaW9uaW5nIHVzZSBhIFBDRSAvIFNETiBjb250cm9sbGVy PyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkd5YW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgTWFyIDEw LCAyMDIyIGF0IDk6NTkgQU0gQW5kcmV3IEFsc3RvbiAtIElFVEYgJmx0O2FuZHJldy1pZXRmPTxh IGhyZWY9Im1haWx0bzo0MGxpcXVpZC50ZWNoQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+NDBsaXF1aWQudGVjaEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+SGkgSmluZ3JvbmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+STwvc3Bh bj7igJk8c3BhbiBsYW5nPSJFTi1VUyI+bSBzdHJ1Z2dsaW5nIHRvIGVudGlyZWx5IHVuZGVyc3Rh bmQgdGhpcy4mbmJzcDsgSSB0aGluayB0aGUgcXVlc3Rpb24gZm9yIG1lIGlzDQo8L3NwYW4+4oCT PHNwYW4gbGFuZz0iRU4tVVMiPiBpZiB5b3UgYXJlIHNlbmRpbmcgcGFja2V0cyB3aXRoIFNJRDwv c3Bhbj7igJk8c3BhbiBsYW5nPSJFTi1VUyI+cyBvdmVyIHRoZSBvcGVuIGludGVybmV0DQo8L3Nw YW4+4oCTPHNwYW4gbGFuZz0iRU4tVVMiPiBhcmUgeW91IGVuY2Fwc3VsYXRpbmcgdGhvc2UgcGFj a2V0cyBhbmQgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIGNyeXB0b2dyYXBoaWNhbGx5IHByb3RlY3Rl ZA0KPC9zcGFuPuKAkzxzcGFuIGxhbmc9IkVOLVVTIj4gSS5FIHRoZSBTSUQ8L3NwYW4+4oCZPHNw YW4gbGFuZz0iRU4tVVMiPnMgYXJlIG5vdCB2aXNpYmxlIG91dHNpZGUgb2YgdGhlIGVuY2Fwc3Vs YXRpb24sIHRvIHByZXNlcnZlIHRoZSBsaW1pdGVkIGRvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5MaW1pdGVkIGRvbWFpbnMgYXJlIHR5cGljYWxseSBleHRlbmRlZCB2aWEgdHVubmVsIG1l Y2hhbmlzbXMsIHZlcnkgb2Z0ZW4gd2l0aCBjcnlwdG9ncmFwaGljIHByb3RlY3Rpb24sIGhlbmNl IHRoZSBxdWVzdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHJldzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBzcHJpbmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+WGllamlu Z3JvbmcgKEppbmdyb25nKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMTAsIDIw MjIgOTo0MCBBTTxicj4NCjxiPlRvOjwvYj4gVG9tIEhpbGwgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b21AbmluamFiYWRnZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9tQG5pbmphYmFkZ2VyLm5ldDwv YT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIE5l dHdvcmsgUHJvZ3JhbW1pbmcgSW50ZXJmYWNlIGZvciBQcm92aXNpb25pbmcgb2YgVW5kZXJsYXkg U2VydmljZXMgdG8gT3ZlcmxheSBOZXR3b3JrcyBVc2luZyBTUnY2IChkcmFmdC14aWUtc3ByaW5n LXNydjYtbnBpLWZvci1vdmVybGF5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5IaSBUb20sPGJyPg0KPGJyPg0KVGhhbmtzIGZvciByZWFkaW5nIHRoZSBkcmFmdCBhbmQg cmFpc2UgZGlzY3Vzc2lvbnMuPGJyPg0KPGJyPg0KSW4gdGhlIHByb3Bvc2FsIHRoZSBTUnY2IGRv bWFpbiBpcyB0aGUgb3ZlcmxheSBuZXR3b3JrLCBiZWxvbmdpbmcgdG8gb25lIGFkbWluaXN0cmF0 aXZlIGRvbWFpbiAtLSB0aGUgb3ZlcmxheSBuZXR3b3JrIG9wZXJhdG9yKHNheSBPTk8pLg0KPGJy Pg0KPGJyPg0KRm9yIHlvdXIgY29uY2VybiBhYm91dCB1c2Ugb2YgU0lEcyAmcXVvdDthY3Jvc3Mm cXVvdDsgdGhlIHB1YmxpYyBJbnRlcm5ldC4gTGV0IG1lIHRyeSB0byBleHBsYWluIHVzaW5nIGZv bGxvd2luZyBmaWd1cmUgKGhvcGUgaXQgd29ya3MpOjxicj4NCjxicj4NCkNQRTEgQ1BFMiBDUEUz PGJyPg0KJiM0MzsgJiM0MzsgJiM0MzsgJiM0Mzs8YnI+DQp8ICYjNDM7LS0tLS0tLS0mIzQzOyB8 IHwgJiM0MzstLS0tLS0tLS0tJiM0MzsgfDxicj4NCiYjNDM7LS0tWzFdIFROMSBbMV0tLS0mIzQz OyAmIzQzOy0tLSYjNDM7IEludGVybmV0IHwtLS0mIzQzOzxicj4NCiYjNDM7LS0tLS0tLS0mIzQz OyAmIzQzOy0tLS0tLS0tLS0mIzQzOyA8YnI+DQo8YnI+DQpJbiB0aGUgcGVyc3BlY3RpdmUgb2Yg dGhlIE9OTywgaXQgaGFzIHRoZSBmb2xsb3dpbmcgU0lEczo8YnI+DQpTSUQxLzIvMzogYWxsb2Nh dGVkIG9uIENQRTEvQ1BFMi9DUEUzIGJ5IHRoZSBPTk8uPGJyPg0KU0lENC81OiBhbGxvY2F0ZWQg YnkgVE4gb3BlcmF0b3IgYnV0IHNlcnZlcyBmb3IgdGhlIE9OTyAoVGVuYW50LTEgb2YgVE4sIG1h cmtlZCBbMV0gaW4gdGhlIGZpZ3VyZSkuPGJyPg0KVGhlIE9OTyBjYW4gdXNlIHRoZXNlIFNJRHMs IGFuZCBJIHdvdWxkIHRoaW5rIHRoZXkgYXJlIGFsbCAmcXVvdDtpbiB0aGUgb3ZlcmxheSBuZXR3 b3JrJnF1b3Q7LCBhbmQgYXJlIHJ1bm5pbmcgJnF1b3Q7T3ZlciB0aGUgSW50ZXJuZXQmcXVvdDsu DQo8YnI+DQo8YnI+DQpZb3UgbWVudGlvbmVkIGluIHRoZSBsYXN0IHNlbnRlbmNlICZxdW90O3Ro ZSB1c2Ugb2YgU0lEcyBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQmcXVvdDsuIFRoYXQgaXMgd2hh dCBJIGFtIG1vZGVsaW5nIGFib3ZlLjxicj4NCjxicj4NClRoYW5rczxicj4NCkppbmdyb25nPGJy Pg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBzcHJp bmcgWzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUb20g SGlsbDxicj4NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggOSwgMjAyMiAxMDo0MyBQTTxicj4NClRv OiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBOZXR3b3JrIFByb2dyYW1t aW5nIEludGVyZmFjZSBmb3IgUHJvdmlzaW9uaW5nIG9mIFVuZGVybGF5IFNlcnZpY2VzIHRvIE92 ZXJsYXkgTmV0d29ya3MgVXNpbmcgU1J2NiAoZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3It b3ZlcmxheSk8YnI+DQo8YnI+DQpIaSBKaW5yb25nLDxicj4NCjxicj4NCk9uIDA4LzAzLzIwMjIg MDE6NTgsIFhpZWppbmdyb25nIChKaW5ncm9uZykgd3JvdGU6PGJyPg0KJmd0OyBJIGp1c3QgcG9z dGVkIGEgZHJhZnQgdGhhdCBzcGVjaWZpZXMgYSBmcmFtZXdvcmsgYW5kIHNvbWUgbW9yZSBkZXRh aWwgPGJyPg0KJmd0OyBvZiB0aGUgaWRlYSBmb3IgcHJvdmlzaW9uaW5nIG9mIHVuZGVybGF5IHNl cnZpY2VzPGJyPg0KJmd0OyAoU2xpY2UvU1ItcG9saWN5L01jYXN0L2V0YykgdG8gb3ZlcmxheSBu ZXR3b3JrcyhTRC1XQU4vQ0ROL2V0YyksIHVzaW5nIFNSdjYuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGll LXNwcmluZy1zcnY2LW5waS1mb3Itb3YiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQteGllLXNwcmluZy1zcnY2LW5waS1mb3Itb3Y8 L2E+PGJyPg0KJmd0OyBlcmxheSA8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9yLW8i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LXhpZS1zcHJpbmctc3J2Ni1ucGktZm9yLW88L2E+PGJyPg0KJmd0OyB2ZXJsYXkmZ3Q7PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSBjb21tZW50IGFuZCBzZW5kIGFueSBmZWVkYmFjay48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhpcyBkb2N1bWVu dCBvdmVyIGUtbWFpbC9tYWlsLWxpc3QuPGJyPg0KPGJyPg0KPGJyPg0KSSdtIGNvbmNlcm5lZCB0 aGF0IHRoaXMgZHJhZnQgaXMgZXhwbGljaXRseSB2aW9sYXRpbmcgdGhlIGNvbmNlcHQgb2Y8YnI+ DQpTUnY2IGFzIGEgcHJvdG9jb2wgdGhhdCBvcGVyYXRlcyB3aXRoaW4gYSBMaW1pdGVkIERvbWFp bi48YnI+DQo8YnI+DQpBcyBwZXIgU2VjdGlvbiAzLjIgb2YgdGhpcyBkcmFmdCwgJnF1b3Q7Li4u IHRoZSBuZXR3b3JrIG9wZXJhdG9yIG9mIEFOLCBUTiBhbmQgSW50ZXJuZXQgY2FuIGJlIGRpZmZl cmVudCBmcm9tIGVhY2ggb3RoZXIuJnF1b3Q7PGJyPg0KPGJyPg0KRnVydGhlciwgJnF1b3Q7SW4g c29tZSBzY2VuYXJpb3MsIHRoZSBBTiBjYW4gYmUgYW4gSW50ZXJuZXQgZXhjaGFuZ2UgcHJvdmlk ZXI8YnI+DQooSVhQKSBpbmRlcGVuZGVudCBvZiBJU1AgYW5kIE5TUC4gSW4gc29tZSBvdGhlciBz Y2VuYXJpb3MsIHRoZSBBTiBjYW4gYmUgYW4gSVNQIHRoYXQgcnVubmluZyBJbnRlcm5ldCBiYWNr Ym9uZSBhcyB3ZWxsLiZxdW90Ozxicj4NCjxicj4NClRoaXMgd291bGQgcmVhZCB0byBtZSB0aGF0 IHRoZSBwcm9wb3NhbCBpcyBleHBsaWNpdGx5IGludGVuZGVkIHRvIGJlIGludGVyLWRvbWFpbiwg YW5kIG5vdCBhdCBhbGwgbGltaXRlZCB0byBhbnkgb25lIGFkbWluaXN0cmF0aXZlIGRvbWFpbi4N Cjxicj4NCkFkZGl0aW9uYWxseSwgSSBjYW5ub3QgZGV0ZXJtaW5lIGlmIHRoZSBkcmFmdCBpbXBs aWNpdGx5IHJlcXVpcmVzIHRoZSB1c2Ugb2YgU0lEcyBhY3Jvc3MgdGhlIHB1YmxpYyBJbnRlcm5l dD88YnI+DQo8YnI+DQpDb3VsZCBJIGFzayBmb3Igc29tZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBz Y29wZSBvZiB0aGUgZHJhZnQsIHdpdGggcmVzcGVjdCB0byBMaW1pdGVkIERvbWFpbnMsIGFuZCBh bHNvIHRoZSB1c2Ugb2YgU0lEcyBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQ/PGJyPg0KPGJyPg0K S2luZCByZWdhcmRzLDxicj4NCjxicj4NCi0tPGJyPg0KVG9tPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJp bmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20v IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0M7Ym9yZGVyOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcg Ym9yZGVyPSIwIiB3aWR0aD0iODEiIGhlaWdodD0iMTgiIGlkPSJnbWFpbC1tXy03NjI4MjU0MTE1 NTUzNzgxNjQyUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEODM5NDku NkZCRjNGMzAiIGFsdD0i5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCIj48L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5HeWFuIE1pc2hyYTwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5O ZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QmbmJzcDs8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5F bWFpbA0KPGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5neWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9hPjwvc3Bhbj48L2k+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtH ZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5NIDMwMSA1MDItMTM0Nzwvc3Bhbj48L2k+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_506fb082c84148d086d83d58de654cb5huaweicom_-- --_004_506fb082c84148d086d83d58de654cb5huaweicom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=356; creation-date="Wed, 16 Mar 2022 07:31:05 GMT"; modification-date="Wed, 16 Mar 2022 07:31:05 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAASAFEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK/9k= --_004_506fb082c84148d086d83d58de654cb5huaweicom_-- From nobody Wed Mar 16 06:40:42 2022 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 E1F723A188A; Wed, 16 Mar 2022 06:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=orange.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 14NIcX1viI_g; Wed, 16 Mar 2022 06:40:35 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 92D8D3A187F; Wed, 16 Mar 2022 06:40:34 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4KJWcc2yGcz5vR4; Wed, 16 Mar 2022 14:40:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1647438032; bh=/184wlg16+OqdHUu+6h6fm0LrugY2LYDEIh90emIEuY=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=B8tIfmf93kJRNqIwqp4cmXf8e7SKmLbCqYatCw3BQEptjNRqN9x74yqVAA62Que6t O1aALz+aMSZXCEAncTjZG3fxViIQeyOTBMsg5hx0DhXpPw1t14s4IXgNzkkYHuSGSn /KmCW+BgUCO+j8/csbtDRr9onUWiwX+J5ngPglNUsjMejd01+CQ+71plv3FxD2GxEJ ImGrktgP4Z95sVNbwUtMk27p53y4ZBI1JRlUm/gnGEomnX3rLCZEl7t2I8SllE4tAQ hraW1S2i6cwSCGHq8I29mZSHiqShohcfC+a882qCQeFmkpm4rHdgAr/Mux0nt6xnn4 J776ra75x6NIA== From: To: "Boutros, Sami" CC: "spring@ietf.org" , "bess-chairs@ietf.org" , James Guichard , "Joel Halpern Direct" Thread-Topic: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Thread-Index: AQHYN8d97Vj2myKfRUyVlMJBHJByT6zCBhaw Date: Wed, 16 Mar 2022 13:40:31 +0000 Message-ID: <5986_1647438032_6231E8D0_5986_381_4_a7932aa651064602ad086333cf5c607a@orange.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-03-16T13:40:29Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-03-16T13:40:29Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: d72780e1-6277-40fa-98dc-5e27a4e83601 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.26.50] Content-Type: multipart/alternative; boundary="_000_a7932aa651064602ad086333cf5c607aorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption for draft-boutros-spring-elan-services-over-sr-00 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 Mar 2022 13:40:40 -0000 --_000_a7932aa651064602ad086333cf5c607aorangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [+bess chairs] Dear Sami, authors, SPRING and BESS chairs believe this work would be better addressed in the B= ESS WG. Thanks, Regards, --Bruno, Jim, Joel Orange Restricted From: Boutros, Sami Sent: Monday, March 14, 2022 6:23 PM To: DECRAENE Bruno INNOV/NET ; James Guichard ; Joel Halpern Direct Cc: spring@ietf.org Subject: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Dear WG Chairs, The authors would like to request a WG adoption for this draft, the draft w= as presented at last IETF. We could present the draft at this IETF too, if you folks like. Thanks, Sami ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_a7932aa651064602ad086333cf5c607aorangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[+bess chairs]

 

Dear Sami, authors,

 

SPRING and BESS chairs believe this work would be better addre= ssed in the BESS WG.

 

Thanks,

Regards,

--Bruno, Jim, Joel

 

 

Orange Restricted

= From: Boutros, Sami <sboutros@ciena.com>
Sent: Monday, March 14, 2022 6:23 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; Jame= s Guichard <james.n.guichard@futurewei.com>; Joel Halpern Direct <= jmh.direct@joelhalpern.com>
Cc: spring@ietf.org
Subject: WG adoption for draft-boutros-spring-elan-services-over-sr-= 00

 

Dear WG Chairs,

 

The authors would like to request a WG adoption for thi= s draft, the draft was presented at last IETF.

 

We could present the draft at this IETF too, if you fol= ks like.

 

Thanks,

 

Sami

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_a7932aa651064602ad086333cf5c607aorangecom_-- From nobody Thu Mar 17 10:08:52 2022 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 466A93A12E8; Thu, 17 Mar 2022 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_SCC_BODY_TEXT_LINE=-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 yUHyDdv8LNxm; Thu, 17 Mar 2022 10:08:39 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 EC2DC3A1304; Thu, 17 Mar 2022 10:08:34 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id h126so215900vsc.13; Thu, 17 Mar 2022 10:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hmSdtcVqSS/BZ7zrsFxLkWWQrOBj4j3sO5IG0gULZo0=; b=T3u/rjRGr3jQWzFDcHWiyfvBzDnKe6uYCQnX5l6HugCdGMi5/yEBujzpUqtpXGDjCN o6uZh1MuwmeKhN4z9CCUIKFzXtf+DPvkvf7gvFPVUybAvHPuAw3NxOLWUqdQ+oYyENzQ d3xn68tElDTUcqFkhECDS2Gv6vyi/BVCTLGzeLSKB1fx5cqFnuL9K+Q7NkED7j8qYbXc 7K38lbtoktn3yd8zxCzUCn8X8QMAggw/8sXrARkGb2u9ruHPwX448Qaojt+uqivGz3wg SlkE2FATpCG2UAkYGP7Di2s3QTfYahx6WFqAESYdpofz356eEv1ZnfupmCAdyKnOsk4f tZ7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hmSdtcVqSS/BZ7zrsFxLkWWQrOBj4j3sO5IG0gULZo0=; b=fZnJOtJaKBgTYSg40GvJgelSOeA/mkDBQZTXSk5qNL76FSOOityfHuj0WoshT8oJxr YC1aZYrFzsmQ8BZv/oQthxgPlUrRwkpMyjpu5zQELuiqmNLOhhrWskQeiQjnuvKagIUI 7X7ofX6JZM5sm5ht4+wt9mmo9bA4cSiX/IJZRz2t8GoyKsGcHYfvKZK8Q5cC5jdp4wP2 cTHBy56fmqhbDRvI3f/j9c2H9TC3I/LFllcXSY58xtYp227rwfFlw/EH9khgS8p9sdHl o+7VnRORipGxar1idAsf/uAaA0upusSKZ6HDEAfxeo35f2I+T7X8Fu4WyW740YtNeyBD adHQ== X-Gm-Message-State: AOAM531aYrOZouG2n0ml49TQsikRvOnpNI9mVvDUBhO4ovwGlq+ZMrzo p2rnUY8s4pjWyADZYfSzdkf0lOzR1JRMIVDNXqXDO9y2 X-Google-Smtp-Source: ABdhPJyoPMD3KI8RMDJme87wkC3ugzuY7KNeGcTpSM21cB8+4jBwxbWwwr6u6e6NhkCkiIkTxqp6IZyE1ZGNhhmZjVA= X-Received: by 2002:a05:6102:284a:b0:31e:c455:5dee with SMTP id az10-20020a056102284a00b0031ec4555deemr2056747vsb.27.1647536913675; Thu, 17 Mar 2022 10:08:33 -0700 (PDT) MIME-Version: 1.0 References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Mar 2022 22:38:21 +0530 Message-ID: To: Alvaro Retana Cc: SPRING WG , spring-chairs@ietf.org, The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="0000000000007e7b3805da6d14cb" Archived-At: Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 17 Mar 2022 17:08:44 -0000 --0000000000007e7b3805da6d14cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thanks again for your detailed review and the discussion to help improve this document. We'll incorporate your suggestion below in the next update once the submission window opens up. Thanks, Ketan On Fri, Mar 11, 2022 at 11:50 PM Alvaro Retana wrote: > On March 5, 2022 at 5:29:36 AM, Ketan Talaulikar wrote: > > Ketan: > > Hi! > > > We have also just posted an update to address some of the comments belo= w > and > > from other ADs. > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-19 > > That version addresses my DISCUSS -- I'm clearing. I have one reply > in the comments below. > > > Thanks! > > Alvaro. > > ... > > > > > (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOULD= be > set to > > > > > 0 by default when not available or known." > > > > > > > > > > When is it ok for the ASN to not be set to 0 (when not available = or > > > > > known)? If that possibility exists, the PCE can use any value > > > > > (including the real number or a random one). What issues exist wi= th > > > > > uncoordinated (or rogue) PCEs using potentially arbitrary ASNs? > > > > > > > > > > Why is this action recommended and not required? > > > > > > > > KT> AFAIR PCEP signaling does not carry AS number. So this is a > > > > recommendation, though a local policy or a future PCEP extension > could > > > > change that and we don't want to preclude it. > > > > ... > > > If the ASN can be signaled, when is it ok for it to not be set to 0 > > > (when not available or known)? If that possibility exists, the PCE > > > can use any value (including the real number or a random one). What > > > issues exist with uncoordinated (or rogue) PCEs using potentially > > > arbitrary ASNs? > > > > KT> I will leave this question for the PCEP WG if and when they decide > to add > > support for ASN to be signaled. It does not make any impact from this > > specification perspective since it is only used to identify the > originator. > > The impact on this document it that it is specifying the behavior > Normatively - let's eliminate that. > > Suggestion> > If signaling via PCEP, it is the IPv4 or IPv6 address of the PCE and > the AS number is expected to be set to 0 by default when not available > or known. > --0000000000007e7b3805da6d14cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

Thanks again for your detail= ed review and the discussion to help improve this document. We'll incor= porate your suggestion below in the next update once the submission window = opens up.

Thanks,
Ketan


On Fri, Mar 11, 2022 at 11:50 PM Alvaro Retana <aretana.ietf@gmail.com> wrot= e:
On March 5, 2= 022 at 5:29:36 AM, Ketan Talaulikar wrote:

Ketan:

Hi!

> We have also just posted an update to address some of the comments bel= ow and
> from other ADs.
>
> https://datatr= acker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19

That version addresses my DISCUSS -- I'm clearing.=C2=A0 I have one rep= ly
in the comments below.


Thanks!

Alvaro.

...
> > > > (7) =C2=A72.4: "When signaling is via PCEP...the A= S number SHOULD be set to
> > > > 0 by default when not available or known."
> > > >
> > > > When is it ok for the ASN to not be set to 0 (when not = available or
> > > > known)? If that possibility exists, the PCE can use any= value
> > > > (including the real number or a random one). What issue= s exist with
> > > > uncoordinated (or rogue) PCEs using potentially arbitra= ry ASNs?
> > > >
> > > > Why is this action recommended and not required?
> > >
> > > KT> AFAIR PCEP signaling does not carry AS number. So thi= s is a
> > > recommendation, though a local policy or a future PCEP exten= sion could
> > > change that and we don't want to preclude it.
> >
...
> > If the ASN can be signaled, when is it ok for it to not be set to= 0
> > (when not available or known)? If that possibility exists, the PC= E
> > can use any value (including the real number or a random one). Wh= at
> > issues exist with uncoordinated (or rogue) PCEs using potentially=
> > arbitrary ASNs?
>
> KT> I will leave this question for the PCEP WG if and when they dec= ide to add
> support for ASN to be signaled. It does not make any impact from this<= br> > specification perspective since it is only used to identify the origin= ator.

The impact on this document it that it is specifying the behavior
Normatively =C2=A0- let's eliminate that.

Suggestion>
=C2=A0 =C2=A0If signaling via PCEP, it is the IPv4 or IPv6 address of the P= CE and
=C2=A0 =C2=A0the AS number is expected to be set to 0 by default when not a= vailable
=C2=A0 =C2=A0or known.
--0000000000007e7b3805da6d14cb-- From nobody Thu Mar 17 10:12:52 2022 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 393873A12EE; Thu, 17 Mar 2022 10:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_SCC_BODY_TEXT_LINE=-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 AGbrbPYObjEL; Thu, 17 Mar 2022 10:12:47 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 19F7C3A1317; Thu, 17 Mar 2022 10:12:47 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id b190so6205596vsc.4; Thu, 17 Mar 2022 10:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a6OCC3232zFbVmcG5SZTZGC+2czG0O5XhHdzmxZTYGw=; b=dJb2rUSHw13/7+vdIErili2t404yQ0qt6A8fIe0IB4wvuXqxKlCtpU1ScXyTRGSKg8 OkVEkMcit3xhHQnSsBdQAtrFSF0oFuz06P0dH0ny+eHN/nG+CplwL9fiZtr7VWmvs1Q7 QzrYP+15wRDFJIRXY1e+8FyxygJBNWp96NvWAvskB77SFVFTMafLZb6SPzq19PwR6S8r cor17DX7dBrUoGyP1u1KLauDCnuG92N9G5f/N0ZvtYrdbDkAKNzG/xRWVqnNs7XeJ2BY kFcaEYyb26c5r1R6urXxOIZyygYbgVhrXxOfDjsOr5kBQT8KGYCZbFldRNisRpJJfJwF et3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a6OCC3232zFbVmcG5SZTZGC+2czG0O5XhHdzmxZTYGw=; b=HtipB8mT8o2iM/qf5qD5AiaNwNRe9DhgI5VxhHq1mX+Yx1geqdX9boLmkjJQYcTa02 7PYj5IiN7j4iurSeVkw4bCr/OA76/JZywiUA6Z4qRPJW6+B+GoZ0CZZpYi3fyqVo+V+h 1RhJDNLl5sPMFGQlyEa3JW1543XRypIqpI5tsKpUskTDtfcrcjeU/MQEhiJN3coBBWSF ot6OWYDRkiiJZy5ooDstQkQtCB7tRQ6PWb8MSfjJhzjw/maFEvWmqSqPkHA/EOtF8D16 yCrDutm5YaGzdtVSTb1mVlDDjMYiA/OPJWSd409oxcRcO0UujHElc14jx/dQYlPT3guo C+3Q== X-Gm-Message-State: AOAM532osn7K9Ej9pMd7itYueW9cTbsAI0kZrdU6BKdroByoFx6O6dta hsf3w3TGVy5WizOoVL7/fxzMIY14nZR2SVii0pd4hf69 X-Google-Smtp-Source: ABdhPJxS5mS2vfBgVT6rTGipsiFqQqb3Xp4nWbq6aQccqf31MfdZHZN2S4yZIhNKNDO2DmEvGluM5AJ9QRTaA81do6g= X-Received: by 2002:a05:6102:21d8:b0:322:930a:e8c0 with SMTP id r24-20020a05610221d800b00322930ae8c0mr2517334vsg.33.1647537165830; Thu, 17 Mar 2022 10:12:45 -0700 (PDT) MIME-Version: 1.0 References: <164504916365.5606.17077981996669554325@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Mar 2022 22:42:33 +0530 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000860cff05da6d237e" Archived-At: Subject: Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 17 Mar 2022 17:12:51 -0000 --000000000000860cff05da6d237e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Could you please check the latest revision below and my responses to your discussion points and comments in the email thread below? https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-20 Please let us know your feedback on whether the responses and draft updates address your concerns. Thanks, Ketan On Thu, Feb 17, 2022 at 11:53 PM Ketan Talaulikar wrote: > Hi Roman, > > We've just posted an update for the document to address the comments > raised by you and other ADs: > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-18 > > Thanks, > Ketan > > > On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar > wrote: > >> Hi Roman, >> >> Thanks for your review and comments/inputs. Please check inline below fo= r >> responses. >> >> >> On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker < >> noreply@ietf.org> wrote: >> >>> Roman Danyliw has entered the following ballot position for >>> draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions/ >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-poli= cy/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> There appear to be a few places where additional pointers or >>> specification is >>> needed to ensure interoperability. >>> >>> ** Section 2.5 >>> When signaling is via PCEP, the method to uniquely signal an >>> individual candidate path along with its discriminator is described >>> in [I-D.ietf-pce-segment-routing-policy-cp]. >>> >>> Where is the explanation of discriminator in this reference? >>> =E2=80=9CDiscriminator=E2=80=9D >>> appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three >>> section it >>> is simply named but not explained. In the last section, it isn=E2=80= =99t >>> explained >>> beyond being defined as 32-bits. >>> >> >> KT> I have not yet reviewed that document and will do so to pass the >> comments to the authors of that document. As a reminder, this is an >> architecture document in SPRING that is then realized using protocol >> extensions/mechanisms that are specified in their respective WG document= s. >> >> >>> >>> ** Section 2.6. >>> Candidate paths MAY also be assigned or signaled with a symbolic name >>> comprising printable ASCII [RFC0020] [RFC5234] characters >>> >>> How these candidate paths names are signaled isn=E2=80=99t defined. I = believe >>> it is >>> per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and >>> Section 2.4.7 >>> of draft-ietf-idr-segment-routing-te-policy. >> >> >>> ** Section 2.7. How is the candidate path preference signaled? Is tha= t >>> draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te= -policy-14#section-2.4.1 >>> ? >>> >> >> KT> Those protocol specs normatively refer to this document. Your >> understanding is correct about the parts of those documents. >> >> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I support John Scudder and Alvaro Retana's DISCUSS positions. >>> >>> ** Section 2.1. >>> The color is an unsigned non-zero 32-bit numerical value that >>> associates the SR Policy with an intent or objective (e.g. low- >>> latency). >>> >>> Should =E2=80=9Cnumeric value=E2=80=9D be =E2=80=9Cinteger=E2=80=9D? >>> >> >> KT> Ack. Will clarify. >> >> >>> >>> ** Section 2.1 >>> The SR Policy name >>> MAY also be signaled along with a candidate path of the SR Policy >>> (refer to Section 2.2). >>> >>> -- It would be helpful to explicitly state either here or in Section 2.= 2 >>> that >>> Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section >>> 5.2.1 of >>> [I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how >>> this >>> naming is signaled. Section 2.2 doesn=E2=80=99t discuss signaling the n= ame. >>> >>> -- Both of these document need to be normative reference since there is >>> dependency on them for interoperable behavior. >>> >> >> KT> Please see one of my previous responses on the architecture and >> protocol specifications split across documents. >> >> >>> >>> ** Section 2.2. Typo. s/heirarchical/hierarchical/ >>> >> >> KT> Ack. >> >> >>> >>> ** Section 2.3. It would be helpful if the precise mechanism to signal >>> the >>> Protocol-Origin was cited. >>> >> >> KT> It is not something that is signaled - refer to "The head-end assign= s >> different Protocol-Origin values to each source of SR Policy information= .". >> It is like an "administrative distance" that is used to attach preferenc= e >> to routes learned via different protocols like OSPF, IS-IS, and BGP. Th= is >> is local on the headend. >> >> >>> >>> -- I believe it is Section 5.2.2 of >>> [I-D.ietf-pce-segment-routing-policy-cp] >>> >> >> KT> Ack but likely we'll need to remove section number references or >> revalidate them at publication given how these documents have been movin= g >> along and their interdependencies. >> >> >>> >>> -- I didn=E2=80=99t find any reference to a =E2=80=9CProtocol Origin=E2= =80=9D or this section in >>> [I-D.ietf-idr-segment-routing-te-policy]. >>> >> >> KT> Please check my previous comment. >> >> >>> >>> ** Section 2.4. >>> When signaling is via BGP SR Policy, the ASN and Node Address are >>> provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy]) >>> on the headend. >>> >>> [I-D.ietf-idr-segment-routing-te-policy] needs to be a normative >>> reference (as >>> stated before due to the text in Section 2.1) >>> >>> ** Section 2.5. Per =E2=80=9CWhen provisioning is via configuration,= this is >>> an >>> implementation's configuration model-specific unique identifier for a >>> candidate >>> path=E2=80=9D, what is a =E2=80=9Cconfiguration model-model-specific un= ique identifier? >>> What >>> scope of the uniqueness? >>> >> >> KT> Please refer to draft-ietf-spring-sr-policy-yang - we could not be >> more specific or provide exact pointer here since that document is still >> under development. >> >>> >>> ** Section 2.13. This section says =E2=80=9Cthe information model is t= he >>> following=E2=80=9D, >>> but I don=E2=80=99t follow where that information model (IM) is per the >>> definition in >>> RFC3444. The text here appears be an example with hard-coded parameter >>> values. >>> >> >> KT> This is an overview and the actual model is being specified >> in draft-ietf-spring-sr-policy-yang >> >> >>> >>> ** Section 4. >>> Based on the desired dataplane, either the MPLS label stack or the >>> SRv6 Segment Routing Header [RFC8754] is built from the Segment- >>> List. >>> >>> Do SRv6 SRH and MPLS label stacks support all the segment types >>> enumerated >>> here? For example, does Type E and F, IPv4 segments, work with a SRv6 >>> SRH? >>> >> >> KT> What goes into the packet, at the end of the day, are MPLS labels or >> SRv6 SIDs. The segment types introduce the different context types that = are >> used to specify a segment especially in the signaling protocols. >> >> >>> >>> ** Section 4. >>> When the algorithm is not specified for the SID types above which >>> optionally allow for it, the headend SHOULD use the Strict Shortest >>> Path algorithm if available; otherwise, it SHOULD use the default >>> Shortest Path algorithm. The specification of the algorithm enables >>> the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific >>> SIDs in SR Policy. >>> >>> Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative >>> reference? >>> >> >> KT> We enable the specification of an algorithm that was introduced by >> RFC8402. A later enhancement carved out a range of algos from there for = IGP >> Flexible Algorithm. The reference is informative to indicate that one co= uld >> use IGP Flex Algo as well. >> >> >>> >>> ** Section 10. Given that this document has a dependency on >>> [I-D.ietf-idr-segment-routing-te-policy] and >>> [I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR >>> Policy, their >>> security considerations should apply. >>> >> >> KT> I refer again to the dependency between this SPRING and the other >> protocol specs. >> >> Thanks, >> Ketan >> >> > --000000000000860cff05da6d237e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Could you please check the la= test revision below and my responses to your discussion points and comments= in the email thread below?


P= lease let us know your feedback on whether the responses and draft updates = address your concerns.

Thanks,
Ketan


On Thu, Feb 17, 2022 at 11:53 PM Ketan Talaulikar <ketant.ietf@gmail.co= m> wrote:
Hi Roman,

We've just posted an upd= ate for the document to address the comments raised by you and other ADs:= =C2=A0https://datat= racker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18

Thanks,
Ketan

On Thu, = Feb 17, 2022 at 8:38 PM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
=
Hi Roman,

Thanks for your review and comments/i= nputs. Please check inline below for responses.

<= br>
On Thu,= Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has ent= ered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: 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/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.o= rg/doc/draft-ietf-spring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There appear to be a few places where additional pointers or specification = is
needed to ensure interoperability.

** Section 2.5
=C2=A0 =C2=A0When signaling is via PCEP, the method to uniquely signal an =C2=A0 =C2=A0individual candidate path along with its discriminator is desc= ribed
=C2=A0 =C2=A0in [I-D.ietf-pce-segment-routing-policy-cp].

Where is the explanation of discriminator in this reference?=C2=A0 =E2=80= =9CDiscriminator=E2=80=9D
appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.=C2=A0 In the first three se= ction it
is simply named but not explained.=C2=A0 In the last section, it isn=E2=80= =99t explained
beyond being defined as 32-bits.

KT>= I have not yet reviewed that document and will do so to pass the comments = to the authors of that document. As a reminder, this is an architecture doc= ument in SPRING that is then realized using protocol extensions/mechanisms = that are specified in their respective WG documents.
=C2=A0
=

** Section 2.6.
=C2=A0 Candidate paths MAY also be assigned or signaled with a symbolic nam= e
=C2=A0 =C2=A0comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn=E2=80=99t defined.=C2=A0 I= believe it is
per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2= .4.7
of draft-ietf-idr-segment-routing-te-policy.=C2=A0

** Section 2.7.=C2=A0 How is the candidate path preference signaled?=C2=A0 = Is that
draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and
https= ://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-1= 4#section-2.4.1?

KT> Those proto= col specs normatively refer to this document. Your understanding is correct= about the parts of those documents.=C2=A0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support John Scudder and Alvaro Retana's DISCUSS positions.

** Section 2.1.
=C2=A0 =C2=A0The color is an unsigned non-zero 32-bit numerical value that<= br> =C2=A0 =C2=A0associates the SR Policy with an intent or objective (e.g.=C2= =A0 low-
=C2=A0 =C2=A0latency).

Should =E2=80=9Cnumeric value=E2=80=9D be =E2=80=9Cinteger=E2=80=9D?

KT> Ack. Will clarify.
=C2=A0

** Section 2.1
=C2=A0 =C2=A0The SR Policy name
=C2=A0 =C2=A0MAY also be signaled along with a candidate path of the SR Pol= icy
=C2=A0 =C2=A0(refer to Section 2.2).

-- It would be helpful to explicitly state either here or in Section 2.2 th= at
Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section 5.2.1= of
[I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how this=
naming is signaled. Section 2.2 doesn=E2=80=99t discuss signaling the name.=

-- Both of these document need to be normative reference since there is
dependency on them for interoperable behavior.

KT> Please see one of my previous responses on the architecture = and protocol specifications split across documents.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
** Section 2.2. Typo. s/heirarchical/hierarchical/
KT> Ack.
=C2=A0

** Section 2.3.=C2=A0 It would be helpful if the precise mechanism to signa= l the
Protocol-Origin was cited.

KT> It is= not something that is signaled - refer to "The head-end assigns diffe= rent Protocol-Origin values to each source of SR Policy information.".= It is like an "administrative distance" that is used to attach p= reference to routes learned via different protocols like OSPF, IS-IS, and B= GP.=C2=A0 This is local on the headend.
=C2=A0

-- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp= ]

KT> Ack but likely we'll need = to remove section number references or revalidate them at publication given= how these documents have been moving along and their interdependencies.=C2= =A0
=C2=A0

-- I didn=E2=80=99t find any reference to a =E2=80=9CProtocol Origin=E2=80= =9D or this section in
[I-D.ietf-idr-segment-routing-te-policy].

KT> Please check my previous comment.
=C2=A0

** Section 2.4.
=C2=A0 =C2=A0When signaling is via BGP SR Policy, the ASN and Node Address = are
=C2=A0 =C2=A0provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-pol= icy])
=C2=A0 =C2=A0on the headend.

[I-D.ietf-idr-segment-routing-te-policy] needs to be a normative reference = (as
stated before due to the text in Section 2.1)

** Section 2.5.=C2=A0 =C2=A0 Per =E2=80=9CWhen provisioning is via configur= ation, this is an
implementation's configuration model-specific unique identifier for a c= andidate
path=E2=80=9D, what is a =E2=80=9Cconfiguration model-model-specific unique= identifier?=C2=A0 What
scope of the uniqueness?

KT> Please = refer to=C2=A0draft-ietf-spring-sr-policy-yang - we could not be more speci= fic or provide exact pointer here since that document is still under develo= pment.=C2=A0

** Section 2.13.=C2=A0 This section says =E2=80=9Cthe information model is = the following=E2=80=9D,
but I don=E2=80=99t follow where that information model (IM) is per the def= inition in
RFC3444.=C2=A0 The text here appears be an example with hard-coded paramete= r values.

KT> This is an overview an= d the actual model is being specified in=C2=A0draft-ietf-spring-sr-policy-y= ang
=C2=A0

** Section 4.
=C2=A0 =C2=A0Based on the desired dataplane, either the MPLS label stack or= the
=C2=A0 =C2=A0SRv6 Segment Routing Header [RFC8754] is built from the Segmen= t-
=C2=A0 =C2=A0 List.

Do SRv6 SRH and MPLS label stacks support all the segment types enumerated<= br> here?=C2=A0 For example, does Type E and F, IPv4 segments, work with a SRv6= SRH?

KT> What goes into the packet,= at the end of the day, are MPLS labels or SRv6 SIDs. The segment types int= roduce the different context types that are used to specify a segment espec= ially in the signaling protocols.
=C2=A0

** Section 4.
=C2=A0 =C2=A0When the algorithm is not specified for the SID types above wh= ich
=C2=A0 =C2=A0optionally allow for it, the headend SHOULD use the Strict Sho= rtest
=C2=A0 =C2=A0Path algorithm if available; otherwise, it SHOULD use the defa= ult
=C2=A0 =C2=A0Shortest Path algorithm.=C2=A0 The specification of the algori= thm enables
=C2=A0 =C2=A0the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] spe= cific
=C2=A0 =C2=A0SIDs in SR Policy.

Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative referen= ce?

KT>=C2=A0 We enable the specific= ation of an algorithm that was introduced by RFC8402. A later enhancement c= arved out a range of algos from there for IGP Flexible Algorithm. The refer= ence is informative to=C2=A0indicate that one could use IGP Flex Algo as we= ll.
=C2=A0

** Section 10.=C2=A0 Given that this document has a dependency on
[I-D.ietf-idr-segment-routing-te-policy] and
[I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, t= heir
security considerations should apply.

K= T> I refer again to the dependency between this SPRING and the other pro= tocol specs.

Thanks,
Ketan
=C2= =A0
--000000000000860cff05da6d237e-- From nobody Thu Mar 17 10:13:46 2022 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 F2FE33A1334; Thu, 17 Mar 2022 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.893 X-Spam-Level: ** X-Spam-Status: No, score=2.893 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, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 t9GVczDx-TgR; Thu, 17 Mar 2022 10:13:27 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 9B6693A12EE; Thu, 17 Mar 2022 10:13:26 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id c4so3197343vkq.9; Thu, 17 Mar 2022 10:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R3NmD8dBlX6NMp81YsqHllSYo0Ea8KkcQm1BrICtmog=; b=gceE65EiT6er+hB2gJzpLehALzLebqr9Wetn95rOtZThurgniGXJUFi3jY27cDUNrb EW2Eg89nrDmDdpBRNpeeIINwBS3JiMyn+ST8YCRZ3VtXmtiknC1sD8epKb9e4IPiSDsm Acn84PYezaedkM9Q/A6i58GuHw2m6qT2jS4dPrnMnd2+ipz8oUEmac2/2c28DNlVH+/R s1q63cJ78Dc+S6SaPbqommp8aJ7v41hEfCe+VgBsTc8m+lPk15mvbAQ02JDrs2eDbZB9 Ob9I089r1ceYXUEjCVquoZvp0pNbJp3hDBhNttQAWvfsgi4GpBwhE5osNhE9S7dDEinZ MO6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R3NmD8dBlX6NMp81YsqHllSYo0Ea8KkcQm1BrICtmog=; b=nIQE2UvIKUTOyquV37Vy6Q1/qbx9U05ecpK2qvxzbuoKl81wKQ6Ti2kwhk6pGZOrvr ztfpd2fg0j0MNayxDDFHkzuvdPIZnL3qrxKOuTw+O1JJXQdeLscds7QM+P6MJhcQIlgM RTkLJt9Bl1sM5DkfHby3XjzyH98TlHe3sBDZHnHvJbn9jC8Ke7kQtWAQyUcQ9nM8bmD+ HWyPlvFNGslTlailuuD8MyXjrEyDLVppLnRJ2gFde7uBIPbrs+6u6xQN0Io2LnXm4xV3 EiYpA+KUDcJQq1QTOIWUvwqEtMbbHZyE8jZfjuk6O7x1SakpNUXY0tDrixuqxqUrZeOg ukKA== X-Gm-Message-State: AOAM533JufP1XN3xcq4QY/11Jm1Lc0VPIBY5VbSd6QpzbW2qDDLRUiAY 2bRCBVbnQlK2PIeTKKT9tzQrqhSHYvjLLzYKHDc= X-Google-Smtp-Source: ABdhPJww7qDwu9YBW/SCu6VMalCkVnHykTdB9N920bYVrpAedTMDOMdqr1M5vPV7fJT2BMgOiJa1RpOmyNcHcaJn2kY= X-Received: by 2002:a05:6122:692:b0:33d:facd:41af with SMTP id n18-20020a056122069200b0033dfacd41afmr2419103vkq.2.1647537204440; Thu, 17 Mar 2022 10:13:24 -0700 (PDT) MIME-Version: 1.0 References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> <20220225020227.GM12881@kduck.mit.edu> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Mar 2022 22:43:12 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000d332f005da6d2540" Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 17 Mar 2022 17:13:35 -0000 --000000000000d332f005da6d2540 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Please let us know your feedback on whether the responses and draft updates address your concerns. The latest version is https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-20 Thanks, Ketan On Sat, Mar 5, 2022 at 4:06 PM Ketan Talaulikar wrote: > Hi Ben, > > Thanks for your response and please check inline below with KT2 > > We've also just posted another update to address some of your comments an= d > those from other ADs. > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-19 > > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk wrote: > >> Hi Ketan, >> >> Thanks for the replies here and the updates in the -18. >> I think there are still some open topics, though; more inline. >> >> On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote: >> > Hi Ben, >> > >> > Thanks for your detailed review and your comments/inputs. Please check >> > inline for responses. >> > >> > >> > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < >> > noreply@ietf.org> wrote: >> > >> > > Benjamin Kaduk has entered the following ballot position for >> > > draft-ietf-spring-segment-routing-policy-17: Discuss >> > > >> > > When responding, please keep the subject line intact and reply to al= l >> > > email addresses included in the To and CC lines. (Feel free to cut >> this >> > > introductory paragraph, however.) >> > > >> > > >> > > Please refer to >> https://www.ietf.org/blog/handling-iesg-ballot-positions/ >> > > for more information about how to handle DISCUSS and COMMENT >> positions. >> > > >> > > >> > > The document, along with other ballot positions, can be found here: >> > > >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-polic= y/ >> > > >> > > >> > > >> > > --------------------------------------------------------------------= -- >> > > DISCUSS: >> > > --------------------------------------------------------------------= -- >> > > >> > > (1) I may just be misunderstanding things, but I'd like to pull on a >> thread >> > > in =C2=A78.4 a bit more. We say that the headend H learns a BGP rou= te >> that has >> > > a >> > > VPN label V, but then the following procedures seem to say that we >> install >> > > a >> > > route on the appropriate SR Policy P and that when we receive a >> packet that >> > > matches the route in question, push a label stack including the VPN >> label, >> > > and send the resulting packet out. >> > >> > >> > KT> Note that we are sending the packet to the selected BGP NH (i.e. >> egress >> > PE) that advertised the route. The SR Policy is enabling the packets t= o >> > traverse a path that is different from (perhaps) the best-effort IGP >> > routing. >> > >> > >> > > Nowhere do we say to check the VPN >> > > status of the incoming packet, >> > >> > >> > KT> That is the ingress part of the forwarding entry which maps the >> > incoming traffic over a customer interface to their specific VPN conte= xt >> > and then performs a lookup in their VPN specific table. This all is >> > unchanged. >> > >> > >> > > so this seems like it would open a hole in >> > > the VPN by allowing "arbitrary" incoming traffic (not marked as >> specific to >> > > V) to enter that VPN. Is the label V filling some other role than >> > > identifying a specific VPN of many VPNs that could run along the >> route R/r? >> > > (This is the only instance of the phrase "VPN label" in the document= , >> and >> > > no >> > > reference is given, so I'm relying heavily on instinct to ascertain >> the >> > > intent here.) >> > > >> > >> > KT> I hope my responses clarified that the only thing that is changed >> here >> > by the steering over the SR Policy is the path taken through the >> network to >> > get to the egress PE. Rest is as today. And yes, of course, we have th= e >> > ability to indicate the need for such steering via the matching Color >> > Extended community to the BGP route. >> >> Yes, these help clarify that the part we're focusing on in this document >> is >> conceptually "after" the determination of the incoming VPN, and so there >> isn't any new processing needed for it. Thanks for the explanation. > > >> > >> > > >> > > (2) The security considerations says that this document does not >> define any >> > > new protocol extensions and (accordingly) does not introduce any >> further >> > > security considerations. The first part of this seems false, not >> least >> > > since we define the meaning of the "CO" bits in the Color Extended >> > > Community. I'm pretty sure that makes the second part also false, >> and we >> > > need to discuss the security considerations relating to imposing SR >> > > Policies >> > > based only on color and not next-hop. Alvaro has also noted >> additional >> > > aspects where security considerations are missing. >> > > >> > >> > KT> Ack. We will add text in the security consideration sections for >> the CO >> > steering modes. >> >> What about the SR-DB concept and other new concepts that Alvaro >> identified? >> Aren't there security and manageability considerations there as well? >> > > KT2> We've just added text for the endpoint uniqueness and steering > aspects. The SRDB is internal to the computation node and the information > within it is derived from existing routing protocols and their extensions= - > we are not adding anything new to it. Do let me know, however, if you fee= l > we are missing something. > > >> > >> > > >> > > (3) The Discriminator as defined in =C2=A72.5 does not seem wide eno= ugh to >> be >> > > able to provide the needed properties. Some later clarification in >> =C2=A72.6 >> > > implies that the definition in =C2=A72.5 is incomplete and the width= is >> actually >> > > appropriate, but in either case =C2=A72.5 seems inadequate in its cu= rrent >> form. >> > > (Details in the COMMENT.) >> > > >> > >> > KT> 32 bit is wide enough and please see further response below. >> >> I think I'm still failing to understand exactly why; more below. >> >> > > >> > > (4) Section 2.11 contains the statement, "A valid SR Policy is >> instantiated >> > > in the forwarding plane." >> > > >> > > Is this a statement of fact (i.e., a consequence of the definition o= f >> > > "valid") or a mandate for something (e.g., the headend) to take >> action to >> > > make it so? Given that the point of SR is to be stateless on nodes >> other >> > > than the headend, I suspect the former, but if we are relying on the >> > > headend >> > > (or some other entity) to take action to ensure this is the case, th= at >> > > needs >> > > to be a clearly stated normative requirement. >> > > >> > >> > KT> The validity of a candidate path and as an extension, the SR Polic= y >> is >> > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its >> > constructs are instantiated in the forwarding plane. >> >> Would it make sense to say something like "In order to be considered >> valid, >> an SR policy needs to be instantiated in the forwarding plane (Section >> 5)"? >> > > KT2> The SR Policy may be valid, but could not be instantiated into the > forwarding due to a resource issue. We are simply stating here that > generally only a valid SR Policy is instantiated in the forwarding plane. > We don't have the "only" here since we have use-cases as in section 8.2 > where we do have to instantiate a "drop" entry in the forwarding for an > invalid SR Policy. > > >> >> > >> > > >> > > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." >> > > There's nothing in the IANA registry for SAFI >> > > (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtm= l >> ) >> > > about >> > > LISP, and RFC 6830 doesn't talk about SAFI. What is this referring >> to? >> > > >> > >> > KT> Ack - there is no SAFI in LISP and the reference was meant to be f= or >> > routing of both IPv4 and IPv6 packets with LISP. Will fix this. >> >> The new text is still a bit terse/opaque for me to be confident that I >> understand properly, but I will drop the discuss point as I think I see >> how >> it works. > > >> > >> > > >> > > >> > > --------------------------------------------------------------------= -- >> > > COMMENT: >> > > --------------------------------------------------------------------= -- >> > > >> > > There's a lot of this document that feels like just some information= al >> > > discussion of "here are some things that many people do", "here are >> some >> > > possible things you can do with SR", etc.. There are also a small >> handful >> > > of places in the document that look to actually be specifying parts = of >> > > protocol behavior (I suspect that John has already identified them i= n >> his >> > > enumeration), and the overall impression ends up being a bit jumbled= , >> > > like there are a bunch of topics stuck together without an overarchi= ng >> > > theme. >> > > I think the overall content would be more valuable if divided into a >> tight >> > > "protocol specification" portion that could stay at proposed >> standard, plus >> > > an informational "architecture details" document that contains the >> > > in-depth exposition that didn't make it into 8402. >> > > >> > > This draft would benefit greatly from a terminology section. I note >> in the >> > > section-by-section comments several places where a term is first use= d >> > > without sufficient background/definition, leaving the matter at hand >> > > underspecified for the reader. >> > > >> > > Section 2 >> > > >> > > An SR Policy is a framework that enables the instantiation of an >> > > ordered list of segments on a node for implementing a source >> routing >> > > >> > > Really, an SR policy is a *framework*? I thought an SR policy was a >> > > specific instantiation of a list of segments, or at least that's wha= t >> I'm >> > > getting from RFC 8402. Perhaps we should say that the general >> concept of >> > > SR >> > > Policy provides a framework? >> > > >> > >> > KT> Ack. Will rephrase. >> > >> > >> > > >> > > Section 2.1 >> > > >> > > An SR Policy MUST be identified through the tuple > > > endpoint>. In the context of a specific headend, an SR policy MU= ST >> > > be identified by the tuple. >> > > >> > > These two MUSTs appear to be in (nominal) conflict. Maybe start the >> first >> > > one with "absent further context" or "absent the context of a known >> headend >> > > node"? >> > > >> > >> > KT> It is not "absence of context" but "within the context of a specif= ic >> > headend". >> > >> > >> > > >> > > The headend is the node where the policy is >> instantiated/implemented. >> > > The headend is specified as an IPv4 or IPv6 address and is expect= ed >> > > to be unique in the domain. >> > > >> > > This is the first instance of the word "domain" in this document. I >> > > suggest >> > > using the introduction to introduce what is meant by the word, even >> if just >> > > by reference to RFC 8402. >> > > >> > >> > KT> Ack. It should be SR Domain. >> > >> > >> > > >> > > An implementation MAY allow the assignment of a symbolic name >> > > comprising printable ASCII [RFC0020] characters (i.e. 0x20 to >> 0x7E) >> > > to an SR Policy to serve as a user-friendly attribute for debuggi= ng >> > > and troubleshooting purposes. [...] >> > > >> > > I agree with the other ADs that limiting to US-ASCII is not actually >> > > user-friendly for many users, and that the likelihood of some >> > > implementations not properly enforcing such a limitation to be high. >> > > (Likewise for the other places where symbolic names are admitted.) >> > > >> > >> > KT> Please see the response to the other reviews on this point. >> >> I don't find them compelling, but this is just the COMMENT section so >> you're not obligated to persuade me. >> >> > >> > > >> > > Section 2.2 >> > > >> > > A dynamic candidate path expresses an optimization objective and = a >> > > set of constraints. [...] >> > > >> > > Down in =C2=A75.2 when we discuss validation procedures for dynamic >> candidate >> > > paths, we say that the optimization problem is solved "for either th= e >> > > SR-MPLS or the SRv6 data-plane as specified". Does the data plane >> need to >> > > be specified as part of the dynamic candidate path itself? >> > > >> > >> > KT> Yes. >> >> Should we say that here, e.g., "a dynamic candidate path expresses an >> optimization objective and a set of constraints within a specified data >> plane"? >> > > KT2> Ack. Have clarified this in the text. > > >> >> > >> > > >> > > Section 2.3 >> > > >> > > in Section 2.9. The table below specifies the RECOMMENDED defaul= t >> > > values of Protocol-Origin: >> > > >> > > I feel like it would be useful to provide some justification for why >> the >> > > recommended default behavior prefers BGP SR configuration over PCEP, >> even >> > > if >> > > that justification is just "we need to have a clear ordering and thi= s >> one >> > > is >> > > arbitrary". >> > > >> > >> > KT> Ack. Will clarify that. >> > >> > >> > > >> > > Section 2.4 >> > > >> > > o Node Address : represented as a 128-bit value. IPv4 addresses >> > > MUST be encoded in the lowest 32 bits, and the high-order bits >> > > MUST be set to zero. >> > > >> > > Its application in the candidate path selection is described in >> > > Section 2.9. >> > > >> > > The tie-breaker procedure for path selection described in =C2=A72.9 = seems >> to >> > > always prefer IPv4 originators over IPv6 ones (by virtue of >> preferring the >> > > smaller value). I guess if we wanted to change that to prefer IPv6 >> we have >> > > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped >> unicast) >> > > from BCP 153, but it's a bit hard to justify either of those as >> appropriate >> > > on technical grounds, and since this is just a tie-breaker and the >> > > Preference is explicitly preferred, it seems like this is probably >> "good >> > > enough" as-is. >> > > >> > >> > KT> Ack. As clarified in a recent text update in v17, preference is th= e >> key >> > parameter really. >> > >> > >> > > >> > > Section 2.5 >> > > >> > > The Discriminator is a 32-bit value associated with a candidate >> path >> > > that uniquely identifies it within the context of an SR Policy >> from a >> > > specific Protocol-Origin as specified below: >> > > >> > > What are the constraints that underlie the 32-bit requirement here? >> > > It looks like some of the scenarios are going to involve uncoordinat= ed >> > > (random) assignment of these discriminator values (e.g., with the BG= P >> > > distribution mechanism, when coming from different BGP peers), and t= he >> > > birthday-bound collision probability is not negligible for this few >> bits. >> > > That, in turn, calls into question the "uniquely identifies" propert= y >> being >> > > claimed. Or is there some other property that means that only >> > > discriminators from a single issuer will ever need to be compared >> with each >> > > other (making the allocation "coordinated"), such as being >> additionally >> > > associated with the originator? >> > > If my initial analysis was incorrect and these are indeed allocated >> in a >> > > "coordinated" fashion, would it be typical/expected for the >> allocation to >> > > occur by incrementing a local counter on the originator? In some >> > > situations >> > > such allocation by counter can have security considerations, which >> > > draft-gont-numeric-ids-sec-considerations attempts to cover. >> > > >> > >> > KT> The discriminator is scoped to a particular originating node for t= he >> > candidate path and as such, there is no requirement for coordination >> across >> > sources/nodes. Therefore, 32-bit is more than sufficient. >> >> When you say "originating node", does that refer to the SR headend, or t= he >> (BGP) originator of the BGP route containing the SR Policy NLRI? >> > > KT2> The BGP originator as you've correctly understood below. > > >> >> I assume the latter, and agree that *within the context of BGP*, the >> discriminator is scoped to the originating BGP node. But the descriptio= n >> we give in =C2=A72.5 of this document does not say anything about making= use of >> such information. As far as I know, the BGP originator information is >> lost >> when the BGP distinguisher is converted into the SR Policy candidate pat= h >> discriminator data model. > > > KT2> The BGP originator information is not lost. We have clarified this i= n > the text below in sec 2.5 itself: > > o When signaling is via BGP SR Policy, the BGP process receiving the > route provides the distinguisher (refer to Section 2.1 of > [I-D.ietf-idr-segment-routing-te-policy ]) as the discriminator. > > > >> And we don't say anything about how candidate >> paths for a given SR Policy can only be originated from a single BGP nod= e, >> so I have to account somehow for the possibility that two BGP nodes are >> independently announcing candidate paths for the same SR Policy, and thu= s >> might collide in their assignment of distinguisher. > > > KT2> You are correct. This can and does indeed happen today in deployment= s > for redundancy and other reasons. > > >> Whereas BGP can >> resolve that collision via the BP origination information, I don't see h= ow >> that would be done in the SR data model. Does that help you understand >> what part I am missing? >> > > KT2> We did have some text in this document in the early days to explain > these scenarios but it was moved out to an individual draft. Sec 2.9 has = a > pointer to this informative draft. Please check > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-con= siderations-08#section-4 > and if they clarify. > > >> >> >> > >> > > >> > > Section 2.8 >> > > >> > > A candidate path is usable when it is valid. A common path >> validity >> > > criterion is the validity of any of its constituent Segment-Lists= . >> > > The validation rules are specified in Section 5. >> > > >> > > This document claims to target Proposed Standard status; are we real= ly >> > > content to say only that this is "a common" criterion? Even when we >> also >> > > go >> > > on to flat-out state "the validation rules are specified [below]"? >> > > >> > >> > KT> We will change this to introduce the word RECOMMENDED. There are >> > deployments where an operator might need a local policy to declare the >> > candidate path invalid when the number of valid SLs drops below a >> certain >> > threshold (for b/w or load-balancing considerations). >> > >> > >> > > >> > > Section 2.9 >> > > >> > > The candidate path selection process operates primarily on the >> > > candidate path Preference. A candidate path is selected when it = is >> > > valid and it has the highest preference value among all the >> candidate >> > > paths of the SR Policy. >> > > >> > > Should this be "among all the valid candidate paths"? A path that's >> > > invalid >> > > is still invalid, even if it has the highest preference value. >> > > >> > >> > KT> Ack - will clarify this. >> > >> > >> > > >> > > 2. If specified by configuration, prefer the existing installed >> > > path. >> > > >> > > Does "if specified by configuration" refer to the act of applying >> this rule >> > > at all, or that the existing installed path was one specified by >> > > configuration? >> > > >> > >> > KT> The existing installed path. The rationale was that in some >> deployment >> > designs an operator may not want to disturb/churn an active and >> > valid/working path that has been installed in the forwarding. >> > >> > >> > > >> > > Section 2.11 >> > > >> > > The fraction of the flows associated with a given Segment-List is >> w/ >> > > Sw, where w is the weight of the Segment-List and Sw is the sum o= f >> > > the weights of the Segment-Lists of the selected path of the SR >> > > Policy. >> > > >> > > Thank you for stating this clearly! >> > > >> > > Section 3 >> > > >> > > o TE Link Attributes (such as TE metric, Shared Risk Link Groups= , >> > > attribute-flag, extended admin group) [RFC5305] [RFC3630]. >> > > >> > > Is RFC 5329 applicable here as well? >> > > >> > >> > KT> Yes, will add that. Thanks. >> >> (It looks like a second 3630 reference got added in the -18, not 5329; >> I'll >> mention that in my updated ballot remarks as well.) >> > > KT2> Ooops :-( .. now fixed for real > > >> >> > >> > > >> > > Section 4 >> > > >> > > Type E: IPv4 Prefix with Local Interface ID: >> > > This type allows identification of Adjacency SID or BGP Pee= r >> > > Adjacency SID (as defined in [RFC8402]) SR-MPLS label for >> > > point-to-point links including IP unnumbered links. The >> > > headend is required to resolve the specified IPv4 Prefix >> > > Address to the Node originating it and then use the Local >> > > Interface ID to identify the point-to-point link whose >> > > adjacency is being referred to. The Local Interface ID lin= k >> > > descriptor follows semantics as specified in [RFC7752]. Th= is >> > > >> > > The phrase "local interface ID" does not appear in RFC 7752 (and eve= n >> > > "local >> > > interface" appears just once"; please use terminology actually >> present in >> > > the referred-to document to clarify what is being referenced. >> > > >> > >> > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn >> > references RFC5307 which in turn RFC4202. We use RFC7752 since it cove= rs >> > and explains the use of the various link descriptors that we use for >> > various segment types. >> > >> > >> > > >> > > Section 4.1 >> > > >> > > When steering unlabeled IPv6 BGP destination traffic using an SR >> > > policy composed of Segment-List(s) based on IPv4 SIDs, the Explic= it >> > > Null Label Policy is processed as specified in >> > > [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an >> > > >> > > It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced docu= ment. >> > > >> > >> > KT> Ack. Will fix. >> > >> > >> > > >> > > Section 5.1 >> > > >> > > The computation/logic that leads to the choice of the Segment-Lis= t >> is >> > > external to the SR Policy headend. The SR Policy headend does no= t >> > > compute the Segment-List. The SR Policy headend only confirms it= s >> > > validity. >> > > >> > > Does the headend actually have to confirm validity? Is it okay to >> just >> > > trust the controller and blindly use what is provided? >> > > >> > >> > KT> At least the first segment needs to be validated from a >> resolvability >> > perspective. The subsequent segments depend on how (i.e., using what >> > segment types) the controller has signalled the path to the headend. I= f >> it >> > is indicated by just referring to a Prefix (e.g. loopback) of a node, >> then >> > the headend will need to resolve and as such validate. While if >> specified >> > as a label, then no resolution is required. >> >> Hmm. So maybe we could say "the SR Policy headend only confirms the >> validity of any segments that it needs to resolve as part of packet >> processing"? Or does that not actually convey the needed information? >> > > KT2> IMHO, the term used in the draft "path resolution to the SID" is mor= e > informative and cleared (at least to someone working on the programming o= f > forwarding entries) than "packet processing". > > >> >> > >> > > >> > > Section 6.2 >> > > >> > > When the active candidate path has a specified BSID, the SR Polic= y >> > > uses that BSID if this value (label in MPLS, IPv6 address in SRv6= ) >> is >> > > available (i.e., not associated with any other usage: e.g. to >> another >> > > MPLS client, to another SRv6 client, to another SID, to another S= R >> > > Policy, outside the range of SRv6 Locators). >> > > >> > > I don't think I understand what is meant by "client" here (for >> "another >> > > client"). This sentence is the only place where the word "client" >> appears >> > > in this document... >> > > >> > >> > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be >> IS-IS >> > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from = a >> > "label manager" within the router. >> >> I think this explanation actually makes me more concerned about the way >> this is written than I previously was. It seems to imply that we are >> trying to describe both that there is an MPLS vs SRv6 data-plane in use >> and >> that the node in question is a client of some unspecified protocol that >> can >> allocate SIDs/MPLS labels, which could be as varied as an IGP or a >> dedicated path computation protocol. Furthermore, not all of these >> possible protocols would intrinsically provide for arbitrary headend nod= es >> to even know if the label/SID in question has already been allocated to >> another "client"! > > >> Is the determination of availability to be made by the controller or by >> the >> headend? > > > KT2> This is local on the headend. > > >> I think we should state that clearly, since (given the above >> discussion) it seems like it is the controller that is best place to >> actually make the determination, but the phrasing "the SR Policy uses" >> implies (at least to me) that the determination is made on the headend, >> since it is the headend that actually instantiates the policy. >> > > KT2> The controller can (and does in some of the deployments that I am > aware of) keep track of the usage of the Labels in the SRGB and SRLB (ref= er > RFC8402). The same goes for SRv6 SIDs from under the SRv6 Locator. In > deployments where controllers do drive the whole SR Policy provisioning, > they do keep track. However, this is not mandatory in general. The headen= d > is taking care of the actual programming into the forwarding and doesn't > have any option but to handle these conditions. > > >> >> > >> > > >> > > Optionally, instead of only checking that the BSID of the active >> path >> > > is available, a headend MAY check that it is available within a >> given >> > > SID range i.e., Segment Routing Local Block (SRLB) as specified i= n >> > > [RFC8402]. >> > > >> > > Is the only allowed range to check the SRLB? If not, I think we nee= d >> to >> > > s/i.e./e.g./. >> > > >> > >> > KT> Yes, SRLB is the one to check/allocate from for such usage. >> >> Okay. I suspect we want s/a given/the given/ then, but am not 100% sure= . >> > > KT2> Ack. Fixed. > > >> > >> > > >> > > When the specified BSID is not available (optionally is not in th= e >> > > SRLB), an alert message MUST be generated. >> > > >> > > This is the first time (of only two) the word "alert" appears in thi= s >> > > document, and there is no prior expalanation of what entity might be >> > > receiving alerts generated by a headend. Please clarify. >> > > >> > >> > KT> Alert mechanism could be one or more of syslog, Netconf >> notification, a >> > telemetry mechanism, etc.. >> >> I think the clarification is best placed in the document itself, e.g., i= n >> a >> glossary/terminology section as I suggested in my high-level comments. >> > > KT2> We have clarified inline. > > >> >> > >> > > >> > > Assuming that at time t the BSID of the SR Policy is B1, if at ti= me >> > > t+dt a different candidate path becomes active and this new activ= e >> > > path does not have a specified BSID or its BSID is specified but = is >> > > not available (e.g. it is in use by something else), then the SR >> > > Policy MAY keep the previous BSID B1. >> > > >> > > Is there a strict bound on or other guidance for what values of dt a= re >> > > allowable for this purpose? >> > >> > >> > KT> None >> > >> > >> > > Is the intent that there be an atomic >> > > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-path= =3DP2? >> > > >> > >> > KT> There is no atomicity requirement. A switch from one active CP to >> > another will vary depending on the cause of the switch - e.g. if it is >> due >> > to a failure or because a more preferred path came up. >> > >> > >> > > >> > > The association of an SR Policy with a BSID thus MAY change over >> the >> > > life of the SR Policy (e.g., upon active path change). Hence, th= e >> > > BSID SHOULD NOT be used as an identification of an SR Policy. >> > > >> > > Is there any guidance available on how long to wait with a given BSI= D >> value >> > > unused before binding it to a new SR Policy? >> > > >> > >> > KT> None. These depend on the implementation and scenarios like resour= ce >> > availability e.g., a BSID might get re-used sooner if the system is >> running >> > short of labels. >> > >> > >> > > >> > > Section 6.2.3 >> > > >> > > An implementation MAY support the configuration of the Specified- >> > > BSID-only restrictive behavior on the headend for all SR Policies >> or >> > > individual SR Policies. Further, this restrictive behavior MAY >> also >> > > be signaled on a per SR Policy basis to the headend. >> > > >> > > Elsewhere in the document we discuss specific potential signaling >> > > mechanisms/protocols, but here we say nothing. Is that vagueness >> > > intentional? >> > > >> > >> > KT> Since this isn't a protocol specification the mechanism is not >> > described here. However, you can look at >> > >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-= policy-14#section-2.4.2 >> > and that document refers back to this specification. >> >> Okay, but if this document isn't a protocol specification and that's >> grounds to not describe mechanism in it, then there are quite a few othe= r >> places in the document that should also not describe mechanism, if we wa= nt >> to be applying the rule consistently. >> > > KT2> There may be very high-level references to some mechanisms in > addition to the informative pointer to the specific protocol spec. This w= as > done to improve readability. > > >> >> > >> > > >> > > Section 6.3 >> > > >> > > A valid SR Policy installs a BSID-keyed entry in the forwarding >> plane >> > > with the action of steering the packets matching this entry to th= e >> > > selected path of the SR Policy. >> > > >> > > I don't think this is stated properly. An SR Policy is the list of >> > > segments; it isn't the entity that's installing entries in the >> forwarding >> > > plane. Some other entity is installing an entry in the forwarding >> plane to >> > > realize the SR Policy in question, and we should make our writing >> reflect >> > > that. >> > > >> > >> > KT> Ack. s/installs/results in the installation of >> > >> > >> > > >> > > Section 6.4 >> > > >> > > An implementation MAY choose to associate a Binding SID with any >> type >> > > of interface (e.g. a layer 3 termination of an Optical Circuit) o= r >> a >> > > tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE >> > > tunnel, etc). This enables the use of other non-SR enabled >> > > >> > > Should we have some discussion that contrasts this scenario against >> the >> > > End.X behavior from RFC 8986 (for the "interface" case)? >> > > >> > >> > KT> What this document says is that a BSID may be also associated to >> direct >> > over these other types of interfaces/tunnels. We can look at them as >> having >> > no other segment being imposed but just redirecting to an interface. I= n >> > that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID = in >> > SR-MPLS). However, those tend to be associated with protocol >> adjacencies. I >> > am not sure that I've followed your point though and please do let me >> know >> > if I've not. >> >> What you write here indicates to me that you got my point. My proposal >> was >> for a sentence something like "this behavior is analogous to the End.X >> behavior defined in [RFC8986] in that the SID is removed, no new SIDs >> applied, and the packet is directed across a particular interface, but i= t >> conceptually fits better as a Binding SID since the SID is bound to a >> specific (logical or physical) interface and End.X is typically used wit= h >> protocol adjacencies rather than interfaces". But that's just a >> suggestion, and if you think it doesn't make sense or doesn't add much >> value, please ignore it. >> >> > >> > > >> > > Section 7 >> > > >> > > The SR Policy State is maintained on the headend to represent the >> > > state of the policy and its candidate paths. [...] >> > > >> > > I confess I don't really understand why we need to have the current, >> > > minimal, description of SR Policy State in this document. What woul= d >> be >> > > lost if we deferred its discussion entirely until there is a more >> > > comprehensive discussion available? >> > > >> > >> > KT> We will add an informational pointer to the SR Policy YANG model. >> What >> > this document calls out is the requirement for reporting the operation= al >> > state and provides pointers to other specs where this is being worked >> out. >> > >> > >> > > >> > > The SR Policy state can be reported by the headend node via BGP-L= S >> > > [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and >> > > [I-D.ietf-pce-binding-label-sid]. >> > > >> > > The functionality of draft-ietf-pce-binding-label-sid seems much mor= e >> > > limited than that of draft-ietf-idr-te-lsp-distribution; in >> particular, the >> > > former does not seem to actually report SR Policy state to the heade= d >> at >> > > all; rather, it only concerns itself with BSID association to path, >> with no >> > > information about "active", "not preferred", etc. >> > > >> > >> > KT> The PCEP work might be spread out over different documents but we = do >> > need to cover these requirements. That is one of the objectives of >> having >> > this document coordinate work across protocol WGs. >> >> It still feels like we're claiming something here that isn't true -- "ca= n >> be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]". It seem= s >> like we are really trying to say "... via extensions to PCEP [some of >> which >> don't exist yet in a form that we're willing to reference]". >> > > KT2> This document, like some others in SPRING, does provide informative > references (perhaps still in the WG doc stage) for better readability and > clarity. > > >> > >> > > >> > > Section 8.3 >> > > >> > > If the SR Policy P is invalid, the BSID B is not in the forwardin= g >> > > plane and hence the packet K is dropped by H. >> > > >> > > We literally just in the previous section talked about a scenario >> where the >> > > BSDI is kept in the forwarding plane (but with the action to drop, s= o >> the >> > > overall outcome is not changed from what this text describes). >> > > Nonetheless, >> > > it's inaccurate to state that "the BSID B is not in the forwarding >> plane" >> > > here. >> > > >> > >> > KT> There is a difference between the drop being referred to in 8.2 an= d >> > 8.3. What we have in 8.2 is like a route pointing to null where we may >> > advertise and get packets but will drop it with normal counters >> associated >> > with that specific entry. While 8.3 is like we are dropping because we >> have >> > no route (ideally we shouldn't have got the packet) and we increment a >> > generic lookup failed counter. The use-cases for both are different. >> >> I (think I) understand that the mechanisms are different and both have u= se >> cases. I just don't think that the specific combination of words used >> here >> makes a true statement. There are probably a number of ways to make a >> slight >> adjustment and come up with a true statement, such as starting it with a >> caveat as in "When Drop-Upon-Invalid behavior is not in use, for an >> invalid >> SR Policy P, its BSID B is not in the forwarding plane and hence the >> packet >> K is dropped by H". >> > > KT2> Thanks for that suggestion. We've incorporated it. > > >> >> > >> > > >> > > Section 8.4.1 >> > > >> > > When a BGP route has multiple Color Extended communities each wit= h >> a >> > > valid SR Policy, the BGP process installs the route on the SR >> Policy >> > > giving preference to the color with the highest numerical value. >> > > >> > > Do we want to say anything about this being an arbitrary tiebreaker >> (rather >> > > than an intentional preference), or is that thought to be implicitly >> clear? >> > > >> > >> > KT> It is an intentional preference. >> >> Peeking forward to =C2=A78.8.2, is this also referring to the BGP color = rather >> than the SR Policy color? If so, please specifically qualify the word >> "color" as being the BGP one. >> >> If not, then I strongly suggest that the introduction of color in =C2=A7= 2.1 >> state that the numerical value of the color is used as a preference >> mechanism in addition to indicating intent or objective (with the >> implication or explicit statement that assignment of color values must b= e >> performed in a manner that is compatible with the operator's >> preference/policy). >> > > KT2> This document needs to refer to the "BGP color" as the "Color > Extended Community". Thanks for catching that. This is not done in a few > places and we've fixed that. > > >> >> > >> > > >> > > Section 8.5 >> > > >> > > In this section, independent of the a-priori existence of any >> > > explicit candidate path of the SR policy (C, N), it is to be note= d >> > > that the BGP process at headend node H triggers the instantiation >> of >> > > a dynamic candidate path for the SR policy (C, N) as soon as: >> > > >> > > I strongly suggest providing a more explicit framework of what the >> > > assumptions and preconditions are for the mechanism described in thi= s >> > > section. My intuition says that it's a fairly optional thing that >> would >> > > need to be specifically configured, but trying to wrap that sentimen= t >> into >> > > the long bullet point involving "a local policy" seems like a very >> > > confusing >> > > way to express the desired behavior. >> > > >> > >> > KT> It is actually a matter of local policy with perhaps some template >> and >> > configuration to drive this. I believe this should get covered in the = SR >> > Policy YANG model at some point in time. >> > >> > >> > > >> > > Section 8.6 >> > > >> > > o is configured to instantiate an array of paths to N where the >> > > entry 0 is the IGP path to N, color C1 is the first entry and >> > > Color C2 is the second entry. The index into the array is >> called >> > > a Forwarding Class (FC). The index can have values 0 to 7. >> > > >> > > Why are the only allowed values 0 to 7? Where does this restriction >> arise >> > > from? It is because of some protocol element? >> > > >> > >> > KT> There is text further in the section to indicated that these >> > ranges/values are implementation-specific. Historically, the 8 values >> have >> > come from the MPLS EXP bits. >> >> If the ranges/values are implementation-specific, then don't give a >> specific range here stated as if it is a universal limitation! I would >> either drop the sentence entirely or say something like "when the index = is >> conveyed using the MPLS EXP bits, only indices 0 to 7 are usable". >> > > KT2> Ack. Have clarified. > > >> >> > >> > > >> > > If the local configuration does not specify any explicit forwardi= ng >> > > information for an entry of the array, then this entry is filled >> with >> > > the same information as entry 0 (i.e. the IGP shortest path). >> > > >> > > If the SR Policy mapped to an entry of the array becomes invalid, >> > > then this entry is filled with the same information as entry 0. >> When >> > > all the array entries have the same information as entry0, the >> > > forwarding entry for N is updated to bypass the array and point >> > > directly to its outgoing interface and next-hop. >> > > >> > > I can't tell how much of this is supposed to be protocol >> specification and >> > > how much an illustrative example. Is A(0) always the IGP shortest >> path? >> > > Are these protocol requirements to fall back to the IGP shortest pat= h >> when >> > > an entry is otherwise unpopulated or the associated SR Policy become= s >> > > invalid? >> > > >> > >> > KT> The specifics are for illustration purposes. Most of these are >> policy >> > knobs/options. >> >> Please add a note at the top of the section that "this section provides = an >> example of how a headend might apply per-flow steering in practice". >> > > KT2> Ack. Added. > > >> >> > >> > > >> > > Section 8.8.2 >> > > >> > > The steering preference is first based on the highest color value >> and >> > > then CO-dependent for the color. [...] >> > > >> > > This seems to contradict what I assumed earlier about the "highest >> color" >> > > rule being a tiebreaker, e.g., the word "preference" is used here. >> Is it >> > > actually intended to be a deliberately configured priority/preferenc= e >> > > scheme? If so, that would seem to require some wide-ranging reworki= ng >> > > throughout the document. >> > > >> > >> > KT> There is the color that is in the identification of an SR Policy - >> > (color, endpoint). This does not get into any tiebreaker or selection >> > logic. All that (sec 2.9) is about the selection of a candidate path >> within >> > an SR Policy. Then there is the color value signaled via the Color >> Extended >> > community on the BGP routes and here, we have the preference for highe= r >> > color when the route is advertised with multiple colors tagged to it. >> >> I think you should clarify that this section refers to the BGP Color, th= en >> -- previously in the document it has been the SR Policy color value and = an >> unqualified reference to "color value" seems like it refers to the conce= pt >> defined in this document, absent other qualifiers. >> > > KT2> Ack. Fixed references as mentioned in a previous comment. > > >> >> > >> > > >> > > Section 9.3 >> > > >> > > the most appropriate alternative for the active candidate path. = A >> > > fast re-route mechanism MAY then be used to trigger sub 50msec >> > > switchover from the active to the backup candidate path in the >> > > forwarding plane. Mechanisms like Bidirectional Forwarding >> Detection >> > > (BFD) MAY be used for fast detection of such failures. >> > > >> > > Why is the specific 50msec value important here? Is there some othe= r >> > > requirement that imposes it? >> > > >> > >> > KT> This comes from "typical" expectations from fast-reroute mechanism= s. >> >> I'd consider '''to trigger "fast" (sub 50msec) switchover''', then, but >> it's not very important. >> >> > >> > > >> > > Section 10 >> > > >> > > I think we also want to mention the security considerations of >> several more >> > > documents, including (but not limited to) >> > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and >> 8986. >> > > >> > >> > KT> Ack on the three RFCs, but convinced about the >> > draft-ietf-idr-segment-routing-te-policy since that depends on this an= d >> not >> > the other way around. >> >> I think this relates to John's Discuss point and whether this document >> specifies the protocol behavior of the two bits in the context of the >> extension defined in draft-ietf-idr-segment-routing-te-policy. You need >> to >> understand draft-ietf-idr-segment-routing-te-policy in order to understa= nd >> the security considerations relating to the protocol behavior controlled >> by >> those two bits, and IMO the protocol behavior specified by those two bit= s >> is solely the responsibility of this document, so this document must >> incorporate the security considerations of >> draft-ietf-idr-segment-routing-te-policy in order to fully document the >> security considerations of the concepts and protocol elements that this >> document defines. >> > > KT2> I am working with John to address his comments. > > Thanks, > Ketan > > >> >> Thanks for this, and all the other parts I didn't specifically reply to. >> >> I will attempt to update my ballot position in the datatracker to remove >> the parts that are fully addressed (though I will probably inadvertently >> leave in something I shouldn't have). >> >> -Ben >> >> > >> > > >> > > Section 15.2 >> > > >> > > I agree with John that draft-ietf-idr-segment-routing-te-policy must >> be >> > > classified as a normative reference. >> > > >> > > It also seems that RFC 7752 should be classified as normative, as we >> > > incorporate its definition for the semantics of several of the >> segment type >> > > descriptions. >> > > >> > >> > KT> Ack >> > >> > >> > > >> > > >> > > NITS >> > > >> > > Section 1 >> > > >> > > Segment Routing Policy (SR Policy) [RFC8402] is an ordered list o= f >> > > segments (i.e. instructions) that represent a source-routed polic= y. >> > > >> > > /Segment/A Segment/ >> > > >> > >> > KT> Ack >> > >> > >> > > >> > > The headend node is said to steer a flow into a SR Policy. The >> > > packets steered into an SR Policy carry an ordered list of segmen= ts >> > > associated with that SR Policy. [...] >> > > >> > > In a certain sense this can be read as saying that the packets that >> "carry >> > > an ordered list of segments" are the ones prior to being steered int= o >> an SR >> > > policy, which would make this statement not true. Perhaps we want t= o >> say >> > > "after being steered into an SR Policy, packets carry an ordered lis= t >> ..."? >> > > (I also went back and forth with myself about whether "packets ... >> carry" >> > > implies in the payload or not. I settled on "not" but make this not= e >> just >> > > in case I am missing an aspect of that question.) >> > > >> > >> > KT> Ack. Will rephrase. >> > >> > >> > > >> > > Section 2 >> > > >> > > An SR Policy is a framework that enables the instantiation of an >> > > ordered list of segments on a node for implementing a source >> routing >> > > >> > > It's easy to read this as saying that all of the segments in the lis= t >> > > instantiated on the single node in question, which I assume is not t= he >> > > intent. Probably the easiest way to aid readability here is to spli= t >> the >> > > sentence up into multiple smaller sentences that are easier to parse= . >> > > >> > >> > KT> Will rephrase. >> > >> > >> > > >> > > Section 2.2 >> > > >> > > A dynamic candidate path expresses an optimization objective and = a >> > > set of constraints. The headend (potentially with the help of a >> PCE) >> > > computes the solution Segment-List (or set of Segment-Lists) that >> > > solves the optimization problem. >> > > >> > > I'd suggest computes the solution/computes a solution/ for genericit= y. >> > > >> > >> > KT> Ack. >> > >> > >> > > A stateful PCE might end up computing a path that is not the optimal >> one >> > > for >> > > this specific optimization problem, due to a desire to cooperate wit= h >> other >> > > paths in the network, and the "Min-Metric with margin and maximum >> number of >> > > SIDs" objective in draft-filsfils-spring-sr-policy-considerations >> doesn't >> > > even have a guaranteed unique best solution. >> > > >> > > Section 2.5 >> > > >> > > When provisioning is via configuration, this is an implementation= 's >> > > configuration model-specific unique identifier for a candidate >> path. >> > > The default value is 0. >> > > >> > > I'm having a lot of trouble parsing this. Did we perhaps mean to >> hyphenate >> > > as "configuration-model-specific"? >> > > >> > >> > KT> Ack >> > >> > >> > > >> > > Section 2.13 >> > > >> > > The SR Policy POL1 is identified by the tuple > > > endpoint>. It has two candidate paths CP1 and CP2. Each is >> > > identified by a tuple . >> > > >> > > I suggest (for the last sentence) "identified within the scope of >> POL1" >> > > >> > >> > KT> Ack >> > >> > >> > > >> > > forwarding instantiation of SR policy POL1. Traffic steered on >> POL1 >> > > is flow-based hashed on Segment-List with a ratio >> > > W1/(W1+W2). >> > > >> > > If I read "ratio" I would instinctively think of the ratio of >> (traffic on >> > > segment list 1)/(traffic on segment list 2), as opposed to the >> proportion >> > > of >> > > all traffic, that would be measured as the indicated W1/(W1+W2). >> > > >> > >> > KT> Ack. s/ratio/proportion >> > >> > >> > > >> > > Section 3 >> > > >> > > The attached domain topology may be learned via IGP, BGP-LS or >> > > NETCONF. >> > > >> > > A non-attached (remote) domain topology may be learned via BGP-LS >> or >> > > NETCONF. >> > > >> > > I think these are both probably not exhaustive lists, so "e.g." or >> similar >> > > may be appropriate. >> > > >> > >> > KT> Ack. >> > >> > >> > > >> > > Section 4 >> > > >> > > Type C: IPv4 Prefix with optional SR Algorithm: >> > > The headend is required to resolve the specified IPv4 Prefi= x >> > > Address to the SR-MPLS label corresponding to a Prefix SID >> > > segment (as defined in [RFC8402]). The SR algorithm (refer >> to >> > > Section 3.1.1 of [RFC8402]) to be used MAY also be provided= . >> > > >> > > Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS= : >> > > In this case, the headend is required to resolve the >> specified >> > > IPv6 Global Prefix Address to the SR-MPLS label correspondi= ng >> > > to its Prefix SID segment (as defined in [RFC8402]). The S= R >> > > Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used >> MAY >> > > >> > > These are effectively just the IPv4 and IPv6 incarnations of the sam= e >> > > underlying procedure, right? Can't we minimize the diff between the >> > > paragraphs further? >> > > >> > >> > KT> Ack >> > >> > >> > > >> > > Section 5.1 >> > > >> > > Additionally, a Segment-List MAY be declared invalid when: >> > > >> > > We probably want another word here ("both"?), to specify how the two >> > > conditions are combined. >> > > >> > >> > KT> Ack - will rephrase. >> > >> > >> > > >> > > Section 5.2 >> > > >> > > When the local computation is not possible (e.g., a policy's >> tail-end >> > > is outside the topology known to the headend) or not desired, the >> > > headend MAY send path computation request to a PCE supporting PCE= P >> > > extension specified in [RFC8664]. >> > > >> > > missing article ("the PCEP extension"). I forget if it should be >> > > "extensions" plural. >> > > >> > >> > KT> Ack >> > >> > >> > > >> > > Section 8.7 >> > > >> > > Finally, headend H MAY be configured with a local routing policy >> > > which overrides any BGP/IGP path and steer a specified packet on = an >> > > >> > > singular/plural mismatch -- s/steer/steers/ >> > > >> > >> > KT> Ack. >> > >> > Thanks, >> > Ketan >> >> --000000000000d332f005da6d2540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Please let us = know your feedback on whether the responses and draft updates address your = concerns.


<= /div>
Thanks,
Ketan


On Sat, Mar 5, 2022 = at 4:06 PM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
Hi B= en,

Thanks=C2=A0for your response and please check inlin= e below with KT2

We've also just posted anothe= r update to address some of your comments and those from other ADs.


On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk <kaduk@mit.edu> wrote:<= br>
Hi Ketan,

Thanks for the replies here and the updates in the -18.
I think there are still some open topics, though; more inline.

On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote:
> Hi Ben,
>
> Thanks for your detailed review and your comments/inputs. Please check=
> inline for responses.
>
>
> On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org= > wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-spring-segment-routing-policy-17: 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 cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT posi= tions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatrac= ker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > (1) I may just be misunderstanding things, but I'd like to pu= ll on a thread
> > in =C2=A78.4 a bit more.=C2=A0 We say that the headend H learns a= BGP route that has
> > a
> > VPN label V, but then the following procedures seem to say that w= e install
> > a
> > route on the appropriate SR Policy P and that when we receive a p= acket that
> > matches the route in question, push a label stack including the V= PN label,
> > and send the resulting packet out.
>
>
> KT> Note that we are sending the packet to the selected BGP NH (i.e= . egress
> PE) that advertised the route. The SR Policy is enabling the packets t= o
> traverse a path that is different from (perhaps) the best-effort IGP > routing.
>
>
> > Nowhere do we say to check the VPN
> > status of the incoming packet,
>
>
> KT> That is the ingress part of the forwarding entry which maps the=
> incoming traffic over a customer interface to their specific VPN conte= xt
> and then performs a lookup in their VPN specific table. This all is > unchanged.
>
>
> > so this seems like it would open a hole in
> > the VPN by allowing "arbitrary" incoming traffic (not m= arked as specific to
> > V) to enter that VPN.=C2=A0 Is the label V filling some other rol= e than
> > identifying a specific VPN of many VPNs that could run along the = route R/r?
> > (This is the only instance of the phrase "VPN label" in= the document, and
> > no
> > reference is given, so I'm relying heavily on instinct to asc= ertain the
> > intent here.)
> >
>
> KT> I hope my responses clarified that the only thing that is chang= ed here
> by the steering over the SR Policy is the path taken through the netwo= rk to
> get to the egress PE. Rest is as today. And yes, of course, we have th= e
> ability to indicate the need for such steering via the matching Color<= br> > Extended community to the BGP route.

Yes, these help clarify that the part we're focusing on in this documen= t is
conceptually "after" the determination of the incoming VPN, and s= o there
isn't any new processing needed for it.=C2=A0 Thanks for the explanatio= n.

>
> >
> > (2) The security considerations says that this document does not = define any
> > new protocol extensions and (accordingly) does not introduce any = further
> > security considerations.=C2=A0 The first part of this seems false= , not least
> > since we define the meaning of the "CO" bits in the Col= or Extended
> > Community.=C2=A0 I'm pretty sure that makes the second part a= lso false, and we
> > need to discuss the security considerations relating to imposing = SR
> > Policies
> > based only on color and not next-hop.=C2=A0 Alvaro has also noted= additional
> > aspects where security considerations are missing.
> >
>
> KT> Ack. We will add text in the security consideration sections fo= r the CO
> steering modes.

What about the SR-DB concept and other new concepts that Alvaro identified?=
Aren't there security and manageability considerations there as well?
=C2=A0
KT2> We've just added text for = the endpoint uniqueness and steering aspects. The SRDB is internal to the c= omputation node and the information within it is derived from existing rout= ing protocols and their extensions - we are not adding anything new to it. = Do let me know, however, if you feel we are missing something.

>
> >
> > (3) The Discriminator as defined in =C2=A72.5 does not seem wide = enough to be
> > able to provide the needed properties.=C2=A0 Some later clarifica= tion in =C2=A72.6
> > implies that the definition in =C2=A72.5 is incomplete and the wi= dth is actually
> > appropriate, but in either case =C2=A72.5 seems inadequate in its= current form.
> > (Details in the COMMENT.)
> >
>
> KT> 32 bit is wide enough and please see further response below.
I think I'm still failing to understand exactly why; more below.

> >
> > (4) Section 2.11 contains the statement, "A valid SR Policy = is instantiated
> > in the forwarding plane."
> >
> > Is this a statement of fact (i.e., a consequence of the definitio= n of
> > "valid") or a mandate for something (e.g., the headend)= to take action to
> > make it so?=C2=A0 Given that the point of SR is to be stateless o= n nodes other
> > than the headend, I suspect the former, but if we are relying on = the
> > headend
> > (or some other entity) to take action to ensure this is the case,= that
> > needs
> > to be a clearly stated normative requirement.
> >
>
> KT> The validity of a candidate path and as an extension, the SR Po= licy is
> discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its > constructs are instantiated in the forwarding plane.

Would it make sense to say something like "In order to be considered v= alid,
an SR policy needs to be instantiated in the forwarding plane (Section 5)&q= uot;?

KT2> The SR Policy may be vali= d, but could not be instantiated into the forwarding due to a resource issu= e. We are simply stating here that generally only a valid SR Policy is inst= antiated in the forwarding plane. We don't have the "only" he= re since we have use-cases as in section 8.2 where we do have to instantiat= e a "drop" entry in the forwarding for an invalid SR Policy.
=C2=A0

>
> >
> > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC68= 30]."
> > There's nothing in the IANA registry for SAFI
> > (https://www.iana.org/= assignments/safi-namespace/safi-namespace.xhtml)
> > about
> > LISP, and RFC 6830 doesn't talk about SAFI.=C2=A0 What is thi= s referring to?
> >
>
> KT> Ack - there is no SAFI in LISP and the reference was meant to b= e for
> routing of both IPv4 and IPv6 packets with LISP. Will fix this.

The new text is still a bit terse/opaque for me to be confident that I
understand properly, but I will drop the discuss point as I think I see how=
it works.

>
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > There's a lot of this document that feels like just some info= rmational
> > discussion of "here are some things that many people do"= ;, "here are some
> > possible things you can do with SR", etc..=C2=A0 There are a= lso a small handful
> > of places in the document that look to actually be specifying par= ts of
> > protocol behavior (I suspect that John has already identified the= m in his
> > enumeration), and the overall impression ends up being a bit jumb= led,
> > like there are a bunch of topics stuck together without an overar= ching
> > theme.
> > I think the overall content would be more valuable if divided int= o a tight
> > "protocol specification" portion that could stay at pro= posed standard, plus
> > an informational "architecture details" document that c= ontains the
> > in-depth exposition that didn't make it into 8402.
> >
> > This draft would benefit greatly from a terminology section.=C2= =A0 I note in the
> > section-by-section comments several places where a term is first = used
> > without sufficient background/definition, leaving the matter at h= and
> > underspecified for the reader.
> >
> > Section 2
> >
> >=C2=A0 =C2=A0 An SR Policy is a framework that enables the instant= iation of an
> >=C2=A0 =C2=A0 ordered list of segments on a node for implementing = a source routing
> >
> > Really, an SR policy is a *framework*?=C2=A0 I thought an SR poli= cy was a
> > specific instantiation of a list of segments, or at least that= 9;s what I'm
> > getting from RFC 8402.=C2=A0 Perhaps we should say that the gener= al concept of
> > SR
> > Policy provides a framework?
> >
>
> KT> Ack. Will rephrase.
>
>
> >
> > Section 2.1
> >
> >=C2=A0 =C2=A0 An SR Policy MUST be identified through the tuple &l= t;headend, color,
> >=C2=A0 =C2=A0 endpoint>.=C2=A0 In the context of a specific hea= dend, an SR policy MUST
> >=C2=A0 =C2=A0 be identified by the <color, endpoint> tuple.<= br> > >
> > These two MUSTs appear to be in (nominal) conflict.=C2=A0 Maybe s= tart the first
> > one with "absent further context" or "absent the c= ontext of a known headend
> > node"?
> >
>
> KT> It is not "absence of context" but "within the c= ontext of a specific
> headend".
>
>
> >
> >=C2=A0 =C2=A0 The headend is the node where the policy is instanti= ated/implemented.
> >=C2=A0 =C2=A0 The headend is specified as an IPv4 or IPv6 address = and is expected
> >=C2=A0 =C2=A0 to be unique in the domain.
> >
> > This is the first instance of the word "domain" in this= document.=C2=A0 I
> > suggest
> > using the introduction to introduce what is meant by the word, ev= en if just
> > by reference to RFC 8402.
> >
>
> KT> Ack. It should be SR Domain.
>
>
> >
> >=C2=A0 =C2=A0 An implementation MAY allow the assignment of a symb= olic name
> >=C2=A0 =C2=A0 comprising printable ASCII [RFC0020] characters (i.e= .=C2=A0 0x20 to 0x7E)
> >=C2=A0 =C2=A0 to an SR Policy to serve as a user-friendly attribut= e for debugging
> >=C2=A0 =C2=A0 and troubleshooting purposes.=C2=A0 [...]
> >
> > I agree with the other ADs that limiting to US-ASCII is not actua= lly
> > user-friendly for many users, and that the likelihood of some
> > implementations not properly enforcing such a limitation to be hi= gh.
> > (Likewise for the other places where symbolic names are admitted.= )
> >
>
> KT> Please see the response to the other reviews on this point.

I don't find them compelling, but this is just the COMMENT section so you're not obligated to persuade me.

>
> >
> > Section 2.2
> >
> >=C2=A0 =C2=A0 A dynamic candidate path expresses an optimization o= bjective and a
> >=C2=A0 =C2=A0 set of constraints.=C2=A0 [...]
> >
> > Down in =C2=A75.2 when we discuss validation procedures for dynam= ic candidate
> > paths, we say that the optimization problem is solved "for e= ither the
> > SR-MPLS or the SRv6 data-plane as specified".=C2=A0 Does the= data plane need to
> > be specified as part of the dynamic candidate path itself?
> >
>
> KT> Yes.

Should we say that here, e.g., "a dynamic candidate path expresses an<= br> optimization objective and a set of constraints within a specified data
plane"?

KT2> Ack. Have clarifie= d this in the text.
=C2=A0

>
> >
> > Section 2.3
> >
> >=C2=A0 =C2=A0 in Section 2.9.=C2=A0 The table below specifies the = RECOMMENDED default
> >=C2=A0 =C2=A0 values of Protocol-Origin:
> >
> > I feel like it would be useful to provide some justification for = why the
> > recommended default behavior prefers BGP SR configuration over PC= EP, even
> > if
> > that justification is just "we need to have a clear ordering= and this one
> > is
> > arbitrary".
> >
>
> KT> Ack. Will clarify that.
>
>
> >
> > Section 2.4
> >
> >=C2=A0 =C2=A0 o=C2=A0 Node Address : represented as a 128-bit valu= e.=C2=A0 IPv4 addresses
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be encoded in the lowest 32 bits, = and the high-order bits
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to zero.
> >
> >=C2=A0 =C2=A0 Its application in the candidate path selection is d= escribed in
> >=C2=A0 =C2=A0 Section 2.9.
> >
> > The tie-breaker procedure for path selection described in =C2=A72= .9 seems to
> > always prefer IPv4 originators over IPv6 ones (by virtue of prefe= rring the
> > smaller value).=C2=A0 I guess if we wanted to change that to pref= er IPv6 we have
> > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped u= nicast)
> > from BCP 153, but it's a bit hard to justify either of those = as appropriate
> > on technical grounds, and since this is just a tie-breaker and th= e
> > Preference is explicitly preferred, it seems like this is probabl= y "good
> > enough" as-is.
> >
>
> KT> Ack. As clarified in a recent text update in v17, preference is= the key
> parameter really.
>
>
> >
> > Section 2.5
> >
> >=C2=A0 =C2=A0 The Discriminator is a 32-bit value associated with = a candidate path
> >=C2=A0 =C2=A0 that uniquely identifies it within the context of an= SR Policy from a
> >=C2=A0 =C2=A0 specific Protocol-Origin as specified below:
> >
> > What are the constraints that underlie the 32-bit requirement her= e?
> > It looks like some of the scenarios are going to involve uncoordi= nated
> > (random) assignment of these discriminator values (e.g., with the= BGP
> > distribution mechanism, when coming from different BGP peers), an= d the
> > birthday-bound collision probability is not negligible for this f= ew bits.
> > That, in turn, calls into question the "uniquely identifies&= quot; property being
> > claimed.=C2=A0 Or is there some other property that means that on= ly
> > discriminators from a single issuer will ever need to be compared= with each
> > other (making the allocation "coordinated"), such as be= ing additionally
> > associated with the originator?
> > If my initial analysis was incorrect and these are indeed allocat= ed in a
> > "coordinated" fashion, would it be typical/expected for= the allocation to
> > occur by incrementing a local counter on the originator?=C2=A0 In= some
> > situations
> > such allocation by counter can have security considerations, whic= h
> > draft-gont-numeric-ids-sec-considerations attempts to cover.
> >
>
> KT> The discriminator is scoped to a particular originating node fo= r the
> candidate path and as such, there is no requirement for coordination a= cross
> sources/nodes. Therefore, 32-bit is more than sufficient.

When you say "originating node", does that refer to the SR headen= d, or the
(BGP) originator of the BGP route containing the SR Policy NLRI?

KT2> The BGP originator as you've correctl= y understood below.=C2=A0
=C2=A0

I assume the latter, and agree that *within the context of BGP*, the
discriminator is scoped to the originating BGP node.=C2=A0 But the descript= ion
we give in =C2=A72.5 of this document does not say anything about making us= e of
such information.=C2=A0 As far as I know, the BGP originator information is= lost
when the BGP distinguisher is converted into the SR Policy candidate path discriminator data model.=C2=A0

KT2> Th= e BGP originator information is not lost. We have clarified this in the tex= t below in sec 2.5 itself:

   o  When signaling is via BGP SR Policy, the BGP process receiving t=
he
      route provides the distinguisher (refer to Section 2.1 of
      [I-D.ietf-idr-segment-routing-te-policy]) as the discriminat=
or.
=C2=A0
And we don't say anything about how candidate
paths for a given SR Policy can only be originated from a single BGP node,<= br> so I have to account somehow for the possibility that two BGP nodes are
independently announcing candidate paths for the same SR Policy, and thus might collide in their assignment of distinguisher.=C2=A0

KT2> You are correct. This can and does indeed happen to= day in deployments for redundancy and other reasons.
=C2=A0
=
Whereas BGP can
resolve that collision via the BP origination information, I don't see = how
that would be done in the SR data model.=C2=A0 Does that help you understan= d
what part I am missing?

KT2> We did = have some text in this document in the early days to explain these scenario= s but it was moved out to an individual draft. Sec 2.9 has a pointer to thi= s informative draft. Please check=C2=A0https://datatracker.ietf.org/doc/html/draft-filsfils-sprin= g-sr-policy-considerations-08#section-4 and if they clarify.
= =C2=A0


>
> >
> > Section 2.8
> >
> >=C2=A0 =C2=A0 A candidate path is usable when it is valid.=C2=A0 A= common path validity
> >=C2=A0 =C2=A0 criterion is the validity of any of its constituent = Segment-Lists.
> >=C2=A0 =C2=A0 The validation rules are specified in Section 5.
> >
> > This document claims to target Proposed Standard status; are we r= eally
> > content to say only that this is "a common" criterion?= =C2=A0 Even when we also
> > go
> > on to flat-out state "the validation rules are specified [be= low]"?
> >
>
> KT> We will change this to introduce the word RECOMMENDED. There ar= e
> deployments where an operator might need a local policy to declare the=
> candidate path invalid when the number of valid SLs drops below a cert= ain
> threshold (for b/w or load-balancing considerations).
>
>
> >
> > Section 2.9
> >
> >=C2=A0 =C2=A0 The candidate path selection process operates primar= ily on the
> >=C2=A0 =C2=A0 candidate path Preference.=C2=A0 A candidate path is= selected when it is
> >=C2=A0 =C2=A0 valid and it has the highest preference value among = all the candidate
> >=C2=A0 =C2=A0 paths of the SR Policy.
> >
> > Should this be "among all the valid candidate paths"?= =C2=A0 A path that's
> > invalid
> > is still invalid, even if it has the highest preference value. > >
>
> KT> Ack - will clarify this.
>
>
> >
> >=C2=A0 =C2=A0 2.=C2=A0 If specified by configuration, prefer the e= xisting installed
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 path.
> >
> > Does "if specified by configuration" refer to the act o= f applying this rule
> > at all, or that the existing installed path was one specified by<= br> > > configuration?
> >
>
> KT> The existing installed path. The rationale was that in some dep= loyment
> designs an operator may not want to disturb/churn an active and
> valid/working path that has been installed in the forwarding.
>
>
> >
> > Section 2.11
> >
> >=C2=A0 =C2=A0 The fraction of the flows associated with a given Se= gment-List is w/
> >=C2=A0 =C2=A0 Sw, where w is the weight of the Segment-List and Sw= is the sum of
> >=C2=A0 =C2=A0 the weights of the Segment-Lists of the selected pat= h of the SR
> >=C2=A0 =C2=A0 Policy.
> >
> > Thank you for stating this clearly!
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 o=C2=A0 TE Link Attributes (such as TE metric, Share= d Risk Link Groups,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0attribute-flag, extended admin group) [= RFC5305] [RFC3630].
> >
> > Is RFC 5329 applicable here as well?
> >
>
> KT> Yes, will add that. Thanks.

(It looks like a second 3630 reference got added in the -18, not 5329; I= 9;ll
mention that in my updated ballot remarks as well.)
KT2> Ooops :-( .. now fixed for real
=C2=A0
=

>
> >
> > Section 4
> >
> >=C2=A0 =C2=A0 Type E: IPv4 Prefix with Local Interface ID:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This type allows identification= of Adjacency SID or BGP Peer
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adjacency SID (as defined in [R= FC8402]) SR-MPLS label for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point-to-point links including = IP unnumbered links.=C2=A0 The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 headend is required to resolve = the specified IPv4 Prefix
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address to the Node originating= it and then use the Local
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interface ID to identify the po= int-to-point link whose
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 adjacency is being referred to.= =C2=A0 The Local Interface ID link
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descriptor follows semantics as= specified in [RFC7752].=C2=A0 This
> >
> > The phrase "local interface ID" does not appear in RFC = 7752 (and even
> > "local
> > interface" appears just once"; please use terminology a= ctually present in
> > the referred-to document to clarify what is being referenced.
> >
>
> KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn=
> references RFC5307 which in turn RFC4202. We use RFC7752 since it cove= rs
> and explains the use of the various link descriptors that we use for > various segment types.
>
>
> >
> > Section 4.1
> >
> >=C2=A0 =C2=A0 When steering unlabeled IPv6 BGP destination traffic= using an SR
> >=C2=A0 =C2=A0 policy composed of Segment-List(s) based on IPv4 SID= s, the Explicit
> >=C2=A0 =C2=A0 Null Label Policy is processed as specified in
> >=C2=A0 =C2=A0 [I-D.ietf-idr-segment-routing-te-policy]) Section 2.= 4.4.=C2=A0 When an
> >
> > It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced d= ocument.
> >
>
> KT> Ack. Will fix.
>
>
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 The computation/logic that leads to the choice of th= e Segment-List is
> >=C2=A0 =C2=A0 external to the SR Policy headend.=C2=A0 The SR Poli= cy headend does not
> >=C2=A0 =C2=A0 compute the Segment-List.=C2=A0 The SR Policy headen= d only confirms its
> >=C2=A0 =C2=A0 validity.
> >
> > Does the headend actually have to confirm validity?=C2=A0 Is it o= kay to just
> > trust the controller and blindly use what is provided?
> >
>
> KT> At least the first segment needs to be validated from a resolva= bility
> perspective. The subsequent segments depend on how (i.e., using what > segment types) the controller has signalled the path to the headend. I= f it
> is indicated by just referring to a Prefix (e.g. loopback) of a node, = then
> the headend will need to resolve and as such validate. While if specif= ied
> as a label, then no resolution is required.

Hmm.=C2=A0 So maybe we could say "the SR Policy headend only confirms = the
validity of any segments that it needs to resolve as part of packet
processing"?=C2=A0 Or does that not actually convey the needed informa= tion?

KT2> IMHO, the term used in th= e draft "path resolution to the SID" is more informative and clea= red=C2=A0(at least to someone working on the programming of forwarding entr= ies) than "packet processing".=C2=A0
=C2=A0

>
> >
> > Section 6.2
> >
> >=C2=A0 =C2=A0 When the active candidate path has a specified BSID,= the SR Policy
> >=C2=A0 =C2=A0 uses that BSID if this value (label in MPLS, IPv6 ad= dress in SRv6) is
> >=C2=A0 =C2=A0 available (i.e., not associated with any other usage= : e.g. to another
> >=C2=A0 =C2=A0 MPLS client, to another SRv6 client, to another SID,= to another SR
> >=C2=A0 =C2=A0 Policy, outside the range of SRv6 Locators).
> >
> > I don't think I understand what is meant by "client"= ; here (for "another
> > client").=C2=A0 This sentence is the only place where the wo= rd "client" appears
> > in this document...
> >
>
> KT> The term is "MPLS client" or "SRv6 client".= MPLS clients can be IS-IS
> enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from = a
> "label manager" within the router.

I think this explanation actually makes me more concerned about the way
this is written than I previously was.=C2=A0 It seems to imply that we are<= br> trying to describe both that there is an MPLS vs SRv6 data-plane in use and=
that the node in question is a client of some unspecified protocol that can=
allocate SIDs/MPLS labels, which could be as varied as an IGP or a
dedicated path computation protocol.=C2=A0 Furthermore, not all of these possible protocols would intrinsically provide for arbitrary headend nodes<= br> to even know if the label/SID in question has already been allocated to
another "client"!=C2=A0

Is the determination of availability to be made by the controller or by the=
headend?=C2=A0

KT2> This is local on th= e headend.
=C2=A0
I think we should state that clearly, since (given the above
discussion) it seems like it is the controller that is best place to
actually make the determination, but the phrasing "the SR Policy uses&= quot;
implies (at least to me) that the determination is made on the headend,
since it is the headend that actually instantiates the policy.

KT2> The controller can (and does in some of the= deployments that I am aware of) keep track of the usage of the Labels in t= he SRGB and SRLB (refer RFC8402). The same goes for SRv6 SIDs from under th= e SRv6 Locator. In deployments where controllers do drive the whole SR Poli= cy provisioning, they do keep track.=C2=A0However, this is not mandatory in= general. The headend is taking care of the actual programming into the for= warding and doesn't have any option but to handle these conditions.
=C2=A0

>
> >
> >=C2=A0 =C2=A0 Optionally, instead of only checking that the BSID o= f the active path
> >=C2=A0 =C2=A0 is available, a headend MAY check that it is availab= le within a given
> >=C2=A0 =C2=A0 SID range i.e., Segment Routing Local Block (SRLB) a= s specified in
> >=C2=A0 =C2=A0 [RFC8402].
> >
> > Is the only allowed range to check the SRLB?=C2=A0 If not, I thin= k we need to
> > s/i.e./e.g./.
> >
>
> KT> Yes, SRLB is the one to check/allocate from for such usage.

Okay.=C2=A0 I suspect we want s/a given/the given/ then, but am not 100% su= re.

KT2> Ack. Fixed.
=C2= =A0
>
> >
> >=C2=A0 =C2=A0 When the specified BSID is not available (optionally= is not in the
> >=C2=A0 =C2=A0 SRLB), an alert message MUST be generated.
> >
> > This is the first time (of only two) the word "alert" a= ppears in this
> > document, and there is no prior expalanation of what entity might= be
> > receiving alerts generated by a headend.=C2=A0 Please clarify. > >
>
> KT> Alert mechanism could be one or more of syslog, Netconf notific= ation, a
> telemetry mechanism, etc..

I think the clarification is best placed in the document itself, e.g., in a=
glossary/terminology section as I suggested in my high-level comments.
<= /blockquote>

KT2> We have clarified inline.
=C2=A0

>
> >
> >=C2=A0 =C2=A0 Assuming that at time t the BSID of the SR Policy is= B1, if at time
> >=C2=A0 =C2=A0 t+dt a different candidate path becomes active and t= his new active
> >=C2=A0 =C2=A0 path does not have a specified BSID or its BSID is s= pecified but is
> >=C2=A0 =C2=A0 not available (e.g. it is in use by something else),= then the SR
> >=C2=A0 =C2=A0 Policy MAY keep the previous BSID B1.
> >
> > Is there a strict bound on or other guidance for what values of d= t are
> > allowable for this purpose?
>
>
> KT> None
>
>
> >=C2=A0 =C2=A0Is the intent that there be an atomic
> > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-pa= th=3DP2?
> >
>
> KT> There is no atomicity requirement. A switch from one active CP = to
> another will vary depending on the cause of the switch - e.g. if it is= due
> to a failure or because a more preferred path came up.
>
>
> >
> >=C2=A0 =C2=A0 The association of an SR Policy with a BSID thus MAY= change over the
> >=C2=A0 =C2=A0 life of the SR Policy (e.g., upon active path change= ).=C2=A0 Hence, the
> >=C2=A0 =C2=A0 BSID SHOULD NOT be used as an identification of an S= R Policy.
> >
> > Is there any guidance available on how long to wait with a given = BSID value
> > unused before binding it to a new SR Policy?
> >
>
> KT> None. These depend on the implementation and scenarios like res= ource
> availability e.g., a BSID might get re-used sooner if the system is ru= nning
> short of labels.
>
>
> >
> > Section 6.2.3
> >
> >=C2=A0 =C2=A0 An implementation MAY support the configuration of t= he Specified-
> >=C2=A0 =C2=A0 BSID-only restrictive behavior on the headend for al= l SR Policies or
> >=C2=A0 =C2=A0 individual SR Policies.=C2=A0 Further, this restrict= ive behavior MAY also
> >=C2=A0 =C2=A0 be signaled on a per SR Policy basis to the headend.=
> >
> > Elsewhere in the document we discuss specific potential signaling=
> > mechanisms/protocols, but here we say nothing.=C2=A0 Is that vagu= eness
> > intentional?
> >
>
> KT> Since this isn't a protocol specification the mechanism is = not
> described here. However, you can look at
> = https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-pol= icy-14#section-2.4.2
> and that document refers back to this specification.

Okay, but if this document isn't a protocol specification and that'= s
grounds to not describe mechanism in it, then there are quite a few other places in the document that should also not describe mechanism, if we want<= br> to be applying the rule consistently.

K= T2> There may be very high-level references to some mechanisms in additi= on to the informative pointer to the specific protocol spec. This was done = to improve readability.
=C2=A0

>
> >
> > Section 6.3
> >
> >=C2=A0 =C2=A0 A valid SR Policy installs a BSID-keyed entry in the= forwarding plane
> >=C2=A0 =C2=A0 with the action of steering the packets matching thi= s entry to the
> >=C2=A0 =C2=A0 selected path of the SR Policy.
> >
> > I don't think this is stated properly.=C2=A0 An SR Policy is = the list of
> > segments; it isn't the entity that's installing entries i= n the forwarding
> > plane.=C2=A0 Some other entity is installing an entry in the forw= arding plane to
> > realize the SR Policy in question, and we should make our writing= reflect
> > that.
> >
>
> KT> Ack. s/installs/results in the installation of
>
>
> >
> > Section 6.4
> >
> >=C2=A0 =C2=A0 An implementation MAY choose to associate a Binding = SID with any type
> >=C2=A0 =C2=A0 of interface (e.g. a layer 3 termination of an Optic= al Circuit) or a
> >=C2=A0 =C2=A0 tunnel (e.g.=C2=A0 IP tunnel, GRE tunnel, IP/UDP tun= nel, MPLS RSVP-TE
> >=C2=A0 =C2=A0 tunnel, etc).=C2=A0 This enables the use of other no= n-SR enabled
> >
> > Should we have some discussion that contrasts this scenario again= st the
> > End.X behavior from RFC 8986 (for the "interface" case)= ?
> >
>
> KT> What this document says is that a BSID may be also associated t= o direct
> over these other types of interfaces/tunnels. We can look at them as h= aving
> no other segment being imposed but just redirecting to an interface. I= n
> that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID = in
> SR-MPLS). However, those tend to be associated with protocol adjacenci= es. I
> am not sure that I've followed your point though and please do let= me know
> if I've not.

What you write here indicates to me that you got my point.=C2=A0 My proposa= l was
for a sentence something like "this behavior is analogous to the End.X=
behavior defined in [RFC8986] in that the SID is removed, no new SIDs
applied, and the packet is directed across a particular interface, but it conceptually fits better as a Binding SID since the SID is bound to a
specific (logical or physical) interface and End.X is typically used with protocol adjacencies rather than interfaces".=C2=A0 But that's jus= t a
suggestion, and if you think it doesn't make sense or doesn't add m= uch
value, please ignore it.

>
> >
> > Section 7
> >
> >=C2=A0 =C2=A0 The SR Policy State is maintained on the headend to = represent the
> >=C2=A0 =C2=A0 state of the policy and its candidate paths.=C2=A0 [= ...]
> >
> > I confess I don't really understand why we need to have the c= urrent,
> > minimal, description of SR Policy State in this document.=C2=A0 W= hat would be
> > lost if we deferred its discussion entirely until there is a more=
> > comprehensive discussion available?
> >
>
> KT> We will add an informational pointer to the SR Policy YANG mode= l. What
> this document calls out is the requirement for reporting the operation= al
> state and provides pointers to other specs where this is being worked = out.
>
>
> >
> >=C2=A0 =C2=A0 The SR Policy state can be reported by the headend n= ode via BGP-LS
> >=C2=A0 =C2=A0 [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231]= and
> >=C2=A0 =C2=A0 [I-D.ietf-pce-binding-label-sid].
> >
> > The functionality of draft-ietf-pce-binding-label-sid seems much = more
> > limited than that of draft-ietf-idr-te-lsp-distribution; in parti= cular, the
> > former does not seem to actually report SR Policy state to the he= aded at
> > all; rather, it only concerns itself with BSID association to pat= h, with no
> > information about "active", "not preferred", = etc.
> >
>
> KT> The PCEP work might be spread out over different documents but = we do
> need to cover these requirements. That is one of the objectives of hav= ing
> this document coordinate work across protocol WGs.

It still feels like we're claiming something here that isn't true -= - "can
be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]".=C2=A0 = It seems
like we are really trying to say "... via extensions to PCEP [some of = which
don't exist yet in a form that we're willing to reference]".
=C2=A0
KT2> This document, like some other= s in SPRING, does provide informative references (perhaps still in the WG d= oc stage) for better readability and clarity.=C2=A0


>
> >
> > Section 8.3
> >
> >=C2=A0 =C2=A0 If the SR Policy P is invalid, the BSID B is not in = the forwarding
> >=C2=A0 =C2=A0 plane and hence the packet K is dropped by H.
> >
> > We literally just in the previous section talked about a scenario= where the
> > BSDI is kept in the forwarding plane (but with the action to drop= , so the
> > overall outcome is not changed from what this text describes). > > Nonetheless,
> > it's inaccurate to state that "the BSID B is not in the = forwarding plane"
> > here.
> >
>
> KT> There is a difference between the drop being referred to in 8.2= and
> 8.3. What we have in 8.2 is like a route pointing to null where we may=
> advertise and get packets but will drop it with normal counters associ= ated
> with that specific entry. While 8.3 is like we are dropping because we= have
> no route (ideally we shouldn't have got the packet) and we increme= nt a
> generic lookup failed counter. The use-cases for both are different.
I (think I) understand that the mechanisms are different and both have use<= br> cases.=C2=A0 I just don't think that the specific combination of words = used here
makes a true statement.=C2=A0 There are probably a number of ways to make a= slight
adjustment and come up with a true statement, such as starting it with a caveat as in "When Drop-Upon-Invalid behavior is not in use, for an in= valid
SR Policy P, its BSID B is not in the forwarding plane and hence the packet=
K is dropped by H".

KT2> Thanks= for that suggestion. We've incorporated it.
=C2=A0

>
> >
> > Section 8.4.1
> >
> >=C2=A0 =C2=A0 When a BGP route has multiple Color Extended communi= ties each with a
> >=C2=A0 =C2=A0 valid SR Policy, the BGP process installs the route = on the SR Policy
> >=C2=A0 =C2=A0 giving preference to the color with the highest nume= rical value.
> >
> > Do we want to say anything about this being an arbitrary tiebreak= er (rather
> > than an intentional preference), or is that thought to be implici= tly clear?
> >
>
> KT> It is an intentional preference.

Peeking forward to =C2=A78.8.2, is this also referring to the BGP color rat= her
than the SR Policy color?=C2=A0 If so, please specifically qualify the word=
"color" as being the BGP one.

If not, then I strongly suggest that the introduction of color in =C2=A72.1=
state that the numerical value of the color is used as a preference
mechanism in addition to indicating intent or objective (with the
implication or explicit statement that assignment of color values must be performed in a manner that is compatible with the operator's
preference/policy).

KT2> This docume= nt needs to refer to the "BGP color" as the "Color Extended = Community". Thanks for catching that. This is not done in a few places= and we've fixed that.
=C2=A0

>
> >
> > Section 8.5
> >
> >=C2=A0 =C2=A0 In this section, independent of the a-priori existen= ce of any
> >=C2=A0 =C2=A0 explicit candidate path of the SR policy (C, N), it = is to be noted
> >=C2=A0 =C2=A0 that the BGP process at headend node H triggers the = instantiation of
> >=C2=A0 =C2=A0 a dynamic candidate path for the SR policy (C, N) as= soon as:
> >
> > I strongly suggest providing a more explicit framework of what th= e
> > assumptions and preconditions are for the mechanism described in = this
> > section.=C2=A0 My intuition says that it's a fairly optional = thing that would
> > need to be specifically configured, but trying to wrap that senti= ment into
> > the long bullet point involving "a local policy" seems = like a very
> > confusing
> > way to express the desired behavior.
> >
>
> KT> It is actually a matter of local policy with perhaps some templ= ate and
> configuration to drive this. I believe this should get covered in the = SR
> Policy YANG model at some point in time.
>
>
> >
> > Section 8.6
> >
> >=C2=A0 =C2=A0 o=C2=A0 is configured to instantiate an array of pat= hs to N where the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0entry 0 is the IGP path to N, color C1 = is the first entry and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Color C2 is the second entry.=C2=A0 The= index into the array is called
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0a Forwarding Class (FC).=C2=A0 The inde= x can have values 0 to 7.
> >
> > Why are the only allowed values 0 to 7?=C2=A0 Where does this res= triction arise
> > from?=C2=A0 It is because of some protocol element?
> >
>
> KT> There is text further in the section to indicated that these > ranges/values are implementation-specific. Historically, the 8 values = have
> come from the MPLS EXP bits.

If the ranges/values are implementation-specific, then don't give a
specific range here stated as if it is a universal limitation!=C2=A0 I woul= d
either drop the sentence entirely or say something like "when the inde= x is
conveyed using the MPLS EXP bits, only indices 0 to 7 are usable".
=

KT2> Ack. Have clarified.
=C2= =A0

>
> >
> >=C2=A0 =C2=A0 If the local configuration does not specify any expl= icit forwarding
> >=C2=A0 =C2=A0 information for an entry of the array, then this ent= ry is filled with
> >=C2=A0 =C2=A0 the same information as entry 0 (i.e. the IGP shorte= st path).
> >
> >=C2=A0 =C2=A0 If the SR Policy mapped to an entry of the array bec= omes invalid,
> >=C2=A0 =C2=A0 then this entry is filled with the same information = as entry 0.=C2=A0 When
> >=C2=A0 =C2=A0 all the array entries have the same information as e= ntry0, the
> >=C2=A0 =C2=A0 forwarding entry for N is updated to bypass the arra= y and point
> >=C2=A0 =C2=A0 directly to its outgoing interface and next-hop.
> >
> > I can't tell how much of this is supposed to be protocol spec= ification and
> > how much an illustrative example.=C2=A0 Is A(0) always the IGP sh= ortest path?
> > Are these protocol requirements to fall back to the IGP shortest = path when
> > an entry is otherwise unpopulated or the associated SR Policy bec= omes
> > invalid?
> >
>
> KT> The specifics are for illustration purposes. Most of these are = policy
> knobs/options.

Please add a note at the top of the section that "this section provide= s an
example of how a headend might apply per-flow steering in practice".

KT2> Ack. Added.
=C2=A0

>
> >
> > Section 8.8.2
> >
> >=C2=A0 =C2=A0 The steering preference is first based on the highes= t color value and
> >=C2=A0 =C2=A0 then CO-dependent for the color.=C2=A0 [...]
> >
> > This seems to contradict what I assumed earlier about the "h= ighest color"
> > rule being a tiebreaker, e.g., the word "preference" is= used here.=C2=A0 Is it
> > actually intended to be a deliberately configured priority/prefer= ence
> > scheme?=C2=A0 If so, that would seem to require some wide-ranging= reworking
> > throughout the document.
> >
>
> KT> There is the color that is in the identification of an SR Polic= y -
> (color, endpoint). This does not get into any tiebreaker or selection<= br> > logic. All that (sec 2.9) is about the selection of a candidate path w= ithin
> an SR Policy. Then there is the color value signaled via the Color Ext= ended
> community on the BGP routes and here, we have the preference for highe= r
> color when the route is advertised with multiple colors tagged to it.<= br>
I think you should clarify that this section refers to the BGP Color, then<= br> -- previously in the document it has been the SR Policy color value and an<= br> unqualified reference to "color value" seems like it refers to th= e concept
defined in this document, absent other qualifiers.
KT2> Ack. Fixed references as mentioned in a previous commen= t.
=C2=A0

>
> >
> > Section 9.3
> >
> >=C2=A0 =C2=A0 the most appropriate alternative for the active cand= idate path.=C2=A0 A
> >=C2=A0 =C2=A0 fast re-route mechanism MAY then be used to trigger = sub 50msec
> >=C2=A0 =C2=A0 switchover from the active to the backup candidate p= ath in the
> >=C2=A0 =C2=A0 forwarding plane.=C2=A0 Mechanisms like Bidirectiona= l Forwarding Detection
> >=C2=A0 =C2=A0 (BFD) MAY be used for fast detection of such failure= s.
> >
> > Why is the specific 50msec value important here?=C2=A0 Is there s= ome other
> > requirement that imposes it?
> >
>
> KT> This comes from "typical" expectations from fast-rero= ute mechanisms.

I'd consider '''to trigger "fast" (sub 50msec) sw= itchover''', then, but
it's not very important.

>
> >
> > Section 10
> >
> > I think we also want to mention the security considerations of se= veral more
> > documents, including (but not limited to)
> > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and= 8986.
> >
>
> KT> Ack on the three RFCs, but convinced about the
> draft-ietf-idr-segment-routing-te-policy since that depends on this an= d not
> the other way around.

I think this relates to John's Discuss point and whether this document<= br> specifies the protocol behavior of the two bits in the context of the
extension defined in draft-ietf-idr-segment-routing-te-policy.=C2=A0 You ne= ed to
understand draft-ietf-idr-segment-routing-te-policy in order to understand<= br> the security considerations relating to the protocol behavior controlled by=
those two bits, and IMO the protocol behavior specified by those two bits is solely the responsibility of this document, so this document must
incorporate the security considerations of
draft-ietf-idr-segment-routing-te-policy in order to fully document the
security considerations of the concepts and protocol elements that this
document defines.

KT2> I am working = with John to address his comments.

Thanks,
Ketan
=C2=A0

Thanks for this, and all the other parts I didn't specifically reply to= .

I will attempt to update my ballot position in the datatracker to remove the parts that are fully addressed (though I will probably inadvertently leave in something I shouldn't have).

-Ben

>
> >
> > Section 15.2
> >
> > I agree with John that draft-ietf-idr-segment-routing-te-policy m= ust be
> > classified as a normative reference.
> >
> > It also seems that RFC 7752 should be classified as normative, as= we
> > incorporate its definition for the semantics of several of the se= gment type
> > descriptions.
> >
>
> KT> Ack
>
>
> >
> >
> > NITS
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 Segment Routing Policy (SR Policy) [RFC8402] is an o= rdered list of
> >=C2=A0 =C2=A0 segments (i.e. instructions) that represent a source= -routed policy.
> >
> > /Segment/A Segment/
> >
>
> KT> Ack
>
>
> >
> >=C2=A0 =C2=A0 The headend node is said to steer a flow into a SR P= olicy.=C2=A0 The
> >=C2=A0 =C2=A0 packets steered into an SR Policy carry an ordered l= ist of segments
> >=C2=A0 =C2=A0 associated with that SR Policy.=C2=A0 [...]
> >
> > In a certain sense this can be read as saying that the packets th= at "carry
> > an ordered list of segments" are the ones prior to being ste= ered into an SR
> > policy, which would make this statement not true.=C2=A0 Perhaps w= e want to say
> > "after being steered into an SR Policy, packets carry an ord= ered list ..."?
> > (I also went back and forth with myself about whether "packe= ts ... carry"
> > implies in the payload or not.=C2=A0 I settled on "not"= but make this note just
> > in case I am missing an aspect of that question.)
> >
>
> KT> Ack. Will rephrase.
>
>
> >
> > Section 2
> >
> >=C2=A0 =C2=A0 An SR Policy is a framework that enables the instant= iation of an
> >=C2=A0 =C2=A0 ordered list of segments on a node for implementing = a source routing
> >
> > It's easy to read this as saying that all of the segments in = the list
> > instantiated on the single node in question, which I assume is no= t the
> > intent.=C2=A0 Probably the easiest way to aid readability here is= to split the
> > sentence up into multiple smaller sentences that are easier to pa= rse.
> >
>
> KT> Will rephrase.
>
>
> >
> > Section 2.2
> >
> >=C2=A0 =C2=A0 A dynamic candidate path expresses an optimization o= bjective and a
> >=C2=A0 =C2=A0 set of constraints.=C2=A0 The headend (potentially w= ith the help of a PCE)
> >=C2=A0 =C2=A0 computes the solution Segment-List (or set of Segmen= t-Lists) that
> >=C2=A0 =C2=A0 solves the optimization problem.
> >
> > I'd suggest computes the solution/computes a solution/ for ge= nericity.
> >
>
> KT> Ack.
>
>
> > A stateful PCE might end up computing a path that is not the opti= mal one
> > for
> > this specific optimization problem, due to a desire to cooperate = with other
> > paths in the network, and the "Min-Metric with margin and ma= ximum number of
> > SIDs" objective in draft-filsfils-spring-sr-policy-considera= tions doesn't
> > even have a guaranteed unique best solution.
> >
> > Section 2.5
> >
> >=C2=A0 =C2=A0 When provisioning is via configuration, this is an i= mplementation's
> >=C2=A0 =C2=A0 configuration model-specific unique identifier for a= candidate path.
> >=C2=A0 =C2=A0 The default value is 0.
> >
> > I'm having a lot of trouble parsing this.=C2=A0 Did we perhap= s mean to hyphenate
> > as "configuration-model-specific"?
> >
>
> KT> Ack
>
>
> >
> > Section 2.13
> >
> >=C2=A0 =C2=A0 The SR Policy POL1 is identified by the tuple <he= adend, color,
> >=C2=A0 =C2=A0 endpoint>.=C2=A0 It has two candidate paths CP1 a= nd CP2.=C2=A0 Each is
> >=C2=A0 =C2=A0 identified by a tuple <protocol-origin, originato= r, discriminator>.
> >
> > I suggest (for the last sentence) "identified within the sco= pe of POL1"
> >
>
> KT> Ack
>
>
> >
> >=C2=A0 =C2=A0 forwarding instantiation of SR policy POL1.=C2=A0 Tr= affic steered on POL1
> >=C2=A0 =C2=A0 is flow-based hashed on Segment-List <SID11...SID= 1i> with a ratio
> >=C2=A0 =C2=A0 W1/(W1+W2).
> >
> > If I read "ratio" I would instinctively think of the ra= tio of (traffic on
> > segment list 1)/(traffic on segment list 2), as opposed to the pr= oportion
> > of
> > all traffic, that would be measured as the indicated W1/(W1+W2).<= br> > >
>
> KT> Ack. s/ratio/proportion
>
>
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 The attached domain topology may be learned via IGP,= BGP-LS or
> >=C2=A0 =C2=A0 NETCONF.
> >
> >=C2=A0 =C2=A0 A non-attached (remote) domain topology may be learn= ed via BGP-LS or
> >=C2=A0 =C2=A0 NETCONF.
> >
> > I think these are both probably not exhaustive lists, so "e.= g." or similar
> > may be appropriate.
> >
>
> KT> Ack.
>
>
> >
> > Section 4
> >
> >=C2=A0 =C2=A0 Type C: IPv4 Prefix with optional SR Algorithm:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The headend is required to reso= lve the specified IPv4 Prefix
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address to the SR-MPLS label co= rresponding to a Prefix SID
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segment (as defined in [RFC8402= ]).=C2=A0 The SR algorithm (refer to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 3.1.1 of [RFC8402]) to = be used MAY also be provided.
> >
> >=C2=A0 =C2=A0 Type D: IPv6 Global Prefix with optional SR Algorith= m for SR-MPLS:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In this case, the headend is re= quired to resolve the specified
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Global Prefix Address to t= he SR-MPLS label corresponding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to its Prefix SID segment (as d= efined in [RFC8402]).=C2=A0 The SR
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Algorithm (refer to Section 3.1= .1 of [RFC8402]) to be used MAY
> >
> > These are effectively just the IPv4 and IPv6 incarnations of the = same
> > underlying procedure, right?=C2=A0 Can't we minimize the diff= between the
> > paragraphs further?
> >
>
> KT> Ack
>
>
> >
> > Section 5.1
> >
> >=C2=A0 =C2=A0 Additionally, a Segment-List MAY be declared invalid= when:
> >
> > We probably want another word here ("both"?), to specif= y how the two
> > conditions are combined.
> >
>
> KT> Ack - will rephrase.
>
>
> >
> > Section 5.2
> >
> >=C2=A0 =C2=A0 When the local computation is not possible (e.g., a = policy's tail-end
> >=C2=A0 =C2=A0 is outside the topology known to the headend) or not= desired, the
> >=C2=A0 =C2=A0 headend MAY send path computation request to a PCE s= upporting PCEP
> >=C2=A0 =C2=A0 extension specified in [RFC8664].
> >
> > missing article ("the PCEP extension").=C2=A0 I forget = if it should be
> > "extensions" plural.
> >
>
> KT> Ack
>
>
> >
> > Section 8.7
> >
> >=C2=A0 =C2=A0 Finally, headend H MAY be configured with a local ro= uting policy
> >=C2=A0 =C2=A0 which overrides any BGP/IGP path and steer a specifi= ed packet on an
> >
> > singular/plural mismatch -- s/steer/steers/
> >
>
> KT> Ack.
>
> Thanks,
> Ketan

--000000000000d332f005da6d2540-- From nobody Thu Mar 17 10:14:24 2022 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 40B2C3A1334; Thu, 17 Mar 2022 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 8wmQepbsJdtM; Thu, 17 Mar 2022 10:14:19 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 DE5E13A12EE; Thu, 17 Mar 2022 10:14:18 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id k184so1519534vsc.2; Thu, 17 Mar 2022 10:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EKMeHCl2DkFJ0zoU5aCGbpmgVSTUJ3/2L86LrbbVSNg=; b=XP50o1P74LY8WMSjJro8BPI0Z6G9I/9NLJp+QUAzrrLdS8qvVd1+1zdBbu9VqvNMTc +H3OX82TENVYn4cWj5tNjVL2SqPz26Qp34b2j/0BCvIDFrq2w1rvGXC/Wd6mJrXbQXws SNOdf1CkHmULlCSKW6FyaQ54Niz3MHn58CQOV4O6w1jB3kMcBfd+ZRITFHGNt06IkyI+ U/tOx3ZXOr7hv2rLBbKm8s63wPS2n6p8kETraYFbkry6DGciyh9sfPl3QugUSWxHLdkD LARpuhYKvaBMFw9x+kd4SvXqP6hfvD3kytnYAl7/SAq1lNHDigeloAZkbeVaVR+S/hC4 SfuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EKMeHCl2DkFJ0zoU5aCGbpmgVSTUJ3/2L86LrbbVSNg=; b=MYZSZr8iOgF6YEHwTFSZNnAd1dIjTDq8XNqAuUcVnFW3wC1TUn7Q8RfPkKGGisqfFn hstIqQ089VDXmXWQ1fDShLLwosX794CBwQ3zeDXP1xOV1KH49FEcB3iPB4ZCXqyO2toD m3vz1sXZ4qr19QbE9km5a+86OoPVakQpVe7fFokxTgj0FFbcc+hItN7r0cS6RriuBla/ Ku3IUVvui/cBQoDf5MVO/4fG0rHhBXUuR2BsOgGtO4xssRa3v9J8qbHrEvYvT5KdKdiu xLqV/ok41lH+XIug/I7EOSFlW+pFGdIx0D741xfl8lhR9YHjlIp2IPE7hb0haos4FyAa 5riA== X-Gm-Message-State: AOAM532/DPktLAlTCD1mO7NapT18iv745TSNpzpP3kgeiIn9i+gWxpUw P+9AjcFREvxvpGF5Tk3wLdpCeVAwZ27i7GHL9SOr0BE+y+U= X-Google-Smtp-Source: ABdhPJxOkwkvVfqm+dGkZrp9NI+jjPDyWWnGEW1xAj5xy2/C7g+XgZSmaVpoPwS/rSfPq7RGkY8bKwPq3ZvVciHMKMg= X-Received: by 2002:a05:6102:510c:b0:322:b84a:4212 with SMTP id bm12-20020a056102510c00b00322b84a4212mr2514719vsb.64.1647537257412; Thu, 17 Mar 2022 10:14:17 -0700 (PDT) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Thu, 17 Mar 2022 22:44:05 +0530 Message-ID: To: John Scudder Cc: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="000000000000fb7e2905da6d2852" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 17 Mar 2022 17:14:23 -0000 --000000000000fb7e2905da6d2852 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Please let us know your feedback on whether the responses and draft updates address your concerns. The latest version is https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-20 Thanks, Ketan On Mon, Mar 7, 2022 at 11:50 AM Ketan Talaulikar wrote: > Hi John, > > We've just posted an update to the draft for the Color-Only steering mode= s > and the allocation of bits from the BGP Color Extended community. > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-20 > > This is along the lines of your suggestions and the ongoing discussions o= n > the IDR list for the draft-ietf-idr-segment-routing-te-policy : > https://mailarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fFh5F9wlQA/ > > Looking forward to your response on your discuss & comments on this > document. Please let know of any outstanding discuss or comments that > remain to be addressed in the document. > > Thanks, > Ketan > > > On Thu, Feb 17, 2022 at 1:12 AM John Scudder wrote: > >> Hi Ketan, >> >> > On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar >> wrote: >> > >> > Hi John, >> > >> > Thanks for your review and please check inline below for responses. >> >> Thanks for your reply. For this response I=E2=80=99m confining myself to= points 3 >> and 4. >> >> [snip] >> >> > 3. Related to the above, at least one of the references listed as >> informational >> > clearly has to be normative with the document as it stands. >> > draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinki= ng of, for >> > example its use in =C2=A72.4 seems like it may rise to the "normative" >> level, =C2=A72.5 >> > almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icin= g on the >> cake >> > because this document defines semantics for a field that isn=E2=80=99t= even >> allocated >> > until and unless draft-ietf-idr-segment-routing-te-policy is published= . >> > >> > KT> It is the other way round. The SPRING document specifies the >> information model and the constructs of the SR Policy. The IDR document = is >> primarily about signaling of the SR Policy from a controller to the head= end >> using the new SR Policy SAFI (73) - as such it does refer normatively to >> the SPRING SR Policy. >> >> Without getting too far into the details on this one, you just can=E2=80= =99t >> write a spec about a field (or set of flags) that doesn=E2=80=99t (don= =E2=80=99t) exist. >> The way you=E2=80=99ve structured these two documents, that field (I wil= l call it a >> field) doesn=E2=80=99t formally exist until and unless >> draft-ietf-idr-segment-routing-te-policy is published. Therefore, >> draft-ietf-spring-segment-routing-policy has a hard dependency on it, an= d >> this is one thing that makes a reference =E2=80=9Cnormative=E2=80=9D. Th= ese would hardly be >> the first two documents to normatively reference one another, it=E2=80= =99s what the >> RFC Editor uses clusters for (amongst other things). >> >> You could also resolve this particular issue by restructuring the >> documents to make them more self-contained. If you do, then perhaps we >> would need to revisit the other references to >> draft-ietf-idr-segment-routing-te-policy in more detail =E2=80=94 but un= til then it >> wouldn=E2=80=99t be time well spent, as the =C2=A78.8.1 reference is suf= ficient to >> cement the requirement. >> >> > 4. In =C2=A72.1 you talk about the signaling of symbolic names for can= didate >> paths. >> > Although you are careful to say that such symbolic names are only used >> for >> > presentation purposes, it seems to me they still could be considered a >> new >> > potential source of vulnerability, since a string that has no >> sanity-checking >> > whatsoever applied by the protocol can display literally anything to a= n >> > operator viewing it. Shouldn=E2=80=99t this be addressed in your Secur= ity >> > Considerations? (For an example of a related Security Considerations, >> see RFC >> > 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the= one I had at my >> > fingertips=E2=80=A6) >> > >> > KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As >> such, I am not aware of security issues around printable ASCII - please = do >> point me to any references. >> >> You=E2=80=99re thinking too much like a protocol designer. The kind of c= oncern >> I=E2=80=99m thinking about has to do with using the string as a vector t= o put some >> words in front of an operator, as part of a larger social engineering >> attempt. I don=E2=80=99t have a detailed attack scenario to paint for yo= u, but a >> quick sketch is along the lines of >> >> - Attacker manages to inject a candidate path with the name >> =E2=80=9CBig_Bank_Low_Latency=E2=80=9D >> - ProTip: the candidate path does not actually terminate at >> Big_Bank >> - Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_Ban= k >> traffic onto that path >> >> You get the idea, I hope. >> >> > Also note that this document does not specify protocol encodings where >> some extra verbiage is normally required (e.g. that it is signaled witho= ut >> NULL, handling truncation/overruns, etc.). >> >> But yet it does specify the precise character set to be used, and a >> near-obsolescent one at that. Why is that? I mean, I don=E2=80=99t hate = ASCII, but >> I just find it odd and assume you actually have a reason for it, instead= of >> taking either the option of leaving the character set unspecified (as yo= u >> point out there are many such details you don=E2=80=99t concern yourself= with in >> this document) or if specifying it, using UTF-8 or similar. >> >> > KT> As discussed in the WG, we are sticking to printable ASCII. When >> the encoding is specified to be printable ASCII, it is expected that >> implementations valid that. >> >> I admire your optimism. >> >> =E2=80=94John > > --000000000000fb7e2905da6d2852 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

Please let us know your feedba= ck on whether the responses and draft updates address your concerns.


Thanks,<= /div>
Ketan



On Mon, Mar 7, 2022 at 1= 1:50 AM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
Hi John,

<= div>We've just posted an update to the draft for the Color-Only steerin= g modes and the allocation of bits from the BGP Color Extended community.


This is along the lines of you= r suggestions and the ongoing discussions on the IDR list for the draft-iet= f-idr-segment-routing-te-policy :=C2=A0https://ma= ilarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fFh5F9wlQA/=C2=A0

Looking forward to your response on your discuss=C2=A0= & comments on this document. Please let know of any outstanding discuss= or comments that remain to be addressed in the document.

Thanks,
Ketan


On Thu, Feb 17, 2022 at= 1:12 AM John Scudder <jgs@juniper.net> wrote:
Hi Ketan,

> On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:=
>
> Hi John,
>
> Thanks for your review and please check inline below for responses.
Thanks for your reply. For this response I=E2=80=99m confining myself to po= ints 3 and 4.

[snip]

> 3. Related to the above, at least one of the references listed as info= rmational
> clearly has to be normative with the document as it stands.
> draft-ietf-idr-segment-routing-te-policy is the one I=E2=80=99m thinki= ng of, for
> example its use in =C2=A72.4 seems like it may rise to the "norma= tive" level, =C2=A72.5
> almost surely does, =C2=A74.1 surely does, and =C2=A78.8.1 is the icin= g on the cake
> because this document defines semantics for a field that isn=E2=80=99t= even allocated
> until and unless draft-ietf-idr-segment-routing-te-policy is published= .
>
> KT> It is the other way round. The SPRING document specifies the in= formation model and the constructs of the SR Policy. The IDR document is pr= imarily about signaling of the SR Policy from a controller to the headend u= sing the new SR Policy SAFI (73) - as such it does refer normatively to the= SPRING SR Policy.

Without getting too far into the details on this one, you just can=E2=80=99= t write a spec about a field (or set of flags) that doesn=E2=80=99t (don=E2= =80=99t) exist. The way you=E2=80=99ve structured these two documents, that= field (I will call it a field) doesn=E2=80=99t formally exist until and un= less draft-ietf-idr-segment-routing-te-policy is published. Therefore, draf= t-ietf-spring-segment-routing-policy has a hard dependency on it, and this = is one thing that makes a reference =E2=80=9Cnormative=E2=80=9D. These woul= d hardly be the first two documents to normatively reference one another, i= t=E2=80=99s what the RFC Editor uses clusters for (amongst other things).
You could also resolve this particular issue by restructuring the documents= to make them more self-contained. If you do, then perhaps we would need to= revisit the other references to draft-ietf-idr-segment-routing-te-policy i= n more detail =E2=80=94 but until then it wouldn=E2=80=99t be time well spe= nt, as the =C2=A78.8.1 reference is sufficient to cement the requirement.
> 4. In =C2=A72.1 you talk about the signaling of symbolic names for can= didate paths.
> Although you are careful to say that such symbolic names are only used= for
> presentation purposes, it seems to me they still could be considered a= new
> potential source of vulnerability, since a string that has no sanity-c= hecking
> whatsoever applied by the protocol can display literally anything to a= n
> operator viewing it. Shouldn=E2=80=99t this be addressed in your Secur= ity
> Considerations? (For an example of a related Security Considerations, = see RFC
> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the= one I had at my
> fingertips=E2=80=A6)
>
> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As= such, I am not aware of security issues around printable ASCII - please do= point me to any references.

You=E2=80=99re thinking too much like a protocol designer. The kind of conc= ern I=E2=80=99m thinking about has to do with using the string as a vector = to put some words in front of an operator, as part of a larger social engin= eering attempt. I don=E2=80=99t have a detailed attack scenario to paint fo= r you, but a quick sketch is along the lines of

- Attacker manages to inject a candidate path with the name =E2=80=9CBig_Ba= nk_Low_Latency=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - ProTip: the candidate path does not actually = terminate at Big_Bank
- Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_Bank t= raffic onto that path

You get the idea, I hope.

> Also note that this document does not specify protocol encodings where= some extra verbiage is normally required (e.g. that it is signaled without= NULL, handling truncation/overruns, etc.).

But yet it does specify the precise character set to be used, and a near-ob= solescent one at that. Why is that? I mean, I don=E2=80=99t hate ASCII, but= I just find it odd and assume you actually have a reason for it, instead o= f taking either the option of leaving the character set unspecified (as you= point out there are many such details you don=E2=80=99t concern yourself w= ith in this document) or if specifying it, using UTF-8 or similar.

> KT> As discussed in the WG, we are sticking to printable ASCII. Whe= n the encoding is specified to be printable ASCII, it is expected that impl= ementations valid that.

I admire your optimism.

=E2=80=94John
--000000000000fb7e2905da6d2852-- From nobody Thu Mar 17 11:53:23 2022 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 7F3193A155F; Thu, 17 Mar 2022 11:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=juniper.net header.b=V6GlWelw; dkim=pass (1024-bit key) header.d=juniper.net header.b=IQZWq252 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 1yQwrXTR_MDm; Thu, 17 Mar 2022 11:52:51 -0700 (PDT) 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 636883A14E5; Thu, 17 Mar 2022 11:52:48 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22HD8YWi013137; Thu, 17 Mar 2022 11:52:45 -0700 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 : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=gbZhIJRhmQxcN6E2pOukxXCCQ4YGQ5Mj7amLowuVofg=; b=V6GlWelwPL6xXE++yM03GqBOIBvM3nPPGu6tqyXCp5a2ZpemqFJ9qX/reVfCQFbRXUwL uUVYWFk8xhSm74YW5G5Ifzhu6KEudWZUXa78JObxNXfcNF+fRDLMBCGOesZ2E8Ke853s myWs2C+8FbHMyKCcOX0mVVR92wVc+X1Et9rTtEJnysf6N8MqBgh2ee9yMfezoXapysgD O++uQMnI4kQ2TNekPM86mMIm+2SeVyJj56jd0ZX02THV7dL3YRvrZwmOIQB5L2TVI0z+ bKKziGhFrSEeIO7c5ePBMCdK6Hc57WIm5SpwimEW7EBSH21E8FDlskyeKD5L+3C6wr1e zQ== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3euf1s3gp6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Mar 2022 11:52:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JargU9yKlMLSP7oHo66IKMdOAwe5eXxhEr4zW9yoNs6WCyjHupzFWF3VXHadhoatPU3+HAqbqcnRnV/MV54mBIcHyZQwl4P7lLJacosSwTS+Q/yspLGdxeP7p0utWEX43ibUFOsQ1uJzsM03PSSf4bilp49hO6rfaPE1FRfVNcSg5aFos2Or+RYGl+qIOXNgyWOb85JEbNuIcJUQu/2+/LflzuOQNMGT0Q0JDJWyTS6BpZEe1OWBQLd585UsA7orU8X5BK0z2kbcg0w1PjxDL9bUnPOjyCRg8W36/bl5qeN/xb63+EIHcl0dr/CYhRJyXEMY3fGEYo6TQg/8g4FBdw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gbZhIJRhmQxcN6E2pOukxXCCQ4YGQ5Mj7amLowuVofg=; b=cUWHmHB6CTdqPYjqrSC9HOVjuSmiEakSdVJocyZgE2DI1OPwkvtMIDstNEI12Cvzoem5DNqNZc/tyq+0TnxMXNc2rl9+gl5FLNbKNY0KKQLhE19h7v8LBmlsbzp6rpcDDOn1fKx0Y5Uy0/Lg3Yk82FQ1rgUh59q5Zo34C0t5/j7ZfyjF4ZtjynTtMVqwysRFfFbYyn86CXLn9OzIohDTkBSwTkFALF5I7x/ia4/rXIcx+2GsH8x2XgAt5fTmf8pC0JIQS6/du9jRjSIBUUoz7GzaGDvoIxK3DY6rKqTknMj5GjBan9rzhjYn/a0BiS0bBpuQUBFy5O3cvt/JXUry+Q== 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=gbZhIJRhmQxcN6E2pOukxXCCQ4YGQ5Mj7amLowuVofg=; b=IQZWq252UTUG7xwDWpW0ZBOoHKhuOnEqVyUuqG+QWm5UYqVy4BScM4xX/+m7Z3E4k5KaHmfaz6odOCsrE5/NSR7dhmmBUqu9ibi+dg6ezQXV7cEaQhh/rjnxZZqAaVrgA9hS7ekJzYlL//Nokjat2/bOUHXjL7Xcx3xxbbl+Dfw= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by DM6PR05MB5243.namprd05.prod.outlook.com (2603:10b6:5:7e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.10; Thu, 17 Mar 2022 18:52:43 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::ac4f:f5d8:f411:5dcf]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::ac4f:f5d8:f411:5dcf%6]) with mapi id 15.20.5102.007; Thu, 17 Mar 2022 18:52:43 +0000 From: John Scudder To: Ketan Talaulikar CC: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Thread-Topic: John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI1ajQRbh7M614068Bbz53eGtPayWiSeAgAAKsYCAHPxgAIAQbeqAgAAbjQA= Date: Thu, 17 Mar 2022 18:52:43 +0000 Message-ID: <44E729D4-D32D-4F60-8BFC-81AEEE00ACEE@juniper.net> References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3696.80.82.1.1) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 39dcaceb-2bdc-4caf-cf6c-08da084751e1 x-ms-traffictypediagnostic: DM6PR05MB5243:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qFa72RyLqx1RVbovIFwMI+ZHO/c6+EVxy8hZWd9N4kOAbZ+HhqV2Lr8zRM42frscumNuG6pEC3m8bytyPx3G/tfQIbPcQZZcfT4M9mNTM8rHJh6br8Kwbi0rox7DWTyDyiXTnjFWtUT6euT/FHRrlA/C7w17cbMx5PMZODwLYhEkkxNbMcwjssI5WN3xTRZWiV6V75RVrrofjUmBr4hR293J6s1w+/JbG91gkRwpWguvyyuTPQ6aptFOKZbNuMB/Oi+N+fdwnveQn3VewcEoZhdSe6ksda/P4IFsBBKj6YdQydxXunVdPDQihnLjQAc7evFj80Ah5MorRX2Lsx4PRNXDORuI9B6OEQZRi66HtqGUtOIEJ7ddyA3ia+hiIvqwC+bADzyKw/vCjk2YKXQ5qkcTUujbNmOPVisjfiITeeu8R0cBOmYt6BkEeVyq7RIWD3+HrXqr1QiipwaewD5ULiS1IhZNzy77TFdfzZr7EHP0w1ssh20dKWO0+bW8h6gt2TSd28CZmWWZYfEeP7K3zkmpnsgm2kHgMFASK0qRH4OScX2sW6U9GkQXPGuaop5/rpwJ2pAC2SR2eV0BPWnfX0sX59AjvN4ZNUf5WmgbHHsngGRgyZrFThgxTiaZCjsU5xlyXO/O3Tc8YIr9Yu7hmHIVhvgjxHGdh/Zojk1+UVKVPjD8wlcv6O4g2CAElAcFTf0MMvJ4aEJZAfSqi4QbUMQPsjXXapIiyb50fPwkZjh2gSrR1CZ1BcSh1hsPp8kjsdq2UtCogudsp9OTAM8xPY0Qw6YH89aTDL0qgR2XrQNY/wOPC07z6MYyPee8rEKE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6506007)(6512007)(2616005)(71200400001)(53546011)(5660300002)(33656002)(8936002)(6486002)(508600001)(36756003)(966005)(316002)(38070700005)(8676002)(76116006)(64756008)(66446008)(66476007)(66556008)(66946007)(4326008)(83380400001)(2906002)(186003)(6916009)(91956017)(122000001)(54906003)(38100700002)(86362001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RkFrbE00R0M1a0I1cGJ6MGNMcmplckxFNzhCSTJrajdWMXA0ZHBnTWhVVXRO?= =?utf-8?B?bmFwUkVHR0dUUEVtTzNraUEzM3hiVWFrbGRpOHhaKzJ2TVY4NlNvOVNtOXlI?= =?utf-8?B?V2hnRWsydTZPRlFHa0FqcFc2MFYraG1vU2o1Qk1qbjhOcFp0WXJFZURoRTBJ?= =?utf-8?B?cWpPNmdEUUEzaEwvc2dBSzNwSjJ5NlNXeXI5MjhEWXZnN0MreG4wY090Qmlz?= =?utf-8?B?MEY3d1ExcFk0a2VvVXlYNjBhcjlKc1FrK3oxWmhSTEI3TG1JQ3ZBSERBK21a?= =?utf-8?B?Kzhhd2dXeGhQZWxnVkRicXZuNWh5M1lPbE5PTDZjbVpqM0xPazZNcW1CdDRF?= =?utf-8?B?UjdnUXFSYWI0QnBXeXhJZFhyZ1dXdzNBVGcvV3hwakh2a2JLSUhadlNGeVVU?= =?utf-8?B?YTNnZ29qeTNUTmUxTHZRYUF4bFhzOW5xdzJoQWU1eWNBMklVeEZuaFd2T281?= =?utf-8?B?ZVNNTjErVGZOeFR3Ukp3UHNDSE5ScWI1VWVoWDBvZjVQSnVENEZaVUFETDhM?= =?utf-8?B?dENLY0VROG44ZXBvcUFncW9MSmRqY3FYN2V2K3pndGNVTFJzeHA2ME03MDlW?= =?utf-8?B?d3hpa3Exa2Z6c3ZIWkZSRlNyR1dJNU9xczliOE5yTVkrYXNqajNWM281eXBZ?= =?utf-8?B?SmFUaFdyMXFuajJ0WWppSnNKakFLSys4UHlIMW50QkhqcEsxTTl0QkFwZGhk?= =?utf-8?B?a0VKdEFFVnphK2RWeE9jeHNkVUYvU0VaRmRzalJNQkU4Um9UNnRqL1A3SkhK?= =?utf-8?B?V3pBMFJPN1p3anBzL0ZkTHBTNFdacnVjbVlWRjd5RExDajcyRkJ4TnppVklt?= =?utf-8?B?ZkUwYmlCcUlaeVpsM2dGdTdHVGs3OU5EUXh2UDVaTVRtdDFwck9tOTdYQXZX?= =?utf-8?B?aWQ1MHdjeVNWYVNya0hjV2tTMFFkWmlTTlZIWTNma3I4UG84N016aUtKWXA3?= =?utf-8?B?RzZYaUYvVDl3OTFlZmkyS0YyamdKc3RjNGxybTBzekR1OTBjbm0zajkrcXpV?= =?utf-8?B?Q2x1Y2NDZ3pKOTBlU0JYeG93MXpyazlqbFhqUHpZWEdTYWhQRHNvWGwxbit0?= =?utf-8?B?T1VLZzRJZXBMTGYydXViODNrdlJxRi8zakFQOHgxU3Q0RHFtcndwSER3ZXg2?= =?utf-8?B?SUpCeWxZNjVWY01iU1dmaHM1d29TRkdUa241anM3ZDdaV1ZuRzFMQW5ZTjgz?= =?utf-8?B?WkphZVFVdkxCM2J0cHBqN01zN3RvTXdnVHYyQmEvbUoyd3llRlArYmxGQ1VO?= =?utf-8?B?UGZzajZONyt2Q0d6M0hxSjRNRzdhcHE4c2JJaGZuYTJUU1dtejNRS1Y1VnlG?= =?utf-8?B?Rlc0enRUd3pSZGlBdXhRVU1wczcwc0ZuVy9qaHF6dVV2aTBwczY1N3VTYzNw?= =?utf-8?B?US9JcytBdnN6TURBeDM5aFI1VVhVYURPc2p1YklFNFZxajhPZlJhNkR4L09h?= =?utf-8?B?T2VpZHo1VXg0Z01QR203QWdlSHpOd1NrQTdBZktCbU9DZlI3c1M5Z2EzRDNB?= =?utf-8?B?Nlk5TGJWdk4rdldjSmkyNVFadURsMWJJbjZIc0MwdDVBU21XdFUwUDVXM2hP?= =?utf-8?B?VW1raWlVVjB1VEhoWEt5Ujh5R1FydjU1bThEVlJKdDdHUzl6Y3RxU1dDVytu?= =?utf-8?B?OXFlK0dVRDBiQzM2ajlDaHVPbzVac2Y5ZFdMM29iclRGWDQzWXNINkRjay9D?= =?utf-8?B?M1lpcnN2ZzdaVDM4TkRDVDYxMHA3bGQxb1A5OUlZOVNuS1doSWpBZVYyRjB6?= =?utf-8?B?SXFwQ3FabWs5KzIrMHRGc1kyUWlZTmQyYUJDVVJjVVlhZ3FtVFcxVTEycjZz?= =?utf-8?B?Rk1rcDVldDJiUWFzZTNrNjBjVnZPRGpiVk52VEJvTFcrNkg2WVl5VjZYK1d4?= =?utf-8?B?ZVNhd1QrUE5nTVFwSFZsT1g5cENNbVExamtUL29mYjNuZE01dy80Mlc1bjRa?= =?utf-8?B?dWpFYzZNK3pvUHhSYlBUT1Q0Nm1wTVFKY21aVEpES3NLbDZ0Tm4xUzUzNkJ5?= =?utf-8?Q?meV1NFzyDAZMV8HVkBPp7xtILnMKOo=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <84E17389F0C9F34AA014FAF32DACBA16@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39dcaceb-2bdc-4caf-cf6c-08da084751e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2022 18:52:43.4237 (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: x7uAMetNVGFAV+wGVD4hUULYPkPXhL7q9SDdZV5FGV+q7zZTBJeVuk/NbEWYXIPm X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5243 X-Proofpoint-GUID: CnX_07NwxDbnhN9v5iU3UJ5Tfug-RRgK X-Proofpoint-ORIG-GUID: CnX_07NwxDbnhN9v5iU3UJ5Tfug-RRgK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-17_07,2022-03-15_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 mlxlogscore=999 impostorscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 bulkscore=0 spamscore=0 priorityscore=1501 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203170106 Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 17 Mar 2022 18:52:57 -0000 Tm90ZWQgYW5kIEnigJlsbCBnZXQgYmFjayB0byB5b3Ugb24gdGhpcyBhcyBzb29uIGFzIEkgY2Fu Lg0KDQrigJRKb2huDQoNCj4gT24gTWFyIDE3LCAyMDIyLCBhdCAxOjE0IFBNLCBLZXRhbiBUYWxh dWxpa2FyIDxrZXRhbnQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gDQo+IEhpIEpvaG4s DQo+IA0KPiBQbGVhc2UgbGV0IHVzIGtub3cgeW91ciBmZWVkYmFjayBvbiB3aGV0aGVyIHRoZSBy ZXNwb25zZXMgYW5kIGRyYWZ0IHVwZGF0ZXMgYWRkcmVzcyB5b3VyIGNvbmNlcm5zLg0KPiANCj4g VGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0yMA0KPiANCj4gVGhh bmtzLA0KPiBLZXRhbg0KPiANCj4gDQo+IA0KPiBPbiBNb24sIE1hciA3LCAyMDIyIGF0IDExOjUw IEFNIEtldGFuIFRhbGF1bGlrYXIgPGtldGFudC5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEhp IEpvaG4sDQo+IA0KPiBXZSd2ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGUgdG8gdGhlIGRyYWZ0IGZv ciB0aGUgQ29sb3ItT25seSBzdGVlcmluZyBtb2RlcyBhbmQgdGhlIGFsbG9jYXRpb24gb2YgYml0 cyBmcm9tIHRoZSBCR1AgQ29sb3IgRXh0ZW5kZWQgY29tbXVuaXR5Lg0KPiANCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJv dXRpbmctcG9saWN5LTIwDQo+IA0KPiBUaGlzIGlzIGFsb25nIHRoZSBsaW5lcyBvZiB5b3VyIHN1 Z2dlc3Rpb25zIGFuZCB0aGUgb25nb2luZyBkaXNjdXNzaW9ucyBvbiB0aGUgSURSIGxpc3QgZm9y IHRoZSBkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5IDogaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pZHIvM0YybTR1c2EtdWFobnJpRjZmRmg1Rjl3 bFFBLyANCj4gDQo+IExvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHJlc3BvbnNlIG9uIHlvdXIgZGlz Y3VzcyAmIGNvbW1lbnRzIG9uIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSBsZXQga25vdyBvZiBhbnkg b3V0c3RhbmRpbmcgZGlzY3VzcyBvciBjb21tZW50cyB0aGF0IHJlbWFpbiB0byBiZSBhZGRyZXNz ZWQgaW4gdGhlIGRvY3VtZW50Lg0KPiANCj4gVGhhbmtzLA0KPiBLZXRhbg0KPiANCj4gDQo+IE9u IFRodSwgRmViIDE3LCAyMDIyIGF0IDE6MTIgQU0gSm9obiBTY3VkZGVyIDxqZ3NAanVuaXBlci5u ZXQ+IHdyb3RlOg0KPiBIaSBLZXRhbiwNCj4gDQo+ID4gT24gRmViIDE2LCAyMDIyLCBhdCAyOjAz IFBNLCBLZXRhbiBUYWxhdWxpa2FyIDxrZXRhbnQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+ IA0KPiA+IEhpIEpvaG4sDQo+ID4gDQo+ID4gVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgcGxl YXNlIGNoZWNrIGlubGluZSBiZWxvdyBmb3IgcmVzcG9uc2VzLiANCj4gDQo+IFRoYW5rcyBmb3Ig eW91ciByZXBseS4gRm9yIHRoaXMgcmVzcG9uc2UgSeKAmW0gY29uZmluaW5nIG15c2VsZiB0byBw b2ludHMgMyBhbmQgNC4NCj4gDQo+IFtzbmlwXQ0KPiANCj4gPiAzLiBSZWxhdGVkIHRvIHRoZSBh Ym92ZSwgYXQgbGVhc3Qgb25lIG9mIHRoZSByZWZlcmVuY2VzIGxpc3RlZCBhcyBpbmZvcm1hdGlv bmFsDQo+ID4gY2xlYXJseSBoYXMgdG8gYmUgbm9ybWF0aXZlIHdpdGggdGhlIGRvY3VtZW50IGFz IGl0IHN0YW5kcy4NCj4gPiBkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5 IGlzIHRoZSBvbmUgSeKAmW0gdGhpbmtpbmcgb2YsIGZvcg0KPiA+IGV4YW1wbGUgaXRzIHVzZSBp biDCpzIuNCBzZWVtcyBsaWtlIGl0IG1heSByaXNlIHRvIHRoZSAibm9ybWF0aXZlIiBsZXZlbCwg wqcyLjUNCj4gPiBhbG1vc3Qgc3VyZWx5IGRvZXMsIMKnNC4xIHN1cmVseSBkb2VzLCBhbmQgwqc4 LjguMSBpcyB0aGUgaWNpbmcgb24gdGhlIGNha2UNCj4gPiBiZWNhdXNlIHRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBzZW1hbnRpY3MgZm9yIGEgZmllbGQgdGhhdCBpc27igJl0IGV2ZW4gYWxsb2NhdGVk DQo+ID4gdW50aWwgYW5kIHVubGVzcyBkcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUt cG9saWN5IGlzIHB1Ymxpc2hlZC4NCj4gPiANCj4gPiBLVD4gSXQgaXMgdGhlIG90aGVyIHdheSBy b3VuZC4gVGhlIFNQUklORyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGluZm9ybWF0aW9uIG1vZGVs IGFuZCB0aGUgY29uc3RydWN0cyBvZiB0aGUgU1IgUG9saWN5LiBUaGUgSURSIGRvY3VtZW50IGlz IHByaW1hcmlseSBhYm91dCBzaWduYWxpbmcgb2YgdGhlIFNSIFBvbGljeSBmcm9tIGEgY29udHJv bGxlciB0byB0aGUgaGVhZGVuZCB1c2luZyB0aGUgbmV3IFNSIFBvbGljeSBTQUZJICg3MykgLSBh cyBzdWNoIGl0IGRvZXMgcmVmZXIgbm9ybWF0aXZlbHkgdG8gdGhlIFNQUklORyBTUiBQb2xpY3ku IA0KPiANCj4gV2l0aG91dCBnZXR0aW5nIHRvbyBmYXIgaW50byB0aGUgZGV0YWlscyBvbiB0aGlz IG9uZSwgeW91IGp1c3QgY2Fu4oCZdCB3cml0ZSBhIHNwZWMgYWJvdXQgYSBmaWVsZCAob3Igc2V0 IG9mIGZsYWdzKSB0aGF0IGRvZXNu4oCZdCAoZG9u4oCZdCkgZXhpc3QuIFRoZSB3YXkgeW914oCZ dmUgc3RydWN0dXJlZCB0aGVzZSB0d28gZG9jdW1lbnRzLCB0aGF0IGZpZWxkIChJIHdpbGwgY2Fs bCBpdCBhIGZpZWxkKSBkb2VzbuKAmXQgZm9ybWFsbHkgZXhpc3QgdW50aWwgYW5kIHVubGVzcyBk cmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5IGlzIHB1Ymxpc2hlZC4gVGhl cmVmb3JlLCBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5IGhhcyBhIGhh cmQgZGVwZW5kZW5jeSBvbiBpdCwgYW5kIHRoaXMgaXMgb25lIHRoaW5nIHRoYXQgbWFrZXMgYSBy ZWZlcmVuY2Ug4oCcbm9ybWF0aXZl4oCdLiBUaGVzZSB3b3VsZCBoYXJkbHkgYmUgdGhlIGZpcnN0 IHR3byBkb2N1bWVudHMgdG8gbm9ybWF0aXZlbHkgcmVmZXJlbmNlIG9uZSBhbm90aGVyLCBpdOKA mXMgd2hhdCB0aGUgUkZDIEVkaXRvciB1c2VzIGNsdXN0ZXJzIGZvciAoYW1vbmdzdCBvdGhlciB0 aGluZ3MpLg0KPiANCj4gWW91IGNvdWxkIGFsc28gcmVzb2x2ZSB0aGlzIHBhcnRpY3VsYXIgaXNz dWUgYnkgcmVzdHJ1Y3R1cmluZyB0aGUgZG9jdW1lbnRzIHRvIG1ha2UgdGhlbSBtb3JlIHNlbGYt Y29udGFpbmVkLiBJZiB5b3UgZG8sIHRoZW4gcGVyaGFwcyB3ZSB3b3VsZCBuZWVkIHRvIHJldmlz aXQgdGhlIG90aGVyIHJlZmVyZW5jZXMgdG8gZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5n LXRlLXBvbGljeSBpbiBtb3JlIGRldGFpbCDigJQgYnV0IHVudGlsIHRoZW4gaXQgd291bGRu4oCZ dCBiZSB0aW1lIHdlbGwgc3BlbnQsIGFzIHRoZSDCpzguOC4xIHJlZmVyZW5jZSBpcyBzdWZmaWNp ZW50IHRvIGNlbWVudCB0aGUgcmVxdWlyZW1lbnQuDQo+IA0KPiA+IDQuIEluIMKnMi4xIHlvdSB0 YWxrIGFib3V0IHRoZSBzaWduYWxpbmcgb2Ygc3ltYm9saWMgbmFtZXMgZm9yIGNhbmRpZGF0ZSBw YXRocy4NCj4gPiBBbHRob3VnaCB5b3UgYXJlIGNhcmVmdWwgdG8gc2F5IHRoYXQgc3VjaCBzeW1i b2xpYyBuYW1lcyBhcmUgb25seSB1c2VkIGZvcg0KPiA+IHByZXNlbnRhdGlvbiBwdXJwb3Nlcywg aXQgc2VlbXMgdG8gbWUgdGhleSBzdGlsbCBjb3VsZCBiZSBjb25zaWRlcmVkIGEgbmV3DQo+ID4g cG90ZW50aWFsIHNvdXJjZSBvZiB2dWxuZXJhYmlsaXR5LCBzaW5jZSBhIHN0cmluZyB0aGF0IGhh cyBubyBzYW5pdHktY2hlY2tpbmcNCj4gPiB3aGF0c29ldmVyIGFwcGxpZWQgYnkgdGhlIHByb3Rv Y29sIGNhbiBkaXNwbGF5IGxpdGVyYWxseSBhbnl0aGluZyB0byBhbg0KPiA+IG9wZXJhdG9yIHZp ZXdpbmcgaXQuIFNob3VsZG7igJl0IHRoaXMgYmUgYWRkcmVzc2VkIGluIHlvdXIgU2VjdXJpdHkN Cj4gPiBDb25zaWRlcmF0aW9ucz8gKEZvciBhbiBleGFtcGxlIG9mIGEgcmVsYXRlZCBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucywgc2VlIFJGQw0KPiA+IDkwMDMuIEl04oCZcyBwcm9iYWJseSBub3Qg dGhlIGJlc3QgZXhhbXBsZSwgYnV0IGl04oCZcyB0aGUgb25lIEkgaGFkIGF0IG15DQo+ID4gZmlu Z2VydGlwc+KApikNCj4gPiANCj4gPiBLVD4gUkZDOTAwMyB1c2VzIFVURi04IHdoaWxlIHRoaXMg ZG9jdW1lbnQgdXNlcyBwcmludGFibGUgQVNDSUkuIEFzIHN1Y2gsIEkgYW0gbm90IGF3YXJlIG9m IHNlY3VyaXR5IGlzc3VlcyBhcm91bmQgcHJpbnRhYmxlIEFTQ0lJIC0gcGxlYXNlIGRvIHBvaW50 IG1lIHRvIGFueSByZWZlcmVuY2VzLg0KPiANCj4gWW914oCZcmUgdGhpbmtpbmcgdG9vIG11Y2gg bGlrZSBhIHByb3RvY29sIGRlc2lnbmVyLiBUaGUga2luZCBvZiBjb25jZXJuIEnigJltIHRoaW5r aW5nIGFib3V0IGhhcyB0byBkbyB3aXRoIHVzaW5nIHRoZSBzdHJpbmcgYXMgYSB2ZWN0b3IgdG8g cHV0IHNvbWUgd29yZHMgaW4gZnJvbnQgb2YgYW4gb3BlcmF0b3IsIGFzIHBhcnQgb2YgYSBsYXJn ZXIgc29jaWFsIGVuZ2luZWVyaW5nIGF0dGVtcHQuIEkgZG9u4oCZdCBoYXZlIGEgZGV0YWlsZWQg YXR0YWNrIHNjZW5hcmlvIHRvIHBhaW50IGZvciB5b3UsIGJ1dCBhIHF1aWNrIHNrZXRjaCBpcyBh bG9uZyB0aGUgbGluZXMgb2YgDQo+IA0KPiAtIEF0dGFja2VyIG1hbmFnZXMgdG8gaW5qZWN0IGEg Y2FuZGlkYXRlIHBhdGggd2l0aCB0aGUgbmFtZSDigJxCaWdfQmFua19Mb3dfTGF0ZW5jeeKAnQ0K PiAgICAgICAgIC0gUHJvVGlwOiB0aGUgY2FuZGlkYXRlIHBhdGggZG9lcyBub3QgYWN0dWFsbHkg dGVybWluYXRlIGF0IEJpZ19CYW5rDQo+IC0gQXR0YWNrZXIgdGhlbiBwaG9uZXMgTk9DLCBmZWln bnMgdXJnZW5jeSwgYXNrcyBOT0MgdG8gcmVkaXJlY3QgQmlnX0JhbmsgdHJhZmZpYyBvbnRvIHRo YXQgcGF0aA0KPiANCj4gWW91IGdldCB0aGUgaWRlYSwgSSBob3BlLg0KPiANCj4gPiBBbHNvIG5v dGUgdGhhdCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgcHJvdG9jb2wgZW5jb2Rpbmdz IHdoZXJlIHNvbWUgZXh0cmEgdmVyYmlhZ2UgaXMgbm9ybWFsbHkgcmVxdWlyZWQgKGUuZy4gdGhh dCBpdCBpcyBzaWduYWxlZCB3aXRob3V0IE5VTEwsIGhhbmRsaW5nIHRydW5jYXRpb24vb3ZlcnJ1 bnMsIGV0Yy4pLg0KPiANCj4gQnV0IHlldCBpdCBkb2VzIHNwZWNpZnkgdGhlIHByZWNpc2UgY2hh cmFjdGVyIHNldCB0byBiZSB1c2VkLCBhbmQgYSBuZWFyLW9ic29sZXNjZW50IG9uZSBhdCB0aGF0 LiBXaHkgaXMgdGhhdD8gSSBtZWFuLCBJIGRvbuKAmXQgaGF0ZSBBU0NJSSwgYnV0IEkganVzdCBm aW5kIGl0IG9kZCBhbmQgYXNzdW1lIHlvdSBhY3R1YWxseSBoYXZlIGEgcmVhc29uIGZvciBpdCwg aW5zdGVhZCBvZiB0YWtpbmcgZWl0aGVyIHRoZSBvcHRpb24gb2YgbGVhdmluZyB0aGUgY2hhcmFj dGVyIHNldCB1bnNwZWNpZmllZCAoYXMgeW91IHBvaW50IG91dCB0aGVyZSBhcmUgbWFueSBzdWNo IGRldGFpbHMgeW91IGRvbuKAmXQgY29uY2VybiB5b3Vyc2VsZiB3aXRoIGluIHRoaXMgZG9jdW1l bnQpIG9yIGlmIHNwZWNpZnlpbmcgaXQsIHVzaW5nIFVURi04IG9yIHNpbWlsYXIuDQo+IA0KPiA+ IEtUPiBBcyBkaXNjdXNzZWQgaW4gdGhlIFdHLCB3ZSBhcmUgc3RpY2tpbmcgdG8gcHJpbnRhYmxl IEFTQ0lJLiBXaGVuIHRoZSBlbmNvZGluZyBpcyBzcGVjaWZpZWQgdG8gYmUgcHJpbnRhYmxlIEFT Q0lJLCBpdCBpcyBleHBlY3RlZCB0aGF0IGltcGxlbWVudGF0aW9ucyB2YWxpZCB0aGF0Lg0KPiAN Cj4gSSBhZG1pcmUgeW91ciBvcHRpbWlzbS4NCj4gDQo+IOKAlEpvaG4NCg0K From nobody Thu Mar 17 18:03:29 2022 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 C6D323A0E47; Thu, 17 Mar 2022 18:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=seicmu.onmicrosoft.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 z3DGK-zL_BOD; Thu, 17 Mar 2022 18:03:06 -0700 (PDT) Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0703.outbound.protection.office365.us [IPv6:2001:489a:2202:c::703]) (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 694E83A0100; Thu, 17 Mar 2022 18:03:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=XdGjoO+434HA/nRmM6bkcJRRy/cOf4kypCdoA3Z+WRcRk/2FYt/OkCN6a8A5GVTHxoWVtrwgFwNRd4qJpXBFssx9pBq92fn/6UWog6OQ2u0afSGFU0rUdfz2km/F8kR6cDn4Nl3m0u/GTcGvJaZVbtkJY3GO4dBal6oCNZLex52jZFLtCrcZTD/Buk/Dlmeha/IKUPsfYFwZRA18o7kySvhxBzm27s9tbJ24n8lZLjscx1v9V1jclwfqtmWFCu0HOXn1rZM36/lcEL+uucijSpYFwJ3plehOoLJfiLOGayHNPy7zlXGBFIL3RbXghulOyeByQNqrl6Qw6eWx2n+xzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=upsuw1pRvyRHdyu1GskMfX6+NitaalLafRnvOujhHHg=; b=mqDbOOeftfpoG+olcjMItn7kehlgtsHxSj+N9dbPUip08cHbSYd6yt0WnZcfigSRQf7p2VomcwVajSTt5VmVV3nI50XpA3DKO1HEGRXs3BANQs7DJ7ybUf7m1Kt88it4q43+QvVXG38YPCUwRpeSuxTmZF0FcjONVJ61G/bqPqL3mGmq++fEj1GBjZWuLiMafNnV71d7DsS9IZoFVs5fGYIxvkmFccjjZXHd7qmkO6lp23mpA0Pfvom1XTY4WvYk9VOHTlD/oRXH6/5YEBMB7PSUKoeVDig80WKo7UIFRK4/T7HMU9J8B43v4OqKCSwE1Pkr3qKWbiDsXaRru8PN/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=upsuw1pRvyRHdyu1GskMfX6+NitaalLafRnvOujhHHg=; b=deRWYAEXoF3fzJxnaruIE/tIU9LQ7AqWoRqX8xj5kA+XPAYfUdnLtTKJXSmjg9tMzX/BzgdcGNBBuSAmv1Ut/myiNfZv+UmNikXm0nSP7WcdezNXmzgff2UkpKnV0Ip2wH3HiFxXV4e7IvDt/8ICIGdrT1IRg1BO7hwKJTgoPu0= Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB0996.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:169::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.24; Fri, 18 Mar 2022 01:02:57 +0000 Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::3525:e765:3ea4:f086]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::3525:e765:3ea4:f086%5]) with mapi id 15.20.5061.024; Fri, 18 Mar 2022 01:02:45 +0000 From: Roman Danyliw To: Ketan Talaulikar CC: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI4FwfTueyb++ZkWOmt16LvpHx6yX2YWAgAA2R4CAK+2SgIAAgOsQ Date: Fri, 18 Mar 2022 01:02:45 +0000 Message-ID: References: <164504916365.5606.17077981996669554325@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 350287c1-a622-4fe0-de01-08da087b0312 x-ms-traffictypediagnostic: BN2P110MB0996:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2zfXX4ufXZb0Kvwfh0T2hmLAGyFU2MCIHRKCCXZSqZ3unL8MHxwVCeSJTctCwPaw8AwrL9gheXPT9RALZaCuT8v6OfTzPl6/kOfxPPVBdM1SQi9vCuhuaWhfXASHNYFGKVnt9xzSEdTHzpbo9xHmUxddBXzd54zdWf65bVpmV2ShZN2sgzKAt8l/7OkxkLHPNta578lVz3NyeCEz7hvoO7YCuLJvB8NDJPMgfiuCecRwEgF04ThtZJHFdeLTlF67+gAlIjs/OYWIO0c3B26XeU5uo19DFMhbPFW5XZUztWDJftRSBNQYC1jO/B4ISTEVCoRJXC2qoiAstSjOnwEWyjphBuMEDjAEnXBtEcYoIipWcIUZlnxSdG9awF+E2BeX65zAulHrdzQelYRtXwZBveOauZ2kVxvmxR2g6P5bibHlOgNsw9SPFRtTHbCbcit24+hhKPQKNl0eyJDXMhAAu+xX1E8AOCsja9rYdR0H04Zbpm6pfbTvruQ7Ttx7vUiddvHNw4jYLoTRF10zMvin8jYj2H87r2AangQBTuriUA1jPsslWPnyOmGSUN5sbu9ligRAJyjIQCGhXNClMccONme/EdjApC2jpc/b+m33UI8hXXMix5+skOlL7c2AvgnMvJVPONjhetnP+3Bkb2xf1lOVpMFTjnf6O5wEwXX7NSbViWeAHfFw6tBaAIKfJ9NYC/m+CHgtaGhfPbLCNgqS6Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(366004)(52536014)(5660300002)(33656002)(8936002)(4326008)(38070700005)(83380400001)(64756008)(86362001)(966005)(498600001)(66446008)(66476007)(66556008)(66946007)(9686003)(76116006)(71200400001)(8676002)(53546011)(7696005)(6506007)(186003)(26005)(82960400001)(122000001)(166002)(38100700002)(2906002)(55016003)(54906003)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 1DvdVGpkF5KLTwUct/QGzdTYA59O4V8iQTNGUFkn0rxoW8goAiPxicb33/UEjkJQeZRgLp5ZRT9f9x9vfFw5mm3VxQfDApsbTtEFDQZt2hPGZBMcZvl70fOUYGw7nKmaSpxfv2dYHpsH+wU67RDlsA== Content-Type: multipart/alternative; boundary="_000_BN2P110MB11079F79FFFE6B5FF972BDADDC139BN2P110MB1107NAMP_" MIME-Version: 1.0 X-OriginatorOrg: cert.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 350287c1-a622-4fe0-de01-08da087b0312 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2022 01:02:45.1133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB0996 Archived-At: Subject: Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (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 Mar 2022 01:03:13 -0000 --_000_BN2P110MB11079F79FFFE6B5FF972BDADDC139BN2P110MB1107NAMP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V0YW4hDQoNCknigJltIGNsaXBwaW5nIHRoZSB0ZXh0IGEgYml0IHRvIG1ha2UgaXQgcmVh ZGFibGUg4oCmDQoNCg0KT24gVGh1LCBGZWIgMTcsIDIwMjIgYXQgODozOCBQTSBLZXRhbiBUYWxh dWxpa2FyIDxrZXRhbnQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmtldGFudC5pZXRmQGdtYWlsLmNv bT4+IHdyb3RlOg0KSGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1l bnRzL2lucHV0cy4gUGxlYXNlIGNoZWNrIGlubGluZSBiZWxvdyBmb3IgcmVzcG9uc2VzLg0KDQoN Ck9uIFRodSwgRmViIDE3LCAyMDIyIGF0IDM6MzYgQU0gUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRy YWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToN ClJvbWFuIERhbnlsaXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQpkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTE3OiBEaXNjdXNz DQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3Qg YW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9ibG9n L2hhbmRsaW5nLWllc2ctYmFsbG90LXBvc2l0aW9ucy8NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IGhvdyB0byBoYW5kbGUgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNClRoZXJlIGFwcGVhciB0byBiZSBhIGZldyBwbGFjZXMgd2hlcmUg YWRkaXRpb25hbCBwb2ludGVycyBvciBzcGVjaWZpY2F0aW9uIGlzDQpuZWVkZWQgdG8gZW5zdXJl IGludGVyb3BlcmFiaWxpdHkuDQoNCioqIFNlY3Rpb24gMi41DQogICBXaGVuIHNpZ25hbGluZyBp cyB2aWEgUENFUCwgdGhlIG1ldGhvZCB0byB1bmlxdWVseSBzaWduYWwgYW4NCiAgIGluZGl2aWR1 YWwgY2FuZGlkYXRlIHBhdGggYWxvbmcgd2l0aCBpdHMgZGlzY3JpbWluYXRvciBpcyBkZXNjcmli ZWQNCiAgIGluIFtJLUQuaWV0Zi1wY2Utc2VnbWVudC1yb3V0aW5nLXBvbGljeS1jcF0uDQoNCldo ZXJlIGlzIHRoZSBleHBsYW5hdGlvbiBvZiBkaXNjcmltaW5hdG9yIGluIHRoaXMgcmVmZXJlbmNl PyAg4oCcRGlzY3JpbWluYXRvcuKAnQ0KYXBwZWFycyBpbiBTZWN0aW9ucyAzLjEsIDMuMiwgNC4x LjIsIGFuZCA1LjIuMi4gIEluIHRoZSBmaXJzdCB0aHJlZSBzZWN0aW9uIGl0DQppcyBzaW1wbHkg bmFtZWQgYnV0IG5vdCBleHBsYWluZWQuICBJbiB0aGUgbGFzdCBzZWN0aW9uLCBpdCBpc27igJl0 IGV4cGxhaW5lZA0KYmV5b25kIGJlaW5nIGRlZmluZWQgYXMgMzItYml0cy4NCg0KS1Q+IEkgaGF2 ZSBub3QgeWV0IHJldmlld2VkIHRoYXQgZG9jdW1lbnQgYW5kIHdpbGwgZG8gc28gdG8gcGFzcyB0 aGUgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgb2YgdGhhdCBkb2N1bWVudC4gQXMgYSByZW1pbmRl ciwgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaW4gU1BSSU5HIHRoYXQgaXMgdGhl biByZWFsaXplZCB1c2luZyBwcm90b2NvbCBleHRlbnNpb25zL21lY2hhbmlzbXMgdGhhdCBhcmUg c3BlY2lmaWVkIGluIHRoZWlyIHJlc3BlY3RpdmUgV0cgZG9jdW1lbnRzLg0KDQpbUm9tYW5dIFVu ZGVyc3Rvb2QgdGhhdCB0aGUgV0cgY29uc2lkZXJzIHRoaXMgYW4gYXJjaGl0ZWN0dXJlIGRvY3Vt ZW50LCBob3dldmVyLCBpdCBpcyBiZWluZyBwdWJsaXNoZWQgYXMgcHJvcG9zZWQgc3RhbmRhcmQu ICBGb3IgdGhhdCByZWFzb24sIEnigJltIG1ha2luZyB0aGVzZSBwYXJ0aWN1bGFyIGNvbW1lbnRz IGFib3V0IGV4cGxpY2l0bHkgcmVmZXJlbmNpbmcgdGhlIGV4cGVjdGVkIG5vcm1hdGl2ZSBiZWhh dmlvci4NCg0KKiogU2VjdGlvbiAyLjYuDQogIENhbmRpZGF0ZSBwYXRocyBNQVkgYWxzbyBiZSBh c3NpZ25lZCBvciBzaWduYWxlZCB3aXRoIGEgc3ltYm9saWMgbmFtZQ0KICAgY29tcHJpc2luZyBw cmludGFibGUgQVNDSUkgW1JGQzAwMjBdIFtSRkM1MjM0XSBjaGFyYWN0ZXJzDQoNCkhvdyB0aGVz ZSBjYW5kaWRhdGUgcGF0aHMgbmFtZXMgYXJlIHNpZ25hbGVkIGlzbuKAmXQgZGVmaW5lZC4gIEkg YmVsaWV2ZSBpdCBpcw0KcGVyIFNlY3Rpb24gNS4yLjMgb2YgZHJhZnQtaWV0Zi1wY2Utc2VnbWVu dC1yb3V0aW5nLXBvbGljeS1jcCBhbmQgU2VjdGlvbiAyLjQuNw0Kb2YgZHJhZnQtaWV0Zi1pZHIt c2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS4NCg0KKiogU2VjdGlvbiAyLjcuICBIb3cgaXMgdGhl IGNhbmRpZGF0ZSBwYXRoIHByZWZlcmVuY2Ugc2lnbmFsZWQ/ICBJcyB0aGF0DQpkcmFmdC1pZXRm LWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5LTE0I3NlY3Rpb24tMi40LjEgYW5kDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaWRyLXNlZ21lbnQt cm91dGluZy10ZS1wb2xpY3ktMTQjc2VjdGlvbi0yLjQuMT8NCg0KS1Q+IFRob3NlIHByb3RvY29s IHNwZWNzIG5vcm1hdGl2ZWx5IHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQuIFlvdXIgdW5kZXJzdGFu ZGluZyBpcyBjb3JyZWN0IGFib3V0IHRoZSBwYXJ0cyBvZiB0aG9zZSBkb2N1bWVudHMuDQoNCltS b21hbl0gU3BlY2lmaWNhbGx5IGFib3V0IFNlY3Rpb24gMi42IGFuZCAyLjcsIHRoYW5rcyBmb3Ig Y29uZmlybWluZyB0aGF0IEkgcmVhZCB0aGUgb3RoZXIgZG9jdW1lbnRzIGNvcnJlY3RseS4gIElz IHRoZXJlIGEgcmVhc29uIHRoZSB0ZXh0IGRvZXNu4oCZdCBleHBsaWNpdGx5IHJlZmVyZW5jZSB0 aGlzIHJlbGV2YW50IHRoZSBub3JtYXRpdmUgYmVoYXZpb3I/DQoNCg0KVGhhbmtzLA0KUm9tYW4N Cg== --_000_BN2P110MB11079F79FFFE6B5FF972BDADDC139BN2P110MB1107NAMP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBLZXRhbiE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gY2xpcHBpbmcg dGhlIHRleHQgYSBiaXQgdG8gbWFrZSBpdCByZWFkYWJsZSDigKY8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgRmViIDE3LCAyMDIyIGF0IDg6MzggUE0gS2V0YW4gVGFsYXVsaWthciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtldGFudC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtldGFudC5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSb21hbiw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBy ZXZpZXcgYW5kIGNvbW1lbnRzL2lucHV0cy4gUGxlYXNlIGNoZWNrIGlubGluZSBiZWxvdyBmb3Ig cmVzcG9uc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFRodSwgRmViIDE3LCAyMDIyIGF0IDM6MzYgQU0gUm9tYW4gRGFueWxpdyB2 aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9tYW4gRGFueWxp dyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFm dC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTE3OiBEaXNjdXNzPGJyPg0KPGJy Pg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsPGJyPg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+DQppbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2UgcmVmZXIgdG8gPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYmxvZy9oYW5kbGluZy1pZXNnLWJhbGxvdC1wb3NpdGlv bnMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9ibG9nL2hhbmRsaW5n LWllc2ctYmFsbG90LXBvc2l0aW9ucy88L2E+PGJyPg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgaG93IHRvIGhhbmRsZSBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQo8YnI+ DQo8YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNw cmluZy1zZWdtZW50LXJvdXRpbmctcG9saWN5LzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KRElTQ1VTUzo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0K VGhlcmUgYXBwZWFyIHRvIGJlIGEgZmV3IHBsYWNlcyB3aGVyZSBhZGRpdGlvbmFsIHBvaW50ZXJz IG9yIHNwZWNpZmljYXRpb24gaXM8YnI+DQpuZWVkZWQgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxp dHkuPGJyPg0KPGJyPg0KKiogU2VjdGlvbiAyLjU8YnI+DQombmJzcDsgJm5ic3A7V2hlbiBzaWdu YWxpbmcgaXMgdmlhIFBDRVAsIHRoZSBtZXRob2QgdG8gdW5pcXVlbHkgc2lnbmFsIGFuPGJyPg0K Jm5ic3A7ICZuYnNwO2luZGl2aWR1YWwgY2FuZGlkYXRlIHBhdGggYWxvbmcgd2l0aCBpdHMgZGlz Y3JpbWluYXRvciBpcyBkZXNjcmliZWQ8YnI+DQombmJzcDsgJm5ic3A7aW4gW0ktRC5pZXRmLXBj ZS1zZWdtZW50LXJvdXRpbmctcG9saWN5LWNwXS48YnI+DQo8YnI+DQpXaGVyZSBpcyB0aGUgZXhw bGFuYXRpb24gb2YgZGlzY3JpbWluYXRvciBpbiB0aGlzIHJlZmVyZW5jZT8mbmJzcDsg4oCcRGlz Y3JpbWluYXRvcuKAnTxicj4NCmFwcGVhcnMgaW4gU2VjdGlvbnMgMy4xLCAzLjIsIDQuMS4yLCBh bmQgNS4yLjIuJm5ic3A7IEluIHRoZSBmaXJzdCB0aHJlZSBzZWN0aW9uIGl0PGJyPg0KaXMgc2lt cGx5IG5hbWVkIGJ1dCBub3QgZXhwbGFpbmVkLiZuYnNwOyBJbiB0aGUgbGFzdCBzZWN0aW9uLCBp dCBpc27igJl0IGV4cGxhaW5lZDxicj4NCmJleW9uZCBiZWluZyBkZWZpbmVkIGFzIDMyLWJpdHMu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5LVCZndDsgSSBoYXZlIG5vdCB5ZXQgcmV2aWV3ZWQgdGhhdCBkb2N1bWVudCBhbmQgd2ls bCBkbyBzbyB0byBwYXNzIHRoZSBjb21tZW50cyB0byB0aGUgYXV0aG9ycyBvZiB0aGF0IGRvY3Vt ZW50LiBBcyBhIHJlbWluZGVyLCB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBpbiBT UFJJTkcgdGhhdCBpcyB0aGVuIHJlYWxpemVkIHVzaW5nIHByb3RvY29sIGV4dGVuc2lvbnMvbWVj aGFuaXNtcyB0aGF0IGFyZQ0KIHNwZWNpZmllZCBpbiB0aGVpciByZXNwZWN0aXZlIFdHIGRvY3Vt ZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1JvbWFuXSBVbmRl cnN0b29kIHRoYXQgdGhlIFdHIGNvbnNpZGVycyB0aGlzIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCwgaG93ZXZlciwgaXQgaXMgYmVpbmcgcHVibGlzaGVkIGFzIHByb3Bvc2VkIHN0YW5kYXJkLiZu YnNwOyBGb3IgdGhhdCByZWFzb24sIEnigJltIG1ha2luZyB0aGVzZSBwYXJ0aWN1bGFyIGNvbW1l bnRzIGFib3V0IGV4cGxpY2l0bHkgcmVmZXJlbmNpbmcgdGhlIGV4cGVjdGVkIG5vcm1hdGl2ZSBi ZWhhdmlvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCioqIFNlY3Rpb24gMi42Ljxicj4NCiZuYnNwOyBDYW5kaWRhdGUgcGF0 aHMgTUFZIGFsc28gYmUgYXNzaWduZWQgb3Igc2lnbmFsZWQgd2l0aCBhIHN5bWJvbGljIG5hbWU8 YnI+DQombmJzcDsgJm5ic3A7Y29tcHJpc2luZyBwcmludGFibGUgQVNDSUkgW1JGQzAwMjBdIFtS RkM1MjM0XSBjaGFyYWN0ZXJzPGJyPg0KPGJyPg0KSG93IHRoZXNlIGNhbmRpZGF0ZSBwYXRocyBu YW1lcyBhcmUgc2lnbmFsZWQgaXNu4oCZdCBkZWZpbmVkLiZuYnNwOyBJIGJlbGlldmUgaXQgaXM8 YnI+DQpwZXIgU2VjdGlvbiA1LjIuMyBvZiBkcmFmdC1pZXRmLXBjZS1zZWdtZW50LXJvdXRpbmct cG9saWN5LWNwIGFuZCBTZWN0aW9uIDIuNC43PGJyPg0Kb2YgZHJhZnQtaWV0Zi1pZHItc2VnbWVu dC1yb3V0aW5nLXRlLXBvbGljeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQoqKiBTZWN0aW9uIDIuNy4m bmJzcDsgSG93IGlzIHRoZSBjYW5kaWRhdGUgcGF0aCBwcmVmZXJlbmNlIHNpZ25hbGVkPyZuYnNw OyBJcyB0aGF0PGJyPg0KZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS0x NCNzZWN0aW9uLTIuNC4xIGFuZDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pZHItc2VnbWVudC1yb3V0aW5nLXRlLXBvbGljeS0x NCNzZWN0aW9uLTIuNC4xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWlkci1zZWdtZW50LXJvdXRpbmctdGUtcG9saWN5LTE0 I3NlY3Rpb24tMi40LjE8L2E+PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S1QmZ3Q7IFRob3NlIHByb3RvY29sIHNwZWNzIG5vcm1h dGl2ZWx5IHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQuIFlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3Jy ZWN0IGFib3V0IHRoZSBwYXJ0cyBvZiB0aG9zZSBkb2N1bWVudHMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltSb21hbl0g U3BlY2lmaWNhbGx5IGFib3V0IFNlY3Rpb24gMi42IGFuZCAyLjcsIHRoYW5rcyBmb3IgY29uZmly bWluZyB0aGF0IEkgcmVhZCB0aGUgb3RoZXIgZG9jdW1lbnRzIGNvcnJlY3RseS4mbmJzcDsgSXMg dGhlcmUgYSByZWFzb24gdGhlIHRleHQgZG9lc27igJl0IGV4cGxpY2l0bHkgcmVmZXJlbmNlIHRo aXMgcmVsZXZhbnQgdGhlIG5vcm1hdGl2ZSBiZWhhdmlvcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9t YW48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BN2P110MB11079F79FFFE6B5FF972BDADDC139BN2P110MB1107NAMP_-- From nobody Thu Mar 17 22:50:06 2022 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 289683A1889; Thu, 17 Mar 2022 22:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 n45YABsstA3t; Thu, 17 Mar 2022 22:49:52 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 518A23A1887; Thu, 17 Mar 2022 22:49:52 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id i63so3211581vsi.5; Thu, 17 Mar 2022 22:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zukKU7sUMqQ69JBy16O0esZn7CbCe1CdW0QIsPYKEuo=; b=crk+pSnU78KjvoxyQPuXFWeMXNigfGDC5gQy4RNMlg8e9Za0hLIgiJnoaT5Nh/GJw/ w6hmBO4YZEzSwZ08ccmAQ1UiZ36XjMCBSY5LuVI7QuPqczJ0+BCxOcLuDf7vtM3EOf6N jqe0VmU7Mu0HInZx016MQDPe4X6soeqvLVPJt4q6tuCLLlHq/9nZHH9f7f2YAiFKC5wB Do5cnk08pkP2seSulh08eoGFf1ll2T2vpYLASXwHupZWqTmStv+3CYW2keg7EIONMbjD TTT8rv09pQDikDnmotOBbPtbzIVIPj6iUMu7yeVlh5nLowsRXE0opH67g8R4cRWdi+YB Yb0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zukKU7sUMqQ69JBy16O0esZn7CbCe1CdW0QIsPYKEuo=; b=qzCwOdVZFdstEEQU5bmLKWPWBb8vkcZgd/NFLh2CbeptJteMhWROJIEV2XyTwsClGv IHjmtjJhtJ8CzuwXJ5WNVvAN2wqg4M87/aXSGdUylLWY2d5yuqgdUTjdw9R3Zd/yFDJi kKL5VtJmePzQzTGePAxzICqkCr5iiu/tS2veLryR9/nxeBJHEyMJRSGj4/lUitJt7SBY IpXKUesBtGmU4N/XSsTTXhpB+X9FBcmBG8nzwmLJYqSOWizgHTaSNCIVsW72SRtTRG7Y RR4fHXZ4m8rDSO/S/uGE7Wiy0JHOgrMK30Cjc8fZCfnnJhj/6HbnmnkpqoHodwWu+r59 1z0Q== X-Gm-Message-State: AOAM530O2wejvewgVGoNbA1sxhHbO6FhphY42IXbZ85QPM2gz4uxXd9F Y64S0C9YImaB1AVQfzvjYqjqG1J+1cvcYD+EydDTm1jq X-Google-Smtp-Source: ABdhPJxwzOXU1nMIOZ5LrGJt5Uh7BNGlbk9qGws5wEX45NvHYNCpS2P7cbI25UALOBuSSR4tw7LT6SBJKvQNknHiE2E= X-Received: by 2002:a05:6102:284a:b0:31e:c455:5dee with SMTP id az10-20020a056102284a00b0031ec4555deemr2916035vsb.27.1647582590784; Thu, 17 Mar 2022 22:49:50 -0700 (PDT) MIME-Version: 1.0 References: <164504916365.5606.17077981996669554325@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Fri, 18 Mar 2022 11:19:38 +0530 Message-ID: To: Roman Danyliw Cc: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Content-Type: multipart/alternative; boundary="0000000000000fd6a505da77b7b0" Archived-At: Subject: Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (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 Mar 2022 05:50:00 -0000 --0000000000000fd6a505da77b7b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, My understanding is that you would like us to put references to the relevant BGP and PCEP documents in sections 2.6 (CP name) and 2.7 (Preference). Can you please confirm so we can include those changes in the next update (once submission re-opens)? Thanks, Ketan On Fri, Mar 18, 2022 at 6:33 AM Roman Danyliw wrote: > Hi Ketan! > > > > I=E2=80=99m clipping the text a bit to make it readable =E2=80=A6 > > > > > > On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar > wrote: > > Hi Roman, > > > > Thanks for your review and comments/inputs. Please check inline below for > responses. > > > > > > On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker < > noreply@ietf.org> wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > There appear to be a few places where additional pointers or specificatio= n > is > needed to ensure interoperability. > > ** Section 2.5 > When signaling is via PCEP, the method to uniquely signal an > individual candidate path along with its discriminator is described > in [I-D.ietf-pce-segment-routing-policy-cp]. > > Where is the explanation of discriminator in this reference? > =E2=80=9CDiscriminator=E2=80=9D > appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three > section it > is simply named but not explained. In the last section, it isn=E2=80=99t= explained > beyond being defined as 32-bits. > > > > KT> I have not yet reviewed that document and will do so to pass the > comments to the authors of that document. As a reminder, this is an > architecture document in SPRING that is then realized using protocol > extensions/mechanisms that are specified in their respective WG documents= . > > > > [Roman] Understood that the WG considers this an architecture document, > however, it is being published as proposed standard. For that reason, I= =E2=80=99m > making these particular comments about explicitly referencing the expecte= d > normative behavior. > > > ** Section 2.6. > Candidate paths MAY also be assigned or signaled with a symbolic name > comprising printable ASCII [RFC0020] [RFC5234] characters > > How these candidate paths names are signaled isn=E2=80=99t defined. I be= lieve it > is > per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section > 2.4.7 > of draft-ietf-idr-segment-routing-te-policy. > > > ** Section 2.7. How is the candidate path preference signaled? Is that > draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-p= olicy-14#section-2.4.1 > ? > > > > KT> Those protocol specs normatively refer to this document. Your > understanding is correct about the parts of those documents. > > > > [Roman] Specifically about Section 2.6 and 2.7, thanks for confirming tha= t > I read the other documents correctly. Is there a reason the text doesn= =E2=80=99t > explicitly reference this relevant the normative behavior? > > > > > Thanks, > > Roman > > --0000000000000fd6a505da77b7b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

My understanding is that you = would like us to put references to the relevant BGP and PCEP documents in s= ections 2.6 (CP name) and 2.7 (Preference).=C2=A0

= Can you please confirm so we can include those changes in the next update (= once submission re-opens)?

Thanks,
Ketan=


On Fri, Mar 18, 2022 at 6:33 AM Roman Danyliw <rdd@cert.org> wrote:

Hi Ketan!

=C2=A0

I=E2=80=99m clipping the text a bit to make it reada= ble =E2=80=A6

=C2=A0

=C2=A0

On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar <= ;ketant.ietf@gma= il.com> wrote:

Hi Roman,

=C2=A0

Thanks for your review and comments/inputs. Please c= heck inline below for responses.

=C2=A0

=C2=A0

On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Da= tatracker <noreply= @ietf.org> wrote:

Roman Danyliw has entered the following ballot posit= ion for
draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There appear to be a few places where additional pointers or specification = is
needed to ensure interoperability.

** Section 2.5
=C2=A0 =C2=A0When signaling is via PCEP, the method to uniquely signal an =C2=A0 =C2=A0individual candidate path along with its discriminator is desc= ribed
=C2=A0 =C2=A0in [I-D.ietf-pce-segment-routing-policy-cp].

Where is the explanation of discriminator in this reference?=C2=A0 =E2=80= =9CDiscriminator=E2=80=9D
appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.=C2=A0 In the first three se= ction it
is simply named but not explained.=C2=A0 In the last section, it isn=E2=80= =99t explained
beyond being defined as 32-bits.

=C2=A0

KT> I have not yet reviewed that document and wil= l do so to pass the comments to the authors of that document. As a reminder= , this is an architecture document in SPRING that is then realized using pr= otocol extensions/mechanisms that are specified in their respective WG documents.

=C2=A0

[Roman] Understood that the WG considers this an arc= hitecture document, however, it is being published as proposed standard.=C2= =A0 For that reason, I=E2=80=99m making these particular comments about exp= licitly referencing the expected normative behavior.


** Section 2.6.
=C2=A0 Candidate paths MAY also be assigned or signaled with a symbolic nam= e
=C2=A0 =C2=A0comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn=E2=80=99t defined.=C2=A0 I= believe it is
per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2= .4.7
of draft-ietf-idr-segment-routing-te-policy.=C2=A0


** Section 2.7.=C2=A0 How is the candidate path preference signaled?=C2=A0 = Is that
draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and
https://datatracker.ietf= .org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1= ?

=C2=A0

KT> Those protocol specs normatively refer to thi= s document. Your understanding is correct about the parts of those document= s.=C2=A0

=C2=A0

[Roman] Specifically about Section 2.6 and 2.7, than= ks for confirming that I read the other documents correctly.=C2=A0 Is there= a reason the text doesn=E2=80=99t explicitly reference this relevant the n= ormative behavior?

=C2=A0


Thanks,

Roman

--0000000000000fd6a505da77b7b0-- From nobody Sat Mar 19 12:24:40 2022 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 40EEA3A0EAD; Sat, 19 Mar 2022 12:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 rnjKJpXVJCmR; Sat, 19 Mar 2022 12:24:31 -0700 (PDT) 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 57BED3A0E71; Sat, 19 Mar 2022 12:24:28 -0700 (PDT) Received: from mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22JJOGrq015236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 19 Mar 2022 15:24:22 -0400 Date: Sat, 19 Mar 2022 12:24:16 -0700 From: Benjamin Kaduk To: Ketan Talaulikar Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Message-ID: <20220319192416.GH13021@mit.edu> References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> <20220225020227.GM12881@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sat, 19 Mar 2022 19:24:38 -0000 Hi Ketan, My apologies for the slow reply, there are quite a few things for me to wrap up before my term as AD ends. As you put it in your graceful note off-list, we are very close. More inline... On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote: > Hi Ben, > > Thanks for your response and please check inline below with KT2 > > We've also just posted another update to address some of your comments and > those from other ADs. > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19 > > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk wrote: > > > Hi Ketan, > > > > Thanks for the replies here and the updates in the -18. > > I think there are still some open topics, though; more inline. > > > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote: > > > Hi Ben, > > > > > > Thanks for your detailed review and your comments/inputs. Please check > > > inline for responses. > > > > > > > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > > > noreply@ietf.org> wrote: > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions/ > > > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > (1) I may just be misunderstanding things, but I'd like to pull on a > > thread > > > > in §8.4 a bit more. We say that the headend H learns a BGP route that > > has > > > > a > > > > VPN label V, but then the following procedures seem to say that we > > install > > > > a > > > > route on the appropriate SR Policy P and that when we receive a packet > > that > > > > matches the route in question, push a label stack including the VPN > > label, > > > > and send the resulting packet out. > > > > > > > > > KT> Note that we are sending the packet to the selected BGP NH (i.e. > > egress > > > PE) that advertised the route. The SR Policy is enabling the packets to > > > traverse a path that is different from (perhaps) the best-effort IGP > > > routing. > > > > > > > > > > Nowhere do we say to check the VPN > > > > status of the incoming packet, > > > > > > > > > KT> That is the ingress part of the forwarding entry which maps the > > > incoming traffic over a customer interface to their specific VPN context > > > and then performs a lookup in their VPN specific table. This all is > > > unchanged. > > > > > > > > > > so this seems like it would open a hole in > > > > the VPN by allowing "arbitrary" incoming traffic (not marked as > > specific to > > > > V) to enter that VPN. Is the label V filling some other role than > > > > identifying a specific VPN of many VPNs that could run along the route > > R/r? > > > > (This is the only instance of the phrase "VPN label" in the document, > > and > > > > no > > > > reference is given, so I'm relying heavily on instinct to ascertain the > > > > intent here.) > > > > > > > > > > KT> I hope my responses clarified that the only thing that is changed > > here > > > by the steering over the SR Policy is the path taken through the network > > to > > > get to the egress PE. Rest is as today. And yes, of course, we have the > > > ability to indicate the need for such steering via the matching Color > > > Extended community to the BGP route. > > > > Yes, these help clarify that the part we're focusing on in this document is > > conceptually "after" the determination of the incoming VPN, and so there > > isn't any new processing needed for it. Thanks for the explanation. > > > > > > > > > > > > > (2) The security considerations says that this document does not > > define any > > > > new protocol extensions and (accordingly) does not introduce any > > further > > > > security considerations. The first part of this seems false, not least > > > > since we define the meaning of the "CO" bits in the Color Extended > > > > Community. I'm pretty sure that makes the second part also false, and > > we > > > > need to discuss the security considerations relating to imposing SR > > > > Policies > > > > based only on color and not next-hop. Alvaro has also noted additional > > > > aspects where security considerations are missing. > > > > > > > > > > KT> Ack. We will add text in the security consideration sections for the > > CO > > > steering modes. > > > > What about the SR-DB concept and other new concepts that Alvaro identified? > > Aren't there security and manageability considerations there as well? > > > > KT2> We've just added text for the endpoint uniqueness and steering > aspects. The SRDB is internal to the computation node and the information > within it is derived from existing routing protocols and their extensions - > we are not adding anything new to it. Do let me know, however, if you feel > we are missing something. I see that Alvaro has cleared his Discuss, so I am willing to consider this topic closed. I did not think very hard about whether there is anything missing, so accordingly I don't have anything to propose adding. > > > > > > > > > > > > (3) The Discriminator as defined in §2.5 does not seem wide enough to > > be > > > > able to provide the needed properties. Some later clarification in > > §2.6 > > > > implies that the definition in §2.5 is incomplete and the width is > > actually > > > > appropriate, but in either case §2.5 seems inadequate in its current > > form. > > > > (Details in the COMMENT.) > > > > > > > > > > KT> 32 bit is wide enough and please see further response below. > > > > I think I'm still failing to understand exactly why; more below. > > > > > > > > > > (4) Section 2.11 contains the statement, "A valid SR Policy is > > instantiated > > > > in the forwarding plane." > > > > > > > > Is this a statement of fact (i.e., a consequence of the definition of > > > > "valid") or a mandate for something (e.g., the headend) to take action > > to > > > > make it so? Given that the point of SR is to be stateless on nodes > > other > > > > than the headend, I suspect the former, but if we are relying on the > > > > headend > > > > (or some other entity) to take action to ensure this is the case, that > > > > needs > > > > to be a clearly stated normative requirement. > > > > > > > > > > KT> The validity of a candidate path and as an extension, the SR Policy > > is > > > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its > > > constructs are instantiated in the forwarding plane. > > > > Would it make sense to say something like "In order to be considered valid, > > an SR policy needs to be instantiated in the forwarding plane (Section 5)"? > > > > KT2> The SR Policy may be valid, but could not be instantiated into the > forwarding due to a resource issue. We are simply stating here that > generally only a valid SR Policy is instantiated in the forwarding plane. > We don't have the "only" here since we have use-cases as in section 8.2 > where we do have to instantiate a "drop" entry in the forwarding for an > invalid SR Policy. Thanks for helping me understand the scenarios here. A few more alternative proposals: "A valid SR policy is instantiated in the forwarding plane by the headend." "A valid SR policy is generally instantiated in the forwarding plane." "Generally, only valid SR policies are instantiated in the forwarding plane." Feel free to use any of those, a modified version thereof, or leave it unchanged (though I would prefer to make some form of clarification, I do not plan to ask my successor to take up this as a Discuss point when my term ends in a few days). > > > > > > > > > > > > > > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." > > > > There's nothing in the IANA registry for SAFI > > > > (https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml) > > > > about > > > > LISP, and RFC 6830 doesn't talk about SAFI. What is this referring to? > > > > > > > > > > KT> Ack - there is no SAFI in LISP and the reference was meant to be for > > > routing of both IPv4 and IPv6 packets with LISP. Will fix this. > > > > The new text is still a bit terse/opaque for me to be confident that I > > understand properly, but I will drop the discuss point as I think I see how > > it works. > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > There's a lot of this document that feels like just some informational > > > > discussion of "here are some things that many people do", "here are > > some > > > > possible things you can do with SR", etc.. There are also a small > > handful > > > > of places in the document that look to actually be specifying parts of > > > > protocol behavior (I suspect that John has already identified them in > > his > > > > enumeration), and the overall impression ends up being a bit jumbled, > > > > like there are a bunch of topics stuck together without an overarching > > > > theme. > > > > I think the overall content would be more valuable if divided into a > > tight > > > > "protocol specification" portion that could stay at proposed standard, > > plus > > > > an informational "architecture details" document that contains the > > > > in-depth exposition that didn't make it into 8402. > > > > > > > > This draft would benefit greatly from a terminology section. I note > > in the > > > > section-by-section comments several places where a term is first used > > > > without sufficient background/definition, leaving the matter at hand > > > > underspecified for the reader. > > > > > > > > Section 2 > > > > > > > > An SR Policy is a framework that enables the instantiation of an > > > > ordered list of segments on a node for implementing a source routing > > > > > > > > Really, an SR policy is a *framework*? I thought an SR policy was a > > > > specific instantiation of a list of segments, or at least that's what > > I'm > > > > getting from RFC 8402. Perhaps we should say that the general concept > > of > > > > SR > > > > Policy provides a framework? > > > > > > > > > > KT> Ack. Will rephrase. > > > > > > > > > > > > > > Section 2.1 > > > > > > > > An SR Policy MUST be identified through the tuple > > > endpoint>. In the context of a specific headend, an SR policy MUST > > > > be identified by the tuple. > > > > > > > > These two MUSTs appear to be in (nominal) conflict. Maybe start the > > first > > > > one with "absent further context" or "absent the context of a known > > headend > > > > node"? > > > > > > > > > > KT> It is not "absence of context" but "within the context of a specific > > > headend". > > > > > > > > > > > > > > The headend is the node where the policy is > > instantiated/implemented. > > > > The headend is specified as an IPv4 or IPv6 address and is expected > > > > to be unique in the domain. > > > > > > > > This is the first instance of the word "domain" in this document. I > > > > suggest > > > > using the introduction to introduce what is meant by the word, even if > > just > > > > by reference to RFC 8402. > > > > > > > > > > KT> Ack. It should be SR Domain. > > > > > > > > > > > > > > An implementation MAY allow the assignment of a symbolic name > > > > comprising printable ASCII [RFC0020] characters (i.e. 0x20 to 0x7E) > > > > to an SR Policy to serve as a user-friendly attribute for debugging > > > > and troubleshooting purposes. [...] > > > > > > > > I agree with the other ADs that limiting to US-ASCII is not actually > > > > user-friendly for many users, and that the likelihood of some > > > > implementations not properly enforcing such a limitation to be high. > > > > (Likewise for the other places where symbolic names are admitted.) > > > > > > > > > > KT> Please see the response to the other reviews on this point. > > > > I don't find them compelling, but this is just the COMMENT section so > > you're not obligated to persuade me. > > > > > > > > > > > > > Section 2.2 > > > > > > > > A dynamic candidate path expresses an optimization objective and a > > > > set of constraints. [...] > > > > > > > > Down in §5.2 when we discuss validation procedures for dynamic > > candidate > > > > paths, we say that the optimization problem is solved "for either the > > > > SR-MPLS or the SRv6 data-plane as specified". Does the data plane > > need to > > > > be specified as part of the dynamic candidate path itself? > > > > > > > > > > KT> Yes. > > > > Should we say that here, e.g., "a dynamic candidate path expresses an > > optimization objective and a set of constraints within a specified data > > plane"? > > > > KT2> Ack. Have clarified this in the text. > > > > > > > > > > > > > > > Section 2.3 > > > > > > > > in Section 2.9. The table below specifies the RECOMMENDED default > > > > values of Protocol-Origin: > > > > > > > > I feel like it would be useful to provide some justification for why > > the > > > > recommended default behavior prefers BGP SR configuration over PCEP, > > even > > > > if > > > > that justification is just "we need to have a clear ordering and this > > one > > > > is > > > > arbitrary". > > > > > > > > > > KT> Ack. Will clarify that. > > > > > > > > > > > > > > Section 2.4 > > > > > > > > o Node Address : represented as a 128-bit value. IPv4 addresses > > > > MUST be encoded in the lowest 32 bits, and the high-order bits > > > > MUST be set to zero. > > > > > > > > Its application in the candidate path selection is described in > > > > Section 2.9. > > > > > > > > The tie-breaker procedure for path selection described in §2.9 seems to > > > > always prefer IPv4 originators over IPv6 ones (by virtue of preferring > > the > > > > smaller value). I guess if we wanted to change that to prefer IPv6 we > > have > > > > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped > > unicast) > > > > from BCP 153, but it's a bit hard to justify either of those as > > appropriate > > > > on technical grounds, and since this is just a tie-breaker and the > > > > Preference is explicitly preferred, it seems like this is probably > > "good > > > > enough" as-is. > > > > > > > > > > KT> Ack. As clarified in a recent text update in v17, preference is the > > key > > > parameter really. > > > > > > > > > > > > > > Section 2.5 > > > > > > > > The Discriminator is a 32-bit value associated with a candidate path > > > > that uniquely identifies it within the context of an SR Policy from > > a > > > > specific Protocol-Origin as specified below: > > > > > > > > What are the constraints that underlie the 32-bit requirement here? > > > > It looks like some of the scenarios are going to involve uncoordinated > > > > (random) assignment of these discriminator values (e.g., with the BGP > > > > distribution mechanism, when coming from different BGP peers), and the > > > > birthday-bound collision probability is not negligible for this few > > bits. > > > > That, in turn, calls into question the "uniquely identifies" property > > being > > > > claimed. Or is there some other property that means that only > > > > discriminators from a single issuer will ever need to be compared with > > each > > > > other (making the allocation "coordinated"), such as being additionally > > > > associated with the originator? > > > > If my initial analysis was incorrect and these are indeed allocated in > > a > > > > "coordinated" fashion, would it be typical/expected for the allocation > > to > > > > occur by incrementing a local counter on the originator? In some > > > > situations > > > > such allocation by counter can have security considerations, which > > > > draft-gont-numeric-ids-sec-considerations attempts to cover. > > > > > > > > > > KT> The discriminator is scoped to a particular originating node for the > > > candidate path and as such, there is no requirement for coordination > > across > > > sources/nodes. Therefore, 32-bit is more than sufficient. > > > > When you say "originating node", does that refer to the SR headend, or the > > (BGP) originator of the BGP route containing the SR Policy NLRI? > > > > KT2> The BGP originator as you've correctly understood below. > > > > > > I assume the latter, and agree that *within the context of BGP*, the > > discriminator is scoped to the originating BGP node. But the description > > we give in §2.5 of this document does not say anything about making use of > > such information. As far as I know, the BGP originator information is lost > > when the BGP distinguisher is converted into the SR Policy candidate path > > discriminator data model. > > > KT2> The BGP originator information is not lost. We have clarified this in > the text below in sec 2.5 itself: > > o When signaling is via BGP SR Policy, the BGP process receiving the > route provides the distinguisher (refer to Section 2.1 of > [I-D.ietf-idr-segment-routing-te-policy > ]) > as the discriminator. I think this is trying to cover too much subtlety to be accessible to all readers. Thanks for the pointer to draft-filsfils-spring-sr-policy-considerations below, that seems to help clarify that the intent is that collisions on BGP distinguisher are expected to be resolved within the BGP layer using BGP best-path selection, so that only a single candidate path is received by the SR layer from BGP for a given distinguisher/discriminator, even if the BGP agent on the SR node receives multiple routes that could be candidate paths prior to the BGP bestpath selection. It seems that there are a number of ways that we could modify this document to clarify; let me list a couple (but these are not intended to be exhaustive): - in this chunk of text, add another sentence like "Note that BGP best path selection is applied before the route is supplied as a candidate path, so only a single candidate path will be seen for a given discriminator." - In the preface at the top of §2.5 before the list of per-Protocol-Origin discussions, add a note that "each Protocol-Origin is expected to apply any processing needed to ensure that only a single candidate path is supplied with a given Discriminiator value" > > > > And we don't say anything about how candidate > > paths for a given SR Policy can only be originated from a single BGP node, > > so I have to account somehow for the possibility that two BGP nodes are > > independently announcing candidate paths for the same SR Policy, and thus > > might collide in their assignment of distinguisher. > > > KT2> You are correct. This can and does indeed happen today in deployments > for redundancy and other reasons. > > > > Whereas BGP can > > resolve that collision via the BP origination information, I don't see how > > that would be done in the SR data model. Does that help you understand > > what part I am missing? > > > > KT2> We did have some text in this document in the early days to explain > these scenarios but it was moved out to an individual draft. Sec 2.9 has a > pointer to this informative draft. Please check > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-08#section-4 > and if they clarify. (As indicated above, they do clarify, but that draft is not referenced here and is not a normative reference, so I must insist on further changes to this document.) > > > > > > > > > > > > > > > > Section 2.8 > > > > > > > > A candidate path is usable when it is valid. A common path validity > > > > criterion is the validity of any of its constituent Segment-Lists. > > > > The validation rules are specified in Section 5. > > > > > > > > This document claims to target Proposed Standard status; are we really > > > > content to say only that this is "a common" criterion? Even when we > > also > > > > go > > > > on to flat-out state "the validation rules are specified [below]"? > > > > > > > > > > KT> We will change this to introduce the word RECOMMENDED. There are > > > deployments where an operator might need a local policy to declare the > > > candidate path invalid when the number of valid SLs drops below a certain > > > threshold (for b/w or load-balancing considerations). > > > > > > > > > > > > > > Section 2.9 > > > > > > > > The candidate path selection process operates primarily on the > > > > candidate path Preference. A candidate path is selected when it is > > > > valid and it has the highest preference value among all the > > candidate > > > > paths of the SR Policy. > > > > > > > > Should this be "among all the valid candidate paths"? A path that's > > > > invalid > > > > is still invalid, even if it has the highest preference value. > > > > > > > > > > KT> Ack - will clarify this. > > > > > > > > > > > > > > 2. If specified by configuration, prefer the existing installed > > > > path. > > > > > > > > Does "if specified by configuration" refer to the act of applying this > > rule > > > > at all, or that the existing installed path was one specified by > > > > configuration? > > > > > > > > > > KT> The existing installed path. The rationale was that in some > > deployment > > > designs an operator may not want to disturb/churn an active and > > > valid/working path that has been installed in the forwarding. > > > > > > > > > > > > > > Section 2.11 > > > > > > > > The fraction of the flows associated with a given Segment-List is w/ > > > > Sw, where w is the weight of the Segment-List and Sw is the sum of > > > > the weights of the Segment-Lists of the selected path of the SR > > > > Policy. > > > > > > > > Thank you for stating this clearly! > > > > > > > > Section 3 > > > > > > > > o TE Link Attributes (such as TE metric, Shared Risk Link Groups, > > > > attribute-flag, extended admin group) [RFC5305] [RFC3630]. > > > > > > > > Is RFC 5329 applicable here as well? > > > > > > > > > > KT> Yes, will add that. Thanks. > > > > (It looks like a second 3630 reference got added in the -18, not 5329; I'll > > mention that in my updated ballot remarks as well.) > > > > KT2> Ooops :-( .. now fixed for real > > > > > > > > > > > > > > > Section 4 > > > > > > > > Type E: IPv4 Prefix with Local Interface ID: > > > > This type allows identification of Adjacency SID or BGP Peer > > > > Adjacency SID (as defined in [RFC8402]) SR-MPLS label for > > > > point-to-point links including IP unnumbered links. The > > > > headend is required to resolve the specified IPv4 Prefix > > > > Address to the Node originating it and then use the Local > > > > Interface ID to identify the point-to-point link whose > > > > adjacency is being referred to. The Local Interface ID link > > > > descriptor follows semantics as specified in [RFC7752]. This > > > > > > > > The phrase "local interface ID" does not appear in RFC 7752 (and even > > > > "local > > > > interface" appears just once"; please use terminology actually present > > in > > > > the referred-to document to clarify what is being referenced. > > > > > > > > > > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn > > > references RFC5307 which in turn RFC4202. We use RFC7752 since it covers > > > and explains the use of the various link descriptors that we use for > > > various segment types. > > > > > > > > > > > > > > Section 4.1 > > > > > > > > When steering unlabeled IPv6 BGP destination traffic using an SR > > > > policy composed of Segment-List(s) based on IPv4 SIDs, the Explicit > > > > Null Label Policy is processed as specified in > > > > [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When an > > > > > > > > It looks like this is §2.4.5, not 2.4.4, in the referenced document. > > > > > > > > > > KT> Ack. Will fix. > > > > > > > > > > > > > > Section 5.1 > > > > > > > > The computation/logic that leads to the choice of the Segment-List > > is > > > > external to the SR Policy headend. The SR Policy headend does not > > > > compute the Segment-List. The SR Policy headend only confirms its > > > > validity. > > > > > > > > Does the headend actually have to confirm validity? Is it okay to just > > > > trust the controller and blindly use what is provided? > > > > > > > > > > KT> At least the first segment needs to be validated from a resolvability > > > perspective. The subsequent segments depend on how (i.e., using what > > > segment types) the controller has signalled the path to the headend. If > > it > > > is indicated by just referring to a Prefix (e.g. loopback) of a node, > > then > > > the headend will need to resolve and as such validate. While if specified > > > as a label, then no resolution is required. > > > > Hmm. So maybe we could say "the SR Policy headend only confirms the > > validity of any segments that it needs to resolve as part of packet > > processing"? Or does that not actually convey the needed information? > > > > KT2> IMHO, the term used in the draft "path resolution to the SID" is more > informative and cleared (at least to someone working on the programming of > forwarding entries) than "packet processing". Okay, I am happy to defer to your domain expertise. > > > > > > > > > > > > > > Section 6.2 > > > > > > > > When the active candidate path has a specified BSID, the SR Policy > > > > uses that BSID if this value (label in MPLS, IPv6 address in SRv6) > > is > > > > available (i.e., not associated with any other usage: e.g. to > > another > > > > MPLS client, to another SRv6 client, to another SID, to another SR > > > > Policy, outside the range of SRv6 Locators). > > > > > > > > I don't think I understand what is meant by "client" here (for "another > > > > client"). This sentence is the only place where the word "client" > > appears > > > > in this document... > > > > > > > > > > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be IS-IS > > > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label from a > > > "label manager" within the router. > > > > I think this explanation actually makes me more concerned about the way > > this is written than I previously was. It seems to imply that we are > > trying to describe both that there is an MPLS vs SRv6 data-plane in use and > > that the node in question is a client of some unspecified protocol that can > > allocate SIDs/MPLS labels, which could be as varied as an IGP or a > > dedicated path computation protocol. Furthermore, not all of these > > possible protocols would intrinsically provide for arbitrary headend nodes > > to even know if the label/SID in question has already been allocated to > > another "client"! > > > > Is the determination of availability to be made by the controller or by the > > headend? > > > KT2> This is local on the headend. > > > > I think we should state that clearly, since (given the above > > discussion) it seems like it is the controller that is best place to > > actually make the determination, but the phrasing "the SR Policy uses" > > implies (at least to me) that the determination is made on the headend, > > since it is the headend that actually instantiates the policy. > > > > KT2> The controller can (and does in some of the deployments that I am > aware of) keep track of the usage of the Labels in the SRGB and SRLB (refer > RFC8402). The same goes for SRv6 SIDs from under the SRv6 Locator. In > deployments where controllers do drive the whole SR Policy provisioning, > they do keep track. However, this is not mandatory in general. The headend > is taking care of the actual programming into the forwarding and doesn't > have any option but to handle these conditions. Okay. I might consider coalescing "to another MPLS client, to another SRv6 client" down to "to another node in the SR domain" since it's not worth adding enough detail to fully clarify "MPLS client" and "SRv6 client", but it's up to you. > > > > > > > > > > > > > > Optionally, instead of only checking that the BSID of the active > > path > > > > is available, a headend MAY check that it is available within a > > given > > > > SID range i.e., Segment Routing Local Block (SRLB) as specified in > > > > [RFC8402]. > > > > > > > > Is the only allowed range to check the SRLB? If not, I think we need > > to > > > > s/i.e./e.g./. > > > > > > > > > > KT> Yes, SRLB is the one to check/allocate from for such usage. > > > > Okay. I suspect we want s/a given/the given/ then, but am not 100% sure. > > > > KT2> Ack. Fixed. > > > > > > > > > > > > > When the specified BSID is not available (optionally is not in the > > > > SRLB), an alert message MUST be generated. > > > > > > > > This is the first time (of only two) the word "alert" appears in this > > > > document, and there is no prior expalanation of what entity might be > > > > receiving alerts generated by a headend. Please clarify. > > > > > > > > > > KT> Alert mechanism could be one or more of syslog, Netconf > > notification, a > > > telemetry mechanism, etc.. > > > > I think the clarification is best placed in the document itself, e.g., in a > > glossary/terminology section as I suggested in my high-level comments. > > > > KT2> We have clarified inline. > > > > > > > > > > > > > > > Assuming that at time t the BSID of the SR Policy is B1, if at time > > > > t+dt a different candidate path becomes active and this new active > > > > path does not have a specified BSID or its BSID is specified but is > > > > not available (e.g. it is in use by something else), then the SR > > > > Policy MAY keep the previous BSID B1. > > > > > > > > Is there a strict bound on or other guidance for what values of dt are > > > > allowable for this purpose? > > > > > > > > > KT> None > > > > > > > > > > Is the intent that there be an atomic > > > > transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2? > > > > > > > > > > KT> There is no atomicity requirement. A switch from one active CP to > > > another will vary depending on the cause of the switch - e.g. if it is > > due > > > to a failure or because a more preferred path came up. > > > > > > > > > > > > > > The association of an SR Policy with a BSID thus MAY change over the > > > > life of the SR Policy (e.g., upon active path change). Hence, the > > > > BSID SHOULD NOT be used as an identification of an SR Policy. > > > > > > > > Is there any guidance available on how long to wait with a given BSID > > value > > > > unused before binding it to a new SR Policy? > > > > > > > > > > KT> None. These depend on the implementation and scenarios like resource > > > availability e.g., a BSID might get re-used sooner if the system is > > running > > > short of labels. > > > > > > > > > > > > > > Section 6.2.3 > > > > > > > > An implementation MAY support the configuration of the Specified- > > > > BSID-only restrictive behavior on the headend for all SR Policies or > > > > individual SR Policies. Further, this restrictive behavior MAY also > > > > be signaled on a per SR Policy basis to the headend. > > > > > > > > Elsewhere in the document we discuss specific potential signaling > > > > mechanisms/protocols, but here we say nothing. Is that vagueness > > > > intentional? > > > > > > > > > > KT> Since this isn't a protocol specification the mechanism is not > > > described here. However, you can look at > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.2 > > > and that document refers back to this specification. > > > > Okay, but if this document isn't a protocol specification and that's > > grounds to not describe mechanism in it, then there are quite a few other > > places in the document that should also not describe mechanism, if we want > > to be applying the rule consistently. > > > > KT2> There may be very high-level references to some mechanisms in addition > to the informative pointer to the specific protocol spec. This was done to > improve readability. > > > > > > > > > > > > > > > Section 6.3 > > > > > > > > A valid SR Policy installs a BSID-keyed entry in the forwarding > > plane > > > > with the action of steering the packets matching this entry to the > > > > selected path of the SR Policy. > > > > > > > > I don't think this is stated properly. An SR Policy is the list of > > > > segments; it isn't the entity that's installing entries in the > > forwarding > > > > plane. Some other entity is installing an entry in the forwarding > > plane to > > > > realize the SR Policy in question, and we should make our writing > > reflect > > > > that. > > > > > > > > > > KT> Ack. s/installs/results in the installation of > > > > > > > > > > > > > > Section 6.4 > > > > > > > > An implementation MAY choose to associate a Binding SID with any > > type > > > > of interface (e.g. a layer 3 termination of an Optical Circuit) or a > > > > tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE > > > > tunnel, etc). This enables the use of other non-SR enabled > > > > > > > > Should we have some discussion that contrasts this scenario against the > > > > End.X behavior from RFC 8986 (for the "interface" case)? > > > > > > > > > > KT> What this document says is that a BSID may be also associated to > > direct > > > over these other types of interfaces/tunnels. We can look at them as > > having > > > no other segment being imposed but just redirecting to an interface. In > > > that sense, it is somewhat similar to End.X in SRv6 (or Adjacency SID in > > > SR-MPLS). However, those tend to be associated with protocol > > adjacencies. I > > > am not sure that I've followed your point though and please do let me > > know > > > if I've not. > > > > What you write here indicates to me that you got my point. My proposal was > > for a sentence something like "this behavior is analogous to the End.X > > behavior defined in [RFC8986] in that the SID is removed, no new SIDs > > applied, and the packet is directed across a particular interface, but it > > conceptually fits better as a Binding SID since the SID is bound to a > > specific (logical or physical) interface and End.X is typically used with > > protocol adjacencies rather than interfaces". But that's just a > > suggestion, and if you think it doesn't make sense or doesn't add much > > value, please ignore it. > > > > > > > > > > > > > Section 7 > > > > > > > > The SR Policy State is maintained on the headend to represent the > > > > state of the policy and its candidate paths. [...] > > > > > > > > I confess I don't really understand why we need to have the current, > > > > minimal, description of SR Policy State in this document. What would > > be > > > > lost if we deferred its discussion entirely until there is a more > > > > comprehensive discussion available? > > > > > > > > > > KT> We will add an informational pointer to the SR Policy YANG model. > > What > > > this document calls out is the requirement for reporting the operational > > > state and provides pointers to other specs where this is being worked > > out. > > > > > > > > > > > > > > The SR Policy state can be reported by the headend node via BGP-LS > > > > [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and > > > > [I-D.ietf-pce-binding-label-sid]. > > > > > > > > The functionality of draft-ietf-pce-binding-label-sid seems much more > > > > limited than that of draft-ietf-idr-te-lsp-distribution; in > > particular, the > > > > former does not seem to actually report SR Policy state to the headed > > at > > > > all; rather, it only concerns itself with BSID association to path, > > with no > > > > information about "active", "not preferred", etc. > > > > > > > > > > KT> The PCEP work might be spread out over different documents but we do > > > need to cover these requirements. That is one of the objectives of having > > > this document coordinate work across protocol WGs. > > > > It still feels like we're claiming something here that isn't true -- "can > > be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]". It seems > > like we are really trying to say "... via extensions to PCEP [some of which > > don't exist yet in a form that we're willing to reference]". > > > > KT2> This document, like some others in SPRING, does provide informative > references (perhaps still in the WG doc stage) for better readability and > clarity. > > > > > > > > > > > > > Section 8.3 > > > > > > > > If the SR Policy P is invalid, the BSID B is not in the forwarding > > > > plane and hence the packet K is dropped by H. > > > > > > > > We literally just in the previous section talked about a scenario > > where the > > > > BSDI is kept in the forwarding plane (but with the action to drop, so > > the > > > > overall outcome is not changed from what this text describes). > > > > Nonetheless, > > > > it's inaccurate to state that "the BSID B is not in the forwarding > > plane" > > > > here. > > > > > > > > > > KT> There is a difference between the drop being referred to in 8.2 and > > > 8.3. What we have in 8.2 is like a route pointing to null where we may > > > advertise and get packets but will drop it with normal counters > > associated > > > with that specific entry. While 8.3 is like we are dropping because we > > have > > > no route (ideally we shouldn't have got the packet) and we increment a > > > generic lookup failed counter. The use-cases for both are different. > > > > I (think I) understand that the mechanisms are different and both have use > > cases. I just don't think that the specific combination of words used here > > makes a true statement. There are probably a number of ways to make a > > slight > > adjustment and come up with a true statement, such as starting it with a > > caveat as in "When Drop-Upon-Invalid behavior is not in use, for an invalid > > SR Policy P, its BSID B is not in the forwarding plane and hence the packet > > K is dropped by H". > > > > KT2> Thanks for that suggestion. We've incorporated it. > > > > > > > > > > > > > > > Section 8.4.1 > > > > > > > > When a BGP route has multiple Color Extended communities each with a > > > > valid SR Policy, the BGP process installs the route on the SR Policy > > > > giving preference to the color with the highest numerical value. > > > > > > > > Do we want to say anything about this being an arbitrary tiebreaker > > (rather > > > > than an intentional preference), or is that thought to be implicitly > > clear? > > > > > > > > > > KT> It is an intentional preference. > > > > Peeking forward to §8.8.2, is this also referring to the BGP color rather > > than the SR Policy color? If so, please specifically qualify the word > > "color" as being the BGP one. > > > > If not, then I strongly suggest that the introduction of color in §2.1 > > state that the numerical value of the color is used as a preference > > mechanism in addition to indicating intent or objective (with the > > implication or explicit statement that assignment of color values must be > > performed in a manner that is compatible with the operator's > > preference/policy). > > > > KT2> This document needs to refer to the "BGP color" as the "Color Extended > Community". Thanks for catching that. This is not done in a few places and > we've fixed that. Many thanks for those fixes, it is a big help. > > > > > > > > > > > > > > Section 8.5 > > > > > > > > In this section, independent of the a-priori existence of any > > > > explicit candidate path of the SR policy (C, N), it is to be noted > > > > that the BGP process at headend node H triggers the instantiation of > > > > a dynamic candidate path for the SR policy (C, N) as soon as: > > > > > > > > I strongly suggest providing a more explicit framework of what the > > > > assumptions and preconditions are for the mechanism described in this > > > > section. My intuition says that it's a fairly optional thing that > > would > > > > need to be specifically configured, but trying to wrap that sentiment > > into > > > > the long bullet point involving "a local policy" seems like a very > > > > confusing > > > > way to express the desired behavior. > > > > > > > > > > KT> It is actually a matter of local policy with perhaps some template > > and > > > configuration to drive this. I believe this should get covered in the SR > > > Policy YANG model at some point in time. > > > > > > > > > > > > > > Section 8.6 > > > > > > > > o is configured to instantiate an array of paths to N where the > > > > entry 0 is the IGP path to N, color C1 is the first entry and > > > > Color C2 is the second entry. The index into the array is called > > > > a Forwarding Class (FC). The index can have values 0 to 7. > > > > > > > > Why are the only allowed values 0 to 7? Where does this restriction > > arise > > > > from? It is because of some protocol element? > > > > > > > > > > KT> There is text further in the section to indicated that these > > > ranges/values are implementation-specific. Historically, the 8 values > > have > > > come from the MPLS EXP bits. > > > > If the ranges/values are implementation-specific, then don't give a > > specific range here stated as if it is a universal limitation! I would > > either drop the sentence entirely or say something like "when the index is > > conveyed using the MPLS EXP bits, only indices 0 to 7 are usable". > > > > KT2> Ack. Have clarified. > > > > > > > > > > > > > > > If the local configuration does not specify any explicit forwarding > > > > information for an entry of the array, then this entry is filled > > with > > > > the same information as entry 0 (i.e. the IGP shortest path). > > > > > > > > If the SR Policy mapped to an entry of the array becomes invalid, > > > > then this entry is filled with the same information as entry 0. > > When > > > > all the array entries have the same information as entry0, the > > > > forwarding entry for N is updated to bypass the array and point > > > > directly to its outgoing interface and next-hop. > > > > > > > > I can't tell how much of this is supposed to be protocol specification > > and > > > > how much an illustrative example. Is A(0) always the IGP shortest > > path? > > > > Are these protocol requirements to fall back to the IGP shortest path > > when > > > > an entry is otherwise unpopulated or the associated SR Policy becomes > > > > invalid? > > > > > > > > > > KT> The specifics are for illustration purposes. Most of these are policy > > > knobs/options. > > > > Please add a note at the top of the section that "this section provides an > > example of how a headend might apply per-flow steering in practice". > > > > KT2> Ack. Added. > > > > > > > > > > > > > > > Section 8.8.2 > > > > > > > > The steering preference is first based on the highest color value > > and > > > > then CO-dependent for the color. [...] > > > > > > > > This seems to contradict what I assumed earlier about the "highest > > color" > > > > rule being a tiebreaker, e.g., the word "preference" is used here. Is > > it > > > > actually intended to be a deliberately configured priority/preference > > > > scheme? If so, that would seem to require some wide-ranging reworking > > > > throughout the document. > > > > > > > > > > KT> There is the color that is in the identification of an SR Policy - > > > (color, endpoint). This does not get into any tiebreaker or selection > > > logic. All that (sec 2.9) is about the selection of a candidate path > > within > > > an SR Policy. Then there is the color value signaled via the Color > > Extended > > > community on the BGP routes and here, we have the preference for higher > > > color when the route is advertised with multiple colors tagged to it. > > > > I think you should clarify that this section refers to the BGP Color, then > > -- previously in the document it has been the SR Policy color value and an > > unqualified reference to "color value" seems like it refers to the concept > > defined in this document, absent other qualifiers. > > > > KT2> Ack. Fixed references as mentioned in a previous comment. > > > > > > > > > > > > > > > Section 9.3 > > > > > > > > the most appropriate alternative for the active candidate path. A > > > > fast re-route mechanism MAY then be used to trigger sub 50msec > > > > switchover from the active to the backup candidate path in the > > > > forwarding plane. Mechanisms like Bidirectional Forwarding > > Detection > > > > (BFD) MAY be used for fast detection of such failures. > > > > > > > > Why is the specific 50msec value important here? Is there some other > > > > requirement that imposes it? > > > > > > > > > > KT> This comes from "typical" expectations from fast-reroute mechanisms. > > > > I'd consider '''to trigger "fast" (sub 50msec) switchover''', then, but > > it's not very important. > > > > > > > > > > > > > Section 10 > > > > > > > > I think we also want to mention the security considerations of several > > more > > > > documents, including (but not limited to) > > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and 8986. > > > > > > > > > > KT> Ack on the three RFCs, but convinced about the > > > draft-ietf-idr-segment-routing-te-policy since that depends on this and > > not > > > the other way around. > > > > I think this relates to John's Discuss point and whether this document > > specifies the protocol behavior of the two bits in the context of the > > extension defined in draft-ietf-idr-segment-routing-te-policy. You need to > > understand draft-ietf-idr-segment-routing-te-policy in order to understand > > the security considerations relating to the protocol behavior controlled by > > those two bits, and IMO the protocol behavior specified by those two bits > > is solely the responsibility of this document, so this document must > > incorporate the security considerations of > > draft-ietf-idr-segment-routing-te-policy in order to fully document the > > security considerations of the concepts and protocol elements that this > > document defines. > > > > KT2> I am working with John to address his comments. Okay, the changes from -18 to -20 are looking promising, but I will let John decide when it's done. Thanks for all these replies and updates; I didn't respond to them individally but they are all appreciated. -Ben > > > > > > Thanks for this, and all the other parts I didn't specifically reply to. > > > > I will attempt to update my ballot position in the datatracker to remove > > the parts that are fully addressed (though I will probably inadvertently > > leave in something I shouldn't have). > > > > -Ben > > > > > > > > > > > > > Section 15.2 > > > > > > > > I agree with John that draft-ietf-idr-segment-routing-te-policy must be > > > > classified as a normative reference. > > > > > > > > It also seems that RFC 7752 should be classified as normative, as we > > > > incorporate its definition for the semantics of several of the segment > > type > > > > descriptions. > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > NITS > > > > > > > > Section 1 > > > > > > > > Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of > > > > segments (i.e. instructions) that represent a source-routed policy. > > > > > > > > /Segment/A Segment/ > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > The headend node is said to steer a flow into a SR Policy. The > > > > packets steered into an SR Policy carry an ordered list of segments > > > > associated with that SR Policy. [...] > > > > > > > > In a certain sense this can be read as saying that the packets that > > "carry > > > > an ordered list of segments" are the ones prior to being steered into > > an SR > > > > policy, which would make this statement not true. Perhaps we want to > > say > > > > "after being steered into an SR Policy, packets carry an ordered list > > ..."? > > > > (I also went back and forth with myself about whether "packets ... > > carry" > > > > implies in the payload or not. I settled on "not" but make this note > > just > > > > in case I am missing an aspect of that question.) > > > > > > > > > > KT> Ack. Will rephrase. > > > > > > > > > > > > > > Section 2 > > > > > > > > An SR Policy is a framework that enables the instantiation of an > > > > ordered list of segments on a node for implementing a source routing > > > > > > > > It's easy to read this as saying that all of the segments in the list > > > > instantiated on the single node in question, which I assume is not the > > > > intent. Probably the easiest way to aid readability here is to split > > the > > > > sentence up into multiple smaller sentences that are easier to parse. > > > > > > > > > > KT> Will rephrase. > > > > > > > > > > > > > > Section 2.2 > > > > > > > > A dynamic candidate path expresses an optimization objective and a > > > > set of constraints. The headend (potentially with the help of a > > PCE) > > > > computes the solution Segment-List (or set of Segment-Lists) that > > > > solves the optimization problem. > > > > > > > > I'd suggest computes the solution/computes a solution/ for genericity. > > > > > > > > > > KT> Ack. > > > > > > > > > > A stateful PCE might end up computing a path that is not the optimal > > one > > > > for > > > > this specific optimization problem, due to a desire to cooperate with > > other > > > > paths in the network, and the "Min-Metric with margin and maximum > > number of > > > > SIDs" objective in draft-filsfils-spring-sr-policy-considerations > > doesn't > > > > even have a guaranteed unique best solution. > > > > > > > > Section 2.5 > > > > > > > > When provisioning is via configuration, this is an implementation's > > > > configuration model-specific unique identifier for a candidate path. > > > > The default value is 0. > > > > > > > > I'm having a lot of trouble parsing this. Did we perhaps mean to > > hyphenate > > > > as "configuration-model-specific"? > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > Section 2.13 > > > > > > > > The SR Policy POL1 is identified by the tuple > > > endpoint>. It has two candidate paths CP1 and CP2. Each is > > > > identified by a tuple . > > > > > > > > I suggest (for the last sentence) "identified within the scope of POL1" > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > forwarding instantiation of SR policy POL1. Traffic steered on POL1 > > > > is flow-based hashed on Segment-List with a ratio > > > > W1/(W1+W2). > > > > > > > > If I read "ratio" I would instinctively think of the ratio of (traffic > > on > > > > segment list 1)/(traffic on segment list 2), as opposed to the > > proportion > > > > of > > > > all traffic, that would be measured as the indicated W1/(W1+W2). > > > > > > > > > > KT> Ack. s/ratio/proportion > > > > > > > > > > > > > > Section 3 > > > > > > > > The attached domain topology may be learned via IGP, BGP-LS or > > > > NETCONF. > > > > > > > > A non-attached (remote) domain topology may be learned via BGP-LS or > > > > NETCONF. > > > > > > > > I think these are both probably not exhaustive lists, so "e.g." or > > similar > > > > may be appropriate. > > > > > > > > > > KT> Ack. > > > > > > > > > > > > > > Section 4 > > > > > > > > Type C: IPv4 Prefix with optional SR Algorithm: > > > > The headend is required to resolve the specified IPv4 Prefix > > > > Address to the SR-MPLS label corresponding to a Prefix SID > > > > segment (as defined in [RFC8402]). The SR algorithm (refer to > > > > Section 3.1.1 of [RFC8402]) to be used MAY also be provided. > > > > > > > > Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: > > > > In this case, the headend is required to resolve the specified > > > > IPv6 Global Prefix Address to the SR-MPLS label corresponding > > > > to its Prefix SID segment (as defined in [RFC8402]). The SR > > > > Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY > > > > > > > > These are effectively just the IPv4 and IPv6 incarnations of the same > > > > underlying procedure, right? Can't we minimize the diff between the > > > > paragraphs further? > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > Section 5.1 > > > > > > > > Additionally, a Segment-List MAY be declared invalid when: > > > > > > > > We probably want another word here ("both"?), to specify how the two > > > > conditions are combined. > > > > > > > > > > KT> Ack - will rephrase. > > > > > > > > > > > > > > Section 5.2 > > > > > > > > When the local computation is not possible (e.g., a policy's > > tail-end > > > > is outside the topology known to the headend) or not desired, the > > > > headend MAY send path computation request to a PCE supporting PCEP > > > > extension specified in [RFC8664]. > > > > > > > > missing article ("the PCEP extension"). I forget if it should be > > > > "extensions" plural. > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > Section 8.7 > > > > > > > > Finally, headend H MAY be configured with a local routing policy > > > > which overrides any BGP/IGP path and steer a specified packet on an > > > > > > > > singular/plural mismatch -- s/steer/steers/ > > > > > > > > > > KT> Ack. > > > > > > Thanks, > > > Ketan > > > > From nobody Sat Mar 19 20:19:06 2022 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 55EE63A0122; Sat, 19 Mar 2022 20:19:03 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164774634327.16590.9729205391454481759@ietfa.amsl.com> Date: Sat, 19 Mar 2022 20:19:03 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-21.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: Sun, 20 Mar 2022 03:19:04 -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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-21.txt Pages : 40 Date : 2022-03-19 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into a SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC8402 as it details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-21 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Mar 19 20:23:18 2022 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 39AD13A0420; Sat, 19 Mar 2022 20:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 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, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 hFVpIOzJdd5z; Sat, 19 Mar 2022 20:22:56 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 2F9303A0489; Sat, 19 Mar 2022 20:22:56 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id i186so8083158vsc.9; Sat, 19 Mar 2022 20:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y1Y9TO1ubpD3PXLelN7fflvUzlHSsYJt0Q5FhLWxVwk=; b=T9tdWZeZs9RSLExOL4AQKuXDFdkxadRwt1vKSP3EiLpC8D+nkyZWaa1sx2VfxShO7K fH5cHRD5+JTo6p7GcK/PzUpMD0Fuz5F0gHNPUvhhFB966SajLdmV6ioCwhBJPESG7EW+ 2Th7vFzomNFxRiJ6YI/zj/Tow19awLTXeAfdCBzVyDzj2f42ICkpVe374KOkxT/3ijSS jztwhc8nP36kh4J2q9HhLrDvkeelZei3mgLZmFyZtiL4VkNkoyATzXTmaldfAJpbTZJ2 n/ZBulfg/TzkgbZuQbsqr/tWmSHYK+Qoc7XskdbI6pXFMMu81aewqT3Brcj7HslGa/il oawA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y1Y9TO1ubpD3PXLelN7fflvUzlHSsYJt0Q5FhLWxVwk=; b=y6sUm41858/4J4XyTJJnaIDv/ngeNIzWV9aqrpn0mR16mVusBCnLTaPTkKE7GN8CUg SK36EGYKQhC+ihX1wjGyOAPt+ZKvYHziPIOaJGOURwfjPEA0fFPLEdQPrcIaSPG6+DDa /U7l8gIhOfsOgcok1ZicJ3/LjLpqQ/iFzWZmVnu+nRoFzxP0zVj4DrPJg/CVD6itzu5s O6dSH2CBeY/5uqxF4xFGB/INmD6JWScTsgjESSiZu11I4bnNmBf7KoCk/uFj7+4R6d0Z 2EtvpzK6W6e9yZ7gYwCjmtpft8CYGz3ufq8nAdTWYksTjHZ1VdQ96oVs2CbmjixP36Q3 Z0tQ== X-Gm-Message-State: AOAM530f2Hhg0b90ZC7r9hYv+kzlNOVdCBIBBiFP+pXuIU1US83CpB6I wBL6wczcnSb0AkFGZXG56IAwcfuYvmGefEFJrT9U8C5IKdU= X-Google-Smtp-Source: ABdhPJw4Hr5nPzOsVF+5BaCfnJ+CkM9knlwqPK+Lo1aH7Y/xHNaRcIi/I1s4m5ZfNa3jQVK4BEB5X4A14VKx8/tBKWY= X-Received: by 2002:a05:6102:21d8:b0:322:930a:e8c0 with SMTP id r24-20020a05610221d800b00322930ae8c0mr6214513vsg.33.1647746574430; Sat, 19 Mar 2022 20:22:54 -0700 (PDT) MIME-Version: 1.0 References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> <20220225020227.GM12881@kduck.mit.edu> <20220319192416.GH13021@mit.edu> In-Reply-To: <20220319192416.GH13021@mit.edu> From: Ketan Talaulikar Date: Sun, 20 Mar 2022 08:52:41 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="0000000000003fb60905da9de502" Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sun, 20 Mar 2022 03:23:06 -0000 --0000000000003fb60905da9de502 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, Thanks for your time and your response. Please check inline below with KT3. We've also posted an update with changes to address your comments: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-21 On Sun, Mar 20, 2022 at 12:54 AM Benjamin Kaduk wrote: > Hi Ketan, > > My apologies for the slow reply, there are quite a few things for me to > wrap up before my term as AD ends. As you put it in your graceful note > off-list, we are very close. > > More inline... > > On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote: > > Hi Ben, > > > > Thanks for your response and please check inline below with KT2 > > > > We've also just posted another update to address some of your comments > and > > those from other ADs. > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-19 > > > > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk wrote: > > > > > Hi Ketan, > > > > > > Thanks for the replies here and the updates in the -18. > > > I think there are still some open topics, though; more inline. > > > > > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote: > > > > Hi Ben, > > > > > > > > Thanks for your detailed review and your comments/inputs. Please > check > > > > inline for responses. > > > > > > > > > > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > > > > noreply@ietf.org> wrote: > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-spring-segment-routing-policy-17: 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 cu= t > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > > > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found her= e: > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy= / > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > (1) I may just be misunderstanding things, but I'd like to pull o= n > a > > > thread > > > > > in =C2=A78.4 a bit more. We say that the headend H learns a BGP = route > that > > > has > > > > > a > > > > > VPN label V, but then the following procedures seem to say that w= e > > > install > > > > > a > > > > > route on the appropriate SR Policy P and that when we receive a > packet > > > that > > > > > matches the route in question, push a label stack including the V= PN > > > label, > > > > > and send the resulting packet out. > > > > > > > > > > > > KT> Note that we are sending the packet to the selected BGP NH (i.e= . > > > egress > > > > PE) that advertised the route. The SR Policy is enabling the packet= s > to > > > > traverse a path that is different from (perhaps) the best-effort IG= P > > > > routing. > > > > > > > > > > > > > Nowhere do we say to check the VPN > > > > > status of the incoming packet, > > > > > > > > > > > > KT> That is the ingress part of the forwarding entry which maps the > > > > incoming traffic over a customer interface to their specific VPN > context > > > > and then performs a lookup in their VPN specific table. This all is > > > > unchanged. > > > > > > > > > > > > > so this seems like it would open a hole in > > > > > the VPN by allowing "arbitrary" incoming traffic (not marked as > > > specific to > > > > > V) to enter that VPN. Is the label V filling some other role tha= n > > > > > identifying a specific VPN of many VPNs that could run along the > route > > > R/r? > > > > > (This is the only instance of the phrase "VPN label" in the > document, > > > and > > > > > no > > > > > reference is given, so I'm relying heavily on instinct to > ascertain the > > > > > intent here.) > > > > > > > > > > > > > KT> I hope my responses clarified that the only thing that is chang= ed > > > here > > > > by the steering over the SR Policy is the path taken through the > network > > > to > > > > get to the egress PE. Rest is as today. And yes, of course, we have > the > > > > ability to indicate the need for such steering via the matching Col= or > > > > Extended community to the BGP route. > > > > > > Yes, these help clarify that the part we're focusing on in this > document is > > > conceptually "after" the determination of the incoming VPN, and so > there > > > isn't any new processing needed for it. Thanks for the explanation. > > > > > > > > > > > > > > > > > > (2) The security considerations says that this document does not > > > define any > > > > > new protocol extensions and (accordingly) does not introduce any > > > further > > > > > security considerations. The first part of this seems false, not > least > > > > > since we define the meaning of the "CO" bits in the Color Extende= d > > > > > Community. I'm pretty sure that makes the second part also false= , > and > > > we > > > > > need to discuss the security considerations relating to imposing = SR > > > > > Policies > > > > > based only on color and not next-hop. Alvaro has also noted > additional > > > > > aspects where security considerations are missing. > > > > > > > > > > > > > KT> Ack. We will add text in the security consideration sections fo= r > the > > > CO > > > > steering modes. > > > > > > What about the SR-DB concept and other new concepts that Alvaro > identified? > > > Aren't there security and manageability considerations there as well? > > > > > > > KT2> We've just added text for the endpoint uniqueness and steering > > aspects. The SRDB is internal to the computation node and the informati= on > > within it is derived from existing routing protocols and their > extensions - > > we are not adding anything new to it. Do let me know, however, if you > feel > > we are missing something. > > I see that Alvaro has cleared his Discuss, so I am willing to consider th= is > topic closed. I did not think very hard about whether there is anything > missing, so accordingly I don't have anything to propose adding. > > > > > > > > > > > > > > > > > (3) The Discriminator as defined in =C2=A72.5 does not seem wide = enough > to > > > be > > > > > able to provide the needed properties. Some later clarification = in > > > =C2=A72.6 > > > > > implies that the definition in =C2=A72.5 is incomplete and the wi= dth is > > > actually > > > > > appropriate, but in either case =C2=A72.5 seems inadequate in its > current > > > form. > > > > > (Details in the COMMENT.) > > > > > > > > > > > > > KT> 32 bit is wide enough and please see further response below. > > > > > > I think I'm still failing to understand exactly why; more below. > > > > > > > > > > > > > (4) Section 2.11 contains the statement, "A valid SR Policy is > > > instantiated > > > > > in the forwarding plane." > > > > > > > > > > Is this a statement of fact (i.e., a consequence of the definitio= n > of > > > > > "valid") or a mandate for something (e.g., the headend) to take > action > > > to > > > > > make it so? Given that the point of SR is to be stateless on nod= es > > > other > > > > > than the headend, I suspect the former, but if we are relying on > the > > > > > headend > > > > > (or some other entity) to take action to ensure this is the case, > that > > > > > needs > > > > > to be a clearly stated normative requirement. > > > > > > > > > > > > > KT> The validity of a candidate path and as an extension, the SR > Policy > > > is > > > > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and it= s > > > > constructs are instantiated in the forwarding plane. > > > > > > Would it make sense to say something like "In order to be considered > valid, > > > an SR policy needs to be instantiated in the forwarding plane (Sectio= n > 5)"? > > > > > > > KT2> The SR Policy may be valid, but could not be instantiated into the > > forwarding due to a resource issue. We are simply stating here that > > generally only a valid SR Policy is instantiated in the forwarding plan= e. > > We don't have the "only" here since we have use-cases as in section 8.2 > > where we do have to instantiate a "drop" entry in the forwarding for an > > invalid SR Policy. > > Thanks for helping me understand the scenarios here. A few more > alternative proposals: > "A valid SR policy is instantiated in the forwarding plane by the headend= ." > "A valid SR policy is generally instantiated in the forwarding plane." > "Generally, only valid SR policies are instantiated in the forwarding > plane." > > Feel free to use any of those, a modified version thereof, or leave it > unchanged (though I would prefer to make some form of clarification, I do > not plan to ask my successor to take up this as a Discuss point when my > term ends in a few days). > KT3> Ack - we've incorporated this change. > > > > > > > > > > > > > > > > > > > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]." > > > > > There's nothing in the IANA registry for SAFI > > > > > ( > https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml) > > > > > about > > > > > LISP, and RFC 6830 doesn't talk about SAFI. What is this > referring to? > > > > > > > > > > > > > KT> Ack - there is no SAFI in LISP and the reference was meant to b= e > for > > > > routing of both IPv4 and IPv6 packets with LISP. Will fix this. > > > > > > The new text is still a bit terse/opaque for me to be confident that = I > > > understand properly, but I will drop the discuss point as I think I > see how > > > it works. > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > There's a lot of this document that feels like just some > informational > > > > > discussion of "here are some things that many people do", "here a= re > > > some > > > > > possible things you can do with SR", etc.. There are also a smal= l > > > handful > > > > > of places in the document that look to actually be specifying > parts of > > > > > protocol behavior (I suspect that John has already identified the= m > in > > > his > > > > > enumeration), and the overall impression ends up being a bit > jumbled, > > > > > like there are a bunch of topics stuck together without an > overarching > > > > > theme. > > > > > I think the overall content would be more valuable if divided int= o > a > > > tight > > > > > "protocol specification" portion that could stay at proposed > standard, > > > plus > > > > > an informational "architecture details" document that contains th= e > > > > > in-depth exposition that didn't make it into 8402. > > > > > > > > > > This draft would benefit greatly from a terminology section. I > note > > > in the > > > > > section-by-section comments several places where a term is first > used > > > > > without sufficient background/definition, leaving the matter at > hand > > > > > underspecified for the reader. > > > > > > > > > > Section 2 > > > > > > > > > > An SR Policy is a framework that enables the instantiation of = an > > > > > ordered list of segments on a node for implementing a source > routing > > > > > > > > > > Really, an SR policy is a *framework*? I thought an SR policy wa= s > a > > > > > specific instantiation of a list of segments, or at least that's > what > > > I'm > > > > > getting from RFC 8402. Perhaps we should say that the general > concept > > > of > > > > > SR > > > > > Policy provides a framework? > > > > > > > > > > > > > KT> Ack. Will rephrase. > > > > > > > > > > > > > > > > > > Section 2.1 > > > > > > > > > > An SR Policy MUST be identified through the tuple color, > > > > > endpoint>. In the context of a specific headend, an SR policy > MUST > > > > > be identified by the tuple. > > > > > > > > > > These two MUSTs appear to be in (nominal) conflict. Maybe start > the > > > first > > > > > one with "absent further context" or "absent the context of a kno= wn > > > headend > > > > > node"? > > > > > > > > > > > > > KT> It is not "absence of context" but "within the context of a > specific > > > > headend". > > > > > > > > > > > > > > > > > > The headend is the node where the policy is > > > instantiated/implemented. > > > > > The headend is specified as an IPv4 or IPv6 address and is > expected > > > > > to be unique in the domain. > > > > > > > > > > This is the first instance of the word "domain" in this document. > I > > > > > suggest > > > > > using the introduction to introduce what is meant by the word, > even if > > > just > > > > > by reference to RFC 8402. > > > > > > > > > > > > > KT> Ack. It should be SR Domain. > > > > > > > > > > > > > > > > > > An implementation MAY allow the assignment of a symbolic name > > > > > comprising printable ASCII [RFC0020] characters (i.e. 0x20 to > 0x7E) > > > > > to an SR Policy to serve as a user-friendly attribute for > debugging > > > > > and troubleshooting purposes. [...] > > > > > > > > > > I agree with the other ADs that limiting to US-ASCII is not > actually > > > > > user-friendly for many users, and that the likelihood of some > > > > > implementations not properly enforcing such a limitation to be > high. > > > > > (Likewise for the other places where symbolic names are admitted.= ) > > > > > > > > > > > > > KT> Please see the response to the other reviews on this point. > > > > > > I don't find them compelling, but this is just the COMMENT section so > > > you're not obligated to persuade me. > > > > > > > > > > > > > > > > > Section 2.2 > > > > > > > > > > A dynamic candidate path expresses an optimization objective > and a > > > > > set of constraints. [...] > > > > > > > > > > Down in =C2=A75.2 when we discuss validation procedures for dynam= ic > > > candidate > > > > > paths, we say that the optimization problem is solved "for either > the > > > > > SR-MPLS or the SRv6 data-plane as specified". Does the data plan= e > > > need to > > > > > be specified as part of the dynamic candidate path itself? > > > > > > > > > > > > > KT> Yes. > > > > > > Should we say that here, e.g., "a dynamic candidate path expresses an > > > optimization objective and a set of constraints within a specified da= ta > > > plane"? > > > > > > > KT2> Ack. Have clarified this in the text. > > > > > > > > > > > > > > > > > > > > > Section 2.3 > > > > > > > > > > in Section 2.9. The table below specifies the RECOMMENDED > default > > > > > values of Protocol-Origin: > > > > > > > > > > I feel like it would be useful to provide some justification for > why > > > the > > > > > recommended default behavior prefers BGP SR configuration over > PCEP, > > > even > > > > > if > > > > > that justification is just "we need to have a clear ordering and > this > > > one > > > > > is > > > > > arbitrary". > > > > > > > > > > > > > KT> Ack. Will clarify that. > > > > > > > > > > > > > > > > > > Section 2.4 > > > > > > > > > > o Node Address : represented as a 128-bit value. IPv4 > addresses > > > > > MUST be encoded in the lowest 32 bits, and the high-order > bits > > > > > MUST be set to zero. > > > > > > > > > > Its application in the candidate path selection is described i= n > > > > > Section 2.9. > > > > > > > > > > The tie-breaker procedure for path selection described in =C2=A72= .9 > seems to > > > > > always prefer IPv4 originators over IPv6 ones (by virtue of > preferring > > > the > > > > > smaller value). I guess if we wanted to change that to prefer > IPv6 we > > > have > > > > > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped > > > unicast) > > > > > from BCP 153, but it's a bit hard to justify either of those as > > > appropriate > > > > > on technical grounds, and since this is just a tie-breaker and th= e > > > > > Preference is explicitly preferred, it seems like this is probabl= y > > > "good > > > > > enough" as-is. > > > > > > > > > > > > > KT> Ack. As clarified in a recent text update in v17, preference is > the > > > key > > > > parameter really. > > > > > > > > > > > > > > > > > > Section 2.5 > > > > > > > > > > The Discriminator is a 32-bit value associated with a candidat= e > path > > > > > that uniquely identifies it within the context of an SR Policy > from > > > a > > > > > specific Protocol-Origin as specified below: > > > > > > > > > > What are the constraints that underlie the 32-bit requirement her= e? > > > > > It looks like some of the scenarios are going to involve > uncoordinated > > > > > (random) assignment of these discriminator values (e.g., with the > BGP > > > > > distribution mechanism, when coming from different BGP peers), an= d > the > > > > > birthday-bound collision probability is not negligible for this f= ew > > > bits. > > > > > That, in turn, calls into question the "uniquely identifies" > property > > > being > > > > > claimed. Or is there some other property that means that only > > > > > discriminators from a single issuer will ever need to be compared > with > > > each > > > > > other (making the allocation "coordinated"), such as being > additionally > > > > > associated with the originator? > > > > > If my initial analysis was incorrect and these are indeed > allocated in > > > a > > > > > "coordinated" fashion, would it be typical/expected for the > allocation > > > to > > > > > occur by incrementing a local counter on the originator? In some > > > > > situations > > > > > such allocation by counter can have security considerations, whic= h > > > > > draft-gont-numeric-ids-sec-considerations attempts to cover. > > > > > > > > > > > > > KT> The discriminator is scoped to a particular originating node fo= r > the > > > > candidate path and as such, there is no requirement for coordinatio= n > > > across > > > > sources/nodes. Therefore, 32-bit is more than sufficient. > > > > > > When you say "originating node", does that refer to the SR headend, o= r > the > > > (BGP) originator of the BGP route containing the SR Policy NLRI? > > > > > > > KT2> The BGP originator as you've correctly understood below. > > > > > > > > > > I assume the latter, and agree that *within the context of BGP*, the > > > discriminator is scoped to the originating BGP node. But the > description > > > we give in =C2=A72.5 of this document does not say anything about mak= ing > use of > > > such information. As far as I know, the BGP originator information i= s > lost > > > when the BGP distinguisher is converted into the SR Policy candidate > path > > > discriminator data model. > > > > > > KT2> The BGP originator information is not lost. We have clarified this > in > > the text below in sec 2.5 itself: > > > > o When signaling is via BGP SR Policy, the BGP process receiving th= e > > route provides the distinguisher (refer to Section 2.1 of > > [I-D.ietf-idr-segment-routing-te-policy > > < > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-18#ref-I-D.ietf-idr-segment-routing-te-policy > >]) > > as the discriminator. > > I think this is trying to cover too much subtlety to be accessible to all > readers. Thanks for the pointer to > draft-filsfils-spring-sr-policy-considerations below, that seems to help > clarify that the intent is that collisions on BGP distinguisher are > expected to be resolved within the BGP layer using BGP best-path selectio= n, > so that only a single candidate path is received by the SR layer from BGP > for a given distinguisher/discriminator, even if the BGP agent on the SR > node receives multiple routes that could be candidate paths prior to the > BGP bestpath selection. > KT3> This is standard BGP operations given the NLRI design and the referenced sec 2.1 of draft-ietf-idr-segment-routing-te-policy touches upon the use of different discriminators when the CP for the same SR Policy needs to be sent to the SR layer from BGP layer. > > It seems that there are a number of ways that we could modify this docume= nt > to clarify; let me list a couple (but these are not intended to be > exhaustive): > > - in this chunk of text, add another sentence like "Note that BGP best pa= th > selection is applied before the route is supplied as a candidate path, = so > only a single candidate path will be seen for a given discriminator." > > - In the preface at the top of =C2=A72.5 before the list of per-Protocol-= Origin > discussions, add a note that "each Protocol-Origin is expected to apply > any processing needed to ensure that only a single candidate path is > supplied with a given Discriminiator value" > KT3> Ack - we have incorporated the 1st text above. > > > > > > > > And we don't say anything about how candidate > > > paths for a given SR Policy can only be originated from a single BGP > node, > > > so I have to account somehow for the possibility that two BGP nodes a= re > > > independently announcing candidate paths for the same SR Policy, and > thus > > > might collide in their assignment of distinguisher. > > > > > > KT2> You are correct. This can and does indeed happen today in > deployments > > for redundancy and other reasons. > > > > > > > Whereas BGP can > > > resolve that collision via the BP origination information, I don't se= e > how > > > that would be done in the SR data model. Does that help you understa= nd > > > what part I am missing? > > > > > > > KT2> We did have some text in this document in the early days to explai= n > > these scenarios but it was moved out to an individual draft. Sec 2.9 ha= s > a > > pointer to this informative draft. Please check > > > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-con= siderations-08#section-4 > > and if they clarify. > > (As indicated above, they do clarify, but that draft is not referenced he= re > and is not a normative reference, so I must insist on further changes to > this document.) > KT3> The draft-filsfils-spring-sr-policy-considerations is providing only the illustrations and the normative behavior is covered in this document (i.e., the tiebreaker rules) while the BGP protocol behavior is defined in draft-ietf-idr-segment-routing-te-policy document. Please note that the initial versions of this draft did have those illustrations in them but were moved out to a separate document as part of the WG process. > > > > > > > > > > > > > > > > > > > > > > > Section 2.8 > > > > > > > > > > A candidate path is usable when it is valid. A common path > validity > > > > > criterion is the validity of any of its constituent > Segment-Lists. > > > > > The validation rules are specified in Section 5. > > > > > > > > > > This document claims to target Proposed Standard status; are we > really > > > > > content to say only that this is "a common" criterion? Even when > we > > > also > > > > > go > > > > > on to flat-out state "the validation rules are specified [below]"= ? > > > > > > > > > > > > > KT> We will change this to introduce the word RECOMMENDED. There ar= e > > > > deployments where an operator might need a local policy to declare > the > > > > candidate path invalid when the number of valid SLs drops below a > certain > > > > threshold (for b/w or load-balancing considerations). > > > > > > > > > > > > > > > > > > Section 2.9 > > > > > > > > > > The candidate path selection process operates primarily on the > > > > > candidate path Preference. A candidate path is selected when > it is > > > > > valid and it has the highest preference value among all the > > > candidate > > > > > paths of the SR Policy. > > > > > > > > > > Should this be "among all the valid candidate paths"? A path > that's > > > > > invalid > > > > > is still invalid, even if it has the highest preference value. > > > > > > > > > > > > > KT> Ack - will clarify this. > > > > > > > > > > > > > > > > > > 2. If specified by configuration, prefer the existing install= ed > > > > > path. > > > > > > > > > > Does "if specified by configuration" refer to the act of applying > this > > > rule > > > > > at all, or that the existing installed path was one specified by > > > > > configuration? > > > > > > > > > > > > > KT> The existing installed path. The rationale was that in some > > > deployment > > > > designs an operator may not want to disturb/churn an active and > > > > valid/working path that has been installed in the forwarding. > > > > > > > > > > > > > > > > > > Section 2.11 > > > > > > > > > > The fraction of the flows associated with a given Segment-List > is w/ > > > > > Sw, where w is the weight of the Segment-List and Sw is the su= m > of > > > > > the weights of the Segment-Lists of the selected path of the S= R > > > > > Policy. > > > > > > > > > > Thank you for stating this clearly! > > > > > > > > > > Section 3 > > > > > > > > > > o TE Link Attributes (such as TE metric, Shared Risk Link > Groups, > > > > > attribute-flag, extended admin group) [RFC5305] [RFC3630]. > > > > > > > > > > Is RFC 5329 applicable here as well? > > > > > > > > > > > > > KT> Yes, will add that. Thanks. > > > > > > (It looks like a second 3630 reference got added in the -18, not 5329= ; > I'll > > > mention that in my updated ballot remarks as well.) > > > > > > > KT2> Ooops :-( .. now fixed for real > > > > > > > > > > > > > > > > > > > > > Section 4 > > > > > > > > > > Type E: IPv4 Prefix with Local Interface ID: > > > > > This type allows identification of Adjacency SID or BGP > Peer > > > > > Adjacency SID (as defined in [RFC8402]) SR-MPLS label fo= r > > > > > point-to-point links including IP unnumbered links. The > > > > > headend is required to resolve the specified IPv4 Prefix > > > > > Address to the Node originating it and then use the Loca= l > > > > > Interface ID to identify the point-to-point link whose > > > > > adjacency is being referred to. The Local Interface ID > link > > > > > descriptor follows semantics as specified in [RFC7752]. > This > > > > > > > > > > The phrase "local interface ID" does not appear in RFC 7752 (and > even > > > > > "local > > > > > interface" appears just once"; please use terminology actually > present > > > in > > > > > the referred-to document to clarify what is being referenced. > > > > > > > > > > > > > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn > > > > references RFC5307 which in turn RFC4202. We use RFC7752 since it > covers > > > > and explains the use of the various link descriptors that we use fo= r > > > > various segment types. > > > > > > > > > > > > > > > > > > Section 4.1 > > > > > > > > > > When steering unlabeled IPv6 BGP destination traffic using an = SR > > > > > policy composed of Segment-List(s) based on IPv4 SIDs, the > Explicit > > > > > Null Label Policy is processed as specified in > > > > > [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4. When > an > > > > > > > > > > It looks like this is =C2=A72.4.5, not 2.4.4, in the referenced > document. > > > > > > > > > > > > > KT> Ack. Will fix. > > > > > > > > > > > > > > > > > > Section 5.1 > > > > > > > > > > The computation/logic that leads to the choice of the > Segment-List > > > is > > > > > external to the SR Policy headend. The SR Policy headend does > not > > > > > compute the Segment-List. The SR Policy headend only confirms > its > > > > > validity. > > > > > > > > > > Does the headend actually have to confirm validity? Is it okay t= o > just > > > > > trust the controller and blindly use what is provided? > > > > > > > > > > > > > KT> At least the first segment needs to be validated from a > resolvability > > > > perspective. The subsequent segments depend on how (i.e., using wha= t > > > > segment types) the controller has signalled the path to the headend= . > If > > > it > > > > is indicated by just referring to a Prefix (e.g. loopback) of a nod= e, > > > then > > > > the headend will need to resolve and as such validate. While if > specified > > > > as a label, then no resolution is required. > > > > > > Hmm. So maybe we could say "the SR Policy headend only confirms the > > > validity of any segments that it needs to resolve as part of packet > > > processing"? Or does that not actually convey the needed information= ? > > > > > > > KT2> IMHO, the term used in the draft "path resolution to the SID" is > more > > informative and cleared (at least to someone working on the programming > of > > forwarding entries) than "packet processing". > > Okay, I am happy to defer to your domain expertise. > > > > > > > > > > > > > > > > > > > > Section 6.2 > > > > > > > > > > When the active candidate path has a specified BSID, the SR > Policy > > > > > uses that BSID if this value (label in MPLS, IPv6 address in > SRv6) > > > is > > > > > available (i.e., not associated with any other usage: e.g. to > > > another > > > > > MPLS client, to another SRv6 client, to another SID, to anothe= r > SR > > > > > Policy, outside the range of SRv6 Locators). > > > > > > > > > > I don't think I understand what is meant by "client" here (for > "another > > > > > client"). This sentence is the only place where the word "client= " > > > appears > > > > > in this document... > > > > > > > > > > > > > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be > IS-IS > > > > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label > from a > > > > "label manager" within the router. > > > > > > I think this explanation actually makes me more concerned about the w= ay > > > this is written than I previously was. It seems to imply that we are > > > trying to describe both that there is an MPLS vs SRv6 data-plane in > use and > > > that the node in question is a client of some unspecified protocol > that can > > > allocate SIDs/MPLS labels, which could be as varied as an IGP or a > > > dedicated path computation protocol. Furthermore, not all of these > > > possible protocols would intrinsically provide for arbitrary headend > nodes > > > to even know if the label/SID in question has already been allocated = to > > > another "client"! > > > > > > > Is the determination of availability to be made by the controller or > by the > > > headend? > > > > > > KT2> This is local on the headend. > > > > > > > I think we should state that clearly, since (given the above > > > discussion) it seems like it is the controller that is best place to > > > actually make the determination, but the phrasing "the SR Policy uses= " > > > implies (at least to me) that the determination is made on the headen= d, > > > since it is the headend that actually instantiates the policy. > > > > > > > KT2> The controller can (and does in some of the deployments that I am > > aware of) keep track of the usage of the Labels in the SRGB and SRLB > (refer > > RFC8402). The same goes for SRv6 SIDs from under the SRv6 Locator. In > > deployments where controllers do drive the whole SR Policy provisioning= , > > they do keep track. However, this is not mandatory in general. The > headend > > is taking care of the actual programming into the forwarding and doesn'= t > > have any option but to handle these conditions. > > Okay. I might consider coalescing "to another MPLS client, to another SR= v6 > client" down to "to another node in the SR domain" since it's not worth > adding enough detail to fully clarify "MPLS client" and "SRv6 client", bu= t > it's up to you. > KT3> We have edited the text to expand a bit on what is meant by "client" here. > > > > > > > > > > > > > > > > > > > > Optionally, instead of only checking that the BSID of the acti= ve > > > path > > > > > is available, a headend MAY check that it is available within = a > > > given > > > > > SID range i.e., Segment Routing Local Block (SRLB) as specifie= d > in > > > > > [RFC8402]. > > > > > > > > > > Is the only allowed range to check the SRLB? If not, I think we > need > > > to > > > > > s/i.e./e.g./. > > > > > > > > > > > > > KT> Yes, SRLB is the one to check/allocate from for such usage. > > > > > > Okay. I suspect we want s/a given/the given/ then, but am not 100% > sure. > > > > > > > KT2> Ack. Fixed. > > > > > > > > > > > > > > > > > > When the specified BSID is not available (optionally is not in > the > > > > > SRLB), an alert message MUST be generated. > > > > > > > > > > This is the first time (of only two) the word "alert" appears in > this > > > > > document, and there is no prior expalanation of what entity might > be > > > > > receiving alerts generated by a headend. Please clarify. > > > > > > > > > > > > > KT> Alert mechanism could be one or more of syslog, Netconf > > > notification, a > > > > telemetry mechanism, etc.. > > > > > > I think the clarification is best placed in the document itself, e.g.= , > in a > > > glossary/terminology section as I suggested in my high-level comments= . > > > > > > > KT2> We have clarified inline. > > > > > > > > > > > > > > > > > > > > > Assuming that at time t the BSID of the SR Policy is B1, if at > time > > > > > t+dt a different candidate path becomes active and this new > active > > > > > path does not have a specified BSID or its BSID is specified > but is > > > > > not available (e.g. it is in use by something else), then the = SR > > > > > Policy MAY keep the previous BSID B1. > > > > > > > > > > Is there a strict bound on or other guidance for what values of d= t > are > > > > > allowable for this purpose? > > > > > > > > > > > > KT> None > > > > > > > > > > > > > Is the intent that there be an atomic > > > > > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1;active-pa= th=3DP2? > > > > > > > > > > > > > KT> There is no atomicity requirement. A switch from one active CP = to > > > > another will vary depending on the cause of the switch - e.g. if it > is > > > due > > > > to a failure or because a more preferred path came up. > > > > > > > > > > > > > > > > > > The association of an SR Policy with a BSID thus MAY change > over the > > > > > life of the SR Policy (e.g., upon active path change). Hence, > the > > > > > BSID SHOULD NOT be used as an identification of an SR Policy. > > > > > > > > > > Is there any guidance available on how long to wait with a given > BSID > > > value > > > > > unused before binding it to a new SR Policy? > > > > > > > > > > > > > KT> None. These depend on the implementation and scenarios like > resource > > > > availability e.g., a BSID might get re-used sooner if the system is > > > running > > > > short of labels. > > > > > > > > > > > > > > > > > > Section 6.2.3 > > > > > > > > > > An implementation MAY support the configuration of the > Specified- > > > > > BSID-only restrictive behavior on the headend for all SR > Policies or > > > > > individual SR Policies. Further, this restrictive behavior MA= Y > also > > > > > be signaled on a per SR Policy basis to the headend. > > > > > > > > > > Elsewhere in the document we discuss specific potential signaling > > > > > mechanisms/protocols, but here we say nothing. Is that vagueness > > > > > intentional? > > > > > > > > > > > > > KT> Since this isn't a protocol specification the mechanism is not > > > > described here. However, you can look at > > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-p= olicy-14#section-2.4.2 > > > > and that document refers back to this specification. > > > > > > Okay, but if this document isn't a protocol specification and that's > > > grounds to not describe mechanism in it, then there are quite a few > other > > > places in the document that should also not describe mechanism, if we > want > > > to be applying the rule consistently. > > > > > > > KT2> There may be very high-level references to some mechanisms in > addition > > to the informative pointer to the specific protocol spec. This was done > to > > improve readability. > > > > > > > > > > > > > > > > > > > > > Section 6.3 > > > > > > > > > > A valid SR Policy installs a BSID-keyed entry in the forwardin= g > > > plane > > > > > with the action of steering the packets matching this entry to > the > > > > > selected path of the SR Policy. > > > > > > > > > > I don't think this is stated properly. An SR Policy is the list = of > > > > > segments; it isn't the entity that's installing entries in the > > > forwarding > > > > > plane. Some other entity is installing an entry in the forwardin= g > > > plane to > > > > > realize the SR Policy in question, and we should make our writing > > > reflect > > > > > that. > > > > > > > > > > > > > KT> Ack. s/installs/results in the installation of > > > > > > > > > > > > > > > > > > Section 6.4 > > > > > > > > > > An implementation MAY choose to associate a Binding SID with a= ny > > > type > > > > > of interface (e.g. a layer 3 termination of an Optical Circuit= ) > or a > > > > > tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-= TE > > > > > tunnel, etc). This enables the use of other non-SR enabled > > > > > > > > > > Should we have some discussion that contrasts this scenario > against the > > > > > End.X behavior from RFC 8986 (for the "interface" case)? > > > > > > > > > > > > > KT> What this document says is that a BSID may be also associated t= o > > > direct > > > > over these other types of interfaces/tunnels. We can look at them a= s > > > having > > > > no other segment being imposed but just redirecting to an interface= . > In > > > > that sense, it is somewhat similar to End.X in SRv6 (or Adjacency > SID in > > > > SR-MPLS). However, those tend to be associated with protocol > > > adjacencies. I > > > > am not sure that I've followed your point though and please do let = me > > > know > > > > if I've not. > > > > > > What you write here indicates to me that you got my point. My > proposal was > > > for a sentence something like "this behavior is analogous to the End.= X > > > behavior defined in [RFC8986] in that the SID is removed, no new SIDs > > > applied, and the packet is directed across a particular interface, bu= t > it > > > conceptually fits better as a Binding SID since the SID is bound to a > > > specific (logical or physical) interface and End.X is typically used > with > > > protocol adjacencies rather than interfaces". But that's just a > > > suggestion, and if you think it doesn't make sense or doesn't add muc= h > > > value, please ignore it. > > > > > > > > > > > > > > > > > Section 7 > > > > > > > > > > The SR Policy State is maintained on the headend to represent > the > > > > > state of the policy and its candidate paths. [...] > > > > > > > > > > I confess I don't really understand why we need to have the > current, > > > > > minimal, description of SR Policy State in this document. What > would > > > be > > > > > lost if we deferred its discussion entirely until there is a more > > > > > comprehensive discussion available? > > > > > > > > > > > > > KT> We will add an informational pointer to the SR Policy YANG mode= l. > > > What > > > > this document calls out is the requirement for reporting the > operational > > > > state and provides pointers to other specs where this is being work= ed > > > out. > > > > > > > > > > > > > > > > > > The SR Policy state can be reported by the headend node via > BGP-LS > > > > > [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and > > > > > [I-D.ietf-pce-binding-label-sid]. > > > > > > > > > > The functionality of draft-ietf-pce-binding-label-sid seems much > more > > > > > limited than that of draft-ietf-idr-te-lsp-distribution; in > > > particular, the > > > > > former does not seem to actually report SR Policy state to the > headed > > > at > > > > > all; rather, it only concerns itself with BSID association to pat= h, > > > with no > > > > > information about "active", "not preferred", etc. > > > > > > > > > > > > > KT> The PCEP work might be spread out over different documents but > we do > > > > need to cover these requirements. That is one of the objectives of > having > > > > this document coordinate work across protocol WGs. > > > > > > It still feels like we're claiming something here that isn't true -- > "can > > > be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]". It > seems > > > like we are really trying to say "... via extensions to PCEP [some of > which > > > don't exist yet in a form that we're willing to reference]". > > > > > > > KT2> This document, like some others in SPRING, does provide informativ= e > > references (perhaps still in the WG doc stage) for better readability a= nd > > clarity. > > > > > > > > > > > > > > > > > > Section 8.3 > > > > > > > > > > If the SR Policy P is invalid, the BSID B is not in the > forwarding > > > > > plane and hence the packet K is dropped by H. > > > > > > > > > > We literally just in the previous section talked about a scenario > > > where the > > > > > BSDI is kept in the forwarding plane (but with the action to drop= , > so > > > the > > > > > overall outcome is not changed from what this text describes). > > > > > Nonetheless, > > > > > it's inaccurate to state that "the BSID B is not in the forwardin= g > > > plane" > > > > > here. > > > > > > > > > > > > > KT> There is a difference between the drop being referred to in 8.2 > and > > > > 8.3. What we have in 8.2 is like a route pointing to null where we > may > > > > advertise and get packets but will drop it with normal counters > > > associated > > > > with that specific entry. While 8.3 is like we are dropping because > we > > > have > > > > no route (ideally we shouldn't have got the packet) and we incremen= t > a > > > > generic lookup failed counter. The use-cases for both are different= . > > > > > > I (think I) understand that the mechanisms are different and both hav= e > use > > > cases. I just don't think that the specific combination of words use= d > here > > > makes a true statement. There are probably a number of ways to make = a > > > slight > > > adjustment and come up with a true statement, such as starting it wit= h > a > > > caveat as in "When Drop-Upon-Invalid behavior is not in use, for an > invalid > > > SR Policy P, its BSID B is not in the forwarding plane and hence the > packet > > > K is dropped by H". > > > > > > > KT2> Thanks for that suggestion. We've incorporated it. > > > > > > > > > > > > > > > > > > > > > Section 8.4.1 > > > > > > > > > > When a BGP route has multiple Color Extended communities each > with a > > > > > valid SR Policy, the BGP process installs the route on the SR > Policy > > > > > giving preference to the color with the highest numerical valu= e. > > > > > > > > > > Do we want to say anything about this being an arbitrary tiebreak= er > > > (rather > > > > > than an intentional preference), or is that thought to be > implicitly > > > clear? > > > > > > > > > > > > > KT> It is an intentional preference. > > > > > > Peeking forward to =C2=A78.8.2, is this also referring to the BGP col= or > rather > > > than the SR Policy color? If so, please specifically qualify the wor= d > > > "color" as being the BGP one. > > > > > > If not, then I strongly suggest that the introduction of color in =C2= =A72.1 > > > state that the numerical value of the color is used as a preference > > > mechanism in addition to indicating intent or objective (with the > > > implication or explicit statement that assignment of color values mus= t > be > > > performed in a manner that is compatible with the operator's > > > preference/policy). > > > > > > > KT2> This document needs to refer to the "BGP color" as the "Color > Extended > > Community". Thanks for catching that. This is not done in a few places > and > > we've fixed that. > > Many thanks for those fixes, it is a big help. > > > > > > > > > > > > > > > > > > > > > Section 8.5 > > > > > > > > > > In this section, independent of the a-priori existence of any > > > > > explicit candidate path of the SR policy (C, N), it is to be > noted > > > > > that the BGP process at headend node H triggers the > instantiation of > > > > > a dynamic candidate path for the SR policy (C, N) as soon as: > > > > > > > > > > I strongly suggest providing a more explicit framework of what th= e > > > > > assumptions and preconditions are for the mechanism described in > this > > > > > section. My intuition says that it's a fairly optional thing tha= t > > > would > > > > > need to be specifically configured, but trying to wrap that > sentiment > > > into > > > > > the long bullet point involving "a local policy" seems like a ver= y > > > > > confusing > > > > > way to express the desired behavior. > > > > > > > > > > > > > KT> It is actually a matter of local policy with perhaps some > template > > > and > > > > configuration to drive this. I believe this should get covered in > the SR > > > > Policy YANG model at some point in time. > > > > > > > > > > > > > > > > > > Section 8.6 > > > > > > > > > > o is configured to instantiate an array of paths to N where t= he > > > > > entry 0 is the IGP path to N, color C1 is the first entry a= nd > > > > > Color C2 is the second entry. The index into the array is > called > > > > > a Forwarding Class (FC). The index can have values 0 to 7. > > > > > > > > > > Why are the only allowed values 0 to 7? Where does this > restriction > > > arise > > > > > from? It is because of some protocol element? > > > > > > > > > > > > > KT> There is text further in the section to indicated that these > > > > ranges/values are implementation-specific. Historically, the 8 valu= es > > > have > > > > come from the MPLS EXP bits. > > > > > > If the ranges/values are implementation-specific, then don't give a > > > specific range here stated as if it is a universal limitation! I wou= ld > > > either drop the sentence entirely or say something like "when the > index is > > > conveyed using the MPLS EXP bits, only indices 0 to 7 are usable". > > > > > > > KT2> Ack. Have clarified. > > > > > > > > > > > > > > > > > > > > > If the local configuration does not specify any explicit > forwarding > > > > > information for an entry of the array, then this entry is fill= ed > > > with > > > > > the same information as entry 0 (i.e. the IGP shortest path). > > > > > > > > > > If the SR Policy mapped to an entry of the array becomes > invalid, > > > > > then this entry is filled with the same information as entry 0= . > > > When > > > > > all the array entries have the same information as entry0, the > > > > > forwarding entry for N is updated to bypass the array and poin= t > > > > > directly to its outgoing interface and next-hop. > > > > > > > > > > I can't tell how much of this is supposed to be protocol > specification > > > and > > > > > how much an illustrative example. Is A(0) always the IGP shortes= t > > > path? > > > > > Are these protocol requirements to fall back to the IGP shortest > path > > > when > > > > > an entry is otherwise unpopulated or the associated SR Policy > becomes > > > > > invalid? > > > > > > > > > > > > > KT> The specifics are for illustration purposes. Most of these are > policy > > > > knobs/options. > > > > > > Please add a note at the top of the section that "this section > provides an > > > example of how a headend might apply per-flow steering in practice". > > > > > > > KT2> Ack. Added. > > > > > > > > > > > > > > > > > > > > > Section 8.8.2 > > > > > > > > > > The steering preference is first based on the highest color > value > > > and > > > > > then CO-dependent for the color. [...] > > > > > > > > > > This seems to contradict what I assumed earlier about the "highes= t > > > color" > > > > > rule being a tiebreaker, e.g., the word "preference" is used > here. Is > > > it > > > > > actually intended to be a deliberately configured > priority/preference > > > > > scheme? If so, that would seem to require some wide-ranging > reworking > > > > > throughout the document. > > > > > > > > > > > > > KT> There is the color that is in the identification of an SR Polic= y > - > > > > (color, endpoint). This does not get into any tiebreaker or selecti= on > > > > logic. All that (sec 2.9) is about the selection of a candidate pat= h > > > within > > > > an SR Policy. Then there is the color value signaled via the Color > > > Extended > > > > community on the BGP routes and here, we have the preference for > higher > > > > color when the route is advertised with multiple colors tagged to i= t. > > > > > > I think you should clarify that this section refers to the BGP Color, > then > > > -- previously in the document it has been the SR Policy color value > and an > > > unqualified reference to "color value" seems like it refers to the > concept > > > defined in this document, absent other qualifiers. > > > > > > > KT2> Ack. Fixed references as mentioned in a previous comment. > > > > > > > > > > > > > > > > > > > > > Section 9.3 > > > > > > > > > > the most appropriate alternative for the active candidate > path. A > > > > > fast re-route mechanism MAY then be used to trigger sub 50msec > > > > > switchover from the active to the backup candidate path in the > > > > > forwarding plane. Mechanisms like Bidirectional Forwarding > > > Detection > > > > > (BFD) MAY be used for fast detection of such failures. > > > > > > > > > > Why is the specific 50msec value important here? Is there some > other > > > > > requirement that imposes it? > > > > > > > > > > > > > KT> This comes from "typical" expectations from fast-reroute > mechanisms. > > > > > > I'd consider '''to trigger "fast" (sub 50msec) switchover''', then, b= ut > > > it's not very important. > > > > > > > > > > > > > > > > > Section 10 > > > > > > > > > > I think we also want to mention the security considerations of > several > > > more > > > > > documents, including (but not limited to) > > > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and > 8986. > > > > > > > > > > > > > KT> Ack on the three RFCs, but convinced about the > > > > draft-ietf-idr-segment-routing-te-policy since that depends on this > and > > > not > > > > the other way around. > > > > > > I think this relates to John's Discuss point and whether this documen= t > > > specifies the protocol behavior of the two bits in the context of the > > > extension defined in draft-ietf-idr-segment-routing-te-policy. You > need to > > > understand draft-ietf-idr-segment-routing-te-policy in order to > understand > > > the security considerations relating to the protocol behavior > controlled by > > > those two bits, and IMO the protocol behavior specified by those two > bits > > > is solely the responsibility of this document, so this document must > > > incorporate the security considerations of > > > draft-ietf-idr-segment-routing-te-policy in order to fully document t= he > > > security considerations of the concepts and protocol elements that th= is > > > document defines. > > > > > > > KT2> I am working with John to address his comments. > > Okay, the changes from -18 to -20 are looking promising, but I will let > John decide when it's done. > KT3> Our discussion with John is ongoing and seems like might take more time. Would you be clearing your DISCUSS assuming the updates address your concerns? Thanks, Ketan > > Thanks for all these replies and updates; I didn't respond to them > individally but they are all appreciated. > > -Ben > > > > > > > > > > > Thanks for this, and all the other parts I didn't specifically reply > to. > > > > > > I will attempt to update my ballot position in the datatracker to > remove > > > the parts that are fully addressed (though I will probably > inadvertently > > > leave in something I shouldn't have). > > > > > > -Ben > > > > > > > > > > > > > > > > > Section 15.2 > > > > > > > > > > I agree with John that draft-ietf-idr-segment-routing-te-policy > must be > > > > > classified as a normative reference. > > > > > > > > > > It also seems that RFC 7752 should be classified as normative, as > we > > > > > incorporate its definition for the semantics of several of the > segment > > > type > > > > > descriptions. > > > > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > > > > > > NITS > > > > > > > > > > Section 1 > > > > > > > > > > Segment Routing Policy (SR Policy) [RFC8402] is an ordered lis= t > of > > > > > segments (i.e. instructions) that represent a source-routed > policy. > > > > > > > > > > /Segment/A Segment/ > > > > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > The headend node is said to steer a flow into a SR Policy. Th= e > > > > > packets steered into an SR Policy carry an ordered list of > segments > > > > > associated with that SR Policy. [...] > > > > > > > > > > In a certain sense this can be read as saying that the packets th= at > > > "carry > > > > > an ordered list of segments" are the ones prior to being steered > into > > > an SR > > > > > policy, which would make this statement not true. Perhaps we wan= t > to > > > say > > > > > "after being steered into an SR Policy, packets carry an ordered > list > > > ..."? > > > > > (I also went back and forth with myself about whether "packets ..= . > > > carry" > > > > > implies in the payload or not. I settled on "not" but make this > note > > > just > > > > > in case I am missing an aspect of that question.) > > > > > > > > > > > > > KT> Ack. Will rephrase. > > > > > > > > > > > > > > > > > > Section 2 > > > > > > > > > > An SR Policy is a framework that enables the instantiation of = an > > > > > ordered list of segments on a node for implementing a source > routing > > > > > > > > > > It's easy to read this as saying that all of the segments in the > list > > > > > instantiated on the single node in question, which I assume is no= t > the > > > > > intent. Probably the easiest way to aid readability here is to > split > > > the > > > > > sentence up into multiple smaller sentences that are easier to > parse. > > > > > > > > > > > > > KT> Will rephrase. > > > > > > > > > > > > > > > > > > Section 2.2 > > > > > > > > > > A dynamic candidate path expresses an optimization objective > and a > > > > > set of constraints. The headend (potentially with the help of= a > > > PCE) > > > > > computes the solution Segment-List (or set of Segment-Lists) > that > > > > > solves the optimization problem. > > > > > > > > > > I'd suggest computes the solution/computes a solution/ for > genericity. > > > > > > > > > > > > > KT> Ack. > > > > > > > > > > > > > A stateful PCE might end up computing a path that is not the > optimal > > > one > > > > > for > > > > > this specific optimization problem, due to a desire to cooperate > with > > > other > > > > > paths in the network, and the "Min-Metric with margin and maximum > > > number of > > > > > SIDs" objective in draft-filsfils-spring-sr-policy-considerations > > > doesn't > > > > > even have a guaranteed unique best solution. > > > > > > > > > > Section 2.5 > > > > > > > > > > When provisioning is via configuration, this is an > implementation's > > > > > configuration model-specific unique identifier for a candidate > path. > > > > > The default value is 0. > > > > > > > > > > I'm having a lot of trouble parsing this. Did we perhaps mean to > > > hyphenate > > > > > as "configuration-model-specific"? > > > > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > Section 2.13 > > > > > > > > > > The SR Policy POL1 is identified by the tuple > > > > endpoint>. It has two candidate paths CP1 and CP2. Each is > > > > > identified by a tuple discriminator>. > > > > > > > > > > I suggest (for the last sentence) "identified within the scope of > POL1" > > > > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > forwarding instantiation of SR policy POL1. Traffic steered o= n > POL1 > > > > > is flow-based hashed on Segment-List with a > ratio > > > > > W1/(W1+W2). > > > > > > > > > > If I read "ratio" I would instinctively think of the ratio of > (traffic > > > on > > > > > segment list 1)/(traffic on segment list 2), as opposed to the > > > proportion > > > > > of > > > > > all traffic, that would be measured as the indicated W1/(W1+W2). > > > > > > > > > > > > > KT> Ack. s/ratio/proportion > > > > > > > > > > > > > > > > > > Section 3 > > > > > > > > > > The attached domain topology may be learned via IGP, BGP-LS or > > > > > NETCONF. > > > > > > > > > > A non-attached (remote) domain topology may be learned via > BGP-LS or > > > > > NETCONF. > > > > > > > > > > I think these are both probably not exhaustive lists, so "e.g." o= r > > > similar > > > > > may be appropriate. > > > > > > > > > > > > > KT> Ack. > > > > > > > > > > > > > > > > > > Section 4 > > > > > > > > > > Type C: IPv4 Prefix with optional SR Algorithm: > > > > > The headend is required to resolve the specified IPv4 > Prefix > > > > > Address to the SR-MPLS label corresponding to a Prefix S= ID > > > > > segment (as defined in [RFC8402]). The SR algorithm > (refer to > > > > > Section 3.1.1 of [RFC8402]) to be used MAY also be > provided. > > > > > > > > > > Type D: IPv6 Global Prefix with optional SR Algorithm for > SR-MPLS: > > > > > In this case, the headend is required to resolve the > specified > > > > > IPv6 Global Prefix Address to the SR-MPLS label > corresponding > > > > > to its Prefix SID segment (as defined in [RFC8402]). Th= e > SR > > > > > Algorithm (refer to Section 3.1.1 of [RFC8402]) to be > used MAY > > > > > > > > > > These are effectively just the IPv4 and IPv6 incarnations of the > same > > > > > underlying procedure, right? Can't we minimize the diff between > the > > > > > paragraphs further? > > > > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > Section 5.1 > > > > > > > > > > Additionally, a Segment-List MAY be declared invalid when: > > > > > > > > > > We probably want another word here ("both"?), to specify how the > two > > > > > conditions are combined. > > > > > > > > > > > > > KT> Ack - will rephrase. > > > > > > > > > > > > > > > > > > Section 5.2 > > > > > > > > > > When the local computation is not possible (e.g., a policy's > > > tail-end > > > > > is outside the topology known to the headend) or not desired, > the > > > > > headend MAY send path computation request to a PCE supporting > PCEP > > > > > extension specified in [RFC8664]. > > > > > > > > > > missing article ("the PCEP extension"). I forget if it should be > > > > > "extensions" plural. > > > > > > > > > > > > > KT> Ack > > > > > > > > > > > > > > > > > > Section 8.7 > > > > > > > > > > Finally, headend H MAY be configured with a local routing poli= cy > > > > > which overrides any BGP/IGP path and steer a specified packet > on an > > > > > > > > > > singular/plural mismatch -- s/steer/steers/ > > > > > > > > > > > > > KT> Ack. > > > > > > > > Thanks, > > > > Ketan > > > > > > > --0000000000003fb60905da9de502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for you= r time and your response. Please check inline below with KT3.
We've also posted an update with changes to address your co= mments:=C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21=


On Sun, Mar 20, 2022 at 12:54 AM Benjamin Kaduk &l= t;kaduk@mit.edu> = wrote:
Hi Ketan,=

My apologies for the slow reply, there are quite a few things for me to
wrap up before my term as AD ends.=C2=A0 As you put it in your graceful not= e
off-list, we are very close.

More inline...

On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote:
> Hi Ben,
>
> Thanks for your response and please check inline below with KT2
>
> We've also just posted another update to address some of your comm= ents and
> those from other ADs.
>
> https://datatr= acker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19
>
> On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Hi Ketan,
> >
> > Thanks for the replies here and the updates in the -18.
> > I think there are still some open topics, though; more inline. > >
> > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote:=
> > > Hi Ben,
> > >
> > > Thanks for your detailed review and your comments/inputs. Pl= ease check
> > > inline for responses.
> > >
> > >
> > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatrac= ker <
> > > norepl= y@ietf.org> wrote:
> > >
> > > > Benjamin Kaduk has entered the following ballot positio= n for
> > > > draft-ietf-spring-segment-routing-policy-17: Discuss > > > >
> > > > When responding, please keep the subject line intact an= d 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/blog/handlin= g-iesg-ballot-positions/
> > > > for more information about how to handle DISCUSS and CO= MMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be= found here:
> > > >
> > https://datatrac= ker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > DISCUSS:
> > > > -------------------------------------------------------= ---------------
> > > >
> > > > (1) I may just be misunderstanding things, but I'd = like to pull on a
> > thread
> > > > in =C2=A78.4 a bit more.=C2=A0 We say that the headend = H learns a BGP route that
> > has
> > > > a
> > > > VPN label V, but then the following procedures seem to = say that we
> > install
> > > > a
> > > > route on the appropriate SR Policy P and that when we r= eceive a packet
> > that
> > > > matches the route in question, push a label stack inclu= ding the VPN
> > label,
> > > > and send the resulting packet out.
> > >
> > >
> > > KT> Note that we are sending the packet to the selected B= GP NH (i.e.
> > egress
> > > PE) that advertised the route. The SR Policy is enabling the= packets to
> > > traverse a path that is different from (perhaps) the best-ef= fort IGP
> > > routing.
> > >
> > >
> > > > Nowhere do we say to check the VPN
> > > > status of the incoming packet,
> > >
> > >
> > > KT> That is the ingress part of the forwarding entry whic= h maps the
> > > incoming traffic over a customer interface to their specific= VPN context
> > > and then performs a lookup in their VPN specific table. This= all is
> > > unchanged.
> > >
> > >
> > > > so this seems like it would open a hole in
> > > > the VPN by allowing "arbitrary" incoming traf= fic (not marked as
> > specific to
> > > > V) to enter that VPN.=C2=A0 Is the label V filling some= other role than
> > > > identifying a specific VPN of many VPNs that could run = along the route
> > R/r?
> > > > (This is the only instance of the phrase "VPN labe= l" in the document,
> > and
> > > > no
> > > > reference is given, so I'm relying heavily on insti= nct to ascertain the
> > > > intent here.)
> > > >
> > >
> > > KT> I hope my responses clarified that the only thing tha= t is changed
> > here
> > > by the steering over the SR Policy is the path taken through= the network
> > to
> > > get to the egress PE. Rest is as today. And yes, of course, = we have the
> > > ability to indicate the need for such steering via the match= ing Color
> > > Extended community to the BGP route.
> >
> > Yes, these help clarify that the part we're focusing on in th= is document is
> > conceptually "after" the determination of the incoming = VPN, and so there
> > isn't any new processing needed for it.=C2=A0 Thanks for the = explanation.
>
>
> > >
> > > >
> > > > (2) The security considerations says that this document= does not
> > define any
> > > > new protocol extensions and (accordingly) does not intr= oduce any
> > further
> > > > security considerations.=C2=A0 The first part of this s= eems false, not least
> > > > since we define the meaning of the "CO" bits = in the Color Extended
> > > > Community.=C2=A0 I'm pretty sure that makes the sec= ond part also false, and
> > we
> > > > need to discuss the security considerations relating to= imposing SR
> > > > Policies
> > > > based only on color and not next-hop.=C2=A0 Alvaro has = also noted additional
> > > > aspects where security considerations are missing.
> > > >
> > >
> > > KT> Ack. We will add text in the security consideration s= ections for the
> > CO
> > > steering modes.
> >
> > What about the SR-DB concept and other new concepts that Alvaro i= dentified?
> > Aren't there security and manageability considerations there = as well?
> >
>
> KT2> We've just added text for the endpoint uniqueness and stee= ring
> aspects. The SRDB is internal to the computation node and the informat= ion
> within it is derived from existing routing protocols and their extensi= ons -
> we are not adding anything new to it. Do let me know, however, if you = feel
> we are missing something.

I see that Alvaro has cleared his Discuss, so I am willing to consider this=
topic closed.=C2=A0 I did not think very hard about whether there is anythi= ng
missing, so accordingly I don't have anything to propose adding.

>
> > >
> > > >
> > > > (3) The Discriminator as defined in =C2=A72.5 does not = seem wide enough to
> > be
> > > > able to provide the needed properties.=C2=A0 Some later= clarification in
> > =C2=A72.6
> > > > implies that the definition in =C2=A72.5 is incomplete = and the width is
> > actually
> > > > appropriate, but in either case =C2=A72.5 seems inadequ= ate in its current
> > form.
> > > > (Details in the COMMENT.)
> > > >
> > >
> > > KT> 32 bit is wide enough and please see further response= below.
> >
> > I think I'm still failing to understand exactly why; more bel= ow.
> >
> > > >
> > > > (4) Section 2.11 contains the statement, "A valid = SR Policy is
> > instantiated
> > > > in the forwarding plane."
> > > >
> > > > Is this a statement of fact (i.e., a consequence of the= definition of
> > > > "valid") or a mandate for something (e.g., th= e headend) to take action
> > to
> > > > make it so?=C2=A0 Given that the point of SR is to be s= tateless on nodes
> > other
> > > > than the headend, I suspect the former, but if we are r= elying on the
> > > > headend
> > > > (or some other entity) to take action to ensure this is= the case, that
> > > > needs
> > > > to be a clearly stated normative requirement.
> > > >
> > >
> > > KT> The validity of a candidate path and as an extension,= the SR Policy
> > is
> > > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy= and its
> > > constructs are instantiated in the forwarding plane.
> >
> > Would it make sense to say something like "In order to be co= nsidered valid,
> > an SR policy needs to be instantiated in the forwarding plane (Se= ction 5)"?
> >
>
> KT2> The SR Policy may be valid, but could not be instantiated into= the
> forwarding due to a resource issue. We are simply stating here that > generally only a valid SR Policy is instantiated in the forwarding pla= ne.
> We don't have the "only" here since we have use-cases as= in section 8.2
> where we do have to instantiate a "drop" entry in the forwar= ding for an
> invalid SR Policy.

Thanks for helping me understand the scenarios here.=C2=A0 A few more
alternative proposals:
"A valid SR policy is instantiated in the forwarding plane by the head= end."
"A valid SR policy is generally instantiated in the forwarding plane.&= quot;
"Generally, only valid SR policies are instantiated in the forwarding = plane."

Feel free to use any of those, a modified version thereof, or leave it
unchanged (though I would prefer to make some form of clarification, I do not plan to ask my successor to take up this as a Discuss point when my
term ends in a few days).
=C2=A0
KT3> Ack= - we've incorporated this change.


>
> >
> > >
> > > >
> > > > (5) Section 8.4 uses the phrase "any AFI/SAFI of L= ISP [RFC6830]."
> > > > There's nothing in the IANA registry for SAFI
> > > > (https://www= .iana.org/assignments/safi-namespace/safi-namespace.xhtml)
> > > > about
> > > > LISP, and RFC 6830 doesn't talk about SAFI.=C2=A0 W= hat is this referring to?
> > > >
> > >
> > > KT> Ack - there is no SAFI in LISP and the reference was = meant to be for
> > > routing of both IPv4 and IPv6 packets with LISP. Will fix th= is.
> >
> > The new text is still a bit terse/opaque for me to be confident t= hat I
> > understand properly, but I will drop the discuss point as I think= I see how
> > it works.
>
>
> > >
> > > >
> > > >
> > > > -------------------------------------------------------= ---------------
> > > > COMMENT:
> > > > -------------------------------------------------------= ---------------
> > > >
> > > > There's a lot of this document that feels like just= some informational
> > > > discussion of "here are some things that many peop= le do", "here are
> > some
> > > > possible things you can do with SR", etc..=C2=A0 T= here are also a small
> > handful
> > > > of places in the document that look to actually be spec= ifying parts of
> > > > protocol behavior (I suspect that John has already iden= tified them in
> > his
> > > > enumeration), and the overall impression ends up being = a bit jumbled,
> > > > like there are a bunch of topics stuck together without= an overarching
> > > > theme.
> > > > I think the overall content would be more valuable if d= ivided into a
> > tight
> > > > "protocol specification" portion that could s= tay at proposed standard,
> > plus
> > > > an informational "architecture details" docum= ent that contains the
> > > > in-depth exposition that didn't make it into 8402.<= br> > > > >
> > > > This draft would benefit greatly from a terminology sec= tion.=C2=A0 I note
> > in the
> > > > section-by-section comments several places where a term= is first used
> > > > without sufficient background/definition, leaving the m= atter at hand
> > > > underspecified for the reader.
> > > >
> > > > Section 2
> > > >
> > > >=C2=A0 =C2=A0 An SR Policy is a framework that enables t= he instantiation of an
> > > >=C2=A0 =C2=A0 ordered list of segments on a node for imp= lementing a source routing
> > > >
> > > > Really, an SR policy is a *framework*?=C2=A0 I thought = an SR policy was a
> > > > specific instantiation of a list of segments, or at lea= st that's what
> > I'm
> > > > getting from RFC 8402.=C2=A0 Perhaps we should say that= the general concept
> > of
> > > > SR
> > > > Policy provides a framework?
> > > >
> > >
> > > KT> Ack. Will rephrase.
> > >
> > >
> > > >
> > > > Section 2.1
> > > >
> > > >=C2=A0 =C2=A0 An SR Policy MUST be identified through th= e tuple <headend, color,
> > > >=C2=A0 =C2=A0 endpoint>.=C2=A0 In the context of a sp= ecific headend, an SR policy MUST
> > > >=C2=A0 =C2=A0 be identified by the <color, endpoint&g= t; tuple.
> > > >
> > > > These two MUSTs appear to be in (nominal) conflict.=C2= =A0 Maybe start the
> > first
> > > > one with "absent further context" or "ab= sent the context of a known
> > headend
> > > > node"?
> > > >
> > >
> > > KT> It is not "absence of context" but "wi= thin the context of a specific
> > > headend".
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 The headend is the node where the policy i= s
> > instantiated/implemented.
> > > >=C2=A0 =C2=A0 The headend is specified as an IPv4 or IPv= 6 address and is expected
> > > >=C2=A0 =C2=A0 to be unique in the domain.
> > > >
> > > > This is the first instance of the word "domain&quo= t; in this document.=C2=A0 I
> > > > suggest
> > > > using the introduction to introduce what is meant by th= e word, even if
> > just
> > > > by reference to RFC 8402.
> > > >
> > >
> > > KT> Ack. It should be SR Domain.
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 An implementation MAY allow the assignment= of a symbolic name
> > > >=C2=A0 =C2=A0 comprising printable ASCII [RFC0020] chara= cters (i.e.=C2=A0 0x20 to 0x7E)
> > > >=C2=A0 =C2=A0 to an SR Policy to serve as a user-friendl= y attribute for debugging
> > > >=C2=A0 =C2=A0 and troubleshooting purposes.=C2=A0 [...]<= br> > > > >
> > > > I agree with the other ADs that limiting to US-ASCII is= not actually
> > > > user-friendly for many users, and that the likelihood o= f some
> > > > implementations not properly enforcing such a limitatio= n to be high.
> > > > (Likewise for the other places where symbolic names are= admitted.)
> > > >
> > >
> > > KT> Please see the response to the other reviews on this = point.
> >
> > I don't find them compelling, but this is just the COMMENT se= ction so
> > you're not obligated to persuade me.
> >
> > >
> > > >
> > > > Section 2.2
> > > >
> > > >=C2=A0 =C2=A0 A dynamic candidate path expresses an opti= mization objective and a
> > > >=C2=A0 =C2=A0 set of constraints.=C2=A0 [...]
> > > >
> > > > Down in =C2=A75.2 when we discuss validation procedures= for dynamic
> > candidate
> > > > paths, we say that the optimization problem is solved &= quot;for either the
> > > > SR-MPLS or the SRv6 data-plane as specified".=C2= =A0 Does the data plane
> > need to
> > > > be specified as part of the dynamic candidate path itse= lf?
> > > >
> > >
> > > KT> Yes.
> >
> > Should we say that here, e.g., "a dynamic candidate path exp= resses an
> > optimization objective and a set of constraints within a specifie= d data
> > plane"?
> >
>
> KT2> Ack. Have clarified this in the text.
>
>
> >
> > >
> > > >
> > > > Section 2.3
> > > >
> > > >=C2=A0 =C2=A0 in Section 2.9.=C2=A0 The table below spec= ifies the RECOMMENDED default
> > > >=C2=A0 =C2=A0 values of Protocol-Origin:
> > > >
> > > > I feel like it would be useful to provide some justific= ation for why
> > the
> > > > recommended default behavior prefers BGP SR configurati= on over PCEP,
> > even
> > > > if
> > > > that justification is just "we need to have a clea= r ordering and this
> > one
> > > > is
> > > > arbitrary".
> > > >
> > >
> > > KT> Ack. Will clarify that.
> > >
> > >
> > > >
> > > > Section 2.4
> > > >
> > > >=C2=A0 =C2=A0 o=C2=A0 Node Address : represented as a 12= 8-bit value.=C2=A0 IPv4 addresses
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be encoded in the lowest= 32 bits, and the high-order bits
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be set to zero.
> > > >
> > > >=C2=A0 =C2=A0 Its application in the candidate path sele= ction is described in
> > > >=C2=A0 =C2=A0 Section 2.9.
> > > >
> > > > The tie-breaker procedure for path selection described = in =C2=A72.9 seems to
> > > > always prefer IPv4 originators over IPv6 ones (by virtu= e of preferring
> > the
> > > > smaller value).=C2=A0 I guess if we wanted to change th= at to prefer IPv6 we
> > have
> > > > the option of fc00::/7 (unique-local) or fe80::/10 (lin= k-scoped
> > unicast)
> > > > from BCP 153, but it's a bit hard to justify either= of those as
> > appropriate
> > > > on technical grounds, and since this is just a tie-brea= ker and the
> > > > Preference is explicitly preferred, it seems like this = is probably
> > "good
> > > > enough" as-is.
> > > >
> > >
> > > KT> Ack. As clarified in a recent text update in v17, pre= ference is the
> > key
> > > parameter really.
> > >
> > >
> > > >
> > > > Section 2.5
> > > >
> > > >=C2=A0 =C2=A0 The Discriminator is a 32-bit value associ= ated with a candidate path
> > > >=C2=A0 =C2=A0 that uniquely identifies it within the con= text of an SR Policy from
> > a
> > > >=C2=A0 =C2=A0 specific Protocol-Origin as specified belo= w:
> > > >
> > > > What are the constraints that underlie the 32-bit requi= rement here?
> > > > It looks like some of the scenarios are going to involv= e uncoordinated
> > > > (random) assignment of these discriminator values (e.g.= , with the BGP
> > > > distribution mechanism, when coming from different BGP = peers), and the
> > > > birthday-bound collision probability is not negligible = for this few
> > bits.
> > > > That, in turn, calls into question the "uniquely i= dentifies" property
> > being
> > > > claimed.=C2=A0 Or is there some other property that mea= ns that only
> > > > discriminators from a single issuer will ever need to b= e compared with
> > each
> > > > other (making the allocation "coordinated"), = such as being additionally
> > > > associated with the originator?
> > > > If my initial analysis was incorrect and these are inde= ed allocated in
> > a
> > > > "coordinated" fashion, would it be typical/ex= pected for the allocation
> > to
> > > > occur by incrementing a local counter on the originator= ?=C2=A0 In some
> > > > situations
> > > > such allocation by counter can have security considerat= ions, which
> > > > draft-gont-numeric-ids-sec-considerations attempts to c= over.
> > > >
> > >
> > > KT> The discriminator is scoped to a particular originati= ng node for the
> > > candidate path and as such, there is no requirement for coor= dination
> > across
> > > sources/nodes. Therefore, 32-bit is more than sufficient. > >
> > When you say "originating node", does that refer to the= SR headend, or the
> > (BGP) originator of the BGP route containing the SR Policy NLRI?<= br> > >
>
> KT2> The BGP originator as you've correctly understood below. >
>
> >
> > I assume the latter, and agree that *within the context of BGP*, = the
> > discriminator is scoped to the originating BGP node.=C2=A0 But th= e description
> > we give in =C2=A72.5 of this document does not say anything about= making use of
> > such information.=C2=A0 As far as I know, the BGP originator info= rmation is lost
> > when the BGP distinguisher is converted into the SR Policy candid= ate path
> > discriminator data model.
>
>
> KT2> The BGP originator information is not lost. We have clarified = this in
> the text below in sec 2.5 itself:
>
>=C2=A0 =C2=A0 o=C2=A0 When signaling is via BGP SR Policy, the BGP proc= ess receiving the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0route provides the distinguisher (refer to S= ection 2.1 of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-idr-segment-routing-te-policy
> <https://datatracker.ietf.org/doc/html/dra= ft-ietf-spring-segment-routing-policy-18#ref-I-D.ietf-idr-segment-routing-t= e-policy>])
> as the discriminator.

I think this is trying to cover too much subtlety to be accessible to all readers.=C2=A0 Thanks for the pointer to
draft-filsfils-spring-sr-policy-considerations below, that seems to help clarify that the intent is that collisions on BGP distinguisher are
expected to be resolved within the BGP layer using BGP best-path selection,=
so that only a single candidate path is received by the SR layer from BGP for a given distinguisher/discriminator, even if the BGP agent on the SR node receives multiple routes that could be candidate paths prior to the BGP bestpath selection.

KT3> This is= standard BGP operations given the NLRI design and the referenced sec 2.1 o= f draft-ietf-idr-segment-routing-te-policy touches upon the use of differen= t discriminators when the CP for the same SR Policy needs to be sent to the= SR layer from BGP layer.
=C2=A0

It seems that there are a number of ways that we could modify this document=
to clarify; let me list a couple (but these are not intended to be
exhaustive):

- in this chunk of text, add another sentence like "Note that BGP best= path
=C2=A0 selection is applied before the route is supplied as a candidate pat= h, so
=C2=A0 only a single candidate path will be seen for a given discriminator.= "

- In the preface at the top of =C2=A72.5 before the list of per-Protocol-Or= igin
=C2=A0 discussions, add a note that "each Protocol-Origin is expected = to apply
=C2=A0 any processing needed to ensure that only a single candidate path is=
=C2=A0 supplied with a given Discriminiator value"

KT3> Ack - we have incorporated the 1st text above.
=C2=A0

>
>
> > And we don't say anything about how candidate
> > paths for a given SR Policy can only be originated from a single = BGP node,
> > so I have to account somehow for the possibility that two BGP nod= es are
> > independently announcing candidate paths for the same SR Policy, = and thus
> > might collide in their assignment of distinguisher.
>
>
> KT2> You are correct. This can and does indeed happen today in depl= oyments
> for redundancy and other reasons.
>
>
> > Whereas BGP can
> > resolve that collision via the BP origination information, I don&= #39;t see how
> > that would be done in the SR data model.=C2=A0 Does that help you= understand
> > what part I am missing?
> >
>
> KT2> We did have some text in this document in the early days to ex= plain
> these scenarios but it was moved out to an individual draft. Sec 2.9 h= as a
> pointer to this informative draft. Please check
> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-con= siderations-08#section-4
> and if they clarify.

(As indicated above, they do clarify, but that draft is not referenced here=
and is not a normative reference, so I must insist on further changes to this document.)

KT3> The draft-filsf= ils-spring-sr-policy-considerations is providing only the illustrations and= the normative behavior is covered in this document (i.e., the tiebreaker r= ules) while the BGP protocol behavior is defined in draft-ietf-idr-segment-= routing-te-policy document. Please note that the initial versions of this d= raft did have those illustrations in them but were moved out to a separate = document as part of the WG process.
=C2=A0

>
> >
> >
> > >
> > > >
> > > > Section 2.8
> > > >
> > > >=C2=A0 =C2=A0 A candidate path is usable when it is vali= d.=C2=A0 A common path validity
> > > >=C2=A0 =C2=A0 criterion is the validity of any of its co= nstituent Segment-Lists.
> > > >=C2=A0 =C2=A0 The validation rules are specified in Sect= ion 5.
> > > >
> > > > This document claims to target Proposed Standard status= ; are we really
> > > > content to say only that this is "a common" c= riterion?=C2=A0 Even when we
> > also
> > > > go
> > > > on to flat-out state "the validation rules are spe= cified [below]"?
> > > >
> > >
> > > KT> We will change this to introduce the word RECOMMENDED= . There are
> > > deployments where an operator might need a local policy to d= eclare the
> > > candidate path invalid when the number of valid SLs drops be= low a certain
> > > threshold (for b/w or load-balancing considerations).
> > >
> > >
> > > >
> > > > Section 2.9
> > > >
> > > >=C2=A0 =C2=A0 The candidate path selection process opera= tes primarily on the
> > > >=C2=A0 =C2=A0 candidate path Preference.=C2=A0 A candida= te path is selected when it is
> > > >=C2=A0 =C2=A0 valid and it has the highest preference va= lue among all the
> > candidate
> > > >=C2=A0 =C2=A0 paths of the SR Policy.
> > > >
> > > > Should this be "among all the valid candidate path= s"?=C2=A0 A path that's
> > > > invalid
> > > > is still invalid, even if it has the highest preference= value.
> > > >
> > >
> > > KT> Ack - will clarify this.
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 2.=C2=A0 If specified by configuration, pr= efer the existing installed
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 path.
> > > >
> > > > Does "if specified by configuration" refer to= the act of applying this
> > rule
> > > > at all, or that the existing installed path was one spe= cified by
> > > > configuration?
> > > >
> > >
> > > KT> The existing installed path. The rationale was that i= n some
> > deployment
> > > designs an operator may not want to disturb/churn an active = and
> > > valid/working path that has been installed in the forwarding= .
> > >
> > >
> > > >
> > > > Section 2.11
> > > >
> > > >=C2=A0 =C2=A0 The fraction of the flows associated with = a given Segment-List is w/
> > > >=C2=A0 =C2=A0 Sw, where w is the weight of the Segment-L= ist and Sw is the sum of
> > > >=C2=A0 =C2=A0 the weights of the Segment-Lists of the se= lected path of the SR
> > > >=C2=A0 =C2=A0 Policy.
> > > >
> > > > Thank you for stating this clearly!
> > > >
> > > > Section 3
> > > >
> > > >=C2=A0 =C2=A0 o=C2=A0 TE Link Attributes (such as TE met= ric, Shared Risk Link Groups,
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0attribute-flag, extended admi= n group) [RFC5305] [RFC3630].
> > > >
> > > > Is RFC 5329 applicable here as well?
> > > >
> > >
> > > KT> Yes, will add that. Thanks.
> >
> > (It looks like a second 3630 reference got added in the -18, not = 5329; I'll
> > mention that in my updated ballot remarks as well.)
> >
>
> KT2> Ooops :-( .. now fixed for real
>
>
> >
> > >
> > > >
> > > > Section 4
> > > >
> > > >=C2=A0 =C2=A0 Type E: IPv4 Prefix with Local Interface I= D:
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This type allows iden= tification of Adjacency SID or BGP Peer
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adjacency SID (as def= ined in [RFC8402]) SR-MPLS label for
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point-to-point links = including IP unnumbered links.=C2=A0 The
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 headend is required t= o resolve the specified IPv4 Prefix
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address to the Node o= riginating it and then use the Local
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interface ID to ident= ify the point-to-point link whose
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 adjacency is being re= ferred to.=C2=A0 The Local Interface ID link
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descriptor follows se= mantics as specified in [RFC7752].=C2=A0 This
> > > >
> > > > The phrase "local interface ID" does not appe= ar in RFC 7752 (and even
> > > > "local
> > > > interface" appears just once"; please use ter= minology actually present
> > in
> > > > the referred-to document to clarify what is being refer= enced.
> > > >
> > >
> > > KT> This one is a bit complicated since RFC7752 (sec 3.2.= 2) in turn
> > > references RFC5307 which in turn RFC4202. We use RFC7752 sin= ce it covers
> > > and explains the use of the various link descriptors that we= use for
> > > various segment types.
> > >
> > >
> > > >
> > > > Section 4.1
> > > >
> > > >=C2=A0 =C2=A0 When steering unlabeled IPv6 BGP destinati= on traffic using an SR
> > > >=C2=A0 =C2=A0 policy composed of Segment-List(s) based o= n IPv4 SIDs, the Explicit
> > > >=C2=A0 =C2=A0 Null Label Policy is processed as specifie= d in
> > > >=C2=A0 =C2=A0 [I-D.ietf-idr-segment-routing-te-policy]) = Section 2.4.4.=C2=A0 When an
> > > >
> > > > It looks like this is =C2=A72.4.5, not 2.4.4, in the re= ferenced document.
> > > >
> > >
> > > KT> Ack. Will fix.
> > >
> > >
> > > >
> > > > Section 5.1
> > > >
> > > >=C2=A0 =C2=A0 The computation/logic that leads to the ch= oice of the Segment-List
> > is
> > > >=C2=A0 =C2=A0 external to the SR Policy headend.=C2=A0 T= he SR Policy headend does not
> > > >=C2=A0 =C2=A0 compute the Segment-List.=C2=A0 The SR Pol= icy headend only confirms its
> > > >=C2=A0 =C2=A0 validity.
> > > >
> > > > Does the headend actually have to confirm validity?=C2= =A0 Is it okay to just
> > > > trust the controller and blindly use what is provided?<= br> > > > >
> > >
> > > KT> At least the first segment needs to be validated from= a resolvability
> > > perspective. The subsequent segments depend on how (i.e., us= ing what
> > > segment types) the controller has signalled the path to the = headend. If
> > it
> > > is indicated by just referring to a Prefix (e.g. loopback) o= f a node,
> > then
> > > the headend will need to resolve and as such validate. While= if specified
> > > as a label, then no resolution is required.
> >
> > Hmm.=C2=A0 So maybe we could say "the SR Policy headend only= confirms the
> > validity of any segments that it needs to resolve as part of pack= et
> > processing"?=C2=A0 Or does that not actually convey the need= ed information?
> >
>
> KT2> IMHO, the term used in the draft "path resolution to the = SID" is more
> informative and cleared (at least to someone working on the programmin= g of
> forwarding entries) than "packet processing".

Okay, I am happy to defer to your domain expertise.

>
> >
> > >
> > > >
> > > > Section 6.2
> > > >
> > > >=C2=A0 =C2=A0 When the active candidate path has a speci= fied BSID, the SR Policy
> > > >=C2=A0 =C2=A0 uses that BSID if this value (label in MPL= S, IPv6 address in SRv6)
> > is
> > > >=C2=A0 =C2=A0 available (i.e., not associated with any o= ther usage: e.g. to
> > another
> > > >=C2=A0 =C2=A0 MPLS client, to another SRv6 client, to an= other SID, to another SR
> > > >=C2=A0 =C2=A0 Policy, outside the range of SRv6 Locators= ).
> > > >
> > > > I don't think I understand what is meant by "c= lient" here (for "another
> > > > client").=C2=A0 This sentence is the only place wh= ere the word "client"
> > appears
> > > > in this document...
> > > >
> > >
> > > KT> The term is "MPLS client" or "SRv6 cli= ent". MPLS clients can be IS-IS
> > > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate l= abel from a
> > > "label manager" within the router.
> >
> > I think this explanation actually makes me more concerned about t= he way
> > this is written than I previously was.=C2=A0 It seems to imply th= at we are
> > trying to describe both that there is an MPLS vs SRv6 data-plane = in use and
> > that the node in question is a client of some unspecified protoco= l that can
> > allocate SIDs/MPLS labels, which could be as varied as an IGP or = a
> > dedicated path computation protocol.=C2=A0 Furthermore, not all o= f these
> > possible protocols would intrinsically provide for arbitrary head= end nodes
> > to even know if the label/SID in question has already been alloca= ted to
> > another "client"!
>
>
> > Is the determination of availability to be made by the controller= or by the
> > headend?
>
>
> KT2> This is local on the headend.
>
>
> > I think we should state that clearly, since (given the above
> > discussion) it seems like it is the controller that is best place= to
> > actually make the determination, but the phrasing "the SR Po= licy uses"
> > implies (at least to me) that the determination is made on the he= adend,
> > since it is the headend that actually instantiates the policy. > >
>
> KT2> The controller can (and does in some of the deployments that I= am
> aware of) keep track of the usage of the Labels in the SRGB and SRLB (= refer
> RFC8402). The same goes for SRv6 SIDs from under the SRv6 Locator. In<= br> > deployments where controllers do drive the whole SR Policy provisionin= g,
> they do keep track. However, this is not mandatory in general. The hea= dend
> is taking care of the actual programming into the forwarding and doesn= 't
> have any option but to handle these conditions.

Okay.=C2=A0 I might consider coalescing "to another MPLS client, to an= other SRv6
client" down to "to another node in the SR domain" since it&= #39;s not worth
adding enough detail to fully clarify "MPLS client" and "SRv= 6 client", but
it's up to you.

KT3> We have edi= ted the text to expand a bit on what is meant by "client" here.
=C2=A0

>
> >
> > >
> > > >
> > > >=C2=A0 =C2=A0 Optionally, instead of only checking that = the BSID of the active
> > path
> > > >=C2=A0 =C2=A0 is available, a headend MAY check that it = is available within a
> > given
> > > >=C2=A0 =C2=A0 SID range i.e., Segment Routing Local Bloc= k (SRLB) as specified in
> > > >=C2=A0 =C2=A0 [RFC8402].
> > > >
> > > > Is the only allowed range to check the SRLB?=C2=A0 If n= ot, I think we need
> > to
> > > > s/i.e./e.g./.
> > > >
> > >
> > > KT> Yes, SRLB is the one to check/allocate from for such = usage.
> >
> > Okay.=C2=A0 I suspect we want s/a given/the given/ then, but am n= ot 100% sure.
> >
>
> KT2> Ack. Fixed.
>
>
> > >
> > > >
> > > >=C2=A0 =C2=A0 When the specified BSID is not available (= optionally is not in the
> > > >=C2=A0 =C2=A0 SRLB), an alert message MUST be generated.=
> > > >
> > > > This is the first time (of only two) the word "ale= rt" appears in this
> > > > document, and there is no prior expalanation of what en= tity might be
> > > > receiving alerts generated by a headend.=C2=A0 Please c= larify.
> > > >
> > >
> > > KT> Alert mechanism could be one or more of syslog, Netco= nf
> > notification, a
> > > telemetry mechanism, etc..
> >
> > I think the clarification is best placed in the document itself, = e.g., in a
> > glossary/terminology section as I suggested in my high-level comm= ents.
> >
>
> KT2> We have clarified inline.
>
>
> >
> > >
> > > >
> > > >=C2=A0 =C2=A0 Assuming that at time t the BSID of the SR= Policy is B1, if at time
> > > >=C2=A0 =C2=A0 t+dt a different candidate path becomes ac= tive and this new active
> > > >=C2=A0 =C2=A0 path does not have a specified BSID or its= BSID is specified but is
> > > >=C2=A0 =C2=A0 not available (e.g. it is in use by someth= ing else), then the SR
> > > >=C2=A0 =C2=A0 Policy MAY keep the previous BSID B1.
> > > >
> > > > Is there a strict bound on or other guidance for what v= alues of dt are
> > > > allowable for this purpose?
> > >
> > >
> > > KT> None
> > >
> > >
> > > >=C2=A0 =C2=A0Is the intent that there be an atomic
> > > > transition from BSID=3DB1;active-path=3DP1 to BSID=3DB1= ;active-path=3DP2?
> > > >
> > >
> > > KT> There is no atomicity requirement. A switch from one = active CP to
> > > another will vary depending on the cause of the switch - e.g= . if it is
> > due
> > > to a failure or because a more preferred path came up.
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 The association of an SR Policy with a BSI= D thus MAY change over the
> > > >=C2=A0 =C2=A0 life of the SR Policy (e.g., upon active p= ath change).=C2=A0 Hence, the
> > > >=C2=A0 =C2=A0 BSID SHOULD NOT be used as an identificati= on of an SR Policy.
> > > >
> > > > Is there any guidance available on how long to wait wit= h a given BSID
> > value
> > > > unused before binding it to a new SR Policy?
> > > >
> > >
> > > KT> None. These depend on the implementation and scenario= s like resource
> > > availability e.g., a BSID might get re-used sooner if the sy= stem is
> > running
> > > short of labels.
> > >
> > >
> > > >
> > > > Section 6.2.3
> > > >
> > > >=C2=A0 =C2=A0 An implementation MAY support the configur= ation of the Specified-
> > > >=C2=A0 =C2=A0 BSID-only restrictive behavior on the head= end for all SR Policies or
> > > >=C2=A0 =C2=A0 individual SR Policies.=C2=A0 Further, thi= s restrictive behavior MAY also
> > > >=C2=A0 =C2=A0 be signaled on a per SR Policy basis to th= e headend.
> > > >
> > > > Elsewhere in the document we discuss specific potential= signaling
> > > > mechanisms/protocols, but here we say nothing.=C2=A0 Is= that vagueness
> > > > intentional?
> > > >
> > >
> > > KT> Since this isn't a protocol specification the mec= hanism is not
> > > described here. However, you can look at
> > >
> > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-t= e-policy-14#section-2.4.2
> > > and that document refers back to this specification.
> >
> > Okay, but if this document isn't a protocol specification and= that's
> > grounds to not describe mechanism in it, then there are quite a f= ew other
> > places in the document that should also not describe mechanism, i= f we want
> > to be applying the rule consistently.
> >
>
> KT2> There may be very high-level references to some mechanisms in = addition
> to the informative pointer to the specific protocol spec. This was don= e to
> improve readability.
>
>
> >
> > >
> > > >
> > > > Section 6.3
> > > >
> > > >=C2=A0 =C2=A0 A valid SR Policy installs a BSID-keyed en= try in the forwarding
> > plane
> > > >=C2=A0 =C2=A0 with the action of steering the packets ma= tching this entry to the
> > > >=C2=A0 =C2=A0 selected path of the SR Policy.
> > > >
> > > > I don't think this is stated properly.=C2=A0 An SR = Policy is the list of
> > > > segments; it isn't the entity that's installing= entries in the
> > forwarding
> > > > plane.=C2=A0 Some other entity is installing an entry i= n the forwarding
> > plane to
> > > > realize the SR Policy in question, and we should make o= ur writing
> > reflect
> > > > that.
> > > >
> > >
> > > KT> Ack. s/installs/results in the installation of
> > >
> > >
> > > >
> > > > Section 6.4
> > > >
> > > >=C2=A0 =C2=A0 An implementation MAY choose to associate = a Binding SID with any
> > type
> > > >=C2=A0 =C2=A0 of interface (e.g. a layer 3 termination o= f an Optical Circuit) or a
> > > >=C2=A0 =C2=A0 tunnel (e.g.=C2=A0 IP tunnel, GRE tunnel, = IP/UDP tunnel, MPLS RSVP-TE
> > > >=C2=A0 =C2=A0 tunnel, etc).=C2=A0 This enables the use o= f other non-SR enabled
> > > >
> > > > Should we have some discussion that contrasts this scen= ario against the
> > > > End.X behavior from RFC 8986 (for the "interface&q= uot; case)?
> > > >
> > >
> > > KT> What this document says is that a BSID may be also as= sociated to
> > direct
> > > over these other types of interfaces/tunnels. We can look at= them as
> > having
> > > no other segment being imposed but just redirecting to an in= terface. In
> > > that sense, it is somewhat similar to End.X in SRv6 (or Adja= cency SID in
> > > SR-MPLS). However, those tend to be associated with protocol=
> > adjacencies. I
> > > am not sure that I've followed your point though and ple= ase do let me
> > know
> > > if I've not.
> >
> > What you write here indicates to me that you got my point.=C2=A0 = My proposal was
> > for a sentence something like "this behavior is analogous to= the End.X
> > behavior defined in [RFC8986] in that the SID is removed, no new = SIDs
> > applied, and the packet is directed across a particular interface= , but it
> > conceptually fits better as a Binding SID since the SID is bound = to a
> > specific (logical or physical) interface and End.X is typically u= sed with
> > protocol adjacencies rather than interfaces".=C2=A0 But that= 's just a
> > suggestion, and if you think it doesn't make sense or doesn&#= 39;t add much
> > value, please ignore it.
> >
> > >
> > > >
> > > > Section 7
> > > >
> > > >=C2=A0 =C2=A0 The SR Policy State is maintained on the h= eadend to represent the
> > > >=C2=A0 =C2=A0 state of the policy and its candidate path= s.=C2=A0 [...]
> > > >
> > > > I confess I don't really understand why we need to = have the current,
> > > > minimal, description of SR Policy State in this documen= t.=C2=A0 What would
> > be
> > > > lost if we deferred its discussion entirely until there= is a more
> > > > comprehensive discussion available?
> > > >
> > >
> > > KT> We will add an informational pointer to the SR Policy= YANG model.
> > What
> > > this document calls out is the requirement for reporting the= operational
> > > state and provides pointers to other specs where this is bei= ng worked
> > out.
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 The SR Policy state can be reported by the= headend node via BGP-LS
> > > >=C2=A0 =C2=A0 [I-D.ietf-idr-te-lsp-distribution] or PCEP= [RFC8231] and
> > > >=C2=A0 =C2=A0 [I-D.ietf-pce-binding-label-sid].
> > > >
> > > > The functionality of draft-ietf-pce-binding-label-sid s= eems much more
> > > > limited than that of draft-ietf-idr-te-lsp-distribution= ; in
> > particular, the
> > > > former does not seem to actually report SR Policy state= to the headed
> > at
> > > > all; rather, it only concerns itself with BSID associat= ion to path,
> > with no
> > > > information about "active", "not preferr= ed", etc.
> > > >
> > >
> > > KT> The PCEP work might be spread out over different docu= ments but we do
> > > need to cover these requirements. That is one of the objecti= ves of having
> > > this document coordinate work across protocol WGs.
> >
> > It still feels like we're claiming something here that isn= 9;t true -- "can
> > be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]&quo= t;.=C2=A0 It seems
> > like we are really trying to say "... via extensions to PCEP= [some of which
> > don't exist yet in a form that we're willing to reference= ]".
> >
>
> KT2> This document, like some others in SPRING, does provide inform= ative
> references (perhaps still in the WG doc stage) for better readability = and
> clarity.
>
>
> > >
> > > >
> > > > Section 8.3
> > > >
> > > >=C2=A0 =C2=A0 If the SR Policy P is invalid, the BSID B = is not in the forwarding
> > > >=C2=A0 =C2=A0 plane and hence the packet K is dropped by= H.
> > > >
> > > > We literally just in the previous section talked about = a scenario
> > where the
> > > > BSDI is kept in the forwarding plane (but with the acti= on to drop, so
> > the
> > > > overall outcome is not changed from what this text desc= ribes).
> > > > Nonetheless,
> > > > it's inaccurate to state that "the BSID B is n= ot in the forwarding
> > plane"
> > > > here.
> > > >
> > >
> > > KT> There is a difference between the drop being referred= to in 8.2 and
> > > 8.3. What we have in 8.2 is like a route pointing to null wh= ere we may
> > > advertise and get packets but will drop it with normal count= ers
> > associated
> > > with that specific entry. While 8.3 is like we are dropping = because we
> > have
> > > no route (ideally we shouldn't have got the packet) and = we increment a
> > > generic lookup failed counter. The use-cases for both are di= fferent.
> >
> > I (think I) understand that the mechanisms are different and both= have use
> > cases.=C2=A0 I just don't think that the specific combination= of words used here
> > makes a true statement.=C2=A0 There are probably a number of ways= to make a
> > slight
> > adjustment and come up with a true statement, such as starting it= with a
> > caveat as in "When Drop-Upon-Invalid behavior is not in use,= for an invalid
> > SR Policy P, its BSID B is not in the forwarding plane and hence = the packet
> > K is dropped by H".
> >
>
> KT2> Thanks for that suggestion. We've incorporated it.
>
>
> >
> > >
> > > >
> > > > Section 8.4.1
> > > >
> > > >=C2=A0 =C2=A0 When a BGP route has multiple Color Extend= ed communities each with a
> > > >=C2=A0 =C2=A0 valid SR Policy, the BGP process installs = the route on the SR Policy
> > > >=C2=A0 =C2=A0 giving preference to the color with the hi= ghest numerical value.
> > > >
> > > > Do we want to say anything about this being an arbitrar= y tiebreaker
> > (rather
> > > > than an intentional preference), or is that thought to = be implicitly
> > clear?
> > > >
> > >
> > > KT> It is an intentional preference.
> >
> > Peeking forward to =C2=A78.8.2, is this also referring to the BGP= color rather
> > than the SR Policy color?=C2=A0 If so, please specifically qualif= y the word
> > "color" as being the BGP one.
> >
> > If not, then I strongly suggest that the introduction of color in= =C2=A72.1
> > state that the numerical value of the color is used as a preferen= ce
> > mechanism in addition to indicating intent or objective (with the=
> > implication or explicit statement that assignment of color values= must be
> > performed in a manner that is compatible with the operator's<= br> > > preference/policy).
> >
>
> KT2> This document needs to refer to the "BGP color" as t= he "Color Extended
> Community". Thanks for catching that. This is not done in a few p= laces and
> we've fixed that.

Many thanks for those fixes, it is a big help.


>
> >
> > >
> > > >
> > > > Section 8.5
> > > >
> > > >=C2=A0 =C2=A0 In this section, independent of the a-prio= ri existence of any
> > > >=C2=A0 =C2=A0 explicit candidate path of the SR policy (= C, N), it is to be noted
> > > >=C2=A0 =C2=A0 that the BGP process at headend node H tri= ggers the instantiation of
> > > >=C2=A0 =C2=A0 a dynamic candidate path for the SR policy= (C, N) as soon as:
> > > >
> > > > I strongly suggest providing a more explicit framework = of what the
> > > > assumptions and preconditions are for the mechanism des= cribed in this
> > > > section.=C2=A0 My intuition says that it's a fairly= optional thing that
> > would
> > > > need to be specifically configured, but trying to wrap = that sentiment
> > into
> > > > the long bullet point involving "a local policy&qu= ot; seems like a very
> > > > confusing
> > > > way to express the desired behavior.
> > > >
> > >
> > > KT> It is actually a matter of local policy with perhaps = some template
> > and
> > > configuration to drive this. I believe this should get cover= ed in the SR
> > > Policy YANG model at some point in time.
> > >
> > >
> > > >
> > > > Section 8.6
> > > >
> > > >=C2=A0 =C2=A0 o=C2=A0 is configured to instantiate an ar= ray of paths to N where the
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0entry 0 is the IGP path to N,= color C1 is the first entry and
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Color C2 is the second entry.= =C2=A0 The index into the array is called
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0a Forwarding Class (FC).=C2= =A0 The index can have values 0 to 7.
> > > >
> > > > Why are the only allowed values 0 to 7?=C2=A0 Where doe= s this restriction
> > arise
> > > > from?=C2=A0 It is because of some protocol element?
> > > >
> > >
> > > KT> There is text further in the section to indicated tha= t these
> > > ranges/values are implementation-specific. Historically, the= 8 values
> > have
> > > come from the MPLS EXP bits.
> >
> > If the ranges/values are implementation-specific, then don't = give a
> > specific range here stated as if it is a universal limitation!=C2= =A0 I would
> > either drop the sentence entirely or say something like "whe= n the index is
> > conveyed using the MPLS EXP bits, only indices 0 to 7 are usable&= quot;.
> >
>
> KT2> Ack. Have clarified.
>
>
> >
> > >
> > > >
> > > >=C2=A0 =C2=A0 If the local configuration does not specif= y any explicit forwarding
> > > >=C2=A0 =C2=A0 information for an entry of the array, the= n this entry is filled
> > with
> > > >=C2=A0 =C2=A0 the same information as entry 0 (i.e. the = IGP shortest path).
> > > >
> > > >=C2=A0 =C2=A0 If the SR Policy mapped to an entry of the= array becomes invalid,
> > > >=C2=A0 =C2=A0 then this entry is filled with the same in= formation as entry 0.
> > When
> > > >=C2=A0 =C2=A0 all the array entries have the same inform= ation as entry0, the
> > > >=C2=A0 =C2=A0 forwarding entry for N is updated to bypas= s the array and point
> > > >=C2=A0 =C2=A0 directly to its outgoing interface and nex= t-hop.
> > > >
> > > > I can't tell how much of this is supposed to be pro= tocol specification
> > and
> > > > how much an illustrative example.=C2=A0 Is A(0) always = the IGP shortest
> > path?
> > > > Are these protocol requirements to fall back to the IGP= shortest path
> > when
> > > > an entry is otherwise unpopulated or the associated SR = Policy becomes
> > > > invalid?
> > > >
> > >
> > > KT> The specifics are for illustration purposes. Most of = these are policy
> > > knobs/options.
> >
> > Please add a note at the top of the section that "this secti= on provides an
> > example of how a headend might apply per-flow steering in practic= e".
> >
>
> KT2> Ack. Added.
>
>
> >
> > >
> > > >
> > > > Section 8.8.2
> > > >
> > > >=C2=A0 =C2=A0 The steering preference is first based on = the highest color value
> > and
> > > >=C2=A0 =C2=A0 then CO-dependent for the color.=C2=A0 [..= .]
> > > >
> > > > This seems to contradict what I assumed earlier about t= he "highest
> > color"
> > > > rule being a tiebreaker, e.g., the word "preferenc= e" is used here.=C2=A0 Is
> > it
> > > > actually intended to be a deliberately configured prior= ity/preference
> > > > scheme?=C2=A0 If so, that would seem to require some wi= de-ranging reworking
> > > > throughout the document.
> > > >
> > >
> > > KT> There is the color that is in the identification of a= n SR Policy -
> > > (color, endpoint). This does not get into any tiebreaker or = selection
> > > logic. All that (sec 2.9) is about the selection of a candid= ate path
> > within
> > > an SR Policy. Then there is the color value signaled via the= Color
> > Extended
> > > community on the BGP routes and here, we have the preference= for higher
> > > color when the route is advertised with multiple colors tagg= ed to it.
> >
> > I think you should clarify that this section refers to the BGP Co= lor, then
> > -- previously in the document it has been the SR Policy color val= ue and an
> > unqualified reference to "color value" seems like it re= fers to the concept
> > defined in this document, absent other qualifiers.
> >
>
> KT2> Ack. Fixed references as mentioned in a previous comment.
>
>
> >
> > >
> > > >
> > > > Section 9.3
> > > >
> > > >=C2=A0 =C2=A0 the most appropriate alternative for the a= ctive candidate path.=C2=A0 A
> > > >=C2=A0 =C2=A0 fast re-route mechanism MAY then be used t= o trigger sub 50msec
> > > >=C2=A0 =C2=A0 switchover from the active to the backup c= andidate path in the
> > > >=C2=A0 =C2=A0 forwarding plane.=C2=A0 Mechanisms like Bi= directional Forwarding
> > Detection
> > > >=C2=A0 =C2=A0 (BFD) MAY be used for fast detection of su= ch failures.
> > > >
> > > > Why is the specific 50msec value important here?=C2=A0 = Is there some other
> > > > requirement that imposes it?
> > > >
> > >
> > > KT> This comes from "typical" expectations from= fast-reroute mechanisms.
> >
> > I'd consider '''to trigger "fast" (sub = 50msec) switchover''', then, but
> > it's not very important.
> >
> > >
> > > >
> > > > Section 10
> > > >
> > > > I think we also want to mention the security considerat= ions of several
> > more
> > > > documents, including (but not limited to)
> > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660,= 8754, and 8986.
> > > >
> > >
> > > KT> Ack on the three RFCs, but convinced about the
> > > draft-ietf-idr-segment-routing-te-policy since that depends = on this and
> > not
> > > the other way around.
> >
> > I think this relates to John's Discuss point and whether this= document
> > specifies the protocol behavior of the two bits in the context of= the
> > extension defined in draft-ietf-idr-segment-routing-te-policy.=C2= =A0 You need to
> > understand draft-ietf-idr-segment-routing-te-policy in order to u= nderstand
> > the security considerations relating to the protocol behavior con= trolled by
> > those two bits, and IMO the protocol behavior specified by those = two bits
> > is solely the responsibility of this document, so this document m= ust
> > incorporate the security considerations of
> > draft-ietf-idr-segment-routing-te-policy in order to fully docume= nt the
> > security considerations of the concepts and protocol elements tha= t this
> > document defines.
> >
>
> KT2> I am working with John to address his comments.

Okay, the changes from -18 to -20 are looking promising, but I will let
John decide when it's done.

KT3>= Our discussion with John is ongoing and seems like might take more time. W= ould you be clearing your DISCUSS assuming the updates address your concern= s?

Thanks,
Ketan
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for all these replies and updates; I didn't respond to them
individally but they are all appreciated.

-Ben

>
>
> >
> > Thanks for this, and all the other parts I didn't specificall= y reply to.
> >
> > I will attempt to update my ballot position in the datatracker to= remove
> > the parts that are fully addressed (though I will probably inadve= rtently
> > leave in something I shouldn't have).
> >
> > -Ben
> >
> > >
> > > >
> > > > Section 15.2
> > > >
> > > > I agree with John that draft-ietf-idr-segment-routing-t= e-policy must be
> > > > classified as a normative reference.
> > > >
> > > > It also seems that RFC 7752 should be classified as nor= mative, as we
> > > > incorporate its definition for the semantics of several= of the segment
> > type
> > > > descriptions.
> > > >
> > >
> > > KT> Ack
> > >
> > >
> > > >
> > > >
> > > > NITS
> > > >
> > > > Section 1
> > > >
> > > >=C2=A0 =C2=A0 Segment Routing Policy (SR Policy) [RFC840= 2] is an ordered list of
> > > >=C2=A0 =C2=A0 segments (i.e. instructions) that represen= t a source-routed policy.
> > > >
> > > > /Segment/A Segment/
> > > >
> > >
> > > KT> Ack
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 The headend node is said to steer a flow i= nto a SR Policy.=C2=A0 The
> > > >=C2=A0 =C2=A0 packets steered into an SR Policy carry an= ordered list of segments
> > > >=C2=A0 =C2=A0 associated with that SR Policy.=C2=A0 [...= ]
> > > >
> > > > In a certain sense this can be read as saying that the = packets that
> > "carry
> > > > an ordered list of segments" are the ones prior to= being steered into
> > an SR
> > > > policy, which would make this statement not true.=C2=A0= Perhaps we want to
> > say
> > > > "after being steered into an SR Policy, packets ca= rry an ordered list
> > ..."?
> > > > (I also went back and forth with myself about whether &= quot;packets ...
> > carry"
> > > > implies in the payload or not.=C2=A0 I settled on "= ;not" but make this note
> > just
> > > > in case I am missing an aspect of that question.)
> > > >
> > >
> > > KT> Ack. Will rephrase.
> > >
> > >
> > > >
> > > > Section 2
> > > >
> > > >=C2=A0 =C2=A0 An SR Policy is a framework that enables t= he instantiation of an
> > > >=C2=A0 =C2=A0 ordered list of segments on a node for imp= lementing a source routing
> > > >
> > > > It's easy to read this as saying that all of the se= gments in the list
> > > > instantiated on the single node in question, which I as= sume is not the
> > > > intent.=C2=A0 Probably the easiest way to aid readabili= ty here is to split
> > the
> > > > sentence up into multiple smaller sentences that are ea= sier to parse.
> > > >
> > >
> > > KT> Will rephrase.
> > >
> > >
> > > >
> > > > Section 2.2
> > > >
> > > >=C2=A0 =C2=A0 A dynamic candidate path expresses an opti= mization objective and a
> > > >=C2=A0 =C2=A0 set of constraints.=C2=A0 The headend (pot= entially with the help of a
> > PCE)
> > > >=C2=A0 =C2=A0 computes the solution Segment-List (or set= of Segment-Lists) that
> > > >=C2=A0 =C2=A0 solves the optimization problem.
> > > >
> > > > I'd suggest computes the solution/computes a soluti= on/ for genericity.
> > > >
> > >
> > > KT> Ack.
> > >
> > >
> > > > A stateful PCE might end up computing a path that is no= t the optimal
> > one
> > > > for
> > > > this specific optimization problem, due to a desire to = cooperate with
> > other
> > > > paths in the network, and the "Min-Metric with mar= gin and maximum
> > number of
> > > > SIDs" objective in draft-filsfils-spring-sr-policy= -considerations
> > doesn't
> > > > even have a guaranteed unique best solution.
> > > >
> > > > Section 2.5
> > > >
> > > >=C2=A0 =C2=A0 When provisioning is via configuration, th= is is an implementation's
> > > >=C2=A0 =C2=A0 configuration model-specific unique identi= fier for a candidate path.
> > > >=C2=A0 =C2=A0 The default value is 0.
> > > >
> > > > I'm having a lot of trouble parsing this.=C2=A0 Did= we perhaps mean to
> > hyphenate
> > > > as "configuration-model-specific"?
> > > >
> > >
> > > KT> Ack
> > >
> > >
> > > >
> > > > Section 2.13
> > > >
> > > >=C2=A0 =C2=A0 The SR Policy POL1 is identified by the tu= ple <headend, color,
> > > >=C2=A0 =C2=A0 endpoint>.=C2=A0 It has two candidate p= aths CP1 and CP2.=C2=A0 Each is
> > > >=C2=A0 =C2=A0 identified by a tuple <protocol-origin,= originator, discriminator>.
> > > >
> > > > I suggest (for the last sentence) "identified with= in the scope of POL1"
> > > >
> > >
> > > KT> Ack
> > >
> > >
> > > >
> > > >=C2=A0 =C2=A0 forwarding instantiation of SR policy POL1= .=C2=A0 Traffic steered on POL1
> > > >=C2=A0 =C2=A0 is flow-based hashed on Segment-List <S= ID11...SID1i> with a ratio
> > > >=C2=A0 =C2=A0 W1/(W1+W2).
> > > >
> > > > If I read "ratio" I would instinctively think= of the ratio of (traffic
> > on
> > > > segment list 1)/(traffic on segment list 2), as opposed= to the
> > proportion
> > > > of
> > > > all traffic, that would be measured as the indicated W1= /(W1+W2).
> > > >
> > >
> > > KT> Ack. s/ratio/proportion
> > >
> > >
> > > >
> > > > Section 3
> > > >
> > > >=C2=A0 =C2=A0 The attached domain topology may be learne= d via IGP, BGP-LS or
> > > >=C2=A0 =C2=A0 NETCONF.
> > > >
> > > >=C2=A0 =C2=A0 A non-attached (remote) domain topology ma= y be learned via BGP-LS or
> > > >=C2=A0 =C2=A0 NETCONF.
> > > >
> > > > I think these are both probably not exhaustive lists, s= o "e.g." or
> > similar
> > > > may be appropriate.
> > > >
> > >
> > > KT> Ack.
> > >
> > >
> > > >
> > > > Section 4
> > > >
> > > >=C2=A0 =C2=A0 Type C: IPv4 Prefix with optional SR Algor= ithm:
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The headend is requir= ed to resolve the specified IPv4 Prefix
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address to the SR-MPL= S label corresponding to a Prefix SID
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segment (as defined i= n [RFC8402]).=C2=A0 The SR algorithm (refer to
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 3.1.1 of [RFC= 8402]) to be used MAY also be provided.
> > > >
> > > >=C2=A0 =C2=A0 Type D: IPv6 Global Prefix with optional S= R Algorithm for SR-MPLS:
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In this case, the hea= dend is required to resolve the specified
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 Global Prefix Ad= dress to the SR-MPLS label corresponding
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to its Prefix SID seg= ment (as defined in [RFC8402]).=C2=A0 The SR
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Algorithm (refer to S= ection 3.1.1 of [RFC8402]) to be used MAY
> > > >
> > > > These are effectively just the IPv4 and IPv6 incarnatio= ns of the same
> > > > underlying procedure, right?=C2=A0 Can't we minimiz= e the diff between the
> > > > paragraphs further?
> > > >
> > >
> > > KT> Ack
> > >
> > >
> > > >
> > > > Section 5.1
> > > >
> > > >=C2=A0 =C2=A0 Additionally, a Segment-List MAY be declar= ed invalid when:
> > > >
> > > > We probably want another word here ("both"?),= to specify how the two
> > > > conditions are combined.
> > > >
> > >
> > > KT> Ack - will rephrase.
> > >
> > >
> > > >
> > > > Section 5.2
> > > >
> > > >=C2=A0 =C2=A0 When the local computation is not possible= (e.g., a policy's
> > tail-end
> > > >=C2=A0 =C2=A0 is outside the topology known to the heade= nd) or not desired, the
> > > >=C2=A0 =C2=A0 headend MAY send path computation request = to a PCE supporting PCEP
> > > >=C2=A0 =C2=A0 extension specified in [RFC8664].
> > > >
> > > > missing article ("the PCEP extension").=C2=A0= I forget if it should be
> > > > "extensions" plural.
> > > >
> > >
> > > KT> Ack
> > >
> > >
> > > >
> > > > Section 8.7
> > > >
> > > >=C2=A0 =C2=A0 Finally, headend H MAY be configured with = a local routing policy
> > > >=C2=A0 =C2=A0 which overrides any BGP/IGP path and steer= a specified packet on an
> > > >
> > > > singular/plural mismatch -- s/steer/steers/
> > > >
> > >
> > > KT> Ack.
> > >
> > > Thanks,
> > > Ketan
> >
> >
--0000000000003fb60905da9de502-- From nobody Sat Mar 19 20:24:21 2022 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 790393A0420; Sat, 19 Mar 2022 20:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 vhm3KrzDXaj3; Sat, 19 Mar 2022 20:24:05 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 DB6F13A0489; Sat, 19 Mar 2022 20:24:04 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id i186so8084403vsc.9; Sat, 19 Mar 2022 20:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sJjSnKCDDUvFYIoaY/5Tj3uWaMiwX4zH0V4rYjP0EBE=; b=MfQE+t4Db3CPf2ua4PbEDzSGxA8nft4IdM2p+uAA8K2gZuNPorC2PsxehF0+nL3sXa F7V9f+f7iqpo6r1ePEoelAc066iHbFMFiRJdWlgmTh1nnrKQBGcQm0qCDXDWul+yTZ30 9wtRye+GLYbGTagK1f3ic0e1djtSwpB02l5Om3y2uGANalElkfqhXkOsHTdxDQQL9vVl wRhqc5DoTwJLBFPNQwfLHp8ZSy0rVjb/gb3i3ZYy+Ja1e0FoZSEw7j1E9vVbElTxaqpG zgpA6p15bG72NdEqvR5tBXjLlQgAs0k+x+OD97UNSHxPrL3giB2fRkF9yK3hb4fm3MF+ cwEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sJjSnKCDDUvFYIoaY/5Tj3uWaMiwX4zH0V4rYjP0EBE=; b=3FTqJQVdlKdNfwBAel+iE20d9QbFV+pLJ6XbbRwxurCdcnUEIuqdxIoX2xHLRFS+mo Ao9ZK6LsUdEj3tPUWnRuIYVE+ypHCb9hyFZq6tk6ps/kYTnKbNXueaa6J4RKs6FJGqTp yXqbwpc3envDbQihLO59KZsG046selKehWTDe11fR7QLzu1puoIajwq75lbpyLjIFDp7 CjgN8RZShqYvOKv12wupMwZsuI5ze7rEdvaJJwntXqcq1aqWOfFd4fTlDdXIOF7T5FYn LG3ZKN2PJqxyi7nhO0X6KQxBSOQYa6wPcuQiRqeCzujQsL4+a+SV2xbDmE9/DqdoWdFt YIog== X-Gm-Message-State: AOAM5308cCfbXvT2Mw5LXhhAAhpkKlZmN/XIkqsSCo1htZ1pTR5iflf+ lBZSaOcbjr1gVBzei6i7Sc0uWDYnIcemV38xm/g= X-Google-Smtp-Source: ABdhPJzXMykem8blhnO8Wvuj+GJMl12yjrKN8k3V45GwlOT/lCJIJg8yyr+oLkBHR0tTrMhB/76JYT6q4KXvXXVrkwE= X-Received: by 2002:a05:6102:3e95:b0:30f:9865:e97e with SMTP id m21-20020a0561023e9500b0030f9865e97emr5644690vsv.15.1647746643382; Sat, 19 Mar 2022 20:24:03 -0700 (PDT) MIME-Version: 1.0 References: <164504916365.5606.17077981996669554325@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Sun, 20 Mar 2022 08:53:50 +0530 Message-ID: To: Roman Danyliw Cc: The IESG , "draft-ietf-spring-segment-routing-policy@ietf.org" , "spring-chairs@ietf.org" , SPRING WG , "james.n.guichard@futurewei.com" Content-Type: multipart/alternative; boundary="0000000000005bd61c05da9de979" Archived-At: Subject: Re: [spring] Roman Danyliw's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sun, 20 Mar 2022 03:24:10 -0000 --0000000000005bd61c05da9de979 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, We've just submitted an update to address your comments: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-21 Please let us know if it addresses your concerns. Thanks, Ketan On Fri, Mar 18, 2022 at 11:19 AM Ketan Talaulikar wrote: > Hi Roman, > > My understanding is that you would like us to put references to the > relevant BGP and PCEP documents in sections 2.6 (CP name) and 2.7 > (Preference). > > Can you please confirm so we can include those changes in the next update > (once submission re-opens)? > > Thanks, > Ketan > > > On Fri, Mar 18, 2022 at 6:33 AM Roman Danyliw wrote: > >> Hi Ketan! >> >> >> >> I=E2=80=99m clipping the text a bit to make it readable =E2=80=A6 >> >> >> >> >> >> On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar >> wrote: >> >> Hi Roman, >> >> >> >> Thanks for your review and comments/inputs. Please check inline below fo= r >> responses. >> >> >> >> >> >> On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker < >> noreply@ietf.org> wrote: >> >> Roman Danyliw has entered the following ballot position for >> draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions= / >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-polic= y/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> There appear to be a few places where additional pointers or >> specification is >> needed to ensure interoperability. >> >> ** Section 2.5 >> When signaling is via PCEP, the method to uniquely signal an >> individual candidate path along with its discriminator is described >> in [I-D.ietf-pce-segment-routing-policy-cp]. >> >> Where is the explanation of discriminator in this reference? >> =E2=80=9CDiscriminator=E2=80=9D >> appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2. In the first three >> section it >> is simply named but not explained. In the last section, it isn=E2=80=99= t >> explained >> beyond being defined as 32-bits. >> >> >> >> KT> I have not yet reviewed that document and will do so to pass the >> comments to the authors of that document. As a reminder, this is an >> architecture document in SPRING that is then realized using protocol >> extensions/mechanisms that are specified in their respective WG document= s. >> >> >> >> [Roman] Understood that the WG considers this an architecture document, >> however, it is being published as proposed standard. For that reason, I= =E2=80=99m >> making these particular comments about explicitly referencing the expect= ed >> normative behavior. >> >> >> ** Section 2.6. >> Candidate paths MAY also be assigned or signaled with a symbolic name >> comprising printable ASCII [RFC0020] [RFC5234] characters >> >> How these candidate paths names are signaled isn=E2=80=99t defined. I b= elieve it >> is >> per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Sectio= n >> 2.4.7 >> of draft-ietf-idr-segment-routing-te-policy. >> >> >> ** Section 2.7. How is the candidate path preference signaled? Is that >> draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and >> >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-= policy-14#section-2.4.1 >> ? >> >> >> >> KT> Those protocol specs normatively refer to this document. Your >> understanding is correct about the parts of those documents. >> >> >> >> [Roman] Specifically about Section 2.6 and 2.7, thanks for confirming >> that I read the other documents correctly. Is there a reason the text >> doesn=E2=80=99t explicitly reference this relevant the normative behavio= r? >> >> >> >> >> Thanks, >> >> Roman >> >> --0000000000005bd61c05da9de979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

We've just submitted an u= pdate to address your comments:=C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-spring-s= egment-routing-policy-21

Please let us know if it address= es your concerns.

Thanks,
Ketan


On Fri, Mar 18, 2022 at 11:19 AM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
<= /div>
Hi = Roman,

My understanding is that you would like us to put= references to the relevant BGP and PCEP documents in sections 2.6 (CP name= ) and 2.7 (Preference).=C2=A0

Can you please confi= rm so we can include those changes in the next update (once submission re-o= pens)?

Thanks,
Ketan


On Fri, Mar 18, 2022 at 6:33 AM Roman Danyliw <rdd@cert.org> wrote:

Hi Ketan!

=C2=A0

I=E2=80=99m clipping the text a bit to make it reada= ble =E2=80=A6

=C2=A0

=C2=A0

On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar <= ;ketant.ietf@gma= il.com> wrote:

Hi Roman,

=C2=A0

Thanks for your review and comments/inputs. Please c= heck inline below for responses.

=C2=A0

=C2=A0

On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Da= tatracker <noreply= @ietf.org> wrote:

Roman Danyliw has entered the following ballot posit= ion for
draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-s= pring-segment-routing-policy/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There appear to be a few places where additional pointers or specification = is
needed to ensure interoperability.

** Section 2.5
=C2=A0 =C2=A0When signaling is via PCEP, the method to uniquely signal an =C2=A0 =C2=A0individual candidate path along with its discriminator is desc= ribed
=C2=A0 =C2=A0in [I-D.ietf-pce-segment-routing-policy-cp].

Where is the explanation of discriminator in this reference?=C2=A0 =E2=80= =9CDiscriminator=E2=80=9D
appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.=C2=A0 In the first three se= ction it
is simply named but not explained.=C2=A0 In the last section, it isn=E2=80= =99t explained
beyond being defined as 32-bits.

=C2=A0

KT> I have not yet reviewed that document and wil= l do so to pass the comments to the authors of that document. As a reminder= , this is an architecture document in SPRING that is then realized using pr= otocol extensions/mechanisms that are specified in their respective WG documents.

=C2=A0

[Roman] Understood that the WG considers this an arc= hitecture document, however, it is being published as proposed standard.=C2= =A0 For that reason, I=E2=80=99m making these particular comments about exp= licitly referencing the expected normative behavior.


** Section 2.6.
=C2=A0 Candidate paths MAY also be assigned or signaled with a symbolic nam= e
=C2=A0 =C2=A0comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn=E2=80=99t defined.=C2=A0 I= believe it is
per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2= .4.7
of draft-ietf-idr-segment-routing-te-policy.=C2=A0


** Section 2.7.=C2=A0 How is the candidate path preference signaled?=C2=A0 = Is that
draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and
https://datatracker.ietf= .org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1= ?

=C2=A0

KT> Those protocol specs normatively refer to thi= s document. Your understanding is correct about the parts of those document= s.=C2=A0

=C2=A0

[Roman] Specifically about Section 2.6 and 2.7, than= ks for confirming that I read the other documents correctly.=C2=A0 Is there= a reason the text doesn=E2=80=99t explicitly reference this relevant the n= ormative behavior?

=C2=A0


Thanks,

Roman

--0000000000005bd61c05da9de979-- From nobody Sat Mar 19 20:26:20 2022 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 B95793A0596; Sat, 19 Mar 2022 20:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_SCC_BODY_TEXT_LINE=-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 apfJ3S_WB5Zc; Sat, 19 Mar 2022 20:26:08 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 CB89B3A058F; Sat, 19 Mar 2022 20:26:07 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id i186so8086570vsc.9; Sat, 19 Mar 2022 20:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yVD94NGHHo3FHHHCtDCVjidE9h9P/RU1xes/GT+u7P0=; b=j6W5M/o5CUMs1Le92AZImfkzblzZ+OgFEKHZhx60ztkC2m0vzJMcxPGEbO3A12Us68 b7bRpxvM8ta+bEqa8uv9bIO5jcQu9RNEPJMLG5IQ7DVGN922RafG8604lq1y7yw0swrP snmFYEXrmtw+/oNQsrPYB4/4VjZ539xIn1s5pXW6M4UCe2HZmE/Rw5ODm98r/ZjxVMl6 zpoz9mRaGiWX9wdqm/GMxyK6KCnXkk7ILYt/tjtUrZcwP9BqKPVGcpwqYqAYuIuoYSze X5H5jzrvYXLWEfowT7EfCvQbG/Xh+D/0pp6+zcVPH2Wl4vGwnIuPtgmpCpD/DKABEBdv EZVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yVD94NGHHo3FHHHCtDCVjidE9h9P/RU1xes/GT+u7P0=; b=uD/n8Cw1MxlF6xLBAVY7KGJ/J+I7bgMQdxIGfRho0KY3xmWPScpXEDodczNUHgKIPw fqT52lf2D519faueTdTuNJWqXFsKVc7CsZVy2ZKvEKctheA8J/KNTU8OmLTHrD6Z8jkW YKj2rDhQvxJW/GyIScxFvnOlmYQDpclYyZF18EevEnA6Gs3AERnzO7GiE3GvlX8N1Hh7 dByX5z1nHLvWbVlqGL8OcYtJJfcwx25MZ/EVzKdNe6/oLNf6DdBPqv4lir3sLpf8eKbr z/4dLfNC0h77aiaw5ro34Qec6lkNafYn6yGKvnie5dsUjvgnfwt6czQDor/cizSNfIh1 QYVQ== X-Gm-Message-State: AOAM5323HS1Ee8M6XYrobcpfkgCU8q51a1BSEDXmoim6HFNABvayv70G KChsR7Z8bxmIrb7FbFpI/Tz5RA9HrYdksrrr+DiNcL4X3nE= X-Google-Smtp-Source: ABdhPJwKmPeqNey7+9IYrhfVc9D3ERYxtRkbNDfuqeNf+TSe3lI5vkld+71JPs7Je+aHuPZPlxwXGrXwQnVb+9q0vB0= X-Received: by 2002:a05:6102:510c:b0:322:b84a:4212 with SMTP id bm12-20020a056102510c00b00322b84a4212mr6059318vsb.64.1647746766345; Sat, 19 Mar 2022 20:26:06 -0700 (PDT) MIME-Version: 1.0 References: <164504875164.5704.16596621622345086808@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Sun, 20 Mar 2022 08:55:53 +0530 Message-ID: To: Alvaro Retana Cc: SPRING WG , spring-chairs@ietf.org, The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000b01a7905da9df01a" Archived-At: Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sun, 20 Mar 2022 03:26:11 -0000 --000000000000b01a7905da9df01a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, The update posted just now has incorporated your suggestion: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-21 Thanks, Ketan On Thu, Mar 17, 2022 at 10:38 PM Ketan Talaulikar wrote: > Hi Alvaro, > > Thanks again for your detailed review and the discussion to help improve > this document. We'll incorporate your suggestion below in the next update > once the submission window opens up. > > Thanks, > Ketan > > > On Fri, Mar 11, 2022 at 11:50 PM Alvaro Retana > wrote: > >> On March 5, 2022 at 5:29:36 AM, Ketan Talaulikar wrote: >> >> Ketan: >> >> Hi! >> >> > We have also just posted an update to address some of the comments >> below and >> > from other ADs. >> > >> > >> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-= policy-19 >> >> That version addresses my DISCUSS -- I'm clearing. I have one reply >> in the comments below. >> >> >> Thanks! >> >> Alvaro. >> >> ... >> > > > > (7) =C2=A72.4: "When signaling is via PCEP...the AS number SHOUL= D be >> set to >> > > > > 0 by default when not available or known." >> > > > > >> > > > > When is it ok for the ASN to not be set to 0 (when not available >> or >> > > > > known)? If that possibility exists, the PCE can use any value >> > > > > (including the real number or a random one). What issues exist >> with >> > > > > uncoordinated (or rogue) PCEs using potentially arbitrary ASNs? >> > > > > >> > > > > Why is this action recommended and not required? >> > > > >> > > > KT> AFAIR PCEP signaling does not carry AS number. So this is a >> > > > recommendation, though a local policy or a future PCEP extension >> could >> > > > change that and we don't want to preclude it. >> > > >> ... >> > > If the ASN can be signaled, when is it ok for it to not be set to 0 >> > > (when not available or known)? If that possibility exists, the PCE >> > > can use any value (including the real number or a random one). What >> > > issues exist with uncoordinated (or rogue) PCEs using potentially >> > > arbitrary ASNs? >> > >> > KT> I will leave this question for the PCEP WG if and when they decide >> to add >> > support for ASN to be signaled. It does not make any impact from this >> > specification perspective since it is only used to identify the >> originator. >> >> The impact on this document it that it is specifying the behavior >> Normatively - let's eliminate that. >> >> Suggestion> >> If signaling via PCEP, it is the IPv4 or IPv6 address of the PCE and >> the AS number is expected to be set to 0 by default when not availabl= e >> or known. >> > --000000000000b01a7905da9df01a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

The update posted just now h= as incorporated your suggestion:=C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-spring-= segment-routing-policy-21

Thanks,
Ketan


On Thu, Mar 17, 2022 at 10:38 PM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
<= /div>
Hi = Alvaro,

Thanks again for your detailed review and the di= scussion to help improve this document. We'll incorporate your suggesti= on below in the next update once the submission window opens up.
=
Thanks,
Ketan


On Fri, Mar 11, = 2022 at 11:50 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
On March 5, 2022 at 5:29:36 AM, K= etan Talaulikar wrote:

Ketan:

Hi!

> We have also just posted an update to address some of the comments bel= ow and
> from other ADs.
>
> https://datatr= acker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19

That version addresses my DISCUSS -- I'm clearing.=C2=A0 I have one rep= ly
in the comments below.


Thanks!

Alvaro.

...
> > > > (7) =C2=A72.4: "When signaling is via PCEP...the A= S number SHOULD be set to
> > > > 0 by default when not available or known."
> > > >
> > > > When is it ok for the ASN to not be set to 0 (when not = available or
> > > > known)? If that possibility exists, the PCE can use any= value
> > > > (including the real number or a random one). What issue= s exist with
> > > > uncoordinated (or rogue) PCEs using potentially arbitra= ry ASNs?
> > > >
> > > > Why is this action recommended and not required?
> > >
> > > KT> AFAIR PCEP signaling does not carry AS number. So thi= s is a
> > > recommendation, though a local policy or a future PCEP exten= sion could
> > > change that and we don't want to preclude it.
> >
...
> > If the ASN can be signaled, when is it ok for it to not be set to= 0
> > (when not available or known)? If that possibility exists, the PC= E
> > can use any value (including the real number or a random one). Wh= at
> > issues exist with uncoordinated (or rogue) PCEs using potentially=
> > arbitrary ASNs?
>
> KT> I will leave this question for the PCEP WG if and when they dec= ide to add
> support for ASN to be signaled. It does not make any impact from this<= br> > specification perspective since it is only used to identify the origin= ator.

The impact on this document it that it is specifying the behavior
Normatively =C2=A0- let's eliminate that.

Suggestion>
=C2=A0 =C2=A0If signaling via PCEP, it is the IPv4 or IPv6 address of the P= CE and
=C2=A0 =C2=A0the AS number is expected to be set to 0 by default when not a= vailable
=C2=A0 =C2=A0or known.
--000000000000b01a7905da9df01a-- From nobody Sat Mar 19 20:36:20 2022 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 D92C73A0658; Sat, 19 Mar 2022 20:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 NgI8jebSMPjP; Sat, 19 Mar 2022 20:36:13 -0700 (PDT) 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 A2B2C3A067A; Sat, 19 Mar 2022 20:36:12 -0700 (PDT) Received: from mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22K3a0qY024678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 19 Mar 2022 23:36:07 -0400 Date: Sat, 19 Mar 2022 20:36:00 -0700 From: Benjamin Kaduk To: Ketan Talaulikar Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Message-ID: <20220320033600.GK13021@mit.edu> References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> <20220225020227.GM12881@kduck.mit.edu> <20220319192416.GH13021@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sun, 20 Mar 2022 03:36:18 -0000 Hi Ketan, Thanks for the additional text in the -21, I think it is really helpful. Trimming heavily... On Sun, Mar 20, 2022 at 08:52:41AM +0530, Ketan Talaulikar wrote: > Hi Ben, > > Thanks for your time and your response. Please check inline below with KT3. > > We've also posted an update with changes to address your comments: > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21 > > > On Sun, Mar 20, 2022 at 12:54 AM Benjamin Kaduk wrote: > > > On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote: > > > > > > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk wrote: > > > > > > > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote: > > > > > > > > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > > > > > Section 10 > > > > > > > > > > > > I think we also want to mention the security considerations of > > several > > > > more > > > > > > documents, including (but not limited to) > > > > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and > > 8986. > > > > > > > > > > > > > > > > KT> Ack on the three RFCs, but convinced about the > > > > > draft-ietf-idr-segment-routing-te-policy since that depends on this > > and > > > > not > > > > > the other way around. > > > > > > > > I think this relates to John's Discuss point and whether this document > > > > specifies the protocol behavior of the two bits in the context of the > > > > extension defined in draft-ietf-idr-segment-routing-te-policy. You > > need to > > > > understand draft-ietf-idr-segment-routing-te-policy in order to > > understand > > > > the security considerations relating to the protocol behavior > > controlled by > > > > those two bits, and IMO the protocol behavior specified by those two > > bits > > > > is solely the responsibility of this document, so this document must > > > > incorporate the security considerations of > > > > draft-ietf-idr-segment-routing-te-policy in order to fully document the > > > > security considerations of the concepts and protocol elements that this > > > > document defines. > > > > > > > > > > KT2> I am working with John to address his comments. > > > > Okay, the changes from -18 to -20 are looking promising, but I will let > > John decide when it's done. > > > > KT3> Our discussion with John is ongoing and seems like might take more > time. Would you be clearing your DISCUSS assuming the updates address your > concerns? Yes, I have already cleared since my specific Discuss-level concerns are addressed. Thanks again, Ben From nobody Sat Mar 19 20:42:22 2022 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 F37F33A076E; Sat, 19 Mar 2022 20:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_SCC_BODY_TEXT_LINE=-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 d96pegrEwFzM; Sat, 19 Mar 2022 20:42:09 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 DD4323A0745; Sat, 19 Mar 2022 20:42:08 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id m184so104529vsm.12; Sat, 19 Mar 2022 20:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fgDSkeT7FTqEfBQcydvm3u+dhKoOiDPFwY1j0tkNWgs=; b=nOEBBJou+2LDh3zonzRtIXvp0Q/VJnOF8idRKpZnMBF6ctwqzYyqwHOz1umIe6VBru iCYN+WXnYUhItu3ABKNQ4T3JuWcYeKTwXD+KIPTDeW27Me7syw5AQld1uemDvQF8dMWw VbZmSV9G8pSWH20trX7OzRNpZPVfeko8XwdWZh5QN4a6WDWLyk8B9DN5UzC8nLN93lll AqcL1CtEhiNlnxd2+SxroOYPOFzJ1jygX0yywygTrHU54vWcWHNMQTxRiZsWVTzSZOcW OL0CEH8k3Tku+9Qadhlkw3nmHhvd5sdBl1P6bTyjSryltLxeT/mkCD4kjUibV2Bj3agQ G77w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fgDSkeT7FTqEfBQcydvm3u+dhKoOiDPFwY1j0tkNWgs=; b=xhZxdv7goGdEXhAGW0nhmDYQYOAaWrvqDPycQK3uc3qg1ax5zb68ooYTAhccmCF7Qo JhipWXf7Ox4SPL68DcJ6kAzO9p+vvfUTkpWfdQg8VpujkVDe0X0WuvoaiT9Vogl6qE2M onT3lbSQrDMJ5UvuYoqtsgFddMFsbx11vTpdFBbVJXBWeVg1SXG1OWQe/Dvua1e3Gs2o t8edJI4P9fU9Q5/Cn8cyEnPa0hILn54RX+y2Qgfq8pAPJok/NU6ZwKmzHYEg6WsOwm1s KlgLutAZsqLYMVva6KRK9PB48CjAwqM3x83Boo8YUmCK6tgKnc8Gu0Q+szKIXVRw3/s3 3OLg== X-Gm-Message-State: AOAM533Fv9vpWU48gSKRJSwwZFutQbCcBXjmptYUo24vGaAYFIiCtzTu u9Bl3IjlUm2OH5TCkcGHEX49FT+ZDPeRprCbNk3OtnQD X-Google-Smtp-Source: ABdhPJxqXkWYXsyOM6GYxw3R/3JGIqNnPdSONr+z9pGaRRI1oIEy+PX6vbtZqDit3KOeGrafdPeUC7wDZhEtXVH7uI8= X-Received: by 2002:a05:6102:284a:b0:31e:c455:5dee with SMTP id az10-20020a056102284a00b0031ec4555deemr5290324vsb.27.1647747727505; Sat, 19 Mar 2022 20:42:07 -0700 (PDT) MIME-Version: 1.0 References: <164507858486.11948.7818447548279924153@ietfa.amsl.com> <20220225020227.GM12881@kduck.mit.edu> <20220319192416.GH13021@mit.edu> <20220320033600.GK13021@mit.edu> In-Reply-To: <20220320033600.GK13021@mit.edu> From: Ketan Talaulikar Date: Sun, 20 Mar 2022 09:11:54 +0530 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, spring-chairs@ietf.org, SPRING WG , james.n.guichard@futurewei.com Content-Type: multipart/alternative; boundary="000000000000fa3d9605da9e2980" Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (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: Sun, 20 Mar 2022 03:42:11 -0000 --000000000000fa3d9605da9e2980 Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks a lot for all your help and guidance in improving this document. Thanks, Ketan On Sun, Mar 20, 2022 at 9:06 AM Benjamin Kaduk wrote: > Hi Ketan, > > Thanks for the additional text in the -21, I think it is really helpful. > > Trimming heavily... > > On Sun, Mar 20, 2022 at 08:52:41AM +0530, Ketan Talaulikar wrote: > > Hi Ben, > > > > Thanks for your time and your response. Please check inline below with > KT3. > > > > We've also posted an update with changes to address your comments: > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21 > > > > > > On Sun, Mar 20, 2022 at 12:54 AM Benjamin Kaduk wrote: > > > > > On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote: > > > > > > > > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk > wrote: > > > > > > > > > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote: > > > > > > > > > > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker < > > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > > > > > > > > Section 10 > > > > > > > > > > > > > > I think we also want to mention the security considerations of > > > several > > > > > more > > > > > > > documents, including (but not limited to) > > > > > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, > and > > > 8986. > > > > > > > > > > > > > > > > > > > KT> Ack on the three RFCs, but convinced about the > > > > > > draft-ietf-idr-segment-routing-te-policy since that depends on > this > > > and > > > > > not > > > > > > the other way around. > > > > > > > > > > I think this relates to John's Discuss point and whether this > document > > > > > specifies the protocol behavior of the two bits in the context of > the > > > > > extension defined in draft-ietf-idr-segment-routing-te-policy. You > > > need to > > > > > understand draft-ietf-idr-segment-routing-te-policy in order to > > > understand > > > > > the security considerations relating to the protocol behavior > > > controlled by > > > > > those two bits, and IMO the protocol behavior specified by those > two > > > bits > > > > > is solely the responsibility of this document, so this document > must > > > > > incorporate the security considerations of > > > > > draft-ietf-idr-segment-routing-te-policy in order to fully > document the > > > > > security considerations of the concepts and protocol elements that > this > > > > > document defines. > > > > > > > > > > > > > KT2> I am working with John to address his comments. > > > > > > Okay, the changes from -18 to -20 are looking promising, but I will let > > > John decide when it's done. > > > > > > > KT3> Our discussion with John is ongoing and seems like might take more > > time. Would you be clearing your DISCUSS assuming the updates address > your > > concerns? > > Yes, I have already cleared since my specific Discuss-level concerns are > addressed. > > Thanks again, > > Ben > --000000000000fa3d9605da9e2980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks a=C2=A0lot=C2=A0for all = your help and guidance in improving this document.

Thank= s,
Ketan


On Sun, Mar 20, 2022 at 9:06 A= M Benjamin Kaduk <kaduk@mit.edu>= wrote:
Hi Ketan= ,

Thanks for the additional text in the -21, I think it is really helpful.
Trimming heavily...

On Sun, Mar 20, 2022 at 08:52:41AM +0530, Ketan Talaulikar wrote:
> Hi Ben,
>
> Thanks for your time and your response. Please check inline below with= KT3.
>
> We've also posted an update with changes to address your comments:=
> https://datatr= acker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21
>
>
> On Sun, Mar 20, 2022 at 12:54 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote:=
> > >
> > > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > >
> > > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talauli= kar wrote:
> > > > >
> > > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk vi= a Datatracker <
> > > > > noreply@ietf.org> wrote:
> > > > >
> > > > > >
> > > > > > Section 10
> > > > > >
> > > > > > I think we also want to mention the security = considerations of
> > several
> > > > more
> > > > > > documents, including (but not limited to)
> > > > > > draft-ietf-idr-segment-routing-te-policy and = RFCs 8660, 8754, and
> > 8986.
> > > > > >
> > > > >
> > > > > KT> Ack on the three RFCs, but convinced about = the
> > > > > draft-ietf-idr-segment-routing-te-policy since tha= t depends on this
> > and
> > > > not
> > > > > the other way around.
> > > >
> > > > I think this relates to John's Discuss point and wh= ether this document
> > > > specifies the protocol behavior of the two bits in the = context of the
> > > > extension defined in draft-ietf-idr-segment-routing-te-= policy.=C2=A0 You
> > need to
> > > > understand draft-ietf-idr-segment-routing-te-policy in = order to
> > understand
> > > > the security considerations relating to the protocol be= havior
> > controlled by
> > > > those two bits, and IMO the protocol behavior specified= by those two
> > bits
> > > > is solely the responsibility of this document, so this = document must
> > > > incorporate the security considerations of
> > > > draft-ietf-idr-segment-routing-te-policy in order to fu= lly document the
> > > > security considerations of the concepts and protocol el= ements that this
> > > > document defines.
> > > >
> > >
> > > KT2> I am working with John to address his comments.
> >
> > Okay, the changes from -18 to -20 are looking promising, but I wi= ll let
> > John decide when it's done.
> >
>
> KT3> Our discussion with John is ongoing and seems like might take = more
> time. Would you be clearing your DISCUSS assuming the updates address = your
> concerns?

Yes, I have already cleared since my specific Discuss-level concerns are addressed.

Thanks again,

Ben
--000000000000fa3d9605da9e2980-- From nobody Mon Mar 21 04:50:46 2022 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 E352C3A1279; Mon, 21 Mar 2022 04:50:43 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164786344384.16567.1587624164789334183@ietfa.amsl.com> Date: Mon, 21 Mar 2022 04:50:43 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-srv6-srh-compression-01.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: Mon, 21 Mar 2022 11:50:44 -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 : Compressed SRv6 Segment List Encoding in SRH Authors : Weiqiang Cheng Clarence Filsfils Zhenbin Li Bruno Decraene Dennis Cai Daniel Voyer Francois Clad Shay Zadok James N Guichard Liu Aihua Robert Raszuk Cheng Li Filename : draft-ietf-spring-srv6-srh-compression-01.txt Pages : 20 Date : 2022-03-21 Abstract: This document specifies new flavors for the SR endpoint behaviors defined in RFC 8986, which enable a compressed SRv6 Segment-List encoding in the Segment Routing Header (SRH). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-srh-compression-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 21 05:02:06 2022 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 C9B203A1953; Mon, 21 Mar 2022 05:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-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 6bbp1u-rnWJu; Mon, 21 Mar 2022 05:02:01 -0700 (PDT) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (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 7B5503A10B4; Mon, 21 Mar 2022 05:02:01 -0700 (PDT) Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-2e5e31c34bfso72996667b3.10; Mon, 21 Mar 2022 05:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8du0hQKhaBINvirNudVRWzfxnS7nSHKUuAkpwxl5DYY=; b=PAmeUbXt8k5VsreMXq+y3CEB6AGCSWskbm0xRvfnYzabfBzD6vIeX8gXxzd2sNfVdZ M8r658BhaVPQCWCqRMZZgha9wh9TK1aYJ5Ussa7ior0rRPJwk9X+2tV0m32Gae1O/drF P+R+VD4HjesV9Q3CwZu2JhHNYsXPt6loQdMvNGhootjvDrd71wHpU5HJAbWHSxxFQR+h 29LuSorWQo3iBrVCE22d7QEJ3SlGuc5nbYXThH5iQFSqg9xlPJRlkEsbR6NrA6drWrzC 2nn9TABIwjJFMtpytIPzyzAVkFlOssPtfPu34pdi2nAC8AI5iCs/I77TCuYLGELBPXWg gLuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8du0hQKhaBINvirNudVRWzfxnS7nSHKUuAkpwxl5DYY=; b=bJS+ak7ShuabMVPGHSzLeBABqWdrnDcH1SaysaqednUnSug8ivT3HAoH32J1qb8aFR 7CKXwf6wtJvIEmuoR7LKxDbbKr/J0twsuNd4k64FtlBeRqGNkp0AlDDPnAtOMYs+l7Ri pD4JpF6+quBjZOhzed3ERHJ+iTvaPxdLWU+Gw+51zqon6a9DmcgzWg3vdp0DZxEGEZxI QcSxtzTWjsXApwohT86OxsXNX5pknmUn49eiL9LdhL9gagopenoJWeAvArCHsUfjsMUh /Vfr2x64o6zfrL+1er1zfa2p/ZlihDdL1+dBM3eDHCymCGT8y9P9aZfHXTQTZc913dN+ G1nw== X-Gm-Message-State: AOAM531PashLk7Hg6yq+RUXmax6d6+a6vt4Z7B+1Fi3vqcAJBX5qu1l+ hn0qgCFEpo8Ji6TzKGyyPrrGj5d4Yv+wpzyhe61c3f+mPi8RAI0= X-Google-Smtp-Source: ABdhPJwTi69mpkbH8XkvJZqJBmQKzjW70lxXYQATX8eoYvnuMscGZDltesVHib1BZsyAtjw0G3y3GnNhexz6o8Trte8= X-Received: by 2002:a81:1d2:0:b0:2dc:5915:661 with SMTP id 201-20020a8101d2000000b002dc59150661mr23640489ywb.154.1647864119100; Mon, 21 Mar 2022 05:01:59 -0700 (PDT) MIME-Version: 1.0 References: <164786344384.16567.1587624164789334183@ietfa.amsl.com> In-Reply-To: <164786344384.16567.1587624164789334183@ietfa.amsl.com> From: Francois Clad Date: Mon, 21 Mar 2022 13:01:48 +0100 Message-ID: To: spring@ietf.org Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="00000000000075249805dab94343" Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-srh-compression-01.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: Mon, 21 Mar 2022 12:02:05 -0000 --00000000000075249805dab94343 Content-Type: text/plain; charset="UTF-8" Dear WG, Following the formal adoption of this document (thanks Joel!), we started going through the various points raised since the beginning of the working group adoption call. We are working on text proposals for all of them, which will likely take some time, but we wanted to get some of them already out. The changes are as follows: - Added in section 10 a reference to draft-clad-spring-srv6-srh-compression-illus, which provides the illustrations and examples that were requested multiple times ([ILLUS1], [ILLUS2], [ILLUS3],...) - Removed the informative references to the individual documents draft-cl-spring-generalized-srv6-for-cmpr and draft-filsfils-spring-net-pgm-extension-srv6-usid, since these proved more confusing than helpful to understand the document ([REF1]) - Rephrased the text about data plane changes in the abstract and introduction - Added a "Deployment Model" section that explicitly indicates that the target deployment model is the same as defined in Section 5 of RFC 8754, as suggested in [DEPLOYMENT1] and [DEPLOYMENT2]. Thanks, Francois [ILLUS1]: https://mailarchive.ietf.org/arch/msg/ipv6/Vm5z-5h_uvXSFMEz8rnqiPOc6Gc/ [ILLUS2]: https://mailarchive.ietf.org/arch/msg/spring/oyjFMKU5_pA6_jO7iZp3m7YIn1g/ [ILLUS3]: https://mailarchive.ietf.org/arch/msg/ipv6/29Vefuo8iOC6ZwkDfG-PEPNVu2E/ [REF1]: https://mailarchive.ietf.org/arch/msg/spring/ee9DPVu3PbGsIjYLDKnQ2o4xc-8/ [DATAPLANE1]: https://mailarchive.ietf.org/arch/msg/spring/D3HxS4_2P6OuNdhmayo3NFqWxkQ/ [DEPLOYMENT1]: https://mailarchive.ietf.org/arch/msg/spring/mJBhDdWt_SuE1voJFdsnrmhQf80/ [DEPLOYMENT2]: https://mailarchive.ietf.org/arch/msg/spring/MnbiE2dKePnrCuPBpjLpQOAgP4U/ On Mon, Mar 21, 2022 at 12:50 PM wrote: > > 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 : Compressed SRv6 Segment List Encoding in SRH > Authors : Weiqiang Cheng > Clarence Filsfils > Zhenbin Li > Bruno Decraene > Dennis Cai > Daniel Voyer > Francois Clad > Shay Zadok > James N Guichard > Liu Aihua > Robert Raszuk > Cheng Li > Filename : draft-ietf-spring-srv6-srh-compression-01.txt > Pages : 20 > Date : 2022-03-21 > > Abstract: > This document specifies new flavors for the SR endpoint behaviors > defined in RFC 8986, which enable a compressed SRv6 Segment-List > encoding in the Segment Routing Header (SRH). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-srh-compression-01 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000075249805dab94343 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG,
=C2=A0
Following the formal adoption of thi= s document (thanks Joel!), we started going through the various points rais= ed since the beginning of the working group adoption call.
=C2=A0
We = are working on text proposals for all of them, which will likely take some = time, but we wanted to get some of them already out.
=C2=A0
The chang= es are as follows:
- Added in section 10 a reference to draft-clad-sprin= g-srv6-srh-compression-illus, which provides the illustrations and examples= that were requested multiple times ([ILLUS1], [ILLUS2], [ILLUS3],...)
-= Removed the informative references to the individual documents draft-cl-sp= ring-generalized-srv6-for-cmpr and draft-filsfils-spring-net-pgm-extension-= srv6-usid, since these proved more confusing than helpful to understand the= document ([REF1])
- Rephrased the text about data plane changes in the = abstract and introduction
- Added a "Deployment Model" section= that explicitly indicates that the target deployment model is the same as = defined in Section 5 of RFC 8754, as suggested in [DEPLOYMENT1] and [DEPLOY= MENT2].
=C2=A0
Thanks,
Francois
=C2=A0
[ILLUS1]: ht= tps://mailarchive.ietf.org/arch/msg/ipv6/Vm5z-5h_uvXSFMEz8rnqiPOc6Gc/[ILLUS2]: https://mailarchive.ietf.org/arch/msg/spring/oyjFMKU= 5_pA6_jO7iZp3m7YIn1g/
[ILLUS3]: https://mailarchive.ietf.or= g/arch/msg/ipv6/29Vefuo8iOC6ZwkDfG-PEPNVu2E/
[REF1]: http= s://mailarchive.ietf.org/arch/msg/spring/ee9DPVu3PbGsIjYLDKnQ2o4xc-8/[DATAPLANE1]: https://mailarchive.ietf.org/arch/msg/spring/D3H= xS4_2P6OuNdhmayo3NFqWxkQ/
[DEPLOYMENT1]: https://mailarch= ive.ietf.org/arch/msg/spring/mJBhDdWt_SuE1voJFdsnrmhQf80/
[DEPLOYMEN= T2]: https://mailarchive.ietf.org/arch/msg/spring/MnbiE2dKePnrCu= PBpjLpQOAgP4U/

On Mon, Mar 21, 2022 at 12:50 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Source Packet Routing in Networking WG of = the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Compressed SRv6 Segment List Encoding in SRH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Weiq= iang Cheng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Clarence Filsfils
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Zhenbin Li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bruno Decraene
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dennis Cai
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Daniel Voyer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Francois Clad
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Shay Zadok
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 James N Guichard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Liu Aihua
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Robert Raszuk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cheng Li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-spring-srv6-srh-compression-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-03-21

Abstract:
=C2=A0 =C2=A0This document specifies new flavors for the SR endpoint behavi= ors
=C2=A0 =C2=A0defined in RFC 8986, which enable a compressed SRv6 Segment-Li= st
=C2=A0 =C2=A0encoding in the Segment Routing Header (SRH).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-ietf-spring-srv6-srh-compression/

There is also an htmlized version available at:
https://datatracker.i= etf.org/doc/html/draft-ietf-spring-srv6-srh-compression-01

A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-spring-srv6-srh-compression-01


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--00000000000075249805dab94343-- From nobody Mon Mar 21 12:24:45 2022 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 209443A14EB for ; Mon, 21 Mar 2022 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=joelhalpern.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 fnJXo8cnleZn for ; Mon, 21 Mar 2022 12:24:37 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 A510C3A14E2 for ; Mon, 21 Mar 2022 12:24:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4KMl1K26vTz1ntWn for ; Mon, 21 Mar 2022 12:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1647890677; bh=n43p+po0fUrECh9F/DWyTcOhJaqhIbn3kUOsydw/R/o=; h=Date:Subject:References:To:From:In-Reply-To:From; b=Qx2dWmHj6fn+NDHH+5SIC01ty7uaMU1kDe64P3iR+EDWMP/wOjI/pm6gFAHIJ9yms PQEib8ovo9DpFSBt64DWv+ausjcpDtrtFG3ucWHJm/+FVSTtBHHYvN8FnBjpy900JQ ElAif2O2mBMPH1d/kaq7Dace3bv29YZPpPSNBe6E= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.21.218] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4KMl1J5hLZz1ntSp for ; Mon, 21 Mar 2022 12:24:36 -0700 (PDT) Message-ID: Date: Mon, 21 Mar 2022 15:24:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 References: <20220321191257.GT4905@pfrc.org> Content-Language: en-US To: "spring@ietf.org" From: "Joel M. Halpern" In-Reply-To: <20220321191257.GT4905@pfrc.org> X-Forwarded-Message-Id: <20220321191257.GT4905@pfrc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] Fwd: [Idr] BGP routes with color, observations from question threads 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 Mar 2022 19:24:43 -0000 For the information of those interested in the colorful BGP / intent space, to complement the ongoing work on harmonizing the problem statements, the IDR working group has been discussing the solutions. Below is the lengthy email Jeff Haas sent to the IDR working group on the topic. Yours, Joel -------- Forwarded Message -------- Subject: [Idr] BGP routes with color, observations from question threads Date: Mon, 21 Mar 2022 15:12:57 -0400 From: Jeffrey Haas To: idr@ietf.org Working Group, Summary: For route resolution and route origination/propagation, BGP-CAR and BGP-CT are functionally identical but operationally different. "When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean — neither more nor less." [1] After the most recent IDR interim meeting on 24 January, 2022 [2], discussion during presentation and in meeting chat suggested we had need to try to clarify some of the items in the proposals. Two questions were sent to the IDR mailing list to try to achieve clarity. Question 1: How does route resolution work with your feature? [3] Question 2: Route origination and propagation [4] The discussion at the interim suggested that the authors weren't quite dealing with exactly the same ideas of what a route with "color" meant from protocol purposes, and similarly with "intent". The threads were an attempt to ignore the words used and to distill the BGP protocol behaviors based on what each of the proposals did functionally. For route resolution, both proposals permit a service route (e.g. L3VPN) to resolve their BGP nexthops vs. multiple mechanisms using a color (typically, the color Extended Community from RFC 9012). Thus, each proposal not only discussed resolution procedures vs. its mechanisms, but also vs. other mechanism such as IGP Flex-Algo, SR Policy, BGP LU, etc. After question 1, it's also clear that each proposal functionally provides resolution over its routes in a similar fashion in spite of differing descriptions of the mechanics: - The resolution key for a service route is the BGP Nexthop, N, and the color on the route, C - (N,C). - (N,C) is used in resolution by finding the longest-match destination for the proposal's resolution database for color C. - Fallback resolution to different colors are permitted by each proposal to resolve to (N,C2), etc., via configuration. Both proposals have sections describing route resolution. Both would benefit by adding text covering the properties above to their text. Question 1 also highlighted that the "resolution database", for wont of a fully general term, differs in terms of how fully described it is in each of the proposals. This abstraction is the component where the (N,C) lookup is performed; compare vs. RFC 4271 describing resolution in the "Routing Table". In -CT, the "Transport RIBs" construction procedures are described. Loosely, received -CT routes are stripped of their received RD and installed in a longest-prefix match table (RIB) for the Transport Class extended community that is received. The presented abstraction is thus a set of tables {C}. Functionally, resolution for (C,N) is against this set of tables but is a single operation. In -CAR, similar detailed procedures aren't provided... nor do they necessarily need to be described. As long as the functional behavior for resolution is described it doesn't matter. By comparison, the BGP RIB model provides the following caveat in RFC 4271: : Although the conceptual model distinguishes between Adj-RIBs-In, : Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an : implementation must maintain three separate copies of the routing : information. The choice of implementation (for example, 3 copies of : the information vs 1 copy with pointers) is not constrained by the : protocol. I'd urge all of the authors to avoid trying to draw too much comparison to standard BGP route resolution and instead to ensure you're calling out explicit procedures to avoid letting people think they know what's going on only to have issues with the gotchas: - In -CAR, the resolution table is populated by (E,C) where C is the "effective color" of the -CAR route; by default C from the NLRI but overridden by the LCM extended community, when present. - In -CT, while the RFC 4364-like Transport RIBs procedures and the similar resolution procedure is listed, the text perhaps is overly descriptive vs. a specific implementation. See the RFC 4271 caveats. ----- Question 2, while about route origination and propagation, became more of a discussion about the perception of the authors about what they considered a "color" and what "intent" was. Rather than try to argue with a given author's defintion of each of these terms, what we can observe from the conversation are operational differences in how "forwarding diversity" is achieved at an ingress running one of the proposed protocols - or whether such diversity was perceived to be needed. >From the thread: "Forwarding diversity", in this context, is situations where forwarding properties such as BGP Nexthops, labels, SIDS, etc. are desired to be carried through to the ingress. The authors illustrated in their responses that each proposal was capable of addressing similar scenarios from a forwarding diversity standpoint. The authors also seem to largely agree on what scenarios are the most common. I believe that in terms of capability for representing forwarding diversity, both proposals are functionally identical. However, where they differ is in operational presentation and impact: -CAR: In -CAR, the NLRI (E,C) drives the scenario to use C for a specific desired forwarding "intent". That intent is not intended to address "forwarding diversity". If there is a desire for such diversity for a given endpoint, an additional color must be leveraged. Since the color is part of the NLRI key, this has the operational impact that multiple "color domains" MUST agree on a common color space for the intent for a specific C. Domains are capable of mapping between each others' intents using LCM, but C must not be inconsistently used among cooperating domains. However, by having the color in the NLRI and given the need for coordination of the color space, the original "intent" of the route is carried from originator to consumer. If fowarding diversity is desired for the same endpoint, multiple colors might need to be used depending on topology. Based on author discussion, such diversity is not the expected common scenario. -CT: The Route Distinguisher in -CT has the same properties as in most BGP VPN technologies; i.e. it is primarily to provide path uniqueness. Operationally, the authors seem to foresee that it is primarily meant to be used to provide information as to what the originating PE is for the routes. In situations where path uniqueness is not required, the operator may configure identical RDs for a given endpoint. A common scenario for -CAR and -CT is the endpoint PE originating the route. In such situations, diverse RDs may not be needed. Since the NLRI doesn't contain the color and it is solely an extended community (similar to LCM), the original "intent" of the color is not necessarily carried across different color domains. Forwarding diversity is available for the same "color" by varying the RD. For more direct comparability for forwarding diversity, one might consider RD+color in -CT to be the same as color in -CAR. Personal observation: RDs have enough space such that a 32-bit color could be encoded in it to preserve the "original intent". --- In the above, I believe we can see that both proposals are capable of encoding similar desired forwarding diversity. Where the proposals seem to diverge is whether forwarding diversity is intended to directly map to their 32-bit color component. Hopefully the above can serve to help the SPRING Working Group with their discussion on the problem statement work behind these proposals. While each of the authors likely has a precise meaning for "color" and "intent" in mind, the above tries to be mostly mindful of what the functional properties are present in their BGP proposals. A portion of the issue we're dealing with is that the word "color" has been heavily used in IETF RFCs and Internet-Drafts over the years without ensuring consistency of its meaning. An example of this is how color in an RSVP admin-group sense is not comparable to the RFC 9012 BGP extended community sense. Harmonizing the functional behaviors of "color" may be possible in a set of proposals, but I suspect that when dealing with legacy technologies it can't be readily done. -- Jeff [1] https://www.goodreads.com/quotes/12608-when-i-use-a-word-humpty-dumpty-said-in-rather [2] https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr [3] https://mailarchive.ietf.org/arch/msg/idr/OaNnE5epcaK7GtcV8OlAVdD3ZbI/ [4] https://mailarchive.ietf.org/arch/msg/idr/4MYIFyHWITj8-Kk38AmKlkhh5b8/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Mar 21 14:25:10 2022 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 71B783A0EBD; Mon, 21 Mar 2022 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=juniper.net header.b=QYerNkKO; dkim=pass (1024-bit key) header.d=juniper.net header.b=CugzwfwE 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 stPYvbFH3Z_S; Mon, 21 Mar 2022 14:24:45 -0700 (PDT) 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 072B43A0D2A; Mon, 21 Mar 2022 14:24:41 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22LGIBYp013025; Mon, 21 Mar 2022 14:24:36 -0700 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 : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=Ns8NIHkfPqVnyrQODz9Mu8Ag5ZeW9ECf58TdkdvmqPM=; b=QYerNkKOpvzXyg8DSBA1dMhdxu8bdjtvVfIkTehsmti6hAZkNuSYMnHQ1lE1uDz53nuR xLBOLKraVIpeTeAX4CDhirD0E6atfdAZ5cTdK7bpE713O8qZGO5tt0cb2VbEDEGMhnFD MeSe+alwCV+F0U7sXWLvF8tYMRQqadycOHeiXwfrsdOfSS9fZY1nwMzQaTdDfKeaksUT r9uE82m5/iDnqSXoBCNvQaVF68ZSzM6P5PS6vmve/N1p9UwybQCx24pCqcab7nCX5xDv qAPLd6dTQtN6youJuWm4y8+oXaLUt1eR9guy4EGGmNMmhod5/U+U22vqHv+WcgYjREcI tA== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3ewd4vv85b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 14:24:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MXivzT2TXTyDCJOn75toTGfXLZ5j8t+2z8+e5QKpKRqUAuye4Yp5SZwSIJwHxmBJTw5xtAtiYUB0Nr5feJbnOg57BPD3EFOc/ezA0d7l6TxmoMQ0FtSsNANTvZwFiFTbpIgfsv5F0r5KRwu6VmuqvjqN+JJckfsTwkX1OEi1WmSHp8YuqFTxqw6eA+mIIXv5xxrBoebNsPL9OsKf1k+jLjYsjH70tD7+ShnW09CQCVvQnxRIjEoIWajsIR97boOJNh2Z80AQtX0tjzgWappFyWGFvzDnbLHIjq7jZ1SCyfyC6vEDqmguTKo/HvOXJaJowaLBy4uuTKJ4+cUg4ASQBQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ns8NIHkfPqVnyrQODz9Mu8Ag5ZeW9ECf58TdkdvmqPM=; b=Pn9y4hZRcpFiYeBb75EPUlUmpBveC2UE6xGNb2nL3SRWxC2uBlO3Qg90fietHyOUPYzKzs+mW2ymBxOCjvc5K11IQ25yIc2d/GM4SdnjW6N0kVGnIY6XtMKoaMTJwiGrfv+IBoNGjeN89fbj+wR3DD4lYA5GQlY4YW+CStsG3TMmqRg2k/ddsmB6uZft1aZ64ym8LtfEcLeddM2q98enpezyaXBcr7ngYxgzTQu0bhftTnvb2aJsRcAocQdPlzlR4edtWIipFzSByQCmmmrOYvc2MxfhmvPzeViXzW9eh4qSi9OANwHv0Kb93KEeduCfC6B/dM592DBXrZV9x93Ydg== 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=Ns8NIHkfPqVnyrQODz9Mu8Ag5ZeW9ECf58TdkdvmqPM=; b=CugzwfwEIMSUj6MauqKcQjqtB1G7x2gdaIXb4B6uAx44uDt6/bxp9p/nEym7Nzo3XMWATNSvPYUNAu2uKZciEXID/nW8CX2uqAKKR++xbPkFH5/6gAFfKC2swgx0U+RCgOmSmmU4JZmTjWsoKCAEL9G3fg9snkWVFbpdBq5W0/E= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by BYAPR05MB6408.namprd05.prod.outlook.com (2603:10b6:a03:c7::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.8; Mon, 21 Mar 2022 21:24:32 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::8cd3:9859:9c55:6eb8]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::8cd3:9859:9c55:6eb8%5]) with mapi id 15.20.5102.015; Mon, 21 Mar 2022 21:24:32 +0000 From: John Scudder To: Ketan Talaulikar CC: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Thread-Topic: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI1ajQRbh7M614068Bbz53eGtPayWiSeAgAAKsYCAM/mVgA== Date: Mon, 21 Mar 2022 21:24:32 +0000 Message-ID: References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3696.80.82.1.1) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54ff7b86-457e-4004-a3f6-08da0b813100 x-ms-traffictypediagnostic: BYAPR05MB6408:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BOhuPvzeqQVVMbL8cLHkTVvY0/NE83EU2rrMJnfO0riBagE/MHXXbLdR5LTVWUj0qrE30h08Z5q51Qq3XVQmwnJkyh9bMwkNWZlLtHePZv5wmtFTZf3ClihoEiCLS6bnV/PdmNDKpf0vDX4vw4QMMEI5D+3GvdSIig7BllbFCvmX5+UGsMxuPatGzI7l2dRwFIYV4whka0umq3KlxdOg6zYYNTYbr6aoAAvGxMrOpaFJ70IhWuChPJe6JD8n2btKI/ZbhgdipUxP3lMn0IU8gOWzLhOhrAUbEdGoo6qRztkjSGbeghLZ4QiJm4plgnnByf47QyS8MJ17kvfGS8tlGF0ztyQjHsklUKD5gjBexTymSP1hYhjrVo23FMppXRoGx+EVyBm+8uPjOFpKDmSP2HZu5jmP3CvlI0PxEcTsmU6YHn6/R7cBc8u8Gf2I9USNK78fhDHcbV1IaDJIApuX0I5qy0ee6KJvdYNNQEpRBLjjFjh7IaDEUIl6yNJYbbViriYHI6BZUcVAwAVDmUJZKyxeosYB2IaJZ4IopwNynWxIqoyAyD9umeLhBA/e9iOfuCjaSR1cMlPAFCMWpoPgX6+cCQZGoG0Q9Hs2jTmlhioN21njqEold33kgeE4ynQbxiEc9uA/BJaDTpltGLDnueqE6gWGkQzJVuVWgZwCSWgVOGIlAhwVh57U8cIPL5J5jlaNegOwHEZPqIGrTSmYpOs0ERKAnIeL8xz4nbUc6+yz7oEJk2bNezLOMxqxb1tuaiUV3KyKv6Bnom6jCxdvmAHOSThqKxWF0VU/j4hmaIM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(86362001)(2616005)(6506007)(83380400001)(36756003)(26005)(8936002)(53546011)(6512007)(2906002)(186003)(8676002)(66476007)(4326008)(66446008)(64756008)(508600001)(66556008)(66946007)(5660300002)(71200400001)(38100700002)(38070700005)(33656002)(54906003)(6916009)(316002)(91956017)(76116006)(122000001)(6486002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WGVOZ3g3eWdOWVFRcUVLdll5MzJESE5uUmNzWTNNTklhY1hJVFRJODFkbFJ3?= =?utf-8?B?ckhtODZWRzVURXpOVTV6endJaFZiaFhxV0IzQ2RJTXVTeXh6bTBYNUhHRkpN?= =?utf-8?B?c2FHV1ZTTkhBc040ZzFSeXNvcW1rN3NjQjZmMm5BckVQSjIxNC9KMGlZZlk2?= =?utf-8?B?OGdUREUyNVJtNDhBSHFPVjhIcEpWWExBUVhxOW1LVFhydDdxRzhpVnNYVGQ1?= =?utf-8?B?aUIyek5KUXU1MDhXZnRDWmw1V0FWOXNnank4ZWtabW1IeGNpWUlnZnBCR2xF?= =?utf-8?B?UVN3Z2dLdWJKTzJDeVZOMDMyRFE4eHJMcGlBdS9hZHh4VEpyc01pUllEQXoy?= =?utf-8?B?Sng2WlRZMVFKZ2U1aXZnR0dBKzlqUk9FMkt2TVZ1Y0VaMGpnS0M1ZzNvcVBR?= =?utf-8?B?RUU5bUhMTWkwSzJEZXMxeG52RHVGZ21YVjZUMFRvMWUrM0FlK3BoUEJ2RUNl?= =?utf-8?B?MSs2WXBjUGJFYWU3L1E1MGdvSHlOZUR6ZmdqMThDOGdnYXVqVHBZT1hYcndq?= =?utf-8?B?UGliTGpqYnlNaGJEL3piYU9KSjl5NFVwYzdOQkk2NGNNUGhkQURvNHhtN2wy?= =?utf-8?B?QUtBZTRaQnFnWUJCZ2xPQm03MnBYQ2NaaGRHcHFER2Y2aXFnRUh4UGhDT3dP?= =?utf-8?B?VWJpMWl5V2I4NW50QWNJcTRJN0psZ0hDczUvYnVYd1lvWEhsNUJ5MjBrbmdy?= =?utf-8?B?NGRiNk5mN1hVdzNxdWtMZ0o4Q1Jvbzkwd25FM3ZTdmZ5Uit0bnYrTTU1b1Zj?= =?utf-8?B?a0V1VHFrenJ0enJVZ0xWUDVjSm43Q1Y0MGF3YUQwZFZ5cUE4aG9iMWVyNjkw?= =?utf-8?B?ay95WW1sRUQxMUc5Nm9ub2x4TE94eU1Ba0NUekVrMlVHcU5lWEszMTh3bWtp?= =?utf-8?B?TmNuZEFQTGNKMndjcmRvOUpvdkJqMjh0MnRNdEVuQkRmOEVYcmNYbG5rNlFh?= =?utf-8?B?cmFEcWtlSzFoRW9rNmN1Znc1TGZXL3p3MGZqWmQyZHp2VSt0MnYvY0dzemY2?= =?utf-8?B?UTI1NG1hbVJBenFaT2o0M0dRV01SRS81QnB4SVc0aWRuRHh6d2tDVVo2RGZN?= =?utf-8?B?c0F2ZEJjZ0xMVklFNkJod3UvTlJhTEx6c3gvY25RRUFRbmU3SXdzWE9hMXFo?= =?utf-8?B?aG4xaFBWKzR0UXF2TmFIT3piVW1BVE8vUlFQZ09aZHNGK01mTEVPZzFqTmZO?= =?utf-8?B?M2IrdlBSZVBoeGJvVmw0UkRRTjZYVkFtY1dzd0VDR2JBVlpORjlVb1dvS3Fy?= =?utf-8?B?amNESUdQNXd4NmZOcE1wMzlkdzhlOVAxSFRyd2xFVWhQNUUrckloVzdjNVBS?= =?utf-8?B?MjVReDRwT1h6cFNucFIxY1FxN0NhZTNLZVBhMjBObDJJL3NvQWdIVVBETFpw?= =?utf-8?B?THJibFI3WXJjd1R1cytpMGV3NjhIN29BZGl3Q3VJNm5pcElwOHREdGo2emxl?= =?utf-8?B?ZmFONWlhRndZUG5QaXdHTWd1Rzc0UERHcGVjUG11ZU1XcUVOSktBL0RPZUt2?= =?utf-8?B?ZVVPaXVEZVh0aklOWkY4UFRFZWs2eXhUT1dNZlF2dm9hc2J0REdicEMwczV5?= =?utf-8?B?eURDY05VTWVwaDFseVlWUFh2U0RLSGxTTUgzaE9rUXZGR3RBRlI2cTE1Yzlq?= =?utf-8?B?clhZc0VBOG0vYVdkK0dXc2hPVEZDRjZXdzA4a1RqRlBXUWFpNm1HTXVnMEZN?= =?utf-8?B?bmcwNlJHcVo2b1BERlpyK3VreGc2eldkVVJVdldWcmMyNW44T3l4TmJmaUlK?= =?utf-8?B?MFVOMUNRcnozMm4xd1lKNmR1WjE1akZZcERTTjdvbHY4bktTR2gyM0VTZVM2?= =?utf-8?B?c3lSM1h1Q1RXZ3l0SzFDUGpvSzhkUjZ0K2E2dlNFVlFDWElBVGNZY0tmL0xI?= =?utf-8?B?ejRDc1ZvOHIvUHJTOVNpRU0ycDBBQndIcG9EcHRTaEczbSt0YjJWcFlOdVFB?= =?utf-8?B?WTlQSTBacEZ0VE5WWGdVSndXZ0xsV3N6VTM5SkVCb0JYaDZOWGk2dWx3Rjl1?= =?utf-8?B?eGFTWjhGUW5BPT0=?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54ff7b86-457e-4004-a3f6-08da0b813100 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2022 21:24:32.6065 (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: 3I7yAIa/jfazbVvoXZUSI+9i7EXzyMmNlrsIdtzZtV9M7v+ypF64/dfFMVMpmD2s X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6408 X-Proofpoint-GUID: dvTpfYGzP17wzmMTb6T-vVOZtdUiVNei X-Proofpoint-ORIG-GUID: dvTpfYGzP17wzmMTb6T-vVOZtdUiVNei X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-21_09,2022-03-21_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 mlxscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203210136 Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 21 Mar 2022 21:24:51 -0000 SGkgS2V0YW4sDQoNCllvdSBhc2tlZCAid2hldGhlciB0aGUgcmVzcG9uc2VzIGFuZCBkcmFmdCB1 cGRhdGVzIGFkZHJlc3MgW215XSBjb25jZXJuc+KAnS4gSeKAmWQgc2F5IHRoYXQgd2hpbGUgSeKA mW0gbm90IGNvbXBsZXRlbHkgaGFwcHkgYWJvdXQgY2VydGFpbiB0aGluZ3MgKGUuZy4sIEkgcmVt YWluIHVuY29udmluY2VkIHRoYXQgdGhlIGNvbXBhbmlvbiBJRFIgZG9jIHNob3VsZG7igJl0IGJl IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSkgSSBkb27igJl0IG5lZWQgdG8gY29udGludWUgaG9sZGlu ZyBhIERJU0NVU1Mgb24gdGhlbTogd2XigJl2ZSBoYWQgYSBkaXNjdXNzaW9uLCB3ZSBkb27igJl0 IGNvbXBsZXRlbHkgYWdyZWUsIHRoZXNlIHRoaW5ncyBoYXBwZW4uIE9uIHBvaW50IDQgaG93ZXZl ciwgSSBkb27igJl0IHRoaW5rIG91ciBkaXNjdXNzaW9uIGhhcyBjb25jbHVkZWQuIEF0IGxlYXN0 LCBpZiB5b3UgcmVwbGllZCB0byB0aGlzLCBJIG1pc3NlZCBpdDoNCg0KPiBPbiBGZWIgMTYsIDIw MjIsIGF0IDI6NDIgUE0sIEpvaG4gU2N1ZGRlciA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0 Zi5vcmc+IHdyb3RlOg0KPiANCj4+IDQuIEluIMKnMi4xIHlvdSB0YWxrIGFib3V0IHRoZSBzaWdu YWxpbmcgb2Ygc3ltYm9saWMgbmFtZXMgZm9yIGNhbmRpZGF0ZSBwYXRocy4NCj4+IEFsdGhvdWdo IHlvdSBhcmUgY2FyZWZ1bCB0byBzYXkgdGhhdCBzdWNoIHN5bWJvbGljIG5hbWVzIGFyZSBvbmx5 IHVzZWQgZm9yDQo+PiBwcmVzZW50YXRpb24gcHVycG9zZXMsIGl0IHNlZW1zIHRvIG1lIHRoZXkg c3RpbGwgY291bGQgYmUgY29uc2lkZXJlZCBhIG5ldw0KPj4gcG90ZW50aWFsIHNvdXJjZSBvZiB2 dWxuZXJhYmlsaXR5LCBzaW5jZSBhIHN0cmluZyB0aGF0IGhhcyBubyBzYW5pdHktY2hlY2tpbmcN Cj4+IHdoYXRzb2V2ZXIgYXBwbGllZCBieSB0aGUgcHJvdG9jb2wgY2FuIGRpc3BsYXkgbGl0ZXJh bGx5IGFueXRoaW5nIHRvIGFuDQo+PiBvcGVyYXRvciB2aWV3aW5nIGl0LiBTaG91bGRu4oCZdCB0 aGlzIGJlIGFkZHJlc3NlZCBpbiB5b3VyIFNlY3VyaXR5DQo+PiBDb25zaWRlcmF0aW9ucz8gKEZv ciBhbiBleGFtcGxlIG9mIGEgcmVsYXRlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgc2VlIFJG Qw0KPj4gOTAwMy4gSXTigJlzIHByb2JhYmx5IG5vdCB0aGUgYmVzdCBleGFtcGxlLCBidXQgaXTi gJlzIHRoZSBvbmUgSSBoYWQgYXQgbXkNCj4+IGZpbmdlcnRpcHPigKYpDQo+PiANCj4+IEtUPiBS RkM5MDAzIHVzZXMgVVRGLTggd2hpbGUgdGhpcyBkb2N1bWVudCB1c2VzIHByaW50YWJsZSBBU0NJ SS4gQXMgc3VjaCwgSSBhbSBub3QgYXdhcmUgb2Ygc2VjdXJpdHkgaXNzdWVzIGFyb3VuZCBwcmlu dGFibGUgQVNDSUkgLSBwbGVhc2UgZG8gcG9pbnQgbWUgdG8gYW55IHJlZmVyZW5jZXMuDQo+IA0K PiBZb3XigJlyZSB0aGlua2luZyB0b28gbXVjaCBsaWtlIGEgcHJvdG9jb2wgZGVzaWduZXIuIFRo ZSBraW5kIG9mIGNvbmNlcm4gSeKAmW0gdGhpbmtpbmcgYWJvdXQgaGFzIHRvIGRvIHdpdGggdXNp bmcgdGhlIHN0cmluZyBhcyBhIHZlY3RvciB0byBwdXQgc29tZSB3b3JkcyBpbiBmcm9udCBvZiBh biBvcGVyYXRvciwgYXMgcGFydCBvZiBhIGxhcmdlciBzb2NpYWwgZW5naW5lZXJpbmcgYXR0ZW1w dC4gSSBkb27igJl0IGhhdmUgYSBkZXRhaWxlZCBhdHRhY2sgc2NlbmFyaW8gdG8gcGFpbnQgZm9y IHlvdSwgYnV0IGEgcXVpY2sgc2tldGNoIGlzIGFsb25nIHRoZSBsaW5lcyBvZg0KPiANCj4gLSBB dHRhY2tlciBtYW5hZ2VzIHRvIGluamVjdCBhIGNhbmRpZGF0ZSBwYXRoIHdpdGggdGhlIG5hbWUg 4oCcQmlnX0JhbmtfTG93X0xhdGVuY3nigJ0NCj4gLSBQcm9UaXA6IHRoZSBjYW5kaWRhdGUgcGF0 aCBkb2VzIG5vdCBhY3R1YWxseSB0ZXJtaW5hdGUgYXQgQmlnX0JhbmsNCj4gLSBBdHRhY2tlciB0 aGVuIHBob25lcyBOT0MsIGZlaWducyB1cmdlbmN5LCBhc2tzIE5PQyB0byByZWRpcmVjdCBCaWdf QmFuayB0cmFmZmljIG9udG8gdGhhdCBwYXRoDQo+IA0KPiBZb3UgZ2V0IHRoZSBpZGVhLCBJIGhv cGUuDQoNCk1vcmUgc25pcHBlZCwgYnV0IHRoaXMgaXMgdGhlIG1lYXQgb2YgaXQuIEluIGNhc2Ug eW91IGhhdmVu4oCZdCBsb29rZWQgYXQgUkZDIDkwMDPigJlzIHNlY3VyaXR5IHNlY3Rpb24sIGhl cmXigJlzIGEgc25pcCBmcm9tIGl0Og0KDQogICBBcyBCR1AgU2h1dGRvd24gQ29tbXVuaWNhdGlv bnMgYXJlIGxpa2VseSB0byBhcHBlYXIgaW4gc3lzbG9nIG91dHB1dCwNCiAgIHRoZXJlIGlzIGEg cmlzayB0aGF0IGNhcmVmdWxseSBjb25zdHJ1Y3RlZCBTaHV0ZG93biBDb21tdW5pY2F0aW9uDQog ICBtaWdodCBiZSBmb3JtYXR0ZWQgYnkgcmVjZWl2aW5nIHN5c3RlbXMgaW4gYSB3YXkgdG8gbWFr ZSB0aGVtIGFwcGVhcg0KICAgYXMgYWRkaXRpb25hbCBzeXNsb2cgbWVzc2FnZXMuIA0KDQooRldJ VywgSSBkaWRu4oCZdCBjb250cmlidXRlIHRoYXQgdGV4dC4pDQoNClBsZWFzZSBkb27igJl0IG9i c2VzcyBhYm91dCDigJxzeXNsb2figJ0gaW4gdGhlIGV4YW1wbGUgYWJvdmUsIGl04oCZcyBub3Qg Y2VudHJhbCB0byB0aGUgcG9pbnQsIGp1c3QgbGlrZSBVVEYtOCB2cyBBU0NJSSBpc27igJl0IGNl bnRyYWwuIFRoZSBwb2ludCwgYWdhaW4sIGlzIHRoYXQgYnkgaW50cm9kdWNpbmcgYSB3YXkgZm9y IGFuIGF0dGFja2VyIHRvIGNhdXNlIGEgdGFyZ2V0IHN5c3RlbSB0byBkaXNwbGF5IGFyYml0cmFy eSBzdHJpbmdzLCBpdCB3b3VsZCBzZWVtIHJlYXNvbmFibGUgdG8gd29uZGVyIGlmIHRoYXQgY3Jl YXRlcyBhbiBvcHBvcnR1bml0eSBmb3IgbWlzY2hpZWYgdGhhdCBkb2VzbuKAmXQgb3JkaW5hcmls eSBleGlzdCBpbiBvdXIgcHJvdG9jb2xzLCBpbnZvbHZpbmcgbWlzbGVhZGluZyBwZW9wbGUgbG9v a2luZyBhdCB0aGUgZGlzcGxheWVkIHN0cmluZyBpbiBhIHVzZXIgaW50ZXJmYWNlLg0KDQpUaGVy ZSBhcmUgdmFyaW91cyB3YXlzIHRoaXMgY29uY2VybiBjb3VsZCBiZSBtaXRpZ2F0ZWQgKGlmIHdl IHdlcmUgdG8gY29tZSB0byBhZ3JlZW1lbnQgdGhhdCBpdOKAmXMgZXZlbiBhIGNvbmNlcm4pLiBP bmUgd291bGQgYmUgdG8gcmVtb3ZlIHRoZSDigJxzaWduYWwgYXJiaXRyYXJ5IHN0cmluZ3PigJ0g aWRlYTsgdGhpcyBpcyBjbGVhcmx5IHRoZSBzb2xpZGVzdCB3YXkgdG8gZG8gaXQuIEFub3RoZXIg d291bGQgYmUgdG8gbWFuZGF0ZSAob3Igc3Ryb25nbHkgc3VnZ2VzdCkgdGhhdCBzeW1ib2xpYyBu YW1lcyBnbGVhbmVkIGZyb20gc29tZXRoaW5nIG90aGVyIHRoYW4gY29uZmlndXJhdGlvbiBiZSBk aXNwbGF5ZWQgaW4gc3VjaCBhIHdheSBhcyB0byBtYWtlIHRoZSBvcGVyYXRvciBhd2FyZSBvZiB0 aGVpciBzdGF0dXMuIEF0IGEgbWluaW11bSwgb25lIG1pZ2h0IGFkZCBhIHBhcmFncmFwaCBvciB0 d28gaWRlbnRpZnlpbmcgdGhlIGNvbmNlcm4uIEnigJltIHN1cmUgdGhlcmUgYXJlIG90aGVyIHRo aW5ncyB0aGF0IGNvdWxkIGJlIGNvbnRlbXBsYXRlZC4NCg0KUmVnYXJkcywNCg0K4oCUSm9obg== From nobody Mon Mar 21 16:14:55 2022 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 3BF8D3A1364 for ; Mon, 21 Mar 2022 16:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.108 X-Spam-Level: X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=raszuk.net 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 BmfQ0ruk8Rpp for ; Mon, 21 Mar 2022 16:14:15 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 064253A13A5 for ; Mon, 21 Mar 2022 16:14:14 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id l184so232065vkh.0 for ; Mon, 21 Mar 2022 16:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3CQfYfTwEgZ/sXnPzj3o85p+z+80VBLQeVQTkkOzwtQ=; b=RYGRxGviaSr7NpgZJiREsERvew2N88F9IFzS2LSA+HGeZRDZ1Pgw/2xJGi7SdaIHIt wIcmOcZJlAf3z7hpdPMN0YwECE9S3+PEF/wlhbzKix9PrjRga2nYqFUf/Xbe8uxJ06xD H5Gy9uePudkMas6hZ55ujVNPfIFKd8e2lCN7S6oU1X85l8ntu23fM9r37tMQc0k1apIy IkgnyL3vj1R9hGIEQEMaZ9KlsLPi+ndr4WVXiUdoLnIx+0nTwazqxpqQs78GEaXJF3Yv GAYCigcQYJoW2PURJ0Ol6NHYKCd1rZh9L8fsQcX25J3YVWdcn9ynIo8YtA2L5MRMdkJZ 9NPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3CQfYfTwEgZ/sXnPzj3o85p+z+80VBLQeVQTkkOzwtQ=; b=pDN8GiWqsxcnV1ZdQ/MRUNxt+iuhjgTUoDhaX9EXBCkP13Vx8ObsE6+5wFgf1s/YHq o+coevtz/EoGCkgB9wQREyFg2jBEhq46MyNDz+6G/z2R0hQ+hH7CKRX8PNMDYPMuko2q HGjmJcGws3INsdEcdvfuzIi3ulPiz29PhmhBOboK04WgynjErwR65T17K6+XRcwLABEs 5jGlzhhdTySiNrr4y/pSyucQ9NA1Fwm8kPFywrG+/m8+iQ+XT9cpS+KwQwcKKqul6+RR /8JpGBR53eSClz6fDHFtz/WQx00654cFhH6xP91FCxkOftmPK1exsIf+P7mRlqkIIHkD RCcw== X-Gm-Message-State: AOAM531iWD5rAc/nAC/RLHk0N3yjSTq2o8ewDIQ0kdqKRDmTxM1dBAo/ 8FaJaiHNvo/AEtLhH/pbBKaJ5Rsc2nvc7EzEisHsdQ== X-Google-Smtp-Source: ABdhPJywNUXhSsVQ1MRkufyudc04BZIrLP9TXCe45QpiSJkCVRMaOtR7e3wQ5b1wN7IjvZDliCd0fO6fvPQoNtaz3V4= X-Received: by 2002:a05:6122:7c9:b0:33d:d590:585f with SMTP id l9-20020a05612207c900b0033dd590585fmr9199363vkr.18.1647904453373; Mon, 21 Mar 2022 16:14:13 -0700 (PDT) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: From: Robert Raszuk Date: Tue, 22 Mar 2022 00:14:52 +0100 Message-ID: To: John Scudder Cc: Ketan Talaulikar , "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="0000000000009144d805dac2a787" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 21 Mar 2022 23:14:21 -0000 --0000000000009144d805dac2a787 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, The point, again, is that by introducing a way for an attacker to cause a > target system to display arbitrary strings, it would seem reasonable to > wonder if that creates an opportunity for mischief that doesn=E2=80=99t o= rdinarily > exist in our protocols, involving misleading people looking at the > displayed string in a user interface. > Hmmm while I am not clear what "our protocols" mean in this context I do see a number of cases where protocols have the ability to carry free form text. For example, how about RFC8203 ? There are few other works in progress to also add such ability. So above all I am trying to sense if your above comment is a specific to draft-ietf-spring-segment-routing-policy (which is by design *strongly* limited to the same administration so it would be pretty weird to be concerned about it) or is it more general in nature ? Thx, Robert --0000000000009144d805dac2a787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

The point, again, is t= hat by introducing a way for an attacker to cause a target system to displa= y arbitrary strings, it would seem reasonable to wonder if that creates an = opportunity for mischief that doesn=E2=80=99t ordinarily exist in our proto= cols, involving misleading people looking at the displayed string in a user= interface.

Hmmm while I am not clear w= hat "our protocols" mean in this context I do see a number of cas= es where protocols have the ability to carry free form text.=C2=A0

For example, how about RFC8203 ?=C2=A0

There are few other works in progress to also add such ability. So ab= ove all I am trying to sense if your above comment=C2=A0is a specific to=C2= =A0draft-ietf-spring-segment-routing-policy (which is by design *strongly* = limited to the same administration so it would be pretty weird to be concer= ned about it) or is it more general in nature ?=C2=A0

<= div>Thx,
Robert

--0000000000009144d805dac2a787-- From nobody Mon Mar 21 19:31:25 2022 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 354353A1CC9; Mon, 21 Mar 2022 19:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 eQg7zap6I0NS; Mon, 21 Mar 2022 19:31:18 -0700 (PDT) Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) (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 8A14F3A1CC8; Mon, 21 Mar 2022 19:31:16 -0700 (PDT) Received: from mail.maildlp.com ([172.25.15.154]) by h3cspam02-ex.h3c.com with ESMTP id 22M2SikU061533; Tue, 22 Mar 2022 10:28:44 +0800 (GMT-8) (envelope-from linchangwang.04414@h3c.com) Received: from DAG2EX09-IDC.srv.huawei-3com.com (unknown [10.8.0.72]) by mail.maildlp.com (Postfix) with ESMTP id 61D56246D472; Tue, 22 Mar 2022 10:29:55 +0800 (CST) Received: from DAG2EX07-IDC.srv.huawei-3com.com (10.8.0.70) by DAG2EX09-IDC.srv.huawei-3com.com (10.8.0.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 22 Mar 2022 10:28:44 +0800 Received: from DAG2EX07-IDC.srv.huawei-3com.com ([fe80::2dff:54b3:cdc:daad]) by DAG2EX07-IDC.srv.huawei-3com.com ([fe80::2dff:54b3:cdc:daad%9]) with mapi id 15.01.2375.017; Tue, 22 Mar 2022 10:28:44 +0800 From: linchangwang To: "rtg-bfd@ietf.org" , "jhaas@pfrc.org" , "reshad@yahoo.com" CC: Lihao , "jiangwenying@chinamobile.com" , "chengweiqiang (chengweiqiang@chinamobile.com)" , "spring@ietf.org" Thread-Topic: Discuss on draft-lin-sbfd-path-consistency-over-srv6-00 Thread-Index: Adg9lItZSTV7l6NCQVmogVCNMcV8Ig== Date: Tue, 22 Mar 2022 02:28:44 +0000 Message-ID: <84d962b16db840d7a11caeb64dbc7b9c@h3c.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.76.67] x-sender-location: DAG2 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam02-ex.h3c.com 22M2SikU061533 Archived-At: Subject: [spring] Discuss on draft-lin-sbfd-path-consistency-over-srv6-00 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 Mar 2022 02:31:24 -0000 DQpIaSBXRyAsQ2hhaXJzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWxpbi1zYmZkLXBhdGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwDQoNClRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIGtlZXAgdGhlIGZvcndhcmQgcGF0aCBhbmQNCnJl dmVyc2UgcGF0aCBvZiBTLUJGRCBjb25zaXN0ZW50IHdoZW4gZGV0ZWN0aW5nIFNSdjYgUG9saWN5 Lg0KDQpUaGVyZSBpcyBubyBtZWV0aW5nIGZvciBiZmQgaW4gSUVURi0xMTMsICB3ZSB3aWxsIHBy ZXNlbnQgdGhpcyBkcmFmdCBpbiBzcHJpbmcgV0c6DQogIE1hcmNoIDI1LCAyMDIyICAxMjozMC0x NDozMCBGcmlkYXkgQWZ0ZXJub29uIHNlc3Npb24gSSAoVVRDKzEpDQogIG8gUy1CRkQgUGF0aCBD b25zaXN0ZW5jeSBvdmVyIFNSdjZbIDUgbWludXRlcyBdDQoNClMtQkZEIGNvdWxkIGJlIHVzZWQg dG8gbW9uaXRvciBTUnY2IFBvbGljeSwgIGEgc2Vzc2lvbiBhc3NvY2lhdGVkIHdpdGggYSBzZWdt ZW50IGxpc3QuDQpQYXRoIGluY29uc2lzdGVuY3kgbWF5IGNhdXNlIGZhbHNlIHBvc2l0aXZlIGlz c3VlLg0KVG8gdGhlIGlzc3VlLCBUaGUgY29uc2lzdGVuY3kgb2YgZm9yd2FyZCBhbmQgcmV2ZXJz ZSBwYXRoIG9mIHRoZSBzYW1lIHNlc3Npb24gc2hvdWxkIGJlIGd1YXJhbnRlZWQuDQpUaGlzIGRy YWZ0IGRlc2NyaWJlcyBob3cgdG8gcmVhbGl6ZSB0aGUgYmlkaXJlY3Rpb25hbCBwYXRoIGNvbnNp c3RlbmN5IG9mIHBhY2tldCB3aGVuIG1vbml0b3JpbmcgU1J2NiBwb2xpY3kgYnkgUy1CRkQuDQoN CkhvdyB0byBjb3JyZWxhdGUgYmlkaXJlY3Rpb25hbCBwYXRoPw0KMS4gIENvcnJlbGF0aW5nIGJp ZGlyZWN0aW9uYWwgcGF0aCB1c2luZyBQYXRoIFNlZ21lbnQNCiAgICAyLiAgUGF0aCBTZWdtZW50 IGlzIGRlZmluZWQgdG8gaWRlbnRpZnkgYW4gU1IgcGF0aCBpbiBbZHJhZnQtaWV0Zi1zcHJpbmct c3J2Ni1wYXRoLXNlZ21lbnRdDQogICAgMy4gIFtkcmFmdC1pZXRmLWlkci1zci1wb2xpY3ktcGF0 aC1zZWdtZW50XSBleHRlbmRzIEJHUCBTUiBQb2xpY3kNCiAgICA0LiAgVXNpbmcgcGF0aCBzZWdt ZW50IGFuZCByZXZlcnNlIHBhdGggc2VnbWVudCB0byBlc3RhYmxpc2ggYSBtYXBwaW5nIHRhYmxl DQogICAgICAgVXNpbmcgdGhlIG1hcHBpbmcgdGFibGUgdG8gZ2V0IHNlZ21lbnQgbGlzdCBieSBy ZXZlcnNlIFBhdGggc2VnbWVudA0KDQpTLUJGRCBJbml0aWF0b3IgcHJvY2VkdXJlOg0KICAgIDEu IEVuY2Fwc3VsYXRpbmcgdGhlIHNlZ21lbnQgbGlzdCBhc3NvY2lhdGVkIHdpdGggU0JGRC1zZXNz aW9uIHNlc3Npb24gdG8gU1JIDQogICAgMi4gRW5jYXBzdWxhdGluZyB0aGUgcGF0aCBzZWdtZW50 IG9mIHNlZ21lbnQgbGlzdCBpbiBTUkgsIGFuZCBzZXQgU1JILlAtRmxhZw0KDQpTLUJGRCByZWZs ZWN0b3IgcHJvY2VkdXJlOg0KICAgIDEuIElmIFNSSC5QLWZsYWcgaXMgc2V0LCBleHRyYWN0cyB0 aGUgcGF0aCBzZWdtZW50IChpLmUuIFNJRC1QYXRoLUExKW9mIHRoZSBmb3J3YXJkIHBhdGggZnJv bSBTUkgNCiAgICAyLkdldCBzZWdtZW50IGxpc3Qgb2YgcmV2ZXJzZSBwYXRoIGJ5IHRoZSBwYXRo IHNlZ21lbnQgYXMgYSByZXZlcnNlIHBhdGggc2VnbWVudCBmcm9tIG1hcHBpbmcgdGFibGUNCiAg ICAzLiBFbmNhcHN1bGF0aW5nIHJlc3BvbnNlIHBhY2tldCB3aXRoIHRoZSByZXZlcnNlIHNlZ21l bnQgbGlzdA0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBncmVhdGx5IHdlbGNv bWUuDQoNCkJlc3QgcmVnYXJkcywNCkNoYW5nd2FuZyBMaW4NCg0KDQoNCreivP7IyzogbGluY2hh bmd3YW5nIChSRCkNCreiy83KsbzkOiAyMDIyxOoz1MIyyNUgMjM6MTcNCsrVvP7Iyzogamlhbmd3 ZW55aW5nQGNoaW5hbW9iaWxlLmNvbTsgY2hlbmd3ZWlxaWFuZyAoY2hlbmd3ZWlxaWFuZ0BjaGlu YW1vYmlsZS5jb20pOyBsaWhhbyAoMDI1NjYsIFJEKTsgJ3J0Zy1iZmRAaWV0Zi5vcmcnDQrW98zi OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNy djYtMDAudHh0DQoNCkhpIFdHLA0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IGRyYWZ0IGFi b3V0IHNiZmQgcGF0aCBjb25zaXN0ZW5jeSBvdmVyIFNSdjYgaW4gQkZEV0cuDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpbi1zYmZkLXBhdGgtY29uc2lzdGVu Y3ktb3Zlci1zcnY2LTAwDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIGtl ZXAgdGhlIGZvcndhcmQgcGF0aCBhbmQNCnJldmVyc2UgcGF0aCBvZiBTLUJGRCBjb25zaXN0ZW50 IHdoZW4gZGV0ZWN0aW5nIFNSdjYgUG9saWN5Lg0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zIGFyZSBncmVhdGx5IHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNCkNoYW5nd2FuZyBMaW4N Cg0KDQoNCg0KDQq3orz+yMs6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIw MjLE6jPUwjLI1SAxOTozMw0KytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCtb3zOI6IEkt RCBBY3Rpb246IGRyYWZ0LWxpbi1zYmZkLXBhdGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwLnR4 dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAg ICA6IFMtQkZEIFBhdGggQ29uc2lzdGVuY3kgb3ZlciBTUnY2DQogICAgICAgIEF1dGhvcnMgICAg ICAgICA6IENoYW5nd2FuZyBMaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgV2VpcWlhbmcg Q2hlbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgV2VueWluZyBKaWFuZw0KRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNydjYtMDAudHh0 DQpQYWdlcyAgICAgICAgICAgOiAxMg0KRGF0ZSAgICAgICAgICAgIDogMjAyMi0wMy0wMg0KDQpB YnN0cmFjdDoNCiAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgY2Fu IGJlIHVzZWQgdG8gbW9uaXRvcg0KICAgcGF0aHMgYmV0d2VlbiBub2Rlcy4gU2VhbWxlc3MgQkZE IChTLUJGRCkgcHJvdmlkZXMgYSBzaW1wbGlmaWVkDQogICBtZWNoYW5pc20gd2hpY2ggaXMgc3Vp dGFibGUgZm9yIG1vbml0b3Jpbmcgb2YgcGF0aHMgdGhhdCBhcmUgc2V0dXANCiAgIGR5bmFtaWNh bGx5IGFuZCBvbiBhIGxhcmdlIHNjYWxlIG5ldHdvcmsuIEluIFNSdjYsIHdoZW4gYSBoZWFkZW5k DQogICB1c2UgUy1CRkQgdG8gbW9uaXRvciB0aGUgc2VnbWVudCBsaXN0L0NQYXRoIG9mIFNSdjYg UG9saWN5LCB0aGUNCiAgIGZvcndhcmQgcGF0aCBvZiBTLUJGRCBwYWNrZXQgaXMgaW5kaWNhdGVk IGJ5IHNlZ21lbnQgbGlzdCwgdGhlDQogICByZXZlcnNlIHBhdGggb2YgQkZEIHBhY2tldCBpcyB2 aWEgdGhlIHNob3J0ZXN0IHBhdGggZnJvbSB0aGUNCiAgIHJlZmxlY3RvciBiYWNrIHRvIHRoZSBp bml0aWF0b3IgKGhlYWRlbmQpIGFzIGRldGVybWluZWQgYnkgcm91dGluZy4NCiAgIFRoZSBmb3J3 YXJkIHBhdGggYW5kIHJldmVyc2UgcGF0aCBvZiBTLUJGRCBwYWNrZXQgYXJlIGxpa2VseQ0KICAg aW5jb25zaXN0ZW50IGdvaW5nIHRocm91Z2ggZGlmZmVyZW50IGludGVybWVkaWF0ZSBub2RlcyBv ciBsaW5rcy4NCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIGtlZXAgdGhl IGZvcndhcmQgcGF0aCBhbmQNCiAgIHJldmVyc2UgcGF0aCBvZiBTLUJGRCBjb25zaXN0ZW50IHdo ZW4gZGV0ZWN0aW5nIFNSdjYgUG9saWN5Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNydjYvDQoNClRoZXJlIGlz IGFsc28gYW4gaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpbi1zYmZkLXBhdGgtY29uc2lzdGVuY3ktb3Zl ci1zcnY2LTAwDQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSByc3lu YyBhdCByc3luYy5pZXRmLm9yZzo6aW50ZXJuZXQtZHJhZnRzDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxp c3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hh ZG93LXNpdGVzLnR4dA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Ksb7Tyrz+vLDG5Li9vP66rNPQ0MK7 qsj9vK/NxbXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2DQq1xLj2yMu78si6 1+mho7371rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a1 2NC5wrahori01sahog0Ku/LJoreio6mxvtPKvP7W0LXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+ o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb4NCtPKvP6joQ0KVGhpcyBlLW1h aWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBm cm9tIE5ldyBIM0MsIHdoaWNoIGlzDQppbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVu dGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9y bWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxp bWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3Ig ZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBp ZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmJ5IHBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgaXQhDQo= From nobody Tue Mar 22 01:55:26 2022 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 490FC3A0CFC; Tue, 22 Mar 2022 01:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 02AgxiqbyeQe; Tue, 22 Mar 2022 01:54:58 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 7D8613A0CF4; Tue, 22 Mar 2022 01:54:58 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id 186so884345vky.6; Tue, 22 Mar 2022 01:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yHvz4XBuV9juYsZewL8qA15i/5Npxq8nwlAvKaqifLY=; b=lzGKpfmV1arudy/wQKN53f6BIq8HbYuFjHteN0WMKlzfpxgsFMZjrHvA+c5x/qg1bM bAEFMHL5zjq44T473K0BsKIpz18KwEdWt2ZAA5AgvoZZucPltzR/LXKZENSr3EDklVAf IdYRVAdW8OMLbnb3EBscXezEAOyfWRr9BfTcCF12WK9bDc5nSMjuizSjXLXqR+hUmnjH 6v9uK4NOeGfqLqw4FC/0AYmUHtteZXj8Ik2UITWyoGikovyPadE07z1/YZHth5tEHda+ q536hXtNGV9EIUMIEj+TSm6jFSalCUeNv8p9hKCNVGt17T+WAhNn4qGxa8eCObuTVx8B tuOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yHvz4XBuV9juYsZewL8qA15i/5Npxq8nwlAvKaqifLY=; b=J2H3i2Fqs8Eie97+hIbU0NRTb7oy1K2g3PD6UWsqW4fkRTPrf0Jtx/amYjc+l8E/95 jBa8vqkSll9W69pFCzE3ndZAqJ7W5+qlIc4zXPP/rARARqvhs55WXW4HNh3zcgBmDcUg cjzFm+Zo8A1++3+0d9ttIIC8khW3qje+VDxxKMpynCIzTr8bCEe+2/Iwy5Fi/MrAWZ8i dntfhE8cIkrVzru0jMZ0caDS74pPr1BVg8UDe9gGkLLT4sgExKySjm9JLCKivXCu7iEd is1r6baVhoSJhpUqMjZ79KVZbd7yF4xafoiJmB4Z2iE1ysndOE3KygB4Hlzl9tFRiYRC AF6Q== X-Gm-Message-State: AOAM532W357OWSYbfismT7h2U6mrvZMUjdjxze+9w2AuUup8MDHEq45N dMykuDH+w2+TiFHEvMB+7aMtYSPEhvpKt5Q6+6dnCZAbKcs= X-Google-Smtp-Source: ABdhPJzlqybpETbQuEaqDj965WXlVGbbNLUeC7abkmDj0oYtlqsmInJaVyPUlYWcMNSilF+LIzFWGrxJvcVAaa1TJeU= X-Received: by 2002:a05:6122:16a6:b0:33f:262e:2c1d with SMTP id 38-20020a05612216a600b0033f262e2c1dmr2752703vkl.33.1647939296928; Tue, 22 Mar 2022 01:54:56 -0700 (PDT) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: From: Ketan Talaulikar Date: Tue, 22 Mar 2022 14:24:44 +0530 Message-ID: To: John Scudder Cc: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="00000000000067a56105dacac499" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 22 Mar 2022 08:55:04 -0000 --00000000000067a56105dacac499 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, I dug into my emails and you are right that while we had a discussion on point 4 (i.e. security considerations associated with the use of symbolic names), it was not concluded. My apologies for the same. It might be helpful to place a context on why the draft uses symbolic names in the first place. The closest analogies that come to my mind are tunnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These constructs have had symbolic names associated with them for a long time now - both for local use on routers (some implementation-specific - others specified by IETF) and also signaled via routing protocols. Operators are therefore quite familiar with their usage and hence their introduction in the SR Policy construct. I don't believe the WG would want to take the option of their removal (it was a suggested option). Then we get to option of adding specific text to the draft (in the security considerations?) that would discuss your concerns. Such text may be addressed to implementators and/or operators. As mentioned above, the use of symbolic names for constructs similar to SR Policy name and SR Policy Candidate Path name is not "new" for both sets of readers. Therefore, I am not sure if we need to cover or add anything new in this document and I could not find text that I could borrow from other RFCs or point to other RFCs. e.g., https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2 I did look at RFC9003 but its context is very different. From your DISCUSS comment, I see that your concern is that a string does not have any sanity checking - the operator is free to use any text. I agree. Do we want implementations to restrict something? Do we want to give some naming guidelines or precautions to the operators? In a previous response, your suggestions for the text for operators were (somewhat?) of the nature - "beware the name of the SR Policy may not actually be correct or may be misleading because someone might have hacked into the network". I am not sure if something of that nature helps. If the names stop being meaningful then they are no more relevant? Isn't the security aspect to be taken care of here is to prevent hacking? Something beyond the scope of this draft? I'll admit that I am running out of ideas on what would be a meaningful text to add to address your concerns. Would appreciate some text suggestion that is relevant to this specific context. Thanks, Ketan On Tue, Mar 22, 2022 at 2:54 AM John Scudder wrote: > Hi Ketan, > > You asked "whether the responses and draft updates address [my] concerns= =E2=80=9D. > I=E2=80=99d say that while I=E2=80=99m not completely happy about certain= things (e.g., I > remain unconvinced that the companion IDR doc shouldn=E2=80=99t be a norm= ative > reference) I don=E2=80=99t need to continue holding a DISCUSS on them: we= =E2=80=99ve had a > discussion, we don=E2=80=99t completely agree, these things happen. On po= int 4 > however, I don=E2=80=99t think our discussion has concluded. At least, if= you > replied to this, I missed it: > > > On Feb 16, 2022, at 2:42 PM, John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > > >> 4. In =C2=A72.1 you talk about the signaling of symbolic names for can= didate > paths. > >> Although you are careful to say that such symbolic names are only used > for > >> presentation purposes, it seems to me they still could be considered a > new > >> potential source of vulnerability, since a string that has no > sanity-checking > >> whatsoever applied by the protocol can display literally anything to a= n > >> operator viewing it. Shouldn=E2=80=99t this be addressed in your Secur= ity > >> Considerations? (For an example of a related Security Considerations, > see RFC > >> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s the= one I had at my > >> fingertips=E2=80=A6) > >> > >> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As > such, I am not aware of security issues around printable ASCII - please d= o > point me to any references. > > > > You=E2=80=99re thinking too much like a protocol designer. The kind of = concern > I=E2=80=99m thinking about has to do with using the string as a vector to= put some > words in front of an operator, as part of a larger social engineering > attempt. I don=E2=80=99t have a detailed attack scenario to paint for you= , but a > quick sketch is along the lines of > > > > - Attacker manages to inject a candidate path with the name > =E2=80=9CBig_Bank_Low_Latency=E2=80=9D > > - ProTip: the candidate path does not actually terminate at Big_Bank > > - Attacker then phones NOC, feigns urgency, asks NOC to redirect > Big_Bank traffic onto that path > > > > You get the idea, I hope. > > More snipped, but this is the meat of it. In case you haven=E2=80=99t loo= ked at > RFC 9003=E2=80=99s security section, here=E2=80=99s a snip from it: > > As BGP Shutdown Communications are likely to appear in syslog output, > there is a risk that carefully constructed Shutdown Communication > might be formatted by receiving systems in a way to make them appear > as additional syslog messages. > > (FWIW, I didn=E2=80=99t contribute that text.) > > Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the example= above, it=E2=80=99s not central > to the point, just like UTF-8 vs ASCII isn=E2=80=99t central. The point, = again, is > that by introducing a way for an attacker to cause a target system to > display arbitrary strings, it would seem reasonable to wonder if that > creates an opportunity for mischief that doesn=E2=80=99t ordinarily exist= in our > protocols, involving misleading people looking at the displayed string in= a > user interface. > > There are various ways this concern could be mitigated (if we were to com= e > to agreement that it=E2=80=99s even a concern). One would be to remove th= e =E2=80=9Csignal > arbitrary strings=E2=80=9D idea; this is clearly the solidest way to do i= t. Another > would be to mandate (or strongly suggest) that symbolic names gleaned fro= m > something other than configuration be displayed in such a way as to make > the operator aware of their status. At a minimum, one might add a paragra= ph > or two identifying the concern. I=E2=80=99m sure there are other things t= hat could > be contemplated. > > Regards, > > =E2=80=94John --00000000000067a56105dacac499 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

I dug into my= emails and you are right that while we had a discussion on point 4 (i.e. s= ecurity considerations associated with the use of symbolic names), it was n= ot concluded. My apologies for the same.

It might = be helpful to place a context on why the draft uses symbolic names in the f= irst place. The closest analogies that come to my mind are tunnels (differe= nt types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These constructs ha= ve had symbolic names associated with them for a long time now - both for l= ocal use on routers (some implementation-specific - others specified by IET= F) and also signaled via routing protocols. Operators are therefore quite f= amiliar with their usage and hence their introduction in the SR Policy cons= truct. I don't believe the WG would want to take the option of their re= moval (it was a suggested option).

Then we get to = option of adding specific text to the draft (in the security considerations= ?)=C2=A0that would discuss your concerns. Such text may be addressed to=C2= =A0implementators=C2=A0and/or operators. As mentioned above, the use of sym= bolic names for constructs similar to SR Policy name and SR Policy Candidat= e Path name is not "new" for both sets of readers. Therefore, I a= m not sure if we need to cover or add anything new in this document and I c= ould not find text that I could borrow from other RFCs or point to other RF= Cs. e.g.,=C2=A0https://www.rfc-editor.org/rfc/rfc8231.html#sec= tion-7.3.2

I did look at RFC9003 but its conte= xt is very different. From your DISCUSS comment, I see that your concern is= that a string does not have any sanity checking - the operator is free to = use any text. I agree. Do we want implementations to restrict something? Do= we want to give some naming guidelines or precautions to the operators?

In a previous response, your suggestions for the tex= t for operators were (somewhat?) of the nature - "beware the name of t= he SR Policy may not actually be correct or may be misleading because someo= ne might have hacked into the network". I am not sure if something of = that nature helps. If the names stop being meaningful then they are no more= relevant? Isn't the security aspect to be taken care of here is to pre= vent hacking? Something beyond the scope of this draft?

I'll admit that I am running out of ideas on what would be a mean= ingful text to add to address your concerns. Would appreciate some text sug= gestion that is relevant to this specific context.

Thanks,
Ketan

On Tue, Mar 22, 2022 at 2:54 AM John Scudder = <jgs@juniper.net> wrote:
Hi = Ketan,

You asked "whether the responses and draft updates address [my] concer= ns=E2=80=9D. I=E2=80=99d say that while I=E2=80=99m not completely happy ab= out certain things (e.g., I remain unconvinced that the companion IDR doc s= houldn=E2=80=99t be a normative reference) I don=E2=80=99t need to continue= holding a DISCUSS on them: we=E2=80=99ve had a discussion, we don=E2=80=99= t completely agree, these things happen. On point 4 however, I don=E2=80=99= t think our discussion has concluded. At least, if you replied to this, I m= issed it:

> On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.or= g> wrote:
>
>> 4. In =C2=A72.1 you talk about the signaling of symbolic names for= candidate paths.
>> Although you are careful to say that such symbolic names are only = used for
>> presentation purposes, it seems to me they still could be consider= ed a new
>> potential source of vulnerability, since a string that has no sani= ty-checking
>> whatsoever applied by the protocol can display literally anything = to an
>> operator viewing it. Shouldn=E2=80=99t this be addressed in your S= ecurity
>> Considerations? (For an example of a related Security Consideratio= ns, see RFC
>> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s= the one I had at my
>> fingertips=E2=80=A6)
>>
>> KT> RFC9003 uses UTF-8 while this document uses printable ASCII= . As such, I am not aware of security issues around printable ASCII - pleas= e do point me to any references.
>
> You=E2=80=99re thinking too much like a protocol designer. The kind of= concern I=E2=80=99m thinking about has to do with using the string as a ve= ctor to put some words in front of an operator, as part of a larger social = engineering attempt. I don=E2=80=99t have a detailed attack scenario to pai= nt for you, but a quick sketch is along the lines of
>
> - Attacker manages to inject a candidate path with the name =E2=80=9CB= ig_Bank_Low_Latency=E2=80=9D
> - ProTip: the candidate path does not actually terminate at Big_Bank > - Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_B= ank traffic onto that path
>
> You get the idea, I hope.

More snipped, but this is the meat of it. In case you haven=E2=80=99t looke= d at RFC 9003=E2=80=99s security section, here=E2=80=99s a snip from it:
=C2=A0 =C2=A0As BGP Shutdown Communications are likely to appear in syslog = output,
=C2=A0 =C2=A0there is a risk that carefully constructed Shutdown Communicat= ion
=C2=A0 =C2=A0might be formatted by receiving systems in a way to make them = appear
=C2=A0 =C2=A0as additional syslog messages.

(FWIW, I didn=E2=80=99t contribute that text.)

Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the example a= bove, it=E2=80=99s not central to the point, just like UTF-8 vs ASCII isn= =E2=80=99t central. The point, again, is that by introducing a way for an a= ttacker to cause a target system to display arbitrary strings, it would see= m reasonable to wonder if that creates an opportunity for mischief that doe= sn=E2=80=99t ordinarily exist in our protocols, involving misleading people= looking at the displayed string in a user interface.

There are various ways this concern could be mitigated (if we were to come = to agreement that it=E2=80=99s even a concern). One would be to remove the = =E2=80=9Csignal arbitrary strings=E2=80=9D idea; this is clearly the solide= st way to do it. Another would be to mandate (or strongly suggest) that sym= bolic names gleaned from something other than configuration be displayed in= such a way as to make the operator aware of their status. At a minimum, on= e might add a paragraph or two identifying the concern. I=E2=80=99m sure th= ere are other things that could be contemplated.

Regards,

=E2=80=94John
--00000000000067a56105dacac499-- From nobody Tue Mar 22 03:14:40 2022 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 40E183A0DD8; Tue, 22 Mar 2022 03:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CMUaCOFq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OqsI8n+3 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 Ue333qC0nn1K; Tue, 22 Mar 2022 03:13:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0583A1188; Tue, 22 Mar 2022 03:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19041; q=dns/txt; s=iport; t=1647944000; x=1649153600; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PXDOqxeZt4cCJ1UGVMAxGjq1d9dFER7ScqCE4KKvTQY=; b=CMUaCOFqUxuzmebDw/xv2aJ+dK2PmO5w8V7jlGYphlTZ94Q2XlLeKApK aHvHFwEYJQFA8MPPdEqFs4eLFSSREu3B4WWxdNvK86guf8hxsvuToCN5W FahMrlyEFfkijp02LKazPQoMYIltUQZ77BDYpvpWB7RdELajAbB0Ilmmi 0=; X-IPAS-Result: =?us-ascii?q?A0ALAADznzlimIYNJK1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UYHAQELAYEgMVZ+WjdEiB4DhFlghRCDAgOLEYsOhRaBLhSBEQNUCwEBAQ0BA?= =?us-ascii?q?SoBDAoEAQGFBwKEPQIlNAkOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEF?= =?us-ascii?q?AEBAQEBAQEBCRQHBgwFDhAnhTsIJQ2GQgEBAQEDAQEQLgEBLAkDDwIBCBEDA?= =?us-ascii?q?QIBLiEGCx0IAgQBEggagmIBgg5XAy4BDp9xAYE6AoEOiRF4gTOBAYIIAQEGB?= =?us-ascii?q?ASBNwEDBAxBgn8NC4I3AwaBPAGDEIMAgSSHFCccgUlEgRVDgmc+giFCAQECA?= =?us-ascii?q?YEjBQESASMeDYMkgi6XJRAVRjgMJgRRAhRGAQsfQCcnGQVGkkGNAECNPpE/Q?= =?us-ascii?q?2sKg0mLD45phhkVg3SMMJgdlglSIIx1g1KQTxgThHgCBAIEBQIOAQEGgWGBJ?= =?us-ascii?q?XBwFRohgmlRGQ+BNoxqCQMNCRWDO4UUHIUudQI2AgYLAQEDCZBSAQE?= IronPort-PHdr: A9a23:KaNGDhE824KB1kL0Lt6o5Z1GfiYY04WdBeZdwpYkircbdKOl8tyiO UHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLURJWhcAfhQd1BsmDBAXyJ+LraCpvG sNEWRdl8ni3PFITFtz5YgjZo2a56ngZHRCsXTc= IronPort-Data: A9a23:1PUoPqCDM3fRkhVW/6/jw5YqxClBgxIJ4kV8jS/XYbTApD4q0DYHm DRNWm6APf6Ka2H9Ltwka4u/pxkC7JDTzIRmOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOukYAL4EnopH1U8E3170UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqgw48+LdmNaAmQEYKhxWMnIFq8 tV1nMnlIespFvWkdOU1Wh1cFWR1OrdLveadZ3O+qseUiUbBdhMAwd03UxpwZtNeo70xWDoSn RAbAGhlghSrjuK/yr62TvJEjcU4J86tN4Qa0p1l5WGDUq99HMuaGc0m4/de0jYupfwJIMz/O dEFVmBwTinsSiRQbwJ/5JUWxbf02SaXnydjgF6PrKQrpmbSyBd/0bz2dcHNYN2MSoBNl1qY4 37c9m/4BB4yNdGDx3yC6H3Eru7XhSbTWY8OGvu/7PECqEaL3G0VBzUXWEe15/6jhSaWUtJWI UAZ/jF78fA59VegSZ/2WBiQrHuNpBVaWtdMHas98g7l4rbd50CcB3oeRz5ALsQmuOc5QDUr0 hmCmNaBONB0mLSRTXTY/bCOoHbrY24eLHQJYmkPSg5tD8TfTJ8bqzDBZMc+EfSPp9yoFRH1w GGRligGruBG5SIU7JmT8VfCijOqg5HGSA8p+wnaNl5JCCskOOZJgKT1sjDmAeZ8wJWxFQLY5 Sda8ySKxKVfU8/SxXXlrPAlRenxj8tpJgEwlrKG83MJ3jCp9njLkWt4v2wmfRwB3irphVbUj KL7sAdV4tpYO2GnKPYtJYmwEM8ti6PnELwJt8w4jPITPPCdlyfeoUmCgHJ8OUi2yiDAdolkY P+mnT6EVypyNEie5GPeqx0h+bEq3Dsi4mjYWIr2yR+quZLHOiLKGedabALRM71jhE9hnOkz2 4sBXydt40gBONASngGLmWLuBQlQdCNiVcyeRzJ/L7LSeWKK513N+9eIke9+JOSJboxel/zD+ TmmS1RExV/k7UAr2i3UAk2PnIjHBM4lxVpiZHREFQ/xhxALPNb+hI9CJsBfVeR2q4RLk6UuJ 9FbIJroPxi6Ymmdk9jrRcOj/NUKmdXCrV/mAhdJlxBkJs8+HVOVooG4FuYtnQFXZheKWQIFi +XI/mvmrVArHmyO0O6+hCqT8m6M IronPort-HdrOrdr: A9a23:pMll0a38z6oqfV4Sn2oueAqjBQ9yeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5AEtQ5OxoS5PwPU80lKQFrLX5WI3CYOCIghrQEGgP1/qB/9SkIVyFygc/79 YtT0EdMqyJMbESt6+Ti2PUc6dC/DDEytHSuQ609QYIcegeUdAH0+4PMHf9LqQZfngiObMJUL 6nouZXrTupfnoaKu6hAGMeYuTFr9rX0Lr7fB8vHXccmUazpALtzIS/PwmT3x8YXT8K66wl63 L5nwvw4bjmm+2nyyXby3TY4/1t6ZXcI5p4dY2xY/ouW3bRYzWTFcZcsnq5zXUISdSUmRYXeR /30lMd1opImjTslyqO0GTQMkHboUgTAjnZuBmlab+Jm72geNr8YPAx3L6xOyGpmnYIrZVy1r lG0HmesIcSBRTcnD7l79yNTB1ykFGoyEBS2dL7okYvJ7f2UoUh5LD3PXklZasoDWb/8sQqAe NuBMbT6LJfdk6bdWnQui1qzMa3Vno+Ex+aSgxa0/blmQR+jTR81Q8V1cYflnAP+NY0TIRF/f 3NNuBtmKtVRsEbYKphDKMKQNexCGbKXRXQWVjiamjPBeUCITbAupT36LI66KWjf4EJ1oI7nN DbXFZRpQcJCjXT4A21rel2Gzz2MRaAtG7Wu7FjDrBCy8/BeIY= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,201,1643673600"; d="scan'208,217";a="827135312" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2022 10:13:19 +0000 Received: from mail.cisco.com (xfe-rcd-005.cisco.com [173.37.227.253]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 22MADJUU027218 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 22 Mar 2022 10:13:19 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 22 Mar 2022 05:13:18 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 22 Mar 2022 06:13:18 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ij1OXZ44/p7plwYCqnEssgFNeD0oZTWLoRwh3mmRE2nLSfliMvsonCD7lcep27ZYrk2fuwsCizeZsVHqXWP/Dgts6IyxVezwgz9FW3w7XORUYvrGXC7QV0/sdszTPUlFR6LPHXkOZ/UvqqAX98FIk8Bf9JIXO+HKbbss7VaB+LQUeymDX+l4QKqH/f3ByGbALUFWZpQdSTG8RF2IbR5t6hmX058ZIfufTczW4DpZXDZ923DWjFUJvGULMfQHfrPmcRxIzG640D0PRXVpV9rEho7C8f6awd2Zj1Ci4BC3IWAB4LT2JUgFTL5u42QXiFkFhyYQ5bkTN2HKnci+U7zJcA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OoTj9lTxpLYyMhLNvh+reHc/lJmvMt4vPENElIa/yNw=; b=V51ZeHuC9EjukR8p4/xpzDHC3Wtv+agfic/y8OnFJXXyL/Cy4/qrfn31DZVNDcBfsgADJPh5PSQ1y7E7Ls23hHipFl48nBlgfT1ceecfy2Fymf/Qa21hzhECvhTAfWY9GeboBCOqXUvQHHXTAa2Bb7hI3p3O0BMv8wkbp90Z7c1wV708CKGat3VFN/iBLrYrZy8IJI+6BwU8OBXCGN7q322rrskOave762G0Bk9Ov8uMjaGVv0oGyEQUtOOq9LSqHae0QElmZVSqfgf5DRqkK1NyT5sbpvWCjWIzglWwV0UaD2RwGOYaMgD7H2v/Tf0mdpAmLPheUBjVHt+tUkrFmw== 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=OoTj9lTxpLYyMhLNvh+reHc/lJmvMt4vPENElIa/yNw=; b=OqsI8n+3010z8b0b72Ig3MDUDEk//U9f75v2WRmvmex5WDzZxp+k1d/Ts3ekHp2tBLYv/71+yxBre98jxI27HcboMfmwQciF35jbyTsQ6H0y/7hsWZIOJD48GCGkjqI4pu6l0fM1yIpUvOkAxM3xvSNffhTD0tDZuSQhkjwb6oI= Received: from PH0PR11MB5829.namprd11.prod.outlook.com (2603:10b6:510:140::8) by BYAPR11MB2695.namprd11.prod.outlook.com (2603:10b6:a02:c0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14; Tue, 22 Mar 2022 10:13:16 +0000 Received: from PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c]) by PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c%9]) with mapi id 15.20.5102.016; Tue, 22 Mar 2022 10:13:16 +0000 From: "Ahmed Abdelsalam (ahabdels)" To: Tal Mizrahi , "Ahmed Abdelsalam (ahabdels)" , "spring@ietf.org" , "ippm@ietf.org" , "draft-filsfils-spring-path-tracing@ietf.org" Thread-Topic: [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt Thread-Index: AQHYL99cD4laBHfqlECFrXblL/g+Fay3HxwEgAkvn4CACvxoxQ== Date: Tue, 22 Mar 2022 10:13:16 +0000 Message-ID: References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e78e2b11-26d5-4b6b-8cea-08da0bec9504 x-ms-traffictypediagnostic: BYAPR11MB2695:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wmK5JdSuVaTp56Q2FlH4tiZGdQwPbU7yWWSbscWnjOUxkYX086vd7nV578v1C8ekamlQMvL9fBmkX6dPIrn0OCdO6nQXpTx8UIxUF6JOpcPgrVI3K6iLdoc1o8qEgusUHofHu67H9gjpjIZ/WOCzSGaMARgAQ//1b/xF2YVM1i2hweQuwOp2DZHAnNpShXhJR7UlTj92RgIUQHHPo8/eXGZcNE0xQXOXIMAbiWoYtA2yWaJAX8Nt0SaKelzJ+7K7UnPHk2CnfQnD7vcq5KIOacek5Px/F3wUocoOWK7TS2Grmmg6Qp+uzhtzg658HreNbvJmCGAMB3BzC3FFxjm3a/zIYBDJ/G+Wa7+wP60G5P84vU80f6K5l5S//IzLSDyZEFLnYQT/v0xoDgOXnbq3e1FKLk0yT5F5CMBPuwKSKGLFE42x8bTk/Y04SDn/iyXQH70TVz7TwP+HafLZnaEYn1P1O+AeZxwOKRTIbf2TKWUIMk1sXAU+j0qiymbfJO9XOkLS5NGO0LQVfUG6+Fb1Kwsd2OlzM0U1CBxqrjxPgVLYZ46ZLyw61geSmdl7vq4wo83QcnwmTkeiLcKN7lw5CxFe7ZxqPdk4KZdz5Gqv8BI4yOAKl55omPOKK+FcYHvcUKn5XuSUdNJlad+Dh+rqmMn+Mask3dKWozulsDpoZnea1kF/r/m6J54wvZA5PRPUKo1He45unHpz3Wntz26X+HX4XOPdE6MkIPGuJejLyamAZQqy/++0kNRckk7zGWP3M+U/eRp7ED7cYPz5aEopY4KnnKX1uSAWhOnCQB7BCF7uABabpQqGTwX0b4qylt4339Oxja6qjEA/flVPIcANiQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5829.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(33656002)(508600001)(86362001)(55016003)(2906002)(15650500001)(52536014)(76116006)(38070700005)(66476007)(8676002)(64756008)(66946007)(66556008)(91956017)(66446008)(316002)(110136005)(71200400001)(966005)(6506007)(7696005)(8936002)(53546011)(9686003)(38100700002)(26005)(122000001)(186003)(66574015)(83380400001)(5660300002)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?oK29m2GmiilWEFrtT5MKlp1+W4MKlzoF1JGFG2V7xUeE64LN4DcTlsd3?= =?Windows-1252?Q?2ksO64IGPkhnZB+9HsW7n1e3L1RNtpgiC42WDy/h3tbiFbHg/XxKCYnZ?= =?Windows-1252?Q?HJhqXjmyPeEorV4+DuUZEIzgSyRpX6yzF2dbqnsi5Exscwa8P6yvvDeF?= =?Windows-1252?Q?lnpNLrlCTWPMRkcTd2JlDIgvuON0cZ3jCSQaZyvlMPdNVtx5QEz2tP1S?= =?Windows-1252?Q?rwzAszlxQG8amnJKWfY3Dwm54Dv0MXc4oIGRtS5rIpJnNhhi06MqlKlo?= =?Windows-1252?Q?pOejeHMvFTvTae6ikFKkAGV2JT45XuQrPSBSOjQn0mgQXeOtXbWw5NBI?= =?Windows-1252?Q?sDjsoAbLUHJHAC1lQttQ9XjRDSW7v4F/fEsingEhudtKVi8kCcdfxbz+?= =?Windows-1252?Q?KyBfmoFUtdvVSTLJX89+SRR0wm7xRXh7njoj/7pG1u4yLnGqpr6ROnNf?= =?Windows-1252?Q?bXjtYKS4a14XeCYOsgPufbaSriCZk//BNqzTWD3w67jf1cABKjXJGIZF?= =?Windows-1252?Q?h0EZezp551YWxwWdJRKqOd/AqL+2Es1cCryhmTpNFrhBpLqcQysld3Yp?= =?Windows-1252?Q?bJpxjJcKenps9JIuHfFrOOqBvKj/8kuQsHMYk7HxvSjq3R9sOVjU5rU4?= =?Windows-1252?Q?ZxTlw3Fg5SPCgWZlJppan0bVJGzH+fUYkQS5wSbyahogGpnQHP5f3pQZ?= =?Windows-1252?Q?UQKXH11RjjqDLlgbQFrecaqidbVeGGIJ1DPWGpEcVrmUNr4rVxDkhiTH?= =?Windows-1252?Q?V+3aaIG09yCMHfJRf+dlYKLUbpxpYN3fvxdTBgcckTC1a20+X8+cVzjz?= =?Windows-1252?Q?9rUZtBODVsAkb+u/qbT4bUvW5t3XVDxLyk+AumdkbmFVph6ctbdhYCMG?= =?Windows-1252?Q?0arElCr4a/AZVzYmD0sC3uLSxiGHo8XpwiH9fU4m0BQ+5j16B2BGCirP?= =?Windows-1252?Q?1Ffo/Z5MObPW4qeRmDqlxEBd/hsPvAaQ3cW7IlpRgexctP9OdyH0T1eX?= =?Windows-1252?Q?nKvgXkXah2DEpE6ie3g+3XGWvzuWpLSxu+vFgZYzeNmLpfduibskKRtA?= =?Windows-1252?Q?lXzDN7WXlXoPimSo/O5XngDePlYK06fg4HxfPo6W79rIS0W7RG41oRBJ?= =?Windows-1252?Q?dFXuJ0nsDUwxkX81cOoWGWuT+OCdpXXizN0dbyTgguMs4IP01N2tn79f?= =?Windows-1252?Q?x7BSIqYan9cd4y24272YbmGSe43tS2BTXw2XfiqMUZ1Ux9wgXiAUt+WY?= =?Windows-1252?Q?A5NNWHsCewI0/ydAWMLM30msi/UWEifYaDsaT+le2q9S20wI9y89huGc?= =?Windows-1252?Q?S9EHkQ3NopfppdHAlWewKNrdYXVYMi4xSRzXbcybVANfuFLFK7rEfgGZ?= =?Windows-1252?Q?U1cM449cvkpaMLzkN0d2dvQXptcIyNuSUn3v0QSJ62pdF0fslXkDcAVh?= =?Windows-1252?Q?qdQrUgWyDPxVSD398P16tc+tT+i4eGwvWylM8geX7QOzuPSbNdKPw8BM?= =?Windows-1252?Q?s/LKXto4qVqBnoZhANzQ830TWDb0hPHXPgZsoUNVSJPzkxsJT83MD/nf?= =?Windows-1252?Q?8lHoKSlJAwoiqAgwBG7Yvi+LpLjz/77HuW/MXQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB582910BE4EA132F1876BCAE2D4179PH0PR11MB5829namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5829.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e78e2b11-26d5-4b6b-8cea-08da0bec9504 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 10:13:16.4940 (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: ffdYiOXjzpHEWt4k23g0STXBcR8Zy5eL3KkqwtsdY2MMGgWxI1DDr/O77PUQ38Yy3p8uK3ZT8zPe4xt8go1tOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2695 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.227.253, xfe-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [spring] [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-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 Mar 2022 10:14:00 -0000 X-List-Received-Date: Tue, 22 Mar 2022 10:14:00 -0000 --_000_PH0PR11MB582910BE4EA132F1876BCAE2D4179PH0PR11MB5829namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tal. Thanks for the review and comments. Please find Inline [AA] From: Tal Mizrahi Date: Tuesday, 15 March 2022 at 11:28 To: Ahmed Abdelsalam (ahabdels) , sp= ring@ietf.org , ippm@ietf.org , draft-filsf= ils-spring-path-tracing@ietf.org Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-spring-= path-tracing-00.txt Dear authors, Thanks for sharing this interesting draft. Per-hop measurement and reporting is a very important OAM tool, and there is quite a bit of ongoing / previously proposed work in the IETF about this topic. A few comments: 1. It looks like the draft defines two aspects: (a) the path tracing IPv6 option, which is not specific to segment routing, but is actually applicable to IPv6 routers in general, and (b) an SRH TLV. It seems like the SRH TLV could alternatively be defined as a generic IPv6 destination option. Is there anything that functionally limits this feature to networks that use segment routing? [AA] Path Tracing has been designed to work on segment routing networks. As= such, it leverages a few SRv6 constructs: the binding SID (End.B6.TEF) at = the sink node, some assumptions from SR networks that are particularly usef= ul for security (i.e. the SR Domain) and others. 2. As Greg pointed out in a previous email, the functionality here seems very similar to IOAM. The PT option could actually be implemented by using an IOAM trace option: by defining a couple of new data fields you could get an equally compact number of bits as the PT option in the current draft. The SRH TLV could alternatively be defined as an IOAM Edge-to-edge option (again, maybe with a couple of new data fields). Is there a reason why this is a new protocol, rather than just defining new data field types in IOAM? [AA] We believe that PT and iOAM are tackling the problem from different an= gles. We don=92t believe that IOAM with trace option could address our case= (particularly, we have ensured that PT can be implemented at linerate acro= ss most silicon). 3. Time synchronization is defined as a 'MUST' in the draft, but it seems like you can benefit from path tracing even in cases where synchronization is not possible. Have you considered such use cases? [AA] I agree with you. For example, simply collecting the interface IDs is = already valuable. However, it seems all the operators that would be interes= ted in PT do have time synchronization in their network. Hence there seems = to be no value on that. Any feedback is welcomed. 4. Regarding 'MCD.TTS (Truncated Timestamp)': rather than defining some of the bits to represent milliseconds and other bits to represent microseconds, it may be more hardware-friendly to define a subset of the bits of timestamp formats that are commonly implemented in hardware, such as the PTP timestamp format or the NTP timestamp format. [AA] We will clarify the text in the draft. What you are proposing is exact= ly how it works today. The TTS template defines the position of 8-bits to b= e selected from the node timestamp. The HW will just copy these bits into t= he HbH. Still, part of the selected bits can represent milliseconds and par= t can representing microseconds. For example, if the operator configures a = template that selects bits 16 to 23, this means that 4 most significant bit= s are coming from the part carrying the milliseconds and the 4 least signif= icant bits will be carrying fraction of millisecond (i.e., unit of microsec= onds) Thanks! Cheers, Tal. On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels) wrote: > > Dear SPRING WG, IPPM WG, > > > > We have submitted a new I-D for Path Tracing in SRv6 networks (https://da= tatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING W= G. > > > > We are looking for your feedback and comments. > > > > Path Tracing provides a record of the packet path as a sequence of interf= ace ids. In addition, it provides a record of end-to-end delay, per-hop del= ay, and load on each egress interface along the packet delivery path to fac= ilitate operation of SR networks. > > > > Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop= extension header. > > > > We will present Path Tracing to the SPRING WG at next IETF (https://datat= racker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) > > > > Thanks, > > Ahmed > > > > From: internet-drafts@ietf.org > Date: Friday, 4 March 2022 at 16:48 > To: Ahmed Abdelsalam (ahabdels) , cf(mailer list) , Mark Yufit , Pablo Camarillo (pcamari= l) , Pablo Camarillo (pcamaril) , S= atoru Matsushima , Thomas.Graf , Yuanchao Su > Subject: New Version Notification for draft-filsfils-spring-path-tracing-= 00.txt > > > A new version of I-D, draft-filsfils-spring-path-tracing-00.txt > has been successfully submitted by Pablo Camarillo Garvia and posted to t= he > IETF repository. > > Name: draft-filsfils-spring-path-tracing > Revision: 00 > Title: Path Tracing in SRv6 networks > Document date: 2022-03-04 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/archive/id/draft-filsfils-spring-pat= h-tracing-00.txt > Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-pa= th-tracing/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-filsfils-spri= ng-path-tracing > > > Abstract: > Path Tracing provides a record of the packet path as a sequence of > interface ids. In addition, it provides a record of end-to-end > delay, per-hop delay, and load on each egress interface along the > packet delivery path. > > Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- > by-Hop extension header. > > Path Tracing supports fine grained timestamp. It has been designed > for linerate hardware implementation in the base pipeline. > > > > > The IETF Secretariat > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --_000_PH0PR11MB582910BE4EA132F1876BCAE2D4179PH0PR11MB5829namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Tal.

 

Thanks for the review and comments. Please find Inline = ;[AA]

 

From: Tal Mizrahi <tal= .mizrahi.phd@gmail.com>
Date: Tuesday, 15 March 2022 at 11:28
To: Ahmed Abdelsalam (ahabdels) <ahabdels=3D40cisco.com@dmarc.iet= f.org>, spring@ietf.org <spring@ietf.org>, ippm@ietf.org <ippm@= ietf.org>, draft-filsfils-spring-path-tracing@ietf.org <draft-filsfil= s-spring-path-tracing@ietf.org>
Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-= spring-path-tracing-00.txt

Dear authors,

Thanks for sharing this interesting draft.
Per-hop measurement and reporting is a very important OAM tool, and
there is quite a bit of ongoing / previously proposed work in the IETF
about this topic.

A few comments:
1. It looks like the draft defines two aspects:  (a) the path tracing<= br> IPv6 option, which is not specific to segment routing, but is actually
applicable to IPv6 routers in general, and (b) an SRH TLV. It seems
like the SRH TLV could alternatively be defined as a generic IPv6
destination option. Is there anything that functionally limits this
feature to networks that use segment routing?

 

[AA] Path Tra= cing has been designed to work on segment routing networks. As such, it lev= erages a few SRv6 constructs: the binding SID (End.B6.TEF) at the sink node= , some assumptions from SR networks that are particularly useful for security (i.e. the SR Domain) and others.=


2. As Greg pointed out in a previous email, the functionality here
seems very similar to IOAM. The PT option could actually be
implemented by using an IOAM trace option: by defining a couple of new
data fields you could get an equally compact number of bits as the PT
option in the current draft.  The SRH TLV could alternatively be
defined as an IOAM Edge-to-edge option (again, maybe with a couple of
new data fields). Is there a reason why this is a new protocol, rather
than just defining new data field types in IOAM?

 

[AA] We belie= ve that PT and iOAM are tackling the problem from different angles. We don= =92t believe that IOAM with trace option could address our case (particular= ly, we have ensured that PT can be implemented at linerate across most si= licon).


3. Time synchronization is defined as a 'MUST' in the draft, but it
seems like you can benefit from path tracing even in cases where
synchronization is not possible. Have you considered such use cases?

 

[AA] I agree = with you. For example, simply collecting the interface IDs is already valua= ble. However, it seems all the operators that would be interested in PT do = have time synchronization in their network. Hence there seems to be no value on that. Any feedback is welcomed.

 


4. Regarding 'MCD.TTS (Truncated Timestamp)': rather than defining
some of the bits to represent milliseconds and other bits to represent
microseconds, it may be more hardware-friendly to define a subset of
the bits of timestamp formats that are commonly implemented in
hardware, such as the PTP timestamp format or the NTP timestamp
format.

[AA] We will = clarify the text in the draft. What you are proposing is exactly how it wor= ks today. The TTS template defines the position of 8-bits to be selected fr= om the node timestamp. The HW will just copy these bits into the HbH. Still, part of the selected bits can represe= nt milliseconds and part can representing microseconds. For example, if the= operator configures a template that selects bits 16 to 23, this means that= 4 most significant bits are coming from the part carrying the milliseconds and the 4 least significant bits w= ill be carrying fraction of millisecond (i.e., unit of microseconds)

 

Thanks!


Cheers,
Tal.

On Wed, Mar 9, 2022 at 4:14 PM Ahmed Abdelsalam (ahabdels)
<ahabdels=3D40cisco.com@dmarc.ietf.org> wrote:
>
> Dear SPRING WG,  IPPM WG,
>
>
>
> We have submitted a new I-D for Path Tracing in SRv6 networks (https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing= ) to SPRING WG.
>
>
>
> We are looking for your feedback and comments.
>
>
>
> Path Tracing provides a record of the packet path as a sequence of int= erface ids. In addition, it provides a record of end-to-end delay, per-hop = delay, and load on each egress interface along the packet delivery path to = facilitate operation of SR networks.
>
>
>
> Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-= Hop extension header.
>
>
>
> We will present Path Tracing to the SPRING WG at next IETF (https://datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.= txt)
>
>
>
> Thanks,
>
> Ahmed
>
>
>
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Date: Friday, 4 March 2022 at 16:48
> To: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, cf(mailer = list) <cf@cisco.com>, Mark Yufit <mark.yufit@broadcom.com>, Pab= lo Camarillo (pcamaril) <pcamaril@cisco.com>, Pablo Camarillo (pcamar= il) <pcamaril@cisco.com>, Satoru Matsushima <satoru.matsushima@g.s= oftbank.co.jp>, Thomas.Graf <Thomas.Graf@swisscom.com>, Yuanchao Su <yitai.syc@al= ibaba-inc.com>
> Subject: New Version Notification for draft-filsfils-spring-path-traci= ng-00.txt
>
>
> A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
> has been successfully submitted by Pablo Camarillo Garvia and posted t= o the
> IETF repository.
>
> Name:           draf= t-filsfils-spring-path-tracing
> Revision:       00
> Title:          Path Trac= ing in SRv6 networks
> Document date:  2022-03-04
> Group:          Individua= l Submission
> Pages:          15
> URL:           = https://www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing/ > Htmlized:       https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing
>
>
> Abstract:
>    Path Tracing provides a record of the packet path as= a sequence of
>    interface ids.  In addition, it provides a reco= rd of end-to-end
>    delay, per-hop delay, and load on each egress interf= ace along the
>    packet delivery path.
>
>    Path Tracing allows to trace 14 hops with only a 40-= bytes IPv6 Hop-
>    by-Hop extension header.
>
>    Path Tracing supports fine grained timestamp.  = It has been designed
>    for linerate hardware implementation in the base pip= eline.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.iet= f.org/mailman/listinfo/ippm

--_000_PH0PR11MB582910BE4EA132F1876BCAE2D4179PH0PR11MB5829namp_-- From nobody Tue Mar 22 03:14:50 2022 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 B32163A0E05; Tue, 22 Mar 2022 03:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ggD2KPHA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BG+bpls4 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 21vijVLIqQyR; Tue, 22 Mar 2022 03:13:46 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CC33A118D; Tue, 22 Mar 2022 03:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19853; q=dns/txt; s=iport; t=1647944001; x=1649153601; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=u35X3V/w39Wx2lTy2Asn/W3W7D0cFs6eFdKTADVhOak=; b=ggD2KPHAxPGbM7Xkp6khnBJldOlJyrMDpk9heML/HR73ZIASOOXMJj6E yjhPhK8mGHzkYTpksSBaqy6/kujvJr6EWyRWJlD7qR4e26AHH3e0ZUR5e PeIP/PAB4qrEe8aCkqYyHIcB3ScLbia6r/IXn7lCsnSF4exwrcngFgpTe o=; X-IPAS-Result: =?us-ascii?q?A0BIBgCgoDli/4QNJK1aHgEBCxIMQIFPC4EhMVYHd1o3R?= =?us-ascii?q?IgeA4U5hRCDAgOQQYp0gS4UgREDVAsBAQENAQE3CgQBAYUHAoQ9AiU0CQ4BA?= =?us-ascii?q?gQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwSBCROFaA2GQgEBAQEDEi4BATUDD?= =?us-ascii?q?wIBCBEDAQEBLzIdCAIEARIIGoJjgg5XAy4BDp9uAYE6AoEOiRF4gTOBAYIIA?= =?us-ascii?q?QEGBASBNwEDBAxBgn8YgjcDBoE8gxGEJIcUJxyBSUSBFUOCZz6CYwEBAgGBI?= =?us-ascii?q?zweDYMkgi6XSoEwBFECBBBGDGcNEicZS5FjjV5AjT6SbQqDSYsPlQIVg3SMM?= =?us-ascii?q?IZckUGWWyCCKYpMlCEcDxYBhGECBAIEBQIOAQEGgWE8gVlwFRohgmlRGQ+OI?= =?us-ascii?q?AkDFoNQhRSFSnUCNgIGCwEBAwmQUgEB?= IronPort-PHdr: A9a23:8XHR+hV5G82auxsAt3u2OOn5jsLV8K36AWYlg6HPw5pCcaWmqpLlO kGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW0oDjsMbzAAlCdSOXEv8KvOiZicmH cNEAVli+XzzMUVcFMvkIVPIpXjn5j8JERK5Pg1wdYzI IronPort-Data: A9a23:yBlff6CiSg0rnBVW/1/iw5YqxClBgxIJ4kV8jS/XYbTApD13gTECn DNLWG2Pa6nea2fwKtEnadi0pB8HvZCGnNNnOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOukYAL4EnopH1U8E3170UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqgAFuz6cAOcIlSQQJjBnT3PVT0 PFqjMnlIespFvWkdOU1Wh1cFWR1OrdLveafZ3O+qseUiUbBdhMAwd03UxpwZtNeo70xWDoUn RAbAGhlghSrjuK/yr62TvJEjcU4J86tN4Qa0p1l5WGFXax7G8iZHM0m4/dexDYel+JjR8/5R O0XaBRrSRqeTTpmbwJ/5JUW2b3AamPEWzxAsFe9pKcr7S7U1gMZ+KP1KtvTdZmBRcxUhF2wp 2/a8SL+GB5yHMeH0zuD/Vqti/PB2yThV+o6Hb2x/PJnhEbGmjQYCQYdUh2wpvyRhku3QdkZK kEI9Gwpt6da3EWtQsPwQFi5rWKK60JEX9tJDuw2rh2Awar87wOQHGNCTzNdZpohrsBeeNAx/ laNm9WsDjt1vfjMETSW96yfqnW5Pi19wXI+WBLohDAtu7HLyLzfRDqWJjq/OMZZVuHIJAw= IronPort-HdrOrdr: A9a23:V4knVqjrlN6n36Tml5Ulca3brnBQX2d13DAbv31ZSRFFG/FwyP rBoB1L73DJYWgqNE3IwerwRZVoMkmsiaKdgLNhcItKOTOGhILGFvAa0WKP+UyDJ8S6zJ8m6U 4CSdkzNDSTNykDsS+S2mDReLxMoKjlzEnrv5ak854Hd3APV0gU1XYeNu/tKDwQeOApP+tdKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HyVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5V+7Y23+4kowwfX+0WVjbdaKv+/VfcO0aSSAWMR4Z nxStEbToBOAj3qDyaISFDWqnbdOX4VmgHfIBmj8D3eSQiTfkNjNyKH7rgpKycxonBQze1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjx0C3fLFuHoO5l7ZvtX+90a1waR7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm1kxR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XX50vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeLqzNV1wg2TwqUmGLEfQI5tlluhEU5XHNcjWDRE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,201,1643673600"; d="scan'208,217";a="848252027" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2022 10:13:19 +0000 Received: from mail.cisco.com (xfe-aln-001.cisco.com [173.37.135.121]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 22MADJ4f002818 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 22 Mar 2022 10:13:19 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 22 Mar 2022 05:13:19 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 22 Mar 2022 06:13:19 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AZj4wx5Z4obeKtta9pU7yAjK04JkHCBw3foHOUn5V4qwOxTeaoGktwMhxj5aKWa37mYdhxOSunIcqi5EzKQCnCkxf8/QUUW5hpB+UDto/cqd3lXb1HzUspgAfQYmiU/atVmPs8gsWvAtjE2nBcj2JQ0yaZEHfRUEeOGoB8XlimbO6GfoUo2PVLZ3jLIpIfascoqb6fYgT4aqV44id+7zqDI/EGH3Ur9thaU4B3JFyb7QBxj6N7NS3+8V/YxKuJOPIGjUR4ZhLC8gcsa14AU8ICg4K2nOeZOqNXd4JEmWf2wlqqyPvssZRZ+URpxe4Bvbi+u6r7+RYEEDJdmI8Gaa/g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8Vn7CBLA2sOBIVt6JOC54JHZom2nF+szsxa40ViqF9g=; b=TwklKFTXsjU6hg5WkYDCcdg6I98sXueffD1oKY35MXKZZBY1wXL/TZbC/dCOq0E6HmP99Tu+mz19BaJJfNNLmYOAJmuTedYFxbkf5QfFx5vattxAFtc6hEnr5BKVFoRcHRCn1DTuX8X5O6rNw5ZrOtQd+xSvxXLq5xo2rL+/fDdWp+eti28kfgKpHyvQZ5U6cS9PE2J4jN5LrqgMkPj8/8uqhfkfoPIMH4vs+DiB4jD8v38dQtEW15f2MguHb0ure5xC0hpRrp9Ex/yoIsuvJnwYXsXhjrKjfJTpqg1pRAvtrVnMYM0bPbOqjdENWqxKjBJq7l1RfxDp13IeYYWSfQ== 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=8Vn7CBLA2sOBIVt6JOC54JHZom2nF+szsxa40ViqF9g=; b=BG+bpls4dbVfq3m65Rfgr8hPX9fTucUTGSzVqXZZix/NRpuuEP9t/OFN/WPjPfGURY3umt8DNBzQdvw6tFtwnp3kTb9BSB+3YqeUao0vsm7lKRL6rbPSlYs7nay1WbIi7Wt46YSDebIi4/TgBb6ubxVXTzeDad1wZb4NIX+md6E= Received: from PH0PR11MB5829.namprd11.prod.outlook.com (2603:10b6:510:140::8) by BYAPR11MB2695.namprd11.prod.outlook.com (2603:10b6:a02:c0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14; Tue, 22 Mar 2022 10:13:17 +0000 Received: from PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c]) by PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c%9]) with mapi id 15.20.5102.016; Tue, 22 Mar 2022 10:13:17 +0000 From: "Ahmed Abdelsalam (ahabdels)" To: Andrew Alston - IETF , "Ahmed Abdelsalam (ahabdels)" , "spring@ietf.org" , "spring-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-path-tracing-00.txt Thread-Index: AQHYL99cD4laBHfqlECFrXblL/g+Fay3HxwEgAfp/xCADEIFJg== Date: Tue, 22 Mar 2022 10:13:17 +0000 Message-ID: References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 788036d2-3df3-4970-09f5-08da0bec95bb x-ms-traffictypediagnostic: BYAPR11MB2695:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C9nT+wxTZf7QfiQXUlpBUiYhwyOYNo7s18fCzv8s4OEBaC6z234AnSe/DTDeggaTspuQSPb8YkiGx67yT0Weta78Mohjo9FCq6P1AeKAuHM7LMUGhQF4PYKxONwT9GRJT2dsxNGsNL+w9+WrVAWOta9vad3Jb+4I1GLXZBYQzijI+IiFx6xfHdAP6QWLxe6j6rjDd239nrT8asr+B0XPi/aigF6v3n2neYaUjhWSrU0liiojI+zxP2B0va3Kh1nJmEBCFLrVzsNjk3DWwXmR9GQd1a8rkbeSqmnhmPr5SvkpqUwPC1RXjLHYdO/pG7WtBeST+3U7mvqALxW6Tl/7hP+dp8MfYWzTdn8Z4MNA640ljE43zGG/hfhvk1260Oc2QWkzEtFCTe31BpsZMQB1LADXwBTX5ypRfa8Rnhw8JkF4nV0ezJhr2JKAN2czs5qCJ9gmK82Mtg2jxIzHRmIQDKj71+LK+uG3LoJxL0DgtCgl1SL5PDL+Up9ed2e/DHQFR7KcFX28YHh0ZePzyj0zTtCaT/D041kvRGBICc0T+ELTZPJJ5eJovJ2bty6TF53a0hcySstjPf63L0YPIDqkM2NGdkV6Fcz9JffxXYjyjgJrxoP6nmL+XxdIyvOiMV6kFTUS0sSZDkUuUQ3VNArayBPzodpNfiH3vwLvpJY8zopAmo4Zpknrvdpmhn0N9+G2sZ+D2OYKJO+8Z2UngxvXb9bupmLGVP8yOvsApgajZKHlTSTK6yTYfShb8Ypc0Yiff15eWSsn/K2m2ZU1M4iv1MNax0OXgXFTQ6Mzw1WwllIph58u6kQWlyVAi907/5czZfrFM8fUqqo+pHKRvG2hPg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5829.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(33656002)(508600001)(86362001)(55016003)(2906002)(15650500001)(52536014)(76116006)(38070700005)(66476007)(8676002)(64756008)(66946007)(66556008)(91956017)(66446008)(316002)(110136005)(71200400001)(966005)(6506007)(7696005)(8936002)(53546011)(9686003)(38100700002)(26005)(122000001)(186003)(66574015)(83380400001)(5660300002)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ezwtbO2AfZJOhucebCAFKinZQR/g5qO7Nnv4gqVjNIcQu2SUCcFkZlPZ?= =?Windows-1252?Q?gPYFVAYbfckLtcAmuJDB2NDy2iC7E3vwKUUJEPTHq4C2kxChqQT9f3Bi?= =?Windows-1252?Q?7yoiLCuVpantgeO2OjVVbFNlIp9tVwCWe154EfoMJvTWshFHNG30e5t/?= =?Windows-1252?Q?R0si1+fo+mJwy7UM/b61aThXm0FL+xJb0on3/Q3Yv2B0jBW2AhNZ+7tO?= =?Windows-1252?Q?sQHgbRU4P58b9dJMcj/jlW/c9FFF942c/mqgDNDFptYwoEvxPyXuytQ2?= =?Windows-1252?Q?hzs36Dh/czEDXGo9h4xlRg6cjXbvgKyLyGSv7dQAPEdG8F1EX+VCkkEw?= =?Windows-1252?Q?ui+4NQJa0yYu4DENo2xck/EeIkfKm7tXBkroTWscO7TTl/Z+2gRHJt66?= =?Windows-1252?Q?7Lq8Z3Iuhx+KiFSzA93t01GUUBo3uaeSCyOP+5bbNLsy8d8ZAuRo/cUf?= =?Windows-1252?Q?9ijH9fQ9M8eeTVnviB7WY25fw4oubdTOcptlluztshB2Umr4qm+ogMf8?= =?Windows-1252?Q?3WlPxVYJYF3FUCFXvl3akH6Ii7Myz5Rzy9OiPUoTmwiS4ZxtyHqT1XUV?= =?Windows-1252?Q?hpdl4OzOy23cfKXq8MXt2E/j9P/Kgbfg6sESx/aPv21kSTpyHO7jmLDw?= =?Windows-1252?Q?bceux2P0amjZr8K/fht0yVNTM3HTqCteCiMBE8U5yYTLNNUxW0ZGoS1n?= =?Windows-1252?Q?PEI7S1AygKpgRV0PVqI5X6/L5h72mkGYlOA0LUDmbdvmYeRPkztfkrHw?= =?Windows-1252?Q?jHuPF3COMUeVDAJTQ+Fu7b+RSB5Lx+HvEBklA7wt+JNDJmLEcKlrDOMJ?= =?Windows-1252?Q?coIxdqmBoBBMwMYp1VLxW25aJ9izmoTk0Nz6/ZBeLbNJJZfhXb0s4eUq?= =?Windows-1252?Q?WH40Eblbijs809xGDgS8wVysvzU4MVCXkQ34lb3ExEd9bpy/w4TtYQSi?= =?Windows-1252?Q?DSblx4i5lNg2z00uoU/Yr5lnzOKyp5djGAv4t1lFuaap2Ya35+Qci/y7?= =?Windows-1252?Q?Q1Q/hB6UbpzH67iTaL1pEN2pFwTN/5bTDmwMsQppzszg5di9Uc1R2L5W?= =?Windows-1252?Q?n5bBD6xFBu51gVvnZLhPPPpaEdw3ppzdHCKVSZxmd02Ckh4yMes5wSCl?= =?Windows-1252?Q?njxAB+TMr9yXoaIuG+vJGWfHOMf2cNUc3GtYJXuAO8mh2OVRw3TZgt02?= =?Windows-1252?Q?Zie90hf0Q7tErEwjR5EJBVeR/owu4P7R/4Sb6GEP5kjxf1rPlPWER7Fs?= =?Windows-1252?Q?F9jj3FaV0HrN4eKiojnFej4tn+2+P0N/+HorM123zDcokdZ9xtU3yrKY?= =?Windows-1252?Q?1IIikwtLnXtwCmJq4nQKNiF7WFhO+CrGKA1/o9Qqlhed66eEnM1iJkJo?= =?Windows-1252?Q?0GKz786GdpmO2uwY7D75LhQNhLcvvRd+VamhlUS9RUEGYMk065BP1Oaw?= =?Windows-1252?Q?OAz6B43eG9xU6UP9C0JKzjyce2osIUvh6inB75Ev4ucTaBv/IDNW+Gpr?= =?Windows-1252?Q?V05uIu3YkqX6ipS4xHKbzfSQlkuzujPeHM3Pk7cJYukCE2pGWewJffmG?= =?Windows-1252?Q?RACdi/ocZk8VUZC/9HjFsOA/r7i7C5jFILFioA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB582929EE4CB05EAE77A2C0EFD4179PH0PR11MB5829namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5829.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 788036d2-3df3-4970-09f5-08da0bec95bb X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 10:13:17.7285 (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: R9EwNFCf2Q1emQSmz8IZT5UiBJCJjvU361DTmixF5n/xHMgXBAogT7S/644Up5LArM9nbji6XT2QukSVKa08WA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2695 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.135.121, xfe-aln-001.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [spring] New Version Notification for draft-filsfils-spring-path-tracing-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 Mar 2022 10:14:00 -0000 --_000_PH0PR11MB582929EE4CB05EAE77A2C0EFD4179PH0PR11MB5829namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andrew, Thanks for the review and comments. Please find Inline [AA] From: ippm on behalf of Andrew Alston - IETF Date: Monday, 14 March 2022 at 16:08 To: Ahmed Abdelsalam (ahabdels) , sp= ring@ietf.org , spring-chairs@ietf.org , ippm@ietf.org Subject: Re: [ippm] New Version Notification for draft-filsfils-spring-path= -tracing-00.txt Hi There, Speaking entirely as a working group participant, I have two substantial concerns with this document at first skim read. Firstly =96 the 12 bits for an interface ID =96 I have serious concerns tha= t this will be far from sufficient. Keep in mind you have interface specif= ic VLAN=92s (that alone can eat 12 bits), you have PWHE terminated interfac= es =96 and I know of several cases where those are used for termination of = logical circuits that would be doing this type of traffic, etc etc, and in = effect, you can very easily exceed the 4096 interface ID=92s on a single ro= uter. [AA] As mentioned in the draft. The interface ID is assigned by an operator= . It does not have to be either globally unique across the entire network, = or even unique withing the node as long as the end-to-end path can be deter= ministically inferred based on the chain of Interface IDs. Secondly, in the security considerations section of the document, last para= graph of section 11. It states =93The HBH-PT option MUST be processed at l= ine rate.=94 I think the wording here probably needs work. Could we not sa= y that =93A router that cannot process the HBH-PT option in fast path must = ignore said option=94 Because =93line rate=94 does not actually refer to pa= ckets that avoid punt to the CPU =96 all it means is that the CPU=92s are f= ast enough to not slow other things down while processing it. [AA] The intent is to avoid any slowdown in forwarding. draft-ietf-6man-hbh= -processing uses slow-path and fast-path language and may provide better la= nguage to describe the requirement for HBH-PT option. We=92ll update that = in the next version. Thanks! Thanks Andrew From: spring On Behalf Of Ahmed Abdelsalam (ahabd= els) Sent: Wednesday, March 9, 2022 5:13 PM To: spring@ietf.org; spring-chairs@ietf.org; ippm@ietf.org Subject: [spring] FW: New Version Notification for draft-filsfils-spring-pa= th-tracing-00.txt Dear SPRING WG, IPPM WG, We have submitted a new I-D for Path Tracing in SRv6 networks (https://data= tracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG. We are looking for your feedback and comments. Path Tracing provides a record of the packet path as a sequence of interfac= e ids. In addition, it provides a record of end-to-end delay, per-hop delay= , and load on each egress interface along the packet delivery path to facil= itate operation of SR networks. Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop e= xtension header. We will present Path Tracing to the SPRING WG at next IETF (https://datatra= cker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) Thanks, Ahmed From: internet-drafts@ietf.org Date: Friday, 4 March 2022 at 16:48 To: Ahmed Abdelsalam (ahabdels) , cf(mailer list) , Mark Yufit , Pablo Camarillo (pcamaril)= , Pablo Camarillo (pcamaril) , Sat= oru Matsushima , Thomas.Graf , Yuanchao Su Subject: New Version Notification for draft-filsfils-spring-path-tracing-00= .txt A new version of I-D, draft-filsfils-spring-path-tracing-00.txt has been successfully submitted by Pablo Camarillo Garvia and posted to the IETF repository. Name: draft-filsfils-spring-path-tracing Revision: 00 Title: Path Tracing in SRv6 networks Document date: 2022-03-04 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-filsfils-spring-path-= tracing-00.txt Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-path= -tracing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-filsfils-spring= -path-tracing Abstract: Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. The IETF Secretariat --_000_PH0PR11MB582929EE4CB05EAE77A2C0EFD4179PH0PR11MB5829namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

Thanks for the review and comments. Please find Inline = ;[AA]

 

From: ippm= <ippm-bounces@ietf.org> on behalf of Andrew Alston - IETF <andrew= -ietf=3D40liquid.tech@dmarc.ietf.org>
Date: Monday, 14 March 2022 at 16:08
To: Ahmed Abdelsalam (ahabdels) <ahabdels=3D40cisco.com@dmarc.iet= f.org>, spring@ietf.org <spring@ietf.org>, spring-chairs@ietf.org = <spring-chairs@ietf.org>, ippm@ietf.org <ippm@ietf.org>
Subject: Re: [ippm] New Version Notification for draft-filsfils-spri= ng-path-tracing-00.txt

Hi T= here,

&nbs= p;

Spea= king entirely as a working group participant,

&nbs= p;

I ha= ve two substantial concerns with this document at first skim read.

&nbs= p;

Firs= tly =96 the 12 bits for an interface ID =96 I have serious concerns that th= is will be far from sufficient.  Keep in mind you have interface speci= fic VLAN=92s (that alone can eat 12 bits), you have PWHE terminated interfaces =96 and I know of several cases where those are= used for termination of logical circuits that would be doing this type of = traffic, etc etc, and in effect, you can very easily exceed the 4096 interf= ace ID=92s on a single router.

&nbs= p;

[AA] As mentioned in the draft. The interface ID is assigned by an operat= or. It does not have to be either globally unique across the entire network= , or even unique withing the node as long as the end-to-end path can be deterministically inferred based on the chai= n of Interface IDs.

 

Seco= ndly, in the security considerations section of the document, last paragrap= h of section 11.  It states =93The HBH-PT option MUST be processed at = line rate.=94 I think the wording here probably needs work.  Could we not say that =93A router that cannot process th= e HBH-PT option in fast path must ignore said option=94 Because =93line rat= e=94 does not actually refer to packets that avoid punt to the CPU =96 all = it means is that the CPU=92s are fast enough to not slow other things down while processing it.

 

[AA] The intent is to avoid any slowdown in forwarding. draft-ietf-6man-h= bh-processing uses slow-path and fast-path language and may provide better = language to describe the requirement for HBH-PT option.  We=92ll update that in the next version.

 

Thanks!

&nbs= p;

Than= ks

Andr= ew

&nbs= p;

F= rom: spring <= spring-bounces@ietf.org> On Behalf Of Ahmed Abdelsalam (ahabdels)
Sent: Wednesday, March 9, 2022 5:13 PM
To: spring@ietf.org; spring-chairs@ietf.org; ippm@ietf.org
Subject: [spring] FW: New Version Notification for draft-filsfils-sp= ring-path-tracing-00.txt

 

Dear= SPRING WG,  IPPM WG,

&nbs= p;

We h= ave submitted a new I-D for Path Tracing in SRv6 networks (https:= //datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG.

&nbs= p;

We a= re looking for your feedback and comments.

&nbs= p;

Path= Tracing provides a record of the packet path as a sequence of interface id= s. In addition, it provides a record of end-to-end delay, per-hop delay, an= d load on each egress interface along the packet delivery path to facilitate operation of SR networks.

&nbs= p;

Path= Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop exten= sion header.

&nbs= p;

We w= ill present Path Tracing to the SPRING WG at next IETF (https:= //datatracker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt)

&nbs= p;

Than= ks,

Ahme= d

&nbs= p;

From: inte= rnet-drafts@ietf.org <internet-drafts@ietf.org>
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>, cf(maile= r list) <cf@cisco.com>, Mark Yufit <mark.yufit@broadcom.com>, P= ablo Camarillo (pcamaril) <pcamaril@cisco.com>, Pablo Camarillo (pcam= aril) <pcamaril@cisco.com>, Satoru Matsushima <satoru.matsushima@g= .softbank.co.jp>, Thomas.Graf <Thomas.Graf@swisscom.com>, Yuanchao Su <yitai.syc@al= ibaba-inc.com>
Subject: New Version Notification for draft-filsfils-spring-path-tra= cing-00.txt


A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the=
IETF repository.

Name:           draft-fil= sfils-spring-path-tracing
Revision:       00
Title:          Path Tracing i= n SRv6 networks
Document date:  2022-03-04
Group:          Individual Sub= mission
Pages:          15
URL:            https:/= /www.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt
Status:         https://datatracker.ietf.= org/doc/draft-filsfils-spring-path-tracing/
Htmlized:       <= a href=3D"https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-= tracing">https://datatracker.ietf.org/doc/= html/draft-filsfils-spring-path-tracing


Abstract:
   Path Tracing provides a record of the packet path as a sequenc= e of
   interface ids.  In addition, it provides a record of end-= to-end
   delay, per-hop delay, and load on each egress interface along = the
   packet delivery path.

   Path Tracing allows to trace 14 hops with only a 40-bytes IPv6= Hop-
   by-Hop extension header.

   Path Tracing supports fine grained timestamp.  It has bee= n designed
   for linerate hardware implementation in the base pipeline.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

--_000_PH0PR11MB582929EE4CB05EAE77A2C0EFD4179PH0PR11MB5829namp_-- From nobody Tue Mar 22 03:15:19 2022 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 2D2323A0FFA; Tue, 22 Mar 2022 03:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 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_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=kKXBrz7w; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t38rR6UM 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 RqqBXq6uD_9Y; Tue, 22 Mar 2022 03:13:58 -0700 (PDT) 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 AE0F73A0E01; Tue, 22 Mar 2022 03:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41302; q=dns/txt; s=iport; t=1647944007; x=1649153607; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jMEjNi6fA5eYXY84B+rEu3rsIoNEQOhqb4g2mdUqK9Y=; b=kKXBrz7wzEx3DMbeZCY7SXXFst2lZxudWlEXjQ1jNgrOBaOM373PfsoF bOtVyGh1BPgm8+E631g8lI21VT004TM0MnHZ65JL78TtgAIB0PZgisTl9 d7oCq/2CBXSS6KnYCWO0U8JXjkg1rpect2ctwnpY2eAGAF2NHSBr6wuUY 0=; IronPort-PHdr: =?us-ascii?q?A9a23=3AlbzLMhRJeR6Ga1ogzrh2bPhWd9pso7vLVj580?= =?us-ascii?q?XJvo75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFkwkpGsXQD0r9IbbjZDA7G8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZH?= =?us-ascii?q?VP0Mg8mTtk=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AXPnQ56BrS2TTlRVW/4Thw5YqxClBgxIJ4kV8j?= =?us-ascii?q?S/XYbTApD0ggmMCx2VOUWvTb67YMGenKtglbtyy9EgE7cOGytEwOVdlrnsFo?= =?us-ascii?q?1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNPMrEsEOhuFiWG/kz3aOC7xZVB/fjgq?= =?us-ascii?q?oTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343?= =?us-ascii?q?IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u?= =?us-ascii?q?2je5RpoU5Wuk63wdQsBRbu60Qqm0yUNHfP9xEkZ4HVviM7XN9JEAatTozyJl?= =?us-ascii?q?tp9xdFWnZexUgwueKbLnYzxVjEJQ3wlYvYYpeWvzX+X9Jb7I1f9W3r02/BGD?= =?us-ascii?q?UwqM8sf4OkfKXpW7/0eJ3UGbhmCnfmewb+nRK9rnMtLBNLzJoIZtVlhwC3XS?= =?us-ascii?q?/E8TvjrT7/D68Md0jY0nc5PGe2bfNIDaDxgKQzJfx0KJk0eA5M4k8+pi2XxN?= =?us-ascii?q?TpCpzq9rKo+6WTeyBckjODmMcHefZqBQsB9kkORvGmA/mnlDFcdLtP34TWf/?= =?us-ascii?q?32tg+7VhiDqcI0XHby8sPVthTWuKsY7YPENfUGwrf/8gUmkVpcGbUcV4SEp6?= =?us-ascii?q?6M18SSWohDGd0XQiBa5UtQ0ArK8y9EH1Tw=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AGgFQlqlFkQViQmr/gVMW9LXgYJnpDfOYim?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V8sjzhCWatN9OYh0dcIi7SdW9qXO1z+8Q3WBjB8bcYO?= =?us-ascii?q?CGghrlEGgG1+rfKlLbalXDH4JmpMVdmu1FeaDN5DtB/InHCWuDYq0dKbC8mc?= =?us-ascii?q?jC74q/vhRQpENRGttdBmxCe2Gm+zhNNXB77O0CZfyhD6R81l+dUEVSSv7+Km?= =?us-ascii?q?gOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLokCs2Yndq+/MP4GLFmwv26u?= =?us-ascii?q?GIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlawkEyzzYJLiJaYfy/gzdk9vfrW?= =?us-ascii?q?rCV+O85yvICv4DqE85uFvF5icFlTOQlgrGoEWSt2NwyUGT0PARAghKUvaoQe?= =?us-ascii?q?liA0DkA41KhqAl7EsD5RPoi7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSp?= =?us-ascii?q?Z2Us4bkWUzxjIdLH47JlOz1GnnKpgbMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx?= =?us-ascii?q?+DBkwPoNac3TRalG1wixJw/r1Tol4QsJYmD5VU7eXNNapl0LlIU88NdKp4QO?= =?us-ascii?q?MMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+83JwloOWxPJAYxpo7n5rMFFteqG?= =?us-ascii?q?4pYkrrTdaD2ZVamyq9NllVnQ6dvf22y6IJyIEUHoCbQhFrYGpe5vednw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAACgoDli/5hdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUYHAQELAYEgMVYHd1o3RIgeA4RZYIUQgwIDixGQJIEuFIE?= =?us-ascii?q?RA08FCwEBAQ0BASoBDAoEAQGFBwKEPQIlNAkOAQIEAQEBEgEBBQEBAQIBBwS?= =?us-ascii?q?BCROFaA2GQgEBAQEDAQEQLgEBLAkCAQ8CAQgRAQIBAiEBBgchBgsUAwYIAgQ?= =?us-ascii?q?BDQUIEweCY4IOVwMuAQ6fbgGBOgKBDokReIEzgQGCCAEBBgQEgTcBAwQMQYJ?= =?us-ascii?q?/DQuCNwMGgTwBgxCDAIEkhxQnHIFJRIEVQ4JnPoIhQgEBAgGBIzweDQkCgxm?= =?us-ascii?q?CLpdKRl8LBA1EAhQbKwELMh8OCBINAQsNDh43D59BQI0+kT9DawqDSYsPjmm?= =?us-ascii?q?GGRWDdIwwhlyRQZZbIIx1g1KQTyuEeAIEAgQFAg4BAQaBYTyBWXAVGiGCaVE?= =?us-ascii?q?ZD1aNSgkZFYM7hRSFSnUCNgIGCwEBAwmQUgEB?= X-IronPort-AV: E=Sophos;i="5.90,201,1643673600"; d="scan'208,217";a="985373652" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2022 10:13:21 +0000 Received: from mail.cisco.com (xfe-rcd-004.cisco.com [173.37.227.252]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 22MADLa5008813 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 22 Mar 2022 10:13:21 GMT Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 22 Mar 2022 05:13:20 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 22 Mar 2022 06:13:20 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a2nHfbpmZ+QfGFBl6KBPQQkuIlWMkrY8LZUB/TGiUSbUHmrnRcbXHUgnCZ+oHkzKiuiS3f7Kr9wtQCoEIQB+Opnh+q+LJOGGdaBcK/+DO1MJQaEw4YaKSUzhcCS8GloqEx4NGKME6UqMlzc8E31z9pB1kcwHvUGCeSYGpS3xoyK5VXKj6b/WNKUEhRVejx7P//GnsK37ZqvLBEWp2e+snTWowtmkFSuIbnV5GO50R9YuJ5KG0VEio6xz+Tk9PqxNNh3Py9gcvdc8PUFOtwTffluEkQk5Ij1kbJrsIyS6NnMq7jEMEOM07jZrxsWI3amYUMtPhsmy6/NILaD3psLaQg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HmF319xyUyTgcgqcBAnKKO8ChECwDM/BL7td+9eJhWc=; b=By1rHJnV8LWRnW0GWeBv6zEUOAbIpw0wGOcIAfE4WnKw0oyCPzq3yFOroAYHHVT2IEEfSBuz94SGRjNXf+K6uSZxM7qZu/fcDaVE6epJsBOv6Z9M4VJUoiwnr2Ji1v/sJvaAgwQc59XisfYKOFSCNFsk/dTvKMDLjHxHyfYkX5uOOKFxtCk1dhJJPYabFIL42cNgzyJSatO9RIxULU7pEeWkLcRnqHg+2nAQnbxRilXSLI3ENNBLcsWG8wXTQn8ugtfVxESFePXiQg37UKqdwWhClYCMfMMe9onHCUAsu+PTAowgDuJBxZEmAMAd+NzkjmlU5G1fE9aTEI7389r1pg== 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=HmF319xyUyTgcgqcBAnKKO8ChECwDM/BL7td+9eJhWc=; b=t38rR6UMtxsnShsHt8b+ESSuNMGXfted7+G11KEW6kkQG4E0JxRLbdU2PHrVgBs1prbyJNbDoovYtCm0WQp909uVXDiZviy92ktwKxsGscs73BLkS1UhHqLg/A8NAQDHklkBh959aSvFsANlNGtU1KHhzfposTFwD9MHPvhOmtg= Received: from PH0PR11MB5829.namprd11.prod.outlook.com (2603:10b6:510:140::8) by BYAPR11MB2695.namprd11.prod.outlook.com (2603:10b6:a02:c0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14; Tue, 22 Mar 2022 10:13:19 +0000 Received: from PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c]) by PH0PR11MB5829.namprd11.prod.outlook.com ([fe80::8ccf:835f:541b:c47c%9]) with mapi id 15.20.5102.016; Tue, 22 Mar 2022 10:13:19 +0000 From: "Ahmed Abdelsalam (ahabdels)" To: Greg Mirsky , "Ahmed Abdelsalam (ahabdels)" , "draft-filsfils-spring-path-tracing@ietf.org" CC: "spring@ietf.org" , "spring-chairs@ietf.org" , "ippm@ietf.org" Thread-Topic: [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-00.txt Thread-Index: AQHYL99cD4laBHfqlECFrXblL/g+Fay3HxwEgAiYIICAC5PmKg== Date: Tue, 22 Mar 2022 10:13:19 +0000 Message-ID: References: <164640893348.28277.3971579812610487211@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 617f19c8-2ed9-4fa0-fa1e-08da0bec9691 x-ms-traffictypediagnostic: BYAPR11MB2695:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NEgk8+x09QFvkxy8/rHZYdB1WRqd/5tUFiNMS3M6o0/gsQ9Q+3ONnBT1t7l8H3U3Ez1V7Yde5hhERd5B8cW7JHwJJ2IhNoj87vdgiW0AC7sn1FG9lxlwtLKpevVjAi9LnOe3+m+EGCI2VwsDQyHyayVxFJ5lIb3zwS7xvV60jsZNgVXubu87kVl6x7B0fbkcyFgKQrdtzhfw2JIljbv3tkZhBWXgQgIImU7S4q+Wd/wvbvs9O/BguJ6vBoC+TsR7lkN3ezCU8HE/RoihCSZNWs5wEnqANrM7jkoAFnQfPrQGmiNq0IwHDZTcMB5fNIb+YmwfsR8yYXAgJbaQIP/Q60DwzOhHF29hKr7qOaWXt0pT7buia4TDdAbYWIipIv86BZNBb4WzNo3PuvDCtWPhVO/LQW+NqmguWDl4vH6WO5CXZWLeZnZI1tOZuc+sQ6aLGNIp95XKgeB0H2VylmRIgD880wy3pqHs4LyF19KmFSbdWFz7PvgvPcgjrVSbh2JTOrgccaqlOMHvqO/yjWPCVs6OjjymwW6AhtdIIlwgaO0iMmF5lNyYh27rcppXExX1WLVhgQgW3f/wtG8rMP6iS1ScnfqPfgDGe7s41jCHNK9lG5XIxdzhxLXeesbRAbz0JGE4fUlmyR/HYi2dO8Fdk7lQdivoIU16pyr3E7GhurPjMMHyylz4JufjLIApwhATU5nmKC0hOM1/Ao8lzZtUqHiWPpOfUXnzhiJQe1LgO7Zd11Jbidk3f9L7ZdLYT8V5o8s4mNnv6RJULBwhLnlThkjGKkBQdwEhc19U8pRcJZ7Q3rhXTe80/9VZNK53d0pr0y2KxBeAxhihEqUI4PwuKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5829.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(33656002)(508600001)(86362001)(55016003)(2906002)(15650500001)(52536014)(76116006)(38070700005)(66476007)(8676002)(64756008)(66946007)(66556008)(4326008)(91956017)(66446008)(316002)(110136005)(71200400001)(966005)(6506007)(7696005)(8936002)(54906003)(53546011)(9686003)(38100700002)(26005)(122000001)(186003)(66574015)(83380400001)(5660300002)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5HkCySqwBqASitJL/h2w6NaDJTI8wdHGNrqjWJHXOvg5b3h9VSkmr8FYOLOI?= =?us-ascii?Q?+ku1yx1dbwsltu+nmQUXf9ZIrUi2ro+J7mZOdZImBh8CtRBfe1spNJhbVB4s?= =?us-ascii?Q?VBrxiCxUWleeA40QbrJ9AQEdA1DCtto87VzA++dJcSDuYBetVEXjEx0xuQ/+?= =?us-ascii?Q?RbXRCmGGa3/WU5stu9J38JdqwyLDfykX7EOPOlh0ZuYoGc6YP/SlxkEnNJ4x?= =?us-ascii?Q?Bpk2RFkFGVVTiQAU3G34egknKNbitQafB1MEiFlmaICo2napyMWLuyBK6oN7?= =?us-ascii?Q?0EcLUDLL4OrIK260XC7ODeviGABtTD3pqrJYcY+CzJQOT4sgfZ3BI2UTSwpW?= =?us-ascii?Q?9Ar+MxkILTkcrs6bI7PLFdPAH75gNWbz8LNOTNQBYXzXWk/3Xwz76AjtgENK?= =?us-ascii?Q?mYz8QdujqAhkco7xr2RzVUPkxKDAcllGzPxvdvoqkQdMxZM/qOZCTYJBRL/e?= =?us-ascii?Q?5Ci2JxanE39w3mpAdRV5s4o4kKa2/eSOnl5TX0YWHKqO4ca5NV/XlNvoKm4B?= =?us-ascii?Q?XMuCpeEoVqy3yHia8AXWoUYO2jmxxCcSja/g+yl7GRvno+5AETBPhAt9FJti?= =?us-ascii?Q?cq+Gk3A8UWdD85d1mMONdLZX0g0E6nwD2V0OOhPcy8QUMcXPMri+rRXfmJBe?= =?us-ascii?Q?7QAOhFJ1O/xm/Cyn1PB6CP9hVTvkEjmnCakQbxjKqtBstnMQ/K3lJi5lCaHv?= =?us-ascii?Q?cjjsc4innhaqIhqhi7Q6eAlcPbBb3idGvuEaQpARWsluY5d1OuBJ4Pg6Rsgt?= =?us-ascii?Q?wVWfwdQFRbnb3EXwJP/6DkaJv4sfbqtXZ/vbsWBsZRUCG8dENHFV8mXM2NHq?= =?us-ascii?Q?DHguCtDzCuRuj4DYdqzatQYA4CG+SPKG/Aoh3v8i2H6dvZyNfuuDw9cWSorl?= =?us-ascii?Q?Pu+9eLrDi7mNff1QYWDcYv0RTWuo1gOTilC9ljlAwcgplK/607wGC+OG/5kl?= =?us-ascii?Q?gvkqxdgKGxBPHEMk/lv+eFFhIhL+ci+cvj+W2014mfvHBKsYnWY3aOHZQ29E?= =?us-ascii?Q?W99+0hIGTzCnB/hjBmexvA+7FwgR5sADuqMZjPALjv/dlBT++8VaEGZAPGk0?= =?us-ascii?Q?1a7c4hn0Od1p0TaogftnQo8fck3j9T5VHJ0KJ4raMRSioFNqu8ZwPBuEqeyl?= =?us-ascii?Q?3BC551rFLtQIGUVDY/T1/Ap8IfEZUrp3UMT/yzyqi2y7qQuhXQgsKRBVfLId?= =?us-ascii?Q?Y1IKzXmXMb324YTaW2lEMlTPJqy9Q8nx4vc4ubZcCxWGSn6g3ga3xCbbs8Yb?= =?us-ascii?Q?Q1m2hAMGu/tECahGQ4nPg+MqDlkWUusDaxujMKRQHLh5kQgh/mAPJ8/7fuTo?= =?us-ascii?Q?8L04psrLpOt/RKYYCxpJyFrV1RwtoF4uGLUEyLPsMeiDoFmXHIOWmBl52PqU?= =?us-ascii?Q?k3gTwmZiu41Z+RapM6L2wqsdZGwmpY8+5bQ1oBxgJLWno1heJ/YWY3C4+CDE?= =?us-ascii?Q?6nCrKT27pioZwJCMpjXD9P4MqupbOygcZWqzjEakluvhzCta16n8nA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB58296F875F7D8F7837F807ECD4179PH0PR11MB5829namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5829.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 617f19c8-2ed9-4fa0-fa1e-08da0bec9691 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 10:13:19.1120 (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: +oy/B2bbZ6v46sybLbjqxiNH35JFzT8BrniTq6ou2HNK1bHSxFYyBr6qSfCwgqbzk4DW3erl0mf4ch3DMF46Yg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2695 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.227.252, xfe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] [ippm] FW: New Version Notification for draft-filsfils-spring-path-tracing-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 Mar 2022 10:14:21 -0000 --_000_PH0PR11MB58296F875F7D8F7837F807ECD4179PH0PR11MB5829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the review and comments. Please find Inline [AA] From: Greg Mirsky Date: Tuesday, 15 March 2022 at 02:25 To: Ahmed Abdelsalam (ahabdels) , dr= aft-filsfils-spring-path-tracing@ietf.org Cc: spring@ietf.org , spring-chairs@ietf.org , ippm@ietf.org Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-spring-= path-tracing-00.txt Hi Ahmed and the Authors, thank you for sharing this information. I've read the draft and have severa= l questions and comments: * It is not clear if you propose a new active measurement protocol or v= iew it as a hybrid method (based on RFC 7799 classification). On one hand, = packets are referred to as probes, but I don't see why the new Hb H option = cannot be applied to a data packet. [AA] While the examples and pseudocode in this draft focuses on the Active = Measurement case, the HbH option can be used indifferently both in probe pa= ckets and data packets. For the PT midpoint view, it does not make any diff= erence if HbH-PT is part of probe packet or data packet. * Resemblance with IOAM is very strong and it seems that the only advan= tage of PT over IOAM seems in the introduction of a Truncated Timestamp IE = for a Midpoint node. If the same IE is added in IOAM, what do you see as t= he benefit of using PT compared to IOAM? [AA] PT and iOAM are tackling the problem from different angles, and as suc= h their architecture differ. * In the draft you describe how to use PT to collect timestamps along a= path. T64 is recorded in PTP 64 bit-long format. What is the format used t= o record a Truncated Timestamp? Also, I couldn't find an explanation why PT= uses only one timestamp format and, for example, does not allow using NTP = 64 bit-long timestamp format. [AA] Path Tracing can work indifferently with PTP 64-bit and NTP 64-bit. Th= e Truncated Timestamp (TTS) is 8-bits selected from the 64-bit timestamp of= the node. The position of selected 8-bits is identified by the TTS Templat= e. * Furthermore, one-way delay measurement requires clock synchronization= . OIj the draft you use two use cases for PT, intercontinental and DC, what= should be the accuracy of the clock synchronization in the domain to ensur= e the PT produces useful measurement data? [AA] PT does not introduce any requirement in terms of clock synchronizatio= n accuracy, hence this is out of the scope of this draft. * As I understand the process of collecting truncated timestamps at a m= idpoint system, it records the value into the HbH IPv6 EH. You suggest that= the time value is "the time at which the packet egress the router". But si= nce a new value is written in the packet, should the checksum be re-calcula= ted? And if that is the case, would that cause a variable delay that affect= s the accuracy of the measurement provided by the PT method? [AA] Could you please clarify which checksum are you referring to? * Related to the above mentioned scenario, I find that IOAM has an adva= ntage compared with the PT method as a process of generating telemetry data= can be separated from transporting that telemetry information for processi= ng. For example, using IOAM Direct Export or Hybrid Two-Step mechanisms. Su= ch separation allows for more accurate measurements and also can be conduct= ed out-of-band relative to the monitored data flow. [AA] The postcard and passport modes are two different ways of collecting p= acket path information from the network. The Path Tracing solution defined = in this draft uses the passport mode. The original challenge of the passpor= t mode is collecting the data from NPU, in the normal packet pipeline, at l= inerate. This challenge has been solved in Path tracing. Thanks! I greatly appreciate your kind consideration of my comments and questions a= nd looking forward to an interesting discussion. Regards, Greg On Wed, Mar 9, 2022 at 6:14 AM Ahmed Abdelsalam (ahabdels) > wrote: Dear SPRING WG, IPPM WG, We have submitted a new I-D for Path Tracing in SRv6 networks (https://data= tracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing) to SPRING WG. We are looking for your feedback and comments. Path Tracing provides a record of the packet path as a sequence of interfac= e ids. In addition, it provides a record of end-to-end delay, per-hop delay= , and load on each egress interface along the packet delivery path to facil= itate operation of SR networks. Path Tracing allows to trace 14 hops with only a 40-octet IPv6 Hop-by-Hop e= xtension header. We will present Path Tracing to the SPRING WG at next IETF (https://datatra= cker.ietf.org/meeting/113/materials/agenda-113-spring-00.txt) Thanks, Ahmed From: internet-drafts@ietf.org > Date: Friday, 4 March 2022 at 16:48 To: Ahmed Abdelsalam (ahabdels) >, cf(mailer list) >, Mark Yufit >, Pablo Camarillo (pcam= aril) >, Pablo Camarillo (pca= maril) >, Satoru Matsushima <= satoru.matsushima@g.softbank.co.jp>, Thomas.Graf = >, Yuanchao Su = > Subject: New Version Notification for draft-filsfils-spring-path-tracing-00= .txt A new version of I-D, draft-filsfils-spring-path-tracing-00.txt has been successfully submitted by Pablo Camarillo Garvia and posted to the IETF repository. Name: draft-filsfils-spring-path-tracing Revision: 00 Title: Path Tracing in SRv6 networks Document date: 2022-03-04 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-filsfils-spring-path-= tracing-00.txt Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-path= -tracing/ Htmlized: https://datatracker.ietf.org/doc/html/draft-filsfils-spring= -path-tracing Abstract: Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. The IETF Secretariat _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_PH0PR11MB58296F875F7D8F7837F807ECD4179PH0PR11MB5829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for the review and comments. Please find Inline = ;[AA]

 

From: Greg Mirsky <gre= gimirsky@gmail.com>
Date: Tuesday, 15 March 2022 at 02:25
To: Ahmed Abdelsalam (ahabdels) <ahabdels=3D40cisco.com@dmarc.iet= f.org>, draft-filsfils-spring-path-tracing@ietf.org <draft-filsfils-s= pring-path-tracing@ietf.org>
Cc: spring@ietf.org <spring@ietf.org>, spring-chairs@ietf.org = <spring-chairs@ietf.org>, ippm@ietf.org <ippm@ietf.org>
Subject: Re: [ippm] FW: New Version Notification for draft-filsfils-= spring-path-tracing-00.txt

Hi Ahmed and the Au= thors,

thank you for shari= ng this information. I've read the draft and have several questions an= d comments:

  • It is not clear if you propose a new activ= e measurement protocol or view it as a hybrid method (based on RFC 7799 cla= ssification). On one hand, packets are referred to as probes, but I don't s= ee why the new Hb H option cannot be applied to a data packet.

[AA] While the examples and= pseudocode in this draft focuses on the Active Measurement case, the HbH o= ption can be used indifferently both in probe packets and data packets. For the PT midpoint view, it does not make= any difference if HbH-PT is part of probe packet or data packet.

  • Resemblance with IOAM is very strong and i= t seems that the only advantage of PT over IOAM seems in the introduction o= f a Truncated Timestamp IE  for a Midpoint node. If the same IE is add= ed in IOAM, what do you see as the benefit of using PT compared to IOAM?

[AA] PT and iOAM are tackli= ng the problem from different angles, and as such their architecture differ= .

  • In the draft you describe how to use PT to= collect timestamps along a path. T64 is recorded in PTP 64 bit-long format= . What is the format used to record a Truncated Timestamp? Also, I couldn't= find an explanation why PT uses only one timestamp format and, for example, does not allow using NTP 64 bit-lon= g timestamp format.

[AA] Path Tracing can work = indifferently with PTP 64-bit and NTP 64-bit. The Truncated Timestamp (TTS)= is 8-bits selected from the 64-bit timestamp of the node. The position of selected 8-bits is identified by the TTS Temp= late.

  • Furthermore, one-way delay measurement req= uires clock synchronization. OIj the draft you use two use cases for PT, in= tercontinental and DC, what should be the accuracy of the clock synchroniza= tion in the domain to ensure the PT produces useful measurement data?

[AA] PT does not introduce = any requirement in terms of clock synchronization accuracy, hence this is o= ut of the scope of this draft.

  • As I understand the process of collecting = truncated timestamps at a midpoint system, it records the value into the Hb= H IPv6 EH. You suggest that the time value is "the time at which the p= acket egress the router". But since a new value is written in the packet, should the checksum be re-calculated? And = if that is the case, would that cause a variable delay that affects the acc= uracy of the measurement provided by the PT method?
    • <= /ul>

    [AA] Could you please clari= fy which checksum are you referring to?

    • Related to the above mentioned scenario, I= find that IOAM has an advantage compared with the PT method as a process o= f generating telemetry data can be separated from transporting that telemet= ry information for processing. For example, using IOAM Direct Export or Hybrid Two-Step mechanisms. Such sepa= ration allows for more accurate measurements and also can be conducted out-= of-band relative to the monitored data flow.

    [AA] The postcard and passp= ort modes are two different ways of collecting packet path information from= the network. The Path Tracing solution defined in this draft uses the passport mode. The original challenge of th= e passport mode is collecting the data from NPU, in the normal packet pipel= ine, at linerate. This challenge has been solved in Path tracing.

    Thanks!=

    I greatly appreciat= e your kind consideration of my comments and questions and looking for= ward to an interesting discussion.

     

    Regards,=

Greg

 

On Wed, Mar 9, 2022= at 6:14 AM Ahmed Abdelsalam (ahabdels) <ahabdels=3D40cisco.c= om@dmarc.ietf.org> wrote:

Dear SPRING WG,  IPPM WG,

 

We have submitted a new I-D for P= ath Tracing in SRv6 networks (https://datatracker.ietf.org/doc/html/draft-filsfils= -spring-path-tracing) to SPRING WG.

 

We are looking for your feedback = and comments.

 

Path Tracing provides a record of= the packet path as a sequence of interface ids. In addition, it provides a= record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path to facili= tate operation of SR networks.

 

Path Tracing allows to trace 14 h= ops with only a 40-octet IPv6 Hop-by-Hop extension header.

 

We will present Path Tracing to t= he SPRING WG at next IETF (https://datatracker.ietf.org/meeting/113/materials/a= genda-113-spring-00.txt)

 

Thanks,

Ahmed

 

From: internet-drafts@ietf.org <interne= t-drafts@ietf.org&g= t;
Date: Friday, 4 March 2022 at 16:48
To: Ahmed Abdelsalam (ahabdels) <ahabdels@ci= sco.com>, cf(mai= ler list) <cf@cisco.com>, Mark Yufit <mark.yufit@broadcom.com>, Pablo Camarillo (pcamar= il) <pcamaril@cisco.com>, Pablo Camarillo (pcamaril) <pcamaril@cisco.com>, Satoru Matsushima= <satoru.matsushima@g.softbank.co.j= p>, Thomas.Graf <Thomas.Graf@swisscom.com>, Yuanchao Su <yitai.syc@alibaba-inc.com>
Subject: New Version Notification for draft-filsfils-spring-path-tra= cing-00.txt


A new version of I-D, draft-filsfils-spring-path-tracing-00.txt
has been successfully submitted by Pablo Camarillo Garvia and posted to the=
IETF repository.

Name:           draft-fil= sfils-spring-path-tracing
Revision:       00
Title:          Path Tracing i= n SRv6 networks
Document date:  2022-03-04
Group:          Individual Sub= mission
Pages:          15
URL:            https://ww= w.ietf.org/archive/id/draft-filsfils-spring-path-tracing-00.txt<= span style=3D"font-size:11.0pt">
Status:         https://datatracker.ietf.org/d= oc/draft-filsfils-spring-path-tracing/
Htmlized:       https://datatracker.ietf.org/doc/htm= l/draft-filsfils-spring-path-tracing


Abstract:
   Path Tracing provides a record of the packet path as a sequenc= e of
   interface ids.  In addition, it provides a record of end-= to-end
   delay, per-hop delay, and load on each egress interface along = the
   packet delivery path.

   Path Tracing allows to trace 14 hops with only a 40-bytes IPv6= Hop-
   by-Hop extension header.

   Path Tracing supports fine grained timestamp.  It has bee= n designed
   for linerate hardware implementation in the base pipeline.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat

___________________= ____________________________
ippm mailing list
ippm@ietf.org https://www.ietf.org/mailman/listinfo= /ippm

--_000_PH0PR11MB58296F875F7D8F7837F807ECD4179PH0PR11MB5829namp_-- From nobody Tue Mar 22 10:51:09 2022 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 AE5B73A0D7E; Tue, 22 Mar 2022 10:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.11 X-Spam-Level: X-Spam-Status: No, score=-7.11 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=juniper.net header.b=TVcP3prr; dkim=pass (1024-bit key) header.d=juniper.net header.b=iXRnbxW2 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 LAhs0rqquDr5; Tue, 22 Mar 2022 10:50:37 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 175703A0D6C; Tue, 22 Mar 2022 10:50:36 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22M8IhaK013084; Tue, 22 Mar 2022 10:50:33 -0700 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 : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=mhKsF2EudmmD96kxtjo+F3NOMrtwmjqupjfB4V1nU9s=; b=TVcP3prroCdTOIVpzFplQPgBMr9aBFc1/Db3PgZrG3xtnUYyH0lIkJnoqYCQIXGT0+6s AklcFX+tDxMqyY+IRRXmztkYx2jWTDbtBMUItm3m+FGyBaUDH/MOJnSLxv60wGeNQIyl vUAQniqalMgQIc2Q1pODEsxWl7J3Pwm0+COzANLG+6fPeMe8No2w0q/RusVkNzRsyoJh cVsq6Ob/hjAyA1I4I/5GjnCrJai4WZhF/bTUkBQ9onOn5thDCmWkp3i78VT58ms6+qUz 9V/vtxXpuApmNmZDULEvC0B3j038KhL4T8aC2WbB4V2OLPdryTyrl5fN/Vl48QyjtGpE WQ== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3eyatysak6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Mar 2022 10:50:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HIPJqqLq+EswJ2p1ifWCRe8mu4gquMEgsKjLzzGXj1IqHR/qJLlrnafsjPTJqADoezqCNDLpJ331ereu543XdYlku/s5IQAuSzH49tC8w/7I23Yu4bYsUZllrz7+1w1aJKlE/FuncbdX8QF3LY4LX4/XsjVZgwQHiXQqHYhJ4cHo03dSqFVsfpzEifAvUc0yZPMDghRiEihF2RJoh8Cj8dnKM1aBGXJFaxpg1uT1OyU3pbE6mkMP8FhezeAU9/Rw9iMhMe2a1mcT1O/er0uKvzTLJOpdICGydLVmGdI2S9CJerX2x7cFbH3GIH4SYEbw0Je8rh74JUz5HjD7whXbTQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mhKsF2EudmmD96kxtjo+F3NOMrtwmjqupjfB4V1nU9s=; b=ZAh7E9lidZyooib9ebhYATf6k0E2YFrtcWFla4wKQJZCeruz1C/U/8yAPbD/zMqjKdURO2fK10hgY67w4SFpUl2xdpEFzkgyKiohcpfkAiIcocHNxyci7UpQVBpfVVNwAADQM/f8ouDv5jQpMt8oEWzRFml0LsE0vje8R6rVzANmP8iCkyxZ5VgvTmokzt42icbCn92AJLo7hRR8XTLGD5yW9TyuozhhwdSIrNko5LLLVrASbeAPMNxo/I7CSksEzXT6QhpyWfR2OI1r5NWZyVWGBwIZoky8NHw0q/L6ynLcl1NikrV3f63hQ681M0wYdCWHrUBEBwGRHqX7I1T+XQ== 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=mhKsF2EudmmD96kxtjo+F3NOMrtwmjqupjfB4V1nU9s=; b=iXRnbxW2nxTgXaRNdp3csds8a3zqoZI3d5MRKpN4+whCQkUZZpb78MRN07olyG1ZtbTEWpHpzR5Byt8n5BdMCs5bzctHrjdzfjqQh5ERjHq+ywwXihGo1EBBu0aZO8Eqef+wu58pq6A+lpUvpw8uwEgIUU5ml99LmZSv98ecRGI= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by SN6PR05MB5518.namprd05.prod.outlook.com (2603:10b6:805:c1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.16; Tue, 22 Mar 2022 17:50:30 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::8cd3:9859:9c55:6eb8]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::8cd3:9859:9c55:6eb8%5]) with mapi id 15.20.5102.016; Tue, 22 Mar 2022 17:50:29 +0000 From: John Scudder To: Ketan Talaulikar CC: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Thread-Topic: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI1ajQRbh7M614068Bbz53eGtPayWiSeAgAAKsYCAM/mVgIAAwNgAgACVrwA= Date: Tue, 22 Mar 2022 17:50:29 +0000 Message-ID: <6E8C015A-C0AE-4775-9B49-09F7DA40B9B2@juniper.net> References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3696.80.82.1.1) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07a83cd9-9e30-4e15-1a9b-08da0c2c7480 x-ms-traffictypediagnostic: SN6PR05MB5518:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sFvyCTU11ctw9RZrJuhBfuZkQNjRms0Fmw74HJB7TVLVoIGTLiWJxTdx0WLz6pk11Mn8SD9cUMf541pCtt/bSmklbQ8LkX8CzjgoOK3ETkjGF4g31GZ+D0X15c7HuvhrDyBRBHXqq+5MhHwGU0yHLvgI+WQpjIUwsR0OsXr0wUwY0kxGiT8KxpMkByh6T5+LQaLSKgZtWheg3cBELQ3SfSJ2ajD4W7g5lG0ch0080oFn+WABC93ANKakBpTJaL9tMY4kH3OFZHJ+EQ2GeZhm2fSJYi7H0QFPyPtIto+1mdXMbiW5EGk0zlZ4llZCLIfTpFI5v/FvsohgnX+av4p9EetvVXd8S3ZS4i7jyiiz6Mj+83ncfRVb9rrcTSeRckK729ZSadXuthelkpVspQYGLSs0ixlcNdUgJ2pS0fW4oYbHj/sbLTxrvRNzTW6QzLzNGjEjbEU9ZHmGfuuzuDmfe/dXzhQO6bZ6qEHoCfhAtc1U4oDDEXKiXeHOW8bw+FXPfwiqk/um2zYWo0DF9ByJjA6W8Y/lPiUS2xrckfuMoQW/jG8TORj3WdS1VW0TODmsklYY8fkQkWACPjA6rs2Impo5b6UcWXWaC39dgrK4Ae1K7sJgZuFAbaCP6PNwvVaeRAlZ4oIrFDrjekbsIbt1gnP23TmvYphJ6CR9xwViTjYZ5PYJlYQ1CnkBbBTJ+bxpgLOyo68j9GSevF4JAiA43PZ0QkZ+iF6vW3tPl6N+mQZIRfmpFguy4Afx+pDN5/3m6PBcS84rqIMXOdyhL3ZwTZkcQLdGHYLWDMmiBwdt0cxJ/xkbNMyj15GaTPDdcTKF x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6486002)(966005)(508600001)(83380400001)(38100700002)(6916009)(54906003)(36756003)(66574015)(122000001)(316002)(6512007)(2906002)(38070700005)(5660300002)(8936002)(4326008)(71200400001)(186003)(86362001)(2616005)(91956017)(6506007)(66556008)(76116006)(66446008)(64756008)(66476007)(66946007)(8676002)(53546011)(26005)(33656002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VUMxelI1NFlGeXRnN0xRdHF5cXFIOEg1VC9iejB6aUcxV1pUeHJCL1hOc21N?= =?utf-8?B?Ym5yNHNnTUFmVWRqbzZmaDBQZ3NqMHo3VXBVSXVmRE5YN3VRSEdMaWdiUHNB?= =?utf-8?B?RXlaNGRHZXU5Q2VmLzVoUnIrSTBUUitTUnQzTjFoZlR4dC9Xak1PWElFbkNm?= =?utf-8?B?bmNDMFR0ZFd4YktNa2NYTUdxNDJna2M3VFQxa3pHMFlBWTVKODNsRTc0YVh0?= =?utf-8?B?VjhGZFA1L09lVG1XcGNRU1h6bFJDWGFvWHFyV0hpS0JWN3VrVFFDVytpR1da?= =?utf-8?B?bTc0VHNEdEFpS2VPbm92MXJVNDlxb20rZlBYYkQ3NVJITUhYS2dIaTR6SC9S?= =?utf-8?B?ZC9OVDNHSGJOVzd5VUgzcVNGU0NyRWZIdVY3TlNaTXhoaHZrbDlvUDFKZ21J?= =?utf-8?B?a216RGU3M0VmN0JvdVhUWG15eVdXZGwyWW9jNjVWNDhoRk5vdXBXOXdZeXJy?= =?utf-8?B?V1krZWZwNEJmSzhCSG15RWRIRkQ0bllSYTNLeUl1TnNiUXJkUmYvOGRsTXQv?= =?utf-8?B?L1NHVnFUNHZyOTNsMGVua3BrVXlMZ1psNzJpOVU4U3BkYVhJL3pzeXhEN3Rn?= =?utf-8?B?ZXcxRWxSVlNlVVJnNzJYWWMveThEcjY1NTQreWFKTmhGaXdXelgrL2hoMHgz?= =?utf-8?B?eHV5TEZVS2RNMVlsZk84S2VOM0JCY1J1YUw1UTFLSkROVEt3cTkxeHdtcmJj?= =?utf-8?B?M1VvYmRuS3hJNlpObDJjdDdlRFp0d2l0Vzc1eENBT2FGQWhzNGxMSnk0YnpQ?= =?utf-8?B?YTZFV3lONlpUN0c5b0pLRzIvTHVYZDFTRDB4d0t0eTU3NUk5cEd2YStRcHRG?= =?utf-8?B?ZUNsak95QkpnYlZQbmh2OTRhVHZhTWFtQmtnWCtUdWFUUFR2TkNnR3hZMUJr?= =?utf-8?B?Z3ZHUms2QStCK0g2N3QwdHcyckZRRzJIcVJpUVJCUXE3NThNOUd1blFLVHBo?= =?utf-8?B?QmJjd2tKL0NtVUN2dkJGYkozRFR1eHdIekNQalduNDlzVFVKWGU4eWJtSTFn?= =?utf-8?B?SDI2b0tYRVJXZFliN0E4WWU5RUdpcUJWYXJwU0YyRDdPNlVWbm84WHVVNTZj?= =?utf-8?B?bTZacmZtUjlIYldWWnQ3UllvUHluY25ld3lyQlhQRUEzak8rLzh2M2Z6TWJB?= =?utf-8?B?SGdVYmdtT2ZGRXdGU2dQSHBxbXNzY2xuenBHWXVURlhZM1RjMTlFZGxKKzFC?= =?utf-8?B?ejhaVHh3Q0c3cHN4RUk4Y2NjNmhySyt6ZkhqTHpyYm83RzJTQzFZN1k4VlF4?= =?utf-8?B?NUw2VEsxUkpnMjhmem12bFB0UWlocml6L1hwNFBUZzV5dXBEaDhIbzkyOTZR?= =?utf-8?B?N1FJYVc4Q3dCRnBad0RscmdLQm8yY0JLYlNsNlpNczBZT2lBcVJFcjdyUGJo?= =?utf-8?B?M3ZVcjUvUlYybGN5UVZ4WVN0ZW9pcDZvUnhET0xDV05Yd0U3dzJTei9EYUhQ?= =?utf-8?B?Y1VvSFhrMWZBakJOc0xWTGJNbXlXOU1ZT0xOYmdqZGZyZ0VjMnY1RWpsS0h0?= =?utf-8?B?OG42Qnc4SE9SSXcwdkVzRGdheGlOR1h1V1F1VTJ0eHdSUjM2RXRQSWpzLzQv?= =?utf-8?B?SDlLOHBjWHRobm1aV0JuaktQT3VQUjRBN2ZzVjRLOTh2aGV5NmdCMWNxMHpQ?= =?utf-8?B?cEJYQWE0M0hONjBuaHUrSUhRQkoybkRLRVZpbWdoa290enFqVmk2VjZqdktx?= =?utf-8?B?NzR4Z2dCZHR2cERYenlxaGVuVlBubkVSV0twOUYwNEt0MmgwN2hhS0hYMVBJ?= =?utf-8?B?SFF4RUtROEE3MmdIODUrTFUrTUdRVExCeXlXWFpLSlhSb3ZaV2dnV2tOZkNh?= =?utf-8?B?Ui9PZDJPenJCVkxPSXNrMXJGK3ZjNENDQ1FqZms0SVRWTnFYUVpmS0FHaEdu?= =?utf-8?B?VTBtdFRMcHlBNDVXTlY2VWsyNU1mWFVEWDJxbk93MEE0QzdrVzlyRHFxZFA3?= =?utf-8?B?ay9vQnNrUnVsNnJ4SnNrWGY0dUh5QVdHZEFXTk9OL3FMMWdPM0x0OHRodmF4?= =?utf-8?B?WjdhRWFuTzZRPT0=?= Content-Type: text/plain; charset="utf-8" Content-ID: <9FC690BA897245469AA3769878525AB0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07a83cd9-9e30-4e15-1a9b-08da0c2c7480 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 17:50:29.7899 (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: 6maKa9+FIx9X1sRTT6fhrwwHJy11RcGurpB1plPWKGy+qv9XYcQzrp/twL+1U1qu X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB5518 X-Proofpoint-GUID: MwOeREpVuU3ZtmEN-VLHaVz2uZzQrzJ0 X-Proofpoint-ORIG-GUID: MwOeREpVuU3ZtmEN-VLHaVz2uZzQrzJ0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-22_07,2022-03-22_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 malwarescore=0 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 clxscore=1015 mlxscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203220094 Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 22 Mar 2022 17:50:43 -0000 SGkgS2V0YW4sDQoNClRoYW5rcyBhcyBhbHdheXMgZm9yIHlvdXIgcXVpY2sgcmVwbHkuDQoNCj4g T24gTWFyIDIyLCAyMDIyLCBhdCA0OjU0IEFNLCBLZXRhbiBUYWxhdWxpa2FyIDxrZXRhbnQuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gDQo+IEhpIEpvaG4sDQo+IA0KPiBJIGR1ZyBpbnRv IG15IGVtYWlscyBhbmQgeW91IGFyZSByaWdodCB0aGF0IHdoaWxlIHdlIGhhZCBhIGRpc2N1c3Np b24gb24gcG9pbnQgNCAoaS5lLiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhc3NvY2lhdGVkIHdp dGggdGhlIHVzZSBvZiBzeW1ib2xpYyBuYW1lcyksIGl0IHdhcyBub3QgY29uY2x1ZGVkLiBNeSBh cG9sb2dpZXMgZm9yIHRoZSBzYW1lLg0KPiANCj4gSXQgbWlnaHQgYmUgaGVscGZ1bCB0byBwbGFj ZSBhIGNvbnRleHQgb24gd2h5IHRoZSBkcmFmdCB1c2VzIHN5bWJvbGljIG5hbWVzIGluIHRoZSBm aXJzdCBwbGFjZS4gVGhlIGNsb3Nlc3QgYW5hbG9naWVzIHRoYXQgY29tZSB0byBteSBtaW5kIGFy ZSB0dW5uZWxzIChkaWZmZXJlbnQgdHlwZXMgLSBURSwgSVBpbklQLCBJUHNlYykgYW5kIE1QTFMg TFNQcyAob3IgcGF0aHMpLiBUaGVzZSBjb25zdHJ1Y3RzIGhhdmUgaGFkIHN5bWJvbGljIG5hbWVz IGFzc29jaWF0ZWQgd2l0aCB0aGVtIGZvciBhIGxvbmcgdGltZSBub3cgLSBib3RoIGZvciBsb2Nh bCB1c2Ugb24gcm91dGVycyAoc29tZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyAtIG90aGVycyBz cGVjaWZpZWQgYnkgSUVURikNCg0KU3VyZS4gQW55dGhpbmcgbG9jYWwgdG8gdGhlIHJvdXRlciBp c27igJl0IHJlbGF0ZWQgdG8gbXkgY29uY2Vybiwgd2hpY2ggaXMgc3BlY2lmaWMgdG8gdGhlIG9w cG9ydHVuaXR5IGZvciBhIHJlbW90ZSBhdHRhY2tlciB0byBtaXNsZWFkIHNvbWVvbmUgb24gdGhl IGxvY2FsIHJvdXRlci4gSSBob3BlIGl04oCZcyBjbGVhciBieSBub3cgdGhhdCBJIGhhdmUgbm8g aXNzdWUgd2l0aCBhc3NvY2lhdGluZyBhIHN5bWJvbGljIG5hbWUgd2l0aCBhIFNSIFBvbGljeSAo b3IgYW55IG90aGVyIHRoaW5nKSwgYXMgc3VjaC4NCg0KPiBhbmQgYWxzbyBzaWduYWxlZCB2aWEg cm91dGluZyBwcm90b2NvbHMuDQoNCk5vdyB0aGF0IHlvdSBwb2ludCBpdCBvdXQsIEkgZG8gc2Vl IGEgZmV3IHN1Y2gsIGUuZy4gdGhlIFNZTUJPTElDLVBBVEgtTkFNRSBpbiBSRkMgODIzMS4gVGhh dCBwYXJ0aWN1bGFyIGV4YW1wbGUgaGFzIGFyZ3VhYmx5IGRpZmZlcmVudCB0aHJlYXQgcHJvcGVy dGllcyBzaW5jZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBQQ0UgYW5kIGl0cyBjbGllbnRz IGlzbuKAmXQgbWVkaWF0ZWQgdGhyb3VnaCBvdGhlciByb3V0ZXJzOyB0aGUgdHJ1c3QgcmVsYXRp b25zaGlwIGlzIGNsZWFyZXIgYW5kIHRoZSDigJxyZW1vdGUgYXR0YWNrZXLigJ0gaXMgbm90IHNv IHZlcnkgcmVtb3RlLiBCdXQgSSBpbWFnaW5lIHRoZXJlIGFyZSBvdGhlciBleGFtcGxlcyB0byBi ZSBmb3VuZCwgYW5kIEkgZG9u4oCZdCB3YW50IHRvIHNwbGl0IGhhaXJzIG9uIHRoaXMgZGV0YWls Lg0KDQo+IE9wZXJhdG9ycyBhcmUgdGhlcmVmb3JlIHF1aXRlIGZhbWlsaWFyIHdpdGggdGhlaXIg dXNhZ2UgYW5kIGhlbmNlIHRoZWlyIGludHJvZHVjdGlvbiBpbiB0aGUgU1IgUG9saWN5IGNvbnN0 cnVjdC4gSSBkb24ndCBiZWxpZXZlIHRoZSBXRyB3b3VsZCB3YW50IHRvIHRha2UgdGhlIG9wdGlv biBvZiB0aGVpciByZW1vdmFsIChpdCB3YXMgYSBzdWdnZXN0ZWQgb3B0aW9uKS4NCg0KSSBkaWRu 4oCZdCByZWFsbHkgZXhwZWN0IHlvdSB0bzsgSSB3YXMganVzdCBsYXlpbmcgb3V0IHNvbWUgcG9p bnRzIGluIHRoZSBzb2x1dGlvbiBzcGFjZS4NCg0KPiBUaGVuIHdlIGdldCB0byBvcHRpb24gb2Yg YWRkaW5nIHNwZWNpZmljIHRleHQgdG8gdGhlIGRyYWZ0IChpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnM/KSB0aGF0IHdvdWxkIGRpc2N1c3MgeW91ciBjb25jZXJucy4gU3VjaCB0ZXh0IG1h eSBiZSBhZGRyZXNzZWQgdG8gaW1wbGVtZW50YXRvcnMgYW5kL29yIG9wZXJhdG9ycy4gQXMgbWVu dGlvbmVkIGFib3ZlLCB0aGUgdXNlIG9mIHN5bWJvbGljIG5hbWVzIGZvciBjb25zdHJ1Y3RzIHNp bWlsYXIgdG8gU1IgUG9saWN5IG5hbWUgYW5kIFNSIFBvbGljeSBDYW5kaWRhdGUgUGF0aCBuYW1l IGlzIG5vdCAibmV3IiBmb3IgYm90aCBzZXRzIG9mIHJlYWRlcnMuIFRoZXJlZm9yZSwgSSBhbSBu b3Qgc3VyZSBpZiB3ZSBuZWVkIHRvIGNvdmVyIG9yIGFkZCBhbnl0aGluZyBuZXcgaW4gdGhpcyBk b2N1bWVudCBhbmQgSSBjb3VsZCBub3QgZmluZCB0ZXh0IHRoYXQgSSBjb3VsZCBib3Jyb3cgZnJv bSBvdGhlciBSRkNzIG9yIHBvaW50IHRvIG90aGVyIFJGQ3MuIGUuZy4sIGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL3JmYy9yZmM4MjMxLmh0bWwjc2VjdGlvbi03LjMuMg0KPiANCj4gSSBkaWQg bG9vayBhdCBSRkM5MDAzIGJ1dCBpdHMgY29udGV4dCBpcyB2ZXJ5IGRpZmZlcmVudC4gRnJvbSB5 b3VyIERJU0NVU1MgY29tbWVudCwgSSBzZWUgdGhhdCB5b3VyIGNvbmNlcm4gaXMgdGhhdCBhIHN0 cmluZyBkb2VzIG5vdCBoYXZlIGFueSBzYW5pdHkgY2hlY2tpbmcgLSB0aGUgb3BlcmF0b3IgaXMg ZnJlZSB0byB1c2UgYW55IHRleHQuDQoNCkNvcnJlY3QuIEFzIGxvbmcgYXMgeW91IGFzc3VtZSBn b29kIHdpbGwgb24gdGhlIHBhcnQgb2Yg4oCcdGhlIG9wZXJhdG9y4oCdIGl04oCZcyBhbGwgZ29v ZC4gSWYgeW91IHN0YXJ0IHRoaW5raW5nIGluIHRlcm1zIG9mIGFuIGF0dGFja2VyIGluIHNvbWUg ZGlzdGFudCBwYXJ0IG9mIHRoZSBuZXR3b3JrIGluamVjdGluZyBhIHBvbGljeSwgaXQgYmVjb21l cyBwb3RlbnRpYWxseSBjb25jZXJuaW5nLiANCg0KPiBJIGFncmVlLiBEbyB3ZSB3YW50IGltcGxl bWVudGF0aW9ucyB0byByZXN0cmljdCBzb21ldGhpbmc/IERvIHdlIHdhbnQgdG8gZ2l2ZSBzb21l IG5hbWluZyBndWlkZWxpbmVzIG9yIHByZWNhdXRpb25zIHRvIHRoZSBvcGVyYXRvcnM/DQoNCkkg ZG9u4oCZdCB0aGluayB0aGUgY29uY2VybiBpcyBhZGRyZXNzYWJsZSBvbiB0aGUgb3JpZ2luYXRp b24gc2lkZSwgc2luY2UgaXQgYXNzdW1lcyBhIGJhZCBhY3RvciB0byBiZWdpbiB3aXRoLCBhbmQg dGhleeKAmXJlIG5vdCBnb2luZyB0byBiZSBib3RoZXJlZCBieSB3aGF0IHdlIHdyaXRlIGluIGFu IFJGQy4gVGhhdCB3YXMgd2h5IGluIG15IHN1Z2dlc3Rpb24gSSB3YXMgdGhpbmtpbmcgaW4gdGVy bXMgb2YgZGlzcGxheSBjb252ZW50aW9ucy4gSeKAmW0gbm90IHN1cGVyIGV4Y2l0ZWQgYnkgbXkg b3duIGlkZWEsIHRob3VnaCwgYmVjYXVzZSBpdCByZW1pbmRzIG1lIHVuY29tZm9ydGFibHkgbXVj aCBvZiB0aGUgZGlzY2xhaW1lciBteSBJVCBkZXBhcnRtZW50IHNsYXBzIG9uIGV2ZXJ5IGluY29t aW5nIGVtYWlsLCDigJxbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRd4oCd LiBJdOKAmXMgbm90IHBhcnRpY3VsYXJseSBhY3Rpb25hYmxlLCBhbmQgaXTigJlzIGFubm95aW5n LiA6LSgNCg0KPiBJbiBhIHByZXZpb3VzIHJlc3BvbnNlLCB5b3VyIHN1Z2dlc3Rpb25zIGZvciB0 aGUgdGV4dCBmb3Igb3BlcmF0b3JzIHdlcmUgKHNvbWV3aGF0Pykgb2YgdGhlIG5hdHVyZSAtICJi ZXdhcmUgdGhlIG5hbWUgb2YgdGhlIFNSIFBvbGljeSBtYXkgbm90IGFjdHVhbGx5IGJlIGNvcnJl Y3Qgb3IgbWF5IGJlIG1pc2xlYWRpbmcgYmVjYXVzZSBzb21lb25lIG1pZ2h0IGhhdmUgaGFja2Vk IGludG8gdGhlIG5ldHdvcmsiLiBJIGFtIG5vdCBzdXJlIGlmIHNvbWV0aGluZyBvZiB0aGF0IG5h dHVyZSBoZWxwcy4gSWYgdGhlIG5hbWVzIHN0b3AgYmVpbmcgbWVhbmluZ2Z1bCB0aGVuIHRoZXkg YXJlIG5vIG1vcmUgcmVsZXZhbnQ/IElzbid0IHRoZSBzZWN1cml0eSBhc3BlY3QgdG8gYmUgdGFr ZW4gY2FyZSBvZiBoZXJlIGlzIHRvIHByZXZlbnQgaGFja2luZz8gU29tZXRoaW5nIGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhpcyBkcmFmdD8NCg0K4oCcU2VjdXJpdHkgaXMgZXZlcnlvbmXigJlzIHJl c3BvbnNpYmxpdHku4oCdIA0KDQo+IEknbGwgYWRtaXQgdGhhdCBJIGFtIHJ1bm5pbmcgb3V0IG9m IGlkZWFzIG9uIHdoYXQgd291bGQgYmUgYSBtZWFuaW5nZnVsIHRleHQgdG8gYWRkIHRvIGFkZHJl c3MgeW91ciBjb25jZXJucy4gV291bGQgYXBwcmVjaWF0ZSBzb21lIHRleHQgc3VnZ2VzdGlvbiB0 aGF0IGlzIHJlbGV2YW50IHRvIHRoaXMgc3BlY2lmaWMgY29udGV4dC4NCg0KSW4gdGhlIGVuZCwg bWF5YmUgaXTigJlzIHRydWUgdGhhdCB0aGVyZeKAmXMgbm90IG11Y2ggdG8gYmUgZG9uZSwgd2hp Y2ggc3Vja3MsIGJ1dCB0aGF04oCZcyBsaWZlLiBCdXQgZXZlbiBpZiB3ZSB0aHJvdyBvdXIgaGFu ZHMgaW4gdGhlIGFpciBhbmQgc2F5IOKAnG5vdGhpbmcgdG8gYmUgZG9uZeKAnSwgd2hpY2ggaXMg SSB0aGluayB3aGVyZSB3ZeKAmXJlIGdldHRpbmcgdG8sIEkgZG9u4oCZdCB0aGluayB0aGVyZSB3 b3VsZCBiZSBhbnkgaGFybSBpbiBwdXR0aW5nIGEgc2VudGVuY2Ugb3IgdHdvIGluIHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzdWNoIGFzIHlvdSBtZW50aW9uIGp1c3QgYWJvdmUuIFNvbWV0 aGluZyBhbG9uZyB0aGUgbGluZXMgb2YsDQoNCuKAnEluIFNlY3Rpb24gMi4xIHdlIG1lbnRpb24g dGhhdCBhIHN5bWJvbGljIG5hbWUgTUFZIGJlIHNpZ25hbGVkIGFsb25nIHdpdGggYSBjYW5kaWRh dGUgcGF0aC4gV2hpbGUgdGhlIHZhbHVlIG9mIHN5bWJvbGljIG5hbWVzIGZvciBkaXNwbGF5IGNs YXJpdHkgaXMgaW5kaXNwdXRhYmxlLCBhcyB3aXRoIGFueSB1bnJlc3RyaWN0ZWQgZnJlZWZvcm0g dGV4dCByZWNlaXZlZCBmcm9tIGV4dGVybmFsIHBhcnRpZXMsIHRoZXJlIGNhbiBiZSBubyBhYnNv bHV0ZSBhc3N1cmFuY2UgdGhhdCB0aGUgaW5mb3JtYXRpb24gdGhlIHRleHQgcHVycG9ydHMgdG8g c2hvdyBpcyBhY2N1cmF0ZSBvciBldmVuIHRydXRoZnVsLiBGb3IgdGhpcyByZWFzb24sIHVzZXJz IG9mIGltcGxlbWVudGF0aW9ucyB0aGF0IGRpc3BsYXkgc3VjaCBpbmZvcm1hdGlvbiB3b3VsZCBi ZSB3ZWxsLWFkdmlzZWQgbm90IHRvIHJlbHkgb24gaXQgd2l0aG91dCBxdWVzdGlvbi4gRnVydGhl cm1vcmUsIGltcGxlbWVudGF0aW9ucyB0aGF0IGRpc3BsYXkgc3VjaCBpbmZvcm1hdGlvbiBtaWdo dCB3aXNoIHRvIGRpc3BsYXkgaXQgaW4gc3VjaCBhIGZhc2hpb24gYXMgdG8gZGlmZmVyZW50aWF0 ZSBpdCBmcm9tIGtub3duLWdvb2QgaW5mb3JtYXRpb24uIChTdWNoIGRpc3BsYXkgY29udmVudGlv bnMgYXJlIGluaGVyZW50bHkgaW1wbGVtZW50YXRpb24tc3BlY2lmaWM7IG9uZSBleGFtcGxlIG1p Z2h0IGJlIHVzZSBvZiBhIGRpc3Rpbmd1aXNoZWQgdGV4dCBjb2xvciBvciBzdHlsZSBmb3IgaW5m b3JtYXRpb24gdGhhdCBzaG91bGQgYmUgdHJlYXRlZCB3aXRoIGNhdXRpb24uKeKAnQ0KDQpMZXTi gJlzIGJlIGhvbmVzdCwgdGhlIOKAnG9vb2ggYmUgY2FyZWZ1bOKAnSB0ZXh0IHByb3ZpZGVzIGFi b3V0IGFzIG11Y2ggcHJvdGVjdGlvbiBhcyB3ZXQgdGlzc3VlIHBhcGVyLCBhbmQgZGlzcGxheWlu ZyB0aGUgc3RyaW5nIGluIG1hZ2VudGEgbm90IGEgd2hvbGUgbG90IG1vcmUgdGhhbiB0aGF0IOKA lCBidXQgaXTigJlzIHN0aWxsIGJldHRlciB0byBkaXNjbG9zZSB0aGUgY29jbmVybiB0aGFuIG5v dCB0by4NCg0KUmVnYXJkcywNCg0K4oCUSm9obg0KDQo+IFRoYW5rcywNCj4gS2V0YW4NCj4gDQo+ IE9uIFR1ZSwgTWFyIDIyLCAyMDIyIGF0IDI6NTQgQU0gSm9obiBTY3VkZGVyIDxqZ3NAanVuaXBl ci5uZXQ+IHdyb3RlOg0KPj4gSGkgS2V0YW4sDQo+PiANCj4+IFlvdSBhc2tlZCAid2hldGhlciB0 aGUgcmVzcG9uc2VzIGFuZCBkcmFmdCB1cGRhdGVzIGFkZHJlc3MgW215XSBjb25jZXJuc+KAnS4g SeKAmWQgc2F5IHRoYXQgd2hpbGUgSeKAmW0gbm90IGNvbXBsZXRlbHkgaGFwcHkgYWJvdXQgY2Vy dGFpbiB0aGluZ3MgKGUuZy4sIEkgcmVtYWluIHVuY29udmluY2VkIHRoYXQgdGhlIGNvbXBhbmlv biBJRFIgZG9jIHNob3VsZG7igJl0IGJlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSkgSSBkb27igJl0 IG5lZWQgdG8gY29udGludWUgaG9sZGluZyBhIERJU0NVU1Mgb24gdGhlbTogd2XigJl2ZSBoYWQg YSBkaXNjdXNzaW9uLCB3ZSBkb27igJl0IGNvbXBsZXRlbHkgYWdyZWUsIHRoZXNlIHRoaW5ncyBo YXBwZW4uIE9uIHBvaW50IDQgaG93ZXZlciwgSSBkb27igJl0IHRoaW5rIG91ciBkaXNjdXNzaW9u IGhhcyBjb25jbHVkZWQuIEF0IGxlYXN0LCBpZiB5b3UgcmVwbGllZCB0byB0aGlzLCBJIG1pc3Nl ZCBpdDoNCj4+IA0KPj4gPiBPbiBGZWIgMTYsIDIwMjIsIGF0IDI6NDIgUE0sIEpvaG4gU2N1ZGRl ciA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPj4gPiANCj4+ID4+ IDQuIEluIMKnMi4xIHlvdSB0YWxrIGFib3V0IHRoZSBzaWduYWxpbmcgb2Ygc3ltYm9saWMgbmFt ZXMgZm9yIGNhbmRpZGF0ZSBwYXRocy4NCj4+ID4+IEFsdGhvdWdoIHlvdSBhcmUgY2FyZWZ1bCB0 byBzYXkgdGhhdCBzdWNoIHN5bWJvbGljIG5hbWVzIGFyZSBvbmx5IHVzZWQgZm9yDQo+PiA+PiBw cmVzZW50YXRpb24gcHVycG9zZXMsIGl0IHNlZW1zIHRvIG1lIHRoZXkgc3RpbGwgY291bGQgYmUg Y29uc2lkZXJlZCBhIG5ldw0KPj4gPj4gcG90ZW50aWFsIHNvdXJjZSBvZiB2dWxuZXJhYmlsaXR5 LCBzaW5jZSBhIHN0cmluZyB0aGF0IGhhcyBubyBzYW5pdHktY2hlY2tpbmcNCj4+ID4+IHdoYXRz b2V2ZXIgYXBwbGllZCBieSB0aGUgcHJvdG9jb2wgY2FuIGRpc3BsYXkgbGl0ZXJhbGx5IGFueXRo aW5nIHRvIGFuDQo+PiA+PiBvcGVyYXRvciB2aWV3aW5nIGl0LiBTaG91bGRu4oCZdCB0aGlzIGJl IGFkZHJlc3NlZCBpbiB5b3VyIFNlY3VyaXR5DQo+PiA+PiBDb25zaWRlcmF0aW9ucz8gKEZvciBh biBleGFtcGxlIG9mIGEgcmVsYXRlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgc2VlIFJGQw0K Pj4gPj4gOTAwMy4gSXTigJlzIHByb2JhYmx5IG5vdCB0aGUgYmVzdCBleGFtcGxlLCBidXQgaXTi gJlzIHRoZSBvbmUgSSBoYWQgYXQgbXkNCj4+ID4+IGZpbmdlcnRpcHPigKYpDQo+PiA+PiANCj4+ ID4+IEtUPiBSRkM5MDAzIHVzZXMgVVRGLTggd2hpbGUgdGhpcyBkb2N1bWVudCB1c2VzIHByaW50 YWJsZSBBU0NJSS4gQXMgc3VjaCwgSSBhbSBub3QgYXdhcmUgb2Ygc2VjdXJpdHkgaXNzdWVzIGFy b3VuZCBwcmludGFibGUgQVNDSUkgLSBwbGVhc2UgZG8gcG9pbnQgbWUgdG8gYW55IHJlZmVyZW5j ZXMuDQo+PiA+IA0KPj4gPiBZb3XigJlyZSB0aGlua2luZyB0b28gbXVjaCBsaWtlIGEgcHJvdG9j b2wgZGVzaWduZXIuIFRoZSBraW5kIG9mIGNvbmNlcm4gSeKAmW0gdGhpbmtpbmcgYWJvdXQgaGFz IHRvIGRvIHdpdGggdXNpbmcgdGhlIHN0cmluZyBhcyBhIHZlY3RvciB0byBwdXQgc29tZSB3b3Jk cyBpbiBmcm9udCBvZiBhbiBvcGVyYXRvciwgYXMgcGFydCBvZiBhIGxhcmdlciBzb2NpYWwgZW5n aW5lZXJpbmcgYXR0ZW1wdC4gSSBkb27igJl0IGhhdmUgYSBkZXRhaWxlZCBhdHRhY2sgc2NlbmFy aW8gdG8gcGFpbnQgZm9yIHlvdSwgYnV0IGEgcXVpY2sgc2tldGNoIGlzIGFsb25nIHRoZSBsaW5l cyBvZg0KPj4gPiANCj4+ID4gLSBBdHRhY2tlciBtYW5hZ2VzIHRvIGluamVjdCBhIGNhbmRpZGF0 ZSBwYXRoIHdpdGggdGhlIG5hbWUg4oCcQmlnX0JhbmtfTG93X0xhdGVuY3nigJ0NCj4+ID4gLSBQ cm9UaXA6IHRoZSBjYW5kaWRhdGUgcGF0aCBkb2VzIG5vdCBhY3R1YWxseSB0ZXJtaW5hdGUgYXQg QmlnX0JhbmsNCj4+ID4gLSBBdHRhY2tlciB0aGVuIHBob25lcyBOT0MsIGZlaWducyB1cmdlbmN5 LCBhc2tzIE5PQyB0byByZWRpcmVjdCBCaWdfQmFuayB0cmFmZmljIG9udG8gdGhhdCBwYXRoDQo+ PiA+IA0KPj4gPiBZb3UgZ2V0IHRoZSBpZGVhLCBJIGhvcGUuDQo+PiANCj4+IE1vcmUgc25pcHBl ZCwgYnV0IHRoaXMgaXMgdGhlIG1lYXQgb2YgaXQuIEluIGNhc2UgeW91IGhhdmVu4oCZdCBsb29r ZWQgYXQgUkZDIDkwMDPigJlzIHNlY3VyaXR5IHNlY3Rpb24sIGhlcmXigJlzIGEgc25pcCBmcm9t IGl0Og0KPj4gDQo+PiAgICBBcyBCR1AgU2h1dGRvd24gQ29tbXVuaWNhdGlvbnMgYXJlIGxpa2Vs eSB0byBhcHBlYXIgaW4gc3lzbG9nIG91dHB1dCwNCj4+ICAgIHRoZXJlIGlzIGEgcmlzayB0aGF0 IGNhcmVmdWxseSBjb25zdHJ1Y3RlZCBTaHV0ZG93biBDb21tdW5pY2F0aW9uDQo+PiAgICBtaWdo dCBiZSBmb3JtYXR0ZWQgYnkgcmVjZWl2aW5nIHN5c3RlbXMgaW4gYSB3YXkgdG8gbWFrZSB0aGVt IGFwcGVhcg0KPj4gICAgYXMgYWRkaXRpb25hbCBzeXNsb2cgbWVzc2FnZXMuIA0KPj4gDQo+PiAo RldJVywgSSBkaWRu4oCZdCBjb250cmlidXRlIHRoYXQgdGV4dC4pDQo+PiANCj4+IFBsZWFzZSBk b27igJl0IG9ic2VzcyBhYm91dCDigJxzeXNsb2figJ0gaW4gdGhlIGV4YW1wbGUgYWJvdmUsIGl0 4oCZcyBub3QgY2VudHJhbCB0byB0aGUgcG9pbnQsIGp1c3QgbGlrZSBVVEYtOCB2cyBBU0NJSSBp c27igJl0IGNlbnRyYWwuIFRoZSBwb2ludCwgYWdhaW4sIGlzIHRoYXQgYnkgaW50cm9kdWNpbmcg YSB3YXkgZm9yIGFuIGF0dGFja2VyIHRvIGNhdXNlIGEgdGFyZ2V0IHN5c3RlbSB0byBkaXNwbGF5 IGFyYml0cmFyeSBzdHJpbmdzLCBpdCB3b3VsZCBzZWVtIHJlYXNvbmFibGUgdG8gd29uZGVyIGlm IHRoYXQgY3JlYXRlcyBhbiBvcHBvcnR1bml0eSBmb3IgbWlzY2hpZWYgdGhhdCBkb2VzbuKAmXQg b3JkaW5hcmlseSBleGlzdCBpbiBvdXIgcHJvdG9jb2xzLCBpbnZvbHZpbmcgbWlzbGVhZGluZyBw ZW9wbGUgbG9va2luZyBhdCB0aGUgZGlzcGxheWVkIHN0cmluZyBpbiBhIHVzZXIgaW50ZXJmYWNl Lg0KPj4gDQo+PiBUaGVyZSBhcmUgdmFyaW91cyB3YXlzIHRoaXMgY29uY2VybiBjb3VsZCBiZSBt aXRpZ2F0ZWQgKGlmIHdlIHdlcmUgdG8gY29tZSB0byBhZ3JlZW1lbnQgdGhhdCBpdOKAmXMgZXZl biBhIGNvbmNlcm4pLiBPbmUgd291bGQgYmUgdG8gcmVtb3ZlIHRoZSDigJxzaWduYWwgYXJiaXRy YXJ5IHN0cmluZ3PigJ0gaWRlYTsgdGhpcyBpcyBjbGVhcmx5IHRoZSBzb2xpZGVzdCB3YXkgdG8g ZG8gaXQuIEFub3RoZXIgd291bGQgYmUgdG8gbWFuZGF0ZSAob3Igc3Ryb25nbHkgc3VnZ2VzdCkg dGhhdCBzeW1ib2xpYyBuYW1lcyBnbGVhbmVkIGZyb20gc29tZXRoaW5nIG90aGVyIHRoYW4gY29u ZmlndXJhdGlvbiBiZSBkaXNwbGF5ZWQgaW4gc3VjaCBhIHdheSBhcyB0byBtYWtlIHRoZSBvcGVy YXRvciBhd2FyZSBvZiB0aGVpciBzdGF0dXMuIEF0IGEgbWluaW11bSwgb25lIG1pZ2h0IGFkZCBh IHBhcmFncmFwaCBvciB0d28gaWRlbnRpZnlpbmcgdGhlIGNvbmNlcm4uIEnigJltIHN1cmUgdGhl cmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGNvbnRlbXBsYXRlZC4NCj4+IA0KPj4g UmVnYXJkcywNCj4+IA0KPj4g4oCUSm9obg0KPiANCg== From nobody Tue Mar 22 11:10:32 2022 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 65A693A0E16; Tue, 22 Mar 2022 11:10:12 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164797261227.30711.1685188707217488588@ietfa.amsl.com> Date: Tue, 22 Mar 2022 11:10:12 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-22.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, 22 Mar 2022 18:10:15 -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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-22.txt Pages : 41 Date : 2022-03-22 Abstract: Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into a SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC8402 as it details the concepts of SR Policy and steering into an SR Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-22 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Mar 22 11:12:03 2022 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 DF4603A0E16; Tue, 22 Mar 2022 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_SCC_BODY_TEXT_LINE=-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 2-nU02jHqrGh; Tue, 22 Mar 2022 11:11:56 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 B46173A0990; Tue, 22 Mar 2022 11:11:55 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id w189so1523780vke.10; Tue, 22 Mar 2022 11:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9a1zv9LdyZ73tP+wugpqh+W7/Yg+UwVJ2Wo7fsRK7Gg=; b=et69ROcN9GYw/GsoNHnvOng5cTKTd9cI/FLPBUbnDMReBbgnwZwg99iRahEw/ahL1g PC+g3hOHOFoR7fUZrTopph3ABb/WYDNTVIwoLrPDhyjI4+558Rb2UZqJP04DgWSuTKk1 UZvl+HnIvB5ZvrNE98POpeEAjPxUHu150G1JOc6UmKWhJpyn+Odf8i1cskaRdC8Z9v8L ybdRFKR3OXFd/HjCtvLo/rUyvjicn+V/+4XtkV5EAMn70k8NEDZNEvPxQa5dctknxdVB n/z46lbpfD2bNvrFGcY/piTNB4TZ7zccvHShQRpasmdlyzap2RVFuyTdVi3QqGyC6AvX TMeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9a1zv9LdyZ73tP+wugpqh+W7/Yg+UwVJ2Wo7fsRK7Gg=; b=DFIjf3De9iGWh1q8Bb+xlSKVALXIQMuWmSkpilG0ovkF0RxD3m9pvjVJqHHYdUC0BS e6RqaVgXXSyqnbOQz0qxgsv+G9Y5auRR4Pnwls6Oe1FYI9lUwKKjU/z+U/9aMasnXOAe sZuXqpLUWVqPp3bMzJNJo3p7PVKXxQj1zuHHdb9GiodEuiP9nvZaCFYKndCv3Dj111Ra ENgz6yB/h3tHT0USvRAtjRQjx8RwRtON3uPwU//YwXciP2z6ovsyabp1WXvPNHJchrnF AK0AKA4ySmtyiCnuBwquW3td/OloRYDydLmtFtaEd2xkk2awWIiEDHQ3vEJ+BV7q0IMD tMVQ== X-Gm-Message-State: AOAM530Eamx6ak34Z+hknO+RgpRvbITcyquOggD2kI4ov5wYoiplgZq+ BnjBtxj6ldsnlbP8wtg9f7YH6cNJn2rES1fQmIE= X-Google-Smtp-Source: ABdhPJzeYO6jre4u6gMWmts6ewQR/ko7LU3vlCamrolHJlxCD2A+L6xfNAD2VEtRuvPnqXm6zGJemdbFruc/TT+eJ3w= X-Received: by 2002:a05:6122:a14:b0:33f:59e8:28f3 with SMTP id 20-20020a0561220a1400b0033f59e828f3mr2088897vkn.2.1647972714131; Tue, 22 Mar 2022 11:11:54 -0700 (PDT) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> <6E8C015A-C0AE-4775-9B49-09F7DA40B9B2@juniper.net> In-Reply-To: <6E8C015A-C0AE-4775-9B49-09F7DA40B9B2@juniper.net> From: Ketan Talaulikar Date: Tue, 22 Mar 2022 23:41:42 +0530 Message-ID: To: John Scudder Cc: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="00000000000039b71c05dad28cd6" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 22 Mar 2022 18:12:01 -0000 --00000000000039b71c05dad28cd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for your guidance with the text. Very much appreciated - especially in the middle of the busy IETF week. I've just posted an update to the draft with slight modifications to your text (so as to cover both sec 2.1 and 2.6 and suggest the use of the well-defined identifiers as a mitigation approach instead of relying solely on the symbolic names. https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-pol= icy-22 Please let us know if this addresses your concerns. Thanks, Ketan On Tue, Mar 22, 2022 at 11:20 PM John Scudder wrote: > Hi Ketan, > > Thanks as always for your quick reply. > > > On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar > wrote: > > > > > > Hi John, > > > > I dug into my emails and you are right that while we had a discussion o= n > point 4 (i.e. security considerations associated with the use of symbolic > names), it was not concluded. My apologies for the same. > > > > It might be helpful to place a context on why the draft uses symbolic > names in the first place. The closest analogies that come to my mind are > tunnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). > These constructs have had symbolic names associated with them for a long > time now - both for local use on routers (some implementation-specific - > others specified by IETF) > > Sure. Anything local to the router isn=E2=80=99t related to my concern, w= hich is > specific to the opportunity for a remote attacker to mislead someone on t= he > local router. I hope it=E2=80=99s clear by now that I have no issue with > associating a symbolic name with a SR Policy (or any other thing), as suc= h. > > > and also signaled via routing protocols. > > Now that you point it out, I do see a few such, e.g. the > SYMBOLIC-PATH-NAME in RFC 8231. That particular example has arguably > different threat properties since the relationship between a PCE and its > clients isn=E2=80=99t mediated through other routers; the trust relations= hip is > clearer and the =E2=80=9Cremote attacker=E2=80=9D is not so very remote. = But I imagine > there are other examples to be found, and I don=E2=80=99t want to split h= airs on > this detail. > > > Operators are therefore quite familiar with their usage and hence their > introduction in the SR Policy construct. I don't believe the WG would wan= t > to take the option of their removal (it was a suggested option). > > I didn=E2=80=99t really expect you to; I was just laying out some points = in the > solution space. > > > Then we get to option of adding specific text to the draft (in the > security considerations?) that would discuss your concerns. Such text may > be addressed to implementators and/or operators. As mentioned above, the > use of symbolic names for constructs similar to SR Policy name and SR > Policy Candidate Path name is not "new" for both sets of readers. > Therefore, I am not sure if we need to cover or add anything new in this > document and I could not find text that I could borrow from other RFCs or > point to other RFCs. e.g., > https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2 > > > > I did look at RFC9003 but its context is very different. From your > DISCUSS comment, I see that your concern is that a string does not have a= ny > sanity checking - the operator is free to use any text. > > Correct. As long as you assume good will on the part of =E2=80=9Cthe oper= ator=E2=80=9D > it=E2=80=99s all good. If you start thinking in terms of an attacker in s= ome > distant part of the network injecting a policy, it becomes potentially > concerning. > > > I agree. Do we want implementations to restrict something? Do we want t= o > give some naming guidelines or precautions to the operators? > > I don=E2=80=99t think the concern is addressable on the origination side,= since it > assumes a bad actor to begin with, and they=E2=80=99re not going to be bo= thered by > what we write in an RFC. That was why in my suggestion I was thinking in > terms of display conventions. I=E2=80=99m not super excited by my own ide= a, though, > because it reminds me uncomfortably much of the disclaimer my IT departme= nt > slaps on every incoming email, =E2=80=9C[External Email. Be cautious of c= ontent]=E2=80=9D. > It=E2=80=99s not particularly actionable, and it=E2=80=99s annoying. :-( > > > In a previous response, your suggestions for the text for operators wer= e > (somewhat?) of the nature - "beware the name of the SR Policy may not > actually be correct or may be misleading because someone might have hacke= d > into the network". I am not sure if something of that nature helps. If th= e > names stop being meaningful then they are no more relevant? Isn't the > security aspect to be taken care of here is to prevent hacking? Something > beyond the scope of this draft? > > =E2=80=9CSecurity is everyone=E2=80=99s responsiblity.=E2=80=9D > > > I'll admit that I am running out of ideas on what would be a meaningful > text to add to address your concerns. Would appreciate some text suggesti= on > that is relevant to this specific context. > > In the end, maybe it=E2=80=99s true that there=E2=80=99s not much to be d= one, which sucks, > but that=E2=80=99s life. But even if we throw our hands in the air and sa= y =E2=80=9Cnothing > to be done=E2=80=9D, which is I think where we=E2=80=99re getting to, I d= on=E2=80=99t think there > would be any harm in putting a sentence or two in the Security > Considerations such as you mention just above. Something along the lines = of, > > =E2=80=9CIn Section 2.1 we mention that a symbolic name MAY be signaled a= long with > a candidate path. While the value of symbolic names for display clarity i= s > indisputable, as with any unrestricted freeform text received from extern= al > parties, there can be no absolute assurance that the information the text > purports to show is accurate or even truthful. For this reason, users of > implementations that display such information would be well-advised not t= o > rely on it without question. Furthermore, implementations that display su= ch > information might wish to display it in such a fashion as to differentiat= e > it from known-good information. (Such display conventions are inherently > implementation-specific; one example might be use of a distinguished text > color or style for information that should be treated with caution.)=E2= =80=9D > > Let=E2=80=99s be honest, the =E2=80=9Coooh be careful=E2=80=9D text provi= des about as much > protection as wet tissue paper, and displaying the string in magenta not = a > whole lot more than that =E2=80=94 but it=E2=80=99s still better to discl= ose the cocnern > than not to. > > Regards, > > =E2=80=94John > > > Thanks, > > Ketan > > > > On Tue, Mar 22, 2022 at 2:54 AM John Scudder wrote: > >> Hi Ketan, > >> > >> You asked "whether the responses and draft updates address [my] > concerns=E2=80=9D. I=E2=80=99d say that while I=E2=80=99m not completely = happy about certain things > (e.g., I remain unconvinced that the companion IDR doc shouldn=E2=80=99t = be a > normative reference) I don=E2=80=99t need to continue holding a DISCUSS o= n them: > we=E2=80=99ve had a discussion, we don=E2=80=99t completely agree, these = things happen. On > point 4 however, I don=E2=80=99t think our discussion has concluded. At l= east, if > you replied to this, I missed it: > >> > >> > On Feb 16, 2022, at 2:42 PM, John Scudder 40juniper.net@dmarc.ietf.org> wrote: > >> > > >> >> 4. In =C2=A72.1 you talk about the signaling of symbolic names for > candidate paths. > >> >> Although you are careful to say that such symbolic names are only > used for > >> >> presentation purposes, it seems to me they still could be considere= d > a new > >> >> potential source of vulnerability, since a string that has no > sanity-checking > >> >> whatsoever applied by the protocol can display literally anything t= o > an > >> >> operator viewing it. Shouldn=E2=80=99t this be addressed in your Se= curity > >> >> Considerations? (For an example of a related Security > Considerations, see RFC > >> >> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s = the one I had at > my > >> >> fingertips=E2=80=A6) > >> >> > >> >> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As > such, I am not aware of security issues around printable ASCII - please d= o > point me to any references. > >> > > >> > You=E2=80=99re thinking too much like a protocol designer. The kind = of > concern I=E2=80=99m thinking about has to do with using the string as a v= ector to > put some words in front of an operator, as part of a larger social > engineering attempt. I don=E2=80=99t have a detailed attack scenario to p= aint for > you, but a quick sketch is along the lines of > >> > > >> > - Attacker manages to inject a candidate path with the name > =E2=80=9CBig_Bank_Low_Latency=E2=80=9D > >> > - ProTip: the candidate path does not actually terminate at Big_Bank > >> > - Attacker then phones NOC, feigns urgency, asks NOC to redirect > Big_Bank traffic onto that path > >> > > >> > You get the idea, I hope. > >> > >> More snipped, but this is the meat of it. In case you haven=E2=80=99t = looked at > RFC 9003=E2=80=99s security section, here=E2=80=99s a snip from it: > >> > >> As BGP Shutdown Communications are likely to appear in syslog outpu= t, > >> there is a risk that carefully constructed Shutdown Communication > >> might be formatted by receiving systems in a way to make them appea= r > >> as additional syslog messages. > >> > >> (FWIW, I didn=E2=80=99t contribute that text.) > >> > >> Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the exam= ple above, it=E2=80=99s not > central to the point, just like UTF-8 vs ASCII isn=E2=80=99t central. The= point, > again, is that by introducing a way for an attacker to cause a target > system to display arbitrary strings, it would seem reasonable to wonder i= f > that creates an opportunity for mischief that doesn=E2=80=99t ordinarily = exist in > our protocols, involving misleading people looking at the displayed strin= g > in a user interface. > >> > >> There are various ways this concern could be mitigated (if we were to > come to agreement that it=E2=80=99s even a concern). One would be to remo= ve the > =E2=80=9Csignal arbitrary strings=E2=80=9D idea; this is clearly the soli= dest way to do it. > Another would be to mandate (or strongly suggest) that symbolic names > gleaned from something other than configuration be displayed in such a wa= y > as to make the operator aware of their status. At a minimum, one might ad= d > a paragraph or two identifying the concern. I=E2=80=99m sure there are ot= her things > that could be contemplated. > >> > >> Regards, > >> > >> =E2=80=94John > > > --00000000000039b71c05dad28cd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

Thanks for your guidance with = the text. Very much appreciated - especially in the middle of the busy IETF= week.

I've just posted an update to the draft= with slight modifications to your text (so as to cover both sec 2.1 and 2.= 6 and suggest the use of the well-defined identifiers as a mitigation appro= ach instead of relying solely on the symbolic names.

https://datatrac= ker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22

Please let us know if this addresses your concerns.=

Thanks,
Ketan


On Tu= e, Mar 22, 2022 at 11:20 PM John Scudder <jgs@juniper.net> wrote:
Hi Ketan,

Thanks as always for your quick reply.

> On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:=
>
>
> Hi John,
>
> I dug into my emails and you are right that while we had a discussion = on point 4 (i.e. security considerations associated with the use of symboli= c names), it was not concluded. My apologies for the same.
>
> It might be helpful to place a context on why the draft uses symbolic = names in the first place. The closest analogies that come to my mind are tu= nnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These= constructs have had symbolic names associated with them for a long time no= w - both for local use on routers (some implementation-specific - others sp= ecified by IETF)

Sure. Anything local to the router isn=E2=80=99t related to my concern, whi= ch is specific to the opportunity for a remote attacker to mislead someone = on the local router. I hope it=E2=80=99s clear by now that I have no issue = with associating a symbolic name with a SR Policy (or any other thing), as = such.

> and also signaled via routing protocols.

Now that you point it out, I do see a few such, e.g. the SYMBOLIC-PATH-NAME= in RFC 8231. That particular example has arguably different threat propert= ies since the relationship between a PCE and its clients isn=E2=80=99t medi= ated through other routers; the trust relationship is clearer and the =E2= =80=9Cremote attacker=E2=80=9D is not so very remote. But I imagine there a= re other examples to be found, and I don=E2=80=99t want to split hairs on t= his detail.

> Operators are therefore quite familiar with their usage and hence thei= r introduction in the SR Policy construct. I don't believe the WG would= want to take the option of their removal (it was a suggested option).

I didn=E2=80=99t really expect you to; I was just laying out some points in= the solution space.

> Then we get to option of adding specific text to the draft (in the sec= urity considerations?) that would discuss your concerns. Such text may be a= ddressed to implementators and/or operators. As mentioned above, the use of= symbolic names for constructs similar to SR Policy name and SR Policy Cand= idate Path name is not "new" for both sets of readers. Therefore,= I am not sure if we need to cover or add anything new in this document and= I could not find text that I could borrow from other RFCs or point to othe= r RFCs. e.g., https://www.rfc-editor.org/rf= c/rfc8231.html#section-7.3.2
>
> I did look at RFC9003 but its context is very different. From your DIS= CUSS comment, I see that your concern is that a string does not have any sa= nity checking - the operator is free to use any text.

Correct. As long as you assume good will on the part of =E2=80=9Cthe operat= or=E2=80=9D it=E2=80=99s all good. If you start thinking in terms of an att= acker in some distant part of the network injecting a policy, it becomes po= tentially concerning.

> I agree. Do we want implementations to restrict something? Do we want = to give some naming guidelines or precautions to the operators?

I don=E2=80=99t think the concern is addressable on the origination side, s= ince it assumes a bad actor to begin with, and they=E2=80=99re not going to= be bothered by what we write in an RFC. That was why in my suggestion I wa= s thinking in terms of display conventions. I=E2=80=99m not super excited b= y my own idea, though, because it reminds me uncomfortably much of the disc= laimer my IT department slaps on every incoming email, =E2=80=9C[External E= mail. Be cautious of content]=E2=80=9D. It=E2=80=99s not particularly actio= nable, and it=E2=80=99s annoying. :-(

> In a previous response, your suggestions for the text for operators we= re (somewhat?) of the nature - "beware the name of the SR Policy may n= ot actually be correct or may be misleading because someone might have hack= ed into the network". I am not sure if something of that nature helps.= If the names stop being meaningful then they are no more relevant? Isn'= ;t the security aspect to be taken care of here is to prevent hacking? Some= thing beyond the scope of this draft?

=E2=80=9CSecurity is everyone=E2=80=99s responsiblity.=E2=80=9D

> I'll admit that I am running out of ideas on what would be a meani= ngful text to add to address your concerns. Would appreciate some text sugg= estion that is relevant to this specific context.

In the end, maybe it=E2=80=99s true that there=E2=80=99s not much to be don= e, which sucks, but that=E2=80=99s life. But even if we throw our hands in = the air and say =E2=80=9Cnothing to be done=E2=80=9D, which is I think wher= e we=E2=80=99re getting to, I don=E2=80=99t think there would be any harm i= n putting a sentence or two in the Security Considerations such as you ment= ion just above. Something along the lines of,

=E2=80=9CIn Section 2.1 we mention that a symbolic name MAY be signaled alo= ng with a candidate path. While the value of symbolic names for display cla= rity is indisputable, as with any unrestricted freeform text received from = external parties, there can be no absolute assurance that the information t= he text purports to show is accurate or even truthful. For this reason, use= rs of implementations that display such information would be well-advised n= ot to rely on it without question. Furthermore, implementations that displa= y such information might wish to display it in such a fashion as to differe= ntiate it from known-good information. (Such display conventions are inhere= ntly implementation-specific; one example might be use of a distinguished t= ext color or style for information that should be treated with caution.)=E2= =80=9D

Let=E2=80=99s be honest, the =E2=80=9Coooh be careful=E2=80=9D text provide= s about as much protection as wet tissue paper, and displaying the string i= n magenta not a whole lot more than that =E2=80=94 but it=E2=80=99s still b= etter to disclose the cocnern than not to.

Regards,

=E2=80=94John

> Thanks,
> Ketan
>
> On Tue, Mar 22, 2022 at 2:54 AM John Scudder <jgs@juniper.net> wrote:
>> Hi Ketan,
>>
>> You asked "whether the responses and draft updates address [m= y] concerns=E2=80=9D. I=E2=80=99d say that while I=E2=80=99m not completely= happy about certain things (e.g., I remain unconvinced that the companion = IDR doc shouldn=E2=80=99t be a normative reference) I don=E2=80=99t need to= continue holding a DISCUSS on them: we=E2=80=99ve had a discussion, we don= =E2=80=99t completely agree, these things happen. On point 4 however, I don= =E2=80=99t think our discussion has concluded. At least, if you replied to = this, I missed it:
>>
>> > On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=3D40juniper.net@dm= arc.ietf.org> wrote:
>> >
>> >> 4. In =C2=A72.1 you talk about the signaling of symbolic = names for candidate paths.
>> >> Although you are careful to say that such symbolic names = are only used for
>> >> presentation purposes, it seems to me they still could be= considered a new
>> >> potential source of vulnerability, since a string that ha= s no sanity-checking
>> >> whatsoever applied by the protocol can display literally = anything to an
>> >> operator viewing it. Shouldn=E2=80=99t this be addressed = in your Security
>> >> Considerations? (For an example of a related Security Con= siderations, see RFC
>> >> 9003. It=E2=80=99s probably not the best example, but it= =E2=80=99s the one I had at my
>> >> fingertips=E2=80=A6)
>> >>
>> >> KT> RFC9003 uses UTF-8 while this document uses printa= ble ASCII. As such, I am not aware of security issues around printable ASCI= I - please do point me to any references.
>> >
>> > You=E2=80=99re thinking too much like a protocol designer. Th= e kind of concern I=E2=80=99m thinking about has to do with using the strin= g as a vector to put some words in front of an operator, as part of a large= r social engineering attempt. I don=E2=80=99t have a detailed attack scenar= io to paint for you, but a quick sketch is along the lines of
>> >
>> > - Attacker manages to inject a candidate path with the name = =E2=80=9CBig_Bank_Low_Latency=E2=80=9D
>> > - ProTip: the candidate path does not actually terminate at B= ig_Bank
>> > - Attacker then phones NOC, feigns urgency, asks NOC to redir= ect Big_Bank traffic onto that path
>> >
>> > You get the idea, I hope.
>>
>> More snipped, but this is the meat of it. In case you haven=E2=80= =99t looked at RFC 9003=E2=80=99s security section, here=E2=80=99s a snip f= rom it:
>>
>>=C2=A0 =C2=A0 As BGP Shutdown Communications are likely to appear i= n syslog output,
>>=C2=A0 =C2=A0 there is a risk that carefully constructed Shutdown C= ommunication
>>=C2=A0 =C2=A0 might be formatted by receiving systems in a way to m= ake them appear
>>=C2=A0 =C2=A0 as additional syslog messages.
>>
>> (FWIW, I didn=E2=80=99t contribute that text.)
>>
>> Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the = example above, it=E2=80=99s not central to the point, just like UTF-8 vs AS= CII isn=E2=80=99t central. The point, again, is that by introducing a way f= or an attacker to cause a target system to display arbitrary strings, it wo= uld seem reasonable to wonder if that creates an opportunity for mischief t= hat doesn=E2=80=99t ordinarily exist in our protocols, involving misleading= people looking at the displayed string in a user interface.
>>
>> There are various ways this concern could be mitigated (if we were= to come to agreement that it=E2=80=99s even a concern). One would be to re= move the =E2=80=9Csignal arbitrary strings=E2=80=9D idea; this is clearly t= he solidest way to do it. Another would be to mandate (or strongly suggest)= that symbolic names gleaned from something other than configuration be dis= played in such a way as to make the operator aware of their status. At a mi= nimum, one might add a paragraph or two identifying the concern. I=E2=80=99= m sure there are other things that could be contemplated.
>>
>> Regards,
>>
>> =E2=80=94John
>
--00000000000039b71c05dad28cd6-- From nobody Tue Mar 22 11:21:19 2022 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 9CA923A0AD9; Tue, 22 Mar 2022 11:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=juniper.net header.b=XNHub53V; dkim=pass (1024-bit key) header.d=juniper.net header.b=g/7e9UIB 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 gvoWl3iIpdwq; Tue, 22 Mar 2022 11:21:06 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 087A83A0EFA; Tue, 22 Mar 2022 11:21:02 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22MDsnJG027704; Tue, 22 Mar 2022 11:20:59 -0700 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=NH+RNVLNi2uF416z/aTqHt0fUt2Fav2SX1jrchex6qc=; b=XNHub53VBQdu659b6syomImu2BP9WIwUmy2QX3AwpdDMTgMoUnZr/nm4eJVitkDvGwzg PzNzwZue7nQyJgFQ4xIbAWAxsWrXDX/eDKLx15213vXtpjzTsh33F+txUsD39RWVAIsW U16UBJmCJJf7wB/VQMixPh9jqyL1CsKzoItRx6aTlHq4i8Lsof9BcjFSoj9TP7t28DAk acn96UI3bDbe2MCGWPckHmy58JIefA53KLGSmRszD26FM7ho4MZr3evtVZ+IoCYLHiIB 3IhMqG/WH+fftEu1EgsNld3uHdTTfnXsFLQY7Ix875DAIEPC/FB2Gt8KI8Y/+YbMg48J Nw== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2176.outbound.protection.outlook.com [104.47.55.176]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3eyfrqgs68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Mar 2022 11:20:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EY8mRVkNsJLUdTRyb9xeYcQYiAaMH4PJiij4eWzM3CopA2SfqBHkiuARFiCCDeAyaQDxKZQp/XHkblxFoZBenZEjNHm1/RtfG2RYVHPS3d6vYD/ciz4fqtN9kZXXy4oQWj2w8hvSy/kAzelO0GwM9e8w62AzsfJZJ0OZ2Rv0eYP4cCCGCcQoexPPpTbk5xBnTTz2oWf4+UkKT7vMjHLYm0wB2T7AXM4b4N8RHd7REGh2KK+Xnd13Cm7S2Fj1TGqiObHK/wCcIttsduyGF1/aYiWKVPPYm/V0cMqjgdgPNDjTLftTQ7miPRR5ofOEfig3RDLU88lUYNfDMsC9CaGO+g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NH+RNVLNi2uF416z/aTqHt0fUt2Fav2SX1jrchex6qc=; b=fjORABFk1RyTG1BUzBQ+12/SUywPmSWMFdy8Dojo+gw46RDc5r2BOHC+45Ef4Ptxl8tq8CFpEkBPsv7nVSZTIzt4b9zi/vcV79AFykJ7gGxLYlpPyVPpmuEtk313qSdGAzSsv5oQvisp8EREtwMlPfW/+Wu7jbNqk50+tsgUlCFgRYwc79qURvKdArxoo1Q5LUIWZuNn8K1kCBCBAHpkYmzFEpA8BilgZcw2j8QqZbnn/ZpBw5oGb2sOAXfF+E1WYHthacQSPeppXdnR2GMPpVxhbx6sauxQ0as8sERfBnQsOW1yy0jeTPDYPixAwrfjIx1xBOBpCBa7l//7/L06ug== 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=NH+RNVLNi2uF416z/aTqHt0fUt2Fav2SX1jrchex6qc=; b=g/7e9UIBQ+pmBdf8bA7FygvJFON5FAZZDUh181qnNRBkUrueonne19/IZfz2+JdzxYAcuPfILualkFX5V9TpYjhKeUdYcVzlaKWMM7aHFPS2BrYWk3QRxX0Kg0tc4+KMV304ORBkrjKKwY0pn/h0PmoOVE7Ah9tD/9PbIZEK1oE= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by DM5PR05MB3340.namprd05.prod.outlook.com (2603:10b6:4:46::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.16; Tue, 22 Mar 2022 18:20:57 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::8cd3:9859:9c55:6eb8]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::8cd3:9859:9c55:6eb8%5]) with mapi id 15.20.5102.016; Tue, 22 Mar 2022 18:20:57 +0000 From: John Scudder To: Ketan Talaulikar CC: "james.n.guichard@futurewei.com" , "draft-ietf-spring-segment-routing-policy@ietf.org" , SPRING WG , "spring-chairs@ietf.org" , The IESG Thread-Topic: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT) Thread-Index: AQHYI1ajQRbh7M614068Bbz53eGtPayWiSeAgAAKsYCAM/mVgIAAwNgAgACVrwCAAAXvAIAAApQA Date: Tue, 22 Mar 2022 18:20:57 +0000 Message-ID: References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> <6E8C015A-C0AE-4775-9B49-09F7DA40B9B2@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3696.80.82.1.1) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 787ee9a8-f62e-4556-aaec-08da0c30b5ca x-ms-traffictypediagnostic: DM5PR05MB3340:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OReK38AarEmmrWi+9D5XtH0SyHid3Ya3/EcL1lkzAxg69NwVANBmJNrg8TSHPToczkcGRR0qjA1PFlBlhJ1rEQqARLKq5MiQSQjwp2Sk5wmE5+UVK3HrVJVQmFSdV7l7hnr1FkHTe5ry9/GsT4C/lYpQqdZcJ5I3XXHXOiq8wX7oScgn5oTPVizvGzF7bBhuSkeXfnSchQKQIAtvq16tmRnky8F9mqfHaTWikTzcS278Ye4YDXWmyUTdmaPlEjE2MfnVkkNVSGGCBQZZr9ZoCUY4DCrzKJijg61Q49cas2ijQhrXEKdLBA2MG4Z9uNokSYSDpTwn+AlvyPylInRslCJWiKuGYzFQnSi9qY2Nij/SgPIzKpXnUyNDvuewoUcQki3q70xNbDVifaMD4z8GY4S7YLo/HxiUIb24u3Td8fsWQiRFFJ4aB/Ro8ELAgdTr3Y+FZ5LYq1LqhEe3JalTFrR3ogzDEFNAvm8QZiGVjdTf25moeAMkzTxcuuncTHgk9l9bo7j6THWriSKUk/3SQXZARS8/KOBBqkk62MFMkDo/8dT9HT7Upkdj0zF5gNXiF4lbio0NEnzQsiC2Grl7FgOMphxQHpoCz73N4Zi+C1k+sm+hxudQyUdJ0VRXd59opBPZxQXzolPt64FiVBPAs8pBUqufL/q/FEJYCDgr80q2XHgGKcCDEGH+ld694s4y+SJSn+sy1wMRy1cX5yYZEwamOJpPmaM7ouZGCKxBVuj3lieDwEsmHqaby24b9w6j820qFkQ8jhIEB9pKIBGwtjN/N0GBz4ok2VQz0Zm8F83qq/v21cLBOLtK7hMAHbWUbltWY5XhXKtns0WplAPbM4BuzUVP2cOOHFnNXxjcly64TUE5xtCKNvavowUtSVK8z17CFEKt6gG/lWhPHyO61A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(8936002)(6486002)(966005)(6512007)(2616005)(91956017)(71200400001)(316002)(5660300002)(54906003)(6916009)(508600001)(4326008)(53546011)(6506007)(8676002)(38070700005)(76116006)(66556008)(66446008)(66946007)(86362001)(38100700002)(66476007)(64756008)(83380400001)(66574015)(186003)(36756003)(122000001)(2906002)(166002)(33656002)(26005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?a01PUnU0VHJ1ZC9CU0VqNTQ0VnhUMDd0NW80T2FuVEQvNjNqTXdHNjBoNlpm?= =?utf-8?B?TjRMaDFQb21pR1cyN3I0VGczbGhJRkFqL2pBWE14RUFoaWM0WDdFYnBOMjFY?= =?utf-8?B?aC9ZdzZhOHpzVDBFS0NQMUQ2TGFVZWloQWZUR0V6ZkczK1BFa1JTalNjSEFh?= =?utf-8?B?dnBkRlRLZzNFQldyWi9EUWRQOWlXNnhMdUNtd1lQWmZvaG4xOVFTMXlhNiti?= =?utf-8?B?di9iUFUyMGpkY1RxN3d1UVdnWVRtL1A3ZGcrMFRMc3FzTFRCcGRVV2xWM2ND?= =?utf-8?B?VkIrM3BkajdjY3lxQTAvODgwOWx1ODFWaEgwNGE4QlNBV1c3WHBVY0doYW51?= =?utf-8?B?d0MvT1JNSHFiQnQwbnppTVBZR210K0pWcVl1WXIwb2luNkE2emZnYVdKbnRu?= =?utf-8?B?WWpCT1NpR1VPdUdZdlRaaWxVb3FmUjMyczI3ZW5ySXVsbExhenJhMzJENjFC?= =?utf-8?B?VHBtUTZMZWo3Q3d6b1BhUEdxbFZEZDV3NnlOQmF1K3puc2R3ZTRTWmJqbFA1?= =?utf-8?B?cmRaY25WQnlRSEtmRXRjcktoempCZ3pTWXRIVTArSUdKUXNlYTh0Y1VuZ05V?= =?utf-8?B?NWtqY045UUxHeVZVb1JYN3RPZVdyT29BV3JtMGZWdjdhaExDLzMzY1FES2c2?= =?utf-8?B?cjIvTjBXd05Gc1VybnVpdC94MEQyL1U5UmdJZ3B1MlhDS3ZudytDNkVhODVx?= =?utf-8?B?b1pJZ1JtSUhkODh3Z2tqVWV4eU05TmZ4MGJ6NCtjcFlrTTc1OGk5aGs2dmJl?= =?utf-8?B?RWcvQnJBSWJaYUFTYU83cEtja04veFRkMG5vWThKQ01zUkxlenR4NTNiMjZ0?= =?utf-8?B?R0gzS25zaTJlNld0aTBJWXZRZTJGZmV5WlIzMytTaFQ4N2UvMkFDd015dlE3?= =?utf-8?B?cTJpcGJ0TDU0dHhQU1VoOXBITmxSalJ3NitVNHNmZC84d3pYV08vdlFneXln?= =?utf-8?B?a25zS2daWlVGUFNpbkVxUzVLdzc3aEswNElTallGTy9nSW0zcTNKMkF6aDcv?= =?utf-8?B?a2ZoTEUva29qOGJjOEszYXdOTEpvRkNleTZZclljNXAzelFYWkNsbERabVZH?= =?utf-8?B?YXQ5WlQ5d3lsSHRvZmx1Y2gxaWQ4OUVVUXpvRGtwUlpKdFZCOUFqRDlqemNB?= =?utf-8?B?bEJtL0crejljWTZIdzRtN1BXUXlPK1VRQUV5OEx3K0hpeWhPR2lKUVNDcVVY?= =?utf-8?B?NGdPNnNHVnVvODluVXg0N0l2Unh3MUZpMG92S21pWTZPWlhENGtmK0l3eVFU?= =?utf-8?B?cklKcnA5ZWdZQWh1L2dNelV6L2UvdjhCYUp2WEVSVzlpQkFWRS81MWcyeHdi?= =?utf-8?B?NXpFR1g1d1dVbXBmSWtMVldsOERISEgwaENoMFY4aFBFcmtJRDMvNXJPT2Js?= =?utf-8?B?YVR4TnVkWDJYeDVaZ3JRRHFUR1kwbG1SRWJ2N0F0RVhmK3MzREF1VlVDVDlC?= =?utf-8?B?dGsxbXlwMnlyZEc2OGw5YVFkYmhEcGtWWkgzcHZZRlVHVXpmZGVHRVJuQVZ2?= =?utf-8?B?ck50QWk5OW5nSUdqUUdVL3dTWGxWQ2pqN3ZWdThheVZGQnVFL09xTDAxWDFD?= =?utf-8?B?RVFEY0ZQTTN5L2sramx6RnMwc0lrcmtCc2dJUkQ4TWlHM2w2T3l5Vk5LT01a?= =?utf-8?B?YU9zdUxxSmhuTHNoc0dFdm9UWHR2N1NyeERrTnJPeHlOZjhmZUI3eVROWHFI?= =?utf-8?B?d1h2M25FS3hmUFhjZkdmQmlsbVB5NDMvODI0REI2cWpoMG5zTGF5QVdMUFB1?= =?utf-8?B?V05ZZVdraXhZZnVLbWkzNjRqbXVZVXVTRU1IUmFFSE1ySkM4UmxYaXI5WUh2?= =?utf-8?B?a25UU0VBU3dyaGFTK0Vnc0ZoUzF2VWp3VStiN3FBaUJMUDA1K0xYVjNlTlRi?= =?utf-8?B?UnNFalgxYVJRMTJidGw2dDBwd0JROXNGU2gxaUZZMG41cFFCV0NNM0o3NHBB?= =?utf-8?B?QTZlZE1ZM2toWGpUM0R6U21VZ3NIV1pHQWNVRmg4aFNZSHBuQVBJeERkVkpR?= =?utf-8?B?dktDdE81TFNBPT0=?= Content-Type: multipart/alternative; boundary="_000_C2E55EE9BC364F41834B3604B8C98A70junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 787ee9a8-f62e-4556-aaec-08da0c30b5ca X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 18:20:57.3018 (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: W9EHxQgVWat+PLm0bdcQbZGCYwg62/wykl9dXKvvU257Az1Woj+MiaSeraYHf+K/ X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3340 X-Proofpoint-GUID: y9xpC2gxfnAfmevuR0fpIMmX72viCrIq X-Proofpoint-ORIG-GUID: y9xpC2gxfnAfmevuR0fpIMmX72viCrIq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-22_07,2022-03-22_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 clxscore=1015 bulkscore=0 phishscore=0 impostorscore=0 spamscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203220096 Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 22 Mar 2022 18:21:15 -0000 --_000_C2E55EE9BC364F41834B3604B8C98A70junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZCwgdGhhbmtzLiBJ4oCZdmUgY2xlYXJlZCBteSBkaXNjdXNzLCB0aGFua3MgZm9y IHlvdXIgd29yayBvbiB0aGlzLg0KDQrigJRKb2huDQoNCk9uIE1hciAyMiwgMjAyMiwgYXQgMjox MSBQTSwgS2V0YW4gVGFsYXVsaWthciA8a2V0YW50LmlldGZAZ21haWwuY29tPG1haWx0bzprZXRh bnQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoNCkhpIEpvaG4sDQoNClRoYW5rcyBmb3Ig eW91ciBndWlkYW5jZSB3aXRoIHRoZSB0ZXh0LiBWZXJ5IG11Y2ggYXBwcmVjaWF0ZWQgLSBlc3Bl Y2lhbGx5IGluIHRoZSBtaWRkbGUgb2YgdGhlIGJ1c3kgSUVURiB3ZWVrLg0KDQpJJ3ZlIGp1c3Qg cG9zdGVkIGFuIHVwZGF0ZSB0byB0aGUgZHJhZnQgd2l0aCBzbGlnaHQgbW9kaWZpY2F0aW9ucyB0 byB5b3VyIHRleHQgKHNvIGFzIHRvIGNvdmVyIGJvdGggc2VjIDIuMSBhbmQgMi42IGFuZCBzdWdn ZXN0IHRoZSB1c2Ugb2YgdGhlIHdlbGwtZGVmaW5lZCBpZGVudGlmaWVycyBhcyBhIG1pdGlnYXRp b24gYXBwcm9hY2ggaW5zdGVhZCBvZiByZWx5aW5nIHNvbGVseSBvbiB0aGUgc3ltYm9saWMgbmFt ZXMuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1z cHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0yMjxodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctcG9saWN5LTIyX187ISFORXQ2eU1hTy1nayFUUGR3N1pkcWVDUlMy aHRCMUpDdFU5b3F6ZlVTMGFrb1AzYjJGR29aZnJ5ZTZOQkwtQV9DcHh6UmhWbHoxZyQ+DQoNClBs ZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIGFkZHJlc3NlcyB5b3VyIGNvbmNlcm5zLg0KDQpUaGFu a3MsDQpLZXRhbg0KDQoNCk9uIFR1ZSwgTWFyIDIyLCAyMDIyIGF0IDExOjIwIFBNIEpvaG4gU2N1 ZGRlciA8amdzQGp1bmlwZXIubmV0PG1haWx0bzpqZ3NAanVuaXBlci5uZXQ+PiB3cm90ZToNCkhp IEtldGFuLA0KDQpUaGFua3MgYXMgYWx3YXlzIGZvciB5b3VyIHF1aWNrIHJlcGx5Lg0KDQo+IE9u IE1hciAyMiwgMjAyMiwgYXQgNDo1NCBBTSwgS2V0YW4gVGFsYXVsaWthciA8a2V0YW50LmlldGZA Z21haWwuY29tPG1haWx0bzprZXRhbnQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4NCj4g SGkgSm9obiwNCj4NCj4gSSBkdWcgaW50byBteSBlbWFpbHMgYW5kIHlvdSBhcmUgcmlnaHQgdGhh dCB3aGlsZSB3ZSBoYWQgYSBkaXNjdXNzaW9uIG9uIHBvaW50IDQgKGkuZS4gc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoZSB1c2Ugb2Ygc3ltYm9saWMgbmFtZXMpLCBp dCB3YXMgbm90IGNvbmNsdWRlZC4gTXkgYXBvbG9naWVzIGZvciB0aGUgc2FtZS4NCj4NCj4gSXQg bWlnaHQgYmUgaGVscGZ1bCB0byBwbGFjZSBhIGNvbnRleHQgb24gd2h5IHRoZSBkcmFmdCB1c2Vz IHN5bWJvbGljIG5hbWVzIGluIHRoZSBmaXJzdCBwbGFjZS4gVGhlIGNsb3Nlc3QgYW5hbG9naWVz IHRoYXQgY29tZSB0byBteSBtaW5kIGFyZSB0dW5uZWxzIChkaWZmZXJlbnQgdHlwZXMgLSBURSwg SVBpbklQLCBJUHNlYykgYW5kIE1QTFMgTFNQcyAob3IgcGF0aHMpLiBUaGVzZSBjb25zdHJ1Y3Rz IGhhdmUgaGFkIHN5bWJvbGljIG5hbWVzIGFzc29jaWF0ZWQgd2l0aCB0aGVtIGZvciBhIGxvbmcg dGltZSBub3cgLSBib3RoIGZvciBsb2NhbCB1c2Ugb24gcm91dGVycyAoc29tZSBpbXBsZW1lbnRh dGlvbi1zcGVjaWZpYyAtIG90aGVycyBzcGVjaWZpZWQgYnkgSUVURikNCg0KU3VyZS4gQW55dGhp bmcgbG9jYWwgdG8gdGhlIHJvdXRlciBpc27igJl0IHJlbGF0ZWQgdG8gbXkgY29uY2Vybiwgd2hp Y2ggaXMgc3BlY2lmaWMgdG8gdGhlIG9wcG9ydHVuaXR5IGZvciBhIHJlbW90ZSBhdHRhY2tlciB0 byBtaXNsZWFkIHNvbWVvbmUgb24gdGhlIGxvY2FsIHJvdXRlci4gSSBob3BlIGl04oCZcyBjbGVh ciBieSBub3cgdGhhdCBJIGhhdmUgbm8gaXNzdWUgd2l0aCBhc3NvY2lhdGluZyBhIHN5bWJvbGlj IG5hbWUgd2l0aCBhIFNSIFBvbGljeSAob3IgYW55IG90aGVyIHRoaW5nKSwgYXMgc3VjaC4NCg0K PiBhbmQgYWxzbyBzaWduYWxlZCB2aWEgcm91dGluZyBwcm90b2NvbHMuDQoNCk5vdyB0aGF0IHlv dSBwb2ludCBpdCBvdXQsIEkgZG8gc2VlIGEgZmV3IHN1Y2gsIGUuZy4gdGhlIFNZTUJPTElDLVBB VEgtTkFNRSBpbiBSRkMgODIzMS4gVGhhdCBwYXJ0aWN1bGFyIGV4YW1wbGUgaGFzIGFyZ3VhYmx5 IGRpZmZlcmVudCB0aHJlYXQgcHJvcGVydGllcyBzaW5jZSB0aGUgcmVsYXRpb25zaGlwIGJldHdl ZW4gYSBQQ0UgYW5kIGl0cyBjbGllbnRzIGlzbuKAmXQgbWVkaWF0ZWQgdGhyb3VnaCBvdGhlciBy b3V0ZXJzOyB0aGUgdHJ1c3QgcmVsYXRpb25zaGlwIGlzIGNsZWFyZXIgYW5kIHRoZSDigJxyZW1v dGUgYXR0YWNrZXLigJ0gaXMgbm90IHNvIHZlcnkgcmVtb3RlLiBCdXQgSSBpbWFnaW5lIHRoZXJl IGFyZSBvdGhlciBleGFtcGxlcyB0byBiZSBmb3VuZCwgYW5kIEkgZG9u4oCZdCB3YW50IHRvIHNw bGl0IGhhaXJzIG9uIHRoaXMgZGV0YWlsLg0KDQo+IE9wZXJhdG9ycyBhcmUgdGhlcmVmb3JlIHF1 aXRlIGZhbWlsaWFyIHdpdGggdGhlaXIgdXNhZ2UgYW5kIGhlbmNlIHRoZWlyIGludHJvZHVjdGlv biBpbiB0aGUgU1IgUG9saWN5IGNvbnN0cnVjdC4gSSBkb24ndCBiZWxpZXZlIHRoZSBXRyB3b3Vs ZCB3YW50IHRvIHRha2UgdGhlIG9wdGlvbiBvZiB0aGVpciByZW1vdmFsIChpdCB3YXMgYSBzdWdn ZXN0ZWQgb3B0aW9uKS4NCg0KSSBkaWRu4oCZdCByZWFsbHkgZXhwZWN0IHlvdSB0bzsgSSB3YXMg anVzdCBsYXlpbmcgb3V0IHNvbWUgcG9pbnRzIGluIHRoZSBzb2x1dGlvbiBzcGFjZS4NCg0KPiBU aGVuIHdlIGdldCB0byBvcHRpb24gb2YgYWRkaW5nIHNwZWNpZmljIHRleHQgdG8gdGhlIGRyYWZ0 IChpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM/KSB0aGF0IHdvdWxkIGRpc2N1c3MgeW91 ciBjb25jZXJucy4gU3VjaCB0ZXh0IG1heSBiZSBhZGRyZXNzZWQgdG8gaW1wbGVtZW50YXRvcnMg YW5kL29yIG9wZXJhdG9ycy4gQXMgbWVudGlvbmVkIGFib3ZlLCB0aGUgdXNlIG9mIHN5bWJvbGlj IG5hbWVzIGZvciBjb25zdHJ1Y3RzIHNpbWlsYXIgdG8gU1IgUG9saWN5IG5hbWUgYW5kIFNSIFBv bGljeSBDYW5kaWRhdGUgUGF0aCBuYW1lIGlzIG5vdCAibmV3IiBmb3IgYm90aCBzZXRzIG9mIHJl YWRlcnMuIFRoZXJlZm9yZSwgSSBhbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIHRvIGNvdmVyIG9yIGFk ZCBhbnl0aGluZyBuZXcgaW4gdGhpcyBkb2N1bWVudCBhbmQgSSBjb3VsZCBub3QgZmluZCB0ZXh0 IHRoYXQgSSBjb3VsZCBib3Jyb3cgZnJvbSBvdGhlciBSRkNzIG9yIHBvaW50IHRvIG90aGVyIFJG Q3MuIGUuZy4sIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM4MjMxLmh0bWwjc2Vj dGlvbi03LjMuMjxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjL3JmYzgyMzEuaHRtbCpzZWN0aW9uLTcuMy4yX187SXchIU5FdDZ5TWFPLWdr IVRQZHc3WmRxZUNSUzJodEIxSkN0VTlvcXpmVVMwYWtvUDNiMkZHb1pmcnllNk5CTC1BX0NweHp1 X25KNHVnJD4NCj4NCj4gSSBkaWQgbG9vayBhdCBSRkM5MDAzIGJ1dCBpdHMgY29udGV4dCBpcyB2 ZXJ5IGRpZmZlcmVudC4gRnJvbSB5b3VyIERJU0NVU1MgY29tbWVudCwgSSBzZWUgdGhhdCB5b3Vy IGNvbmNlcm4gaXMgdGhhdCBhIHN0cmluZyBkb2VzIG5vdCBoYXZlIGFueSBzYW5pdHkgY2hlY2tp bmcgLSB0aGUgb3BlcmF0b3IgaXMgZnJlZSB0byB1c2UgYW55IHRleHQuDQoNCkNvcnJlY3QuIEFz IGxvbmcgYXMgeW91IGFzc3VtZSBnb29kIHdpbGwgb24gdGhlIHBhcnQgb2Yg4oCcdGhlIG9wZXJh dG9y4oCdIGl04oCZcyBhbGwgZ29vZC4gSWYgeW91IHN0YXJ0IHRoaW5raW5nIGluIHRlcm1zIG9m IGFuIGF0dGFja2VyIGluIHNvbWUgZGlzdGFudCBwYXJ0IG9mIHRoZSBuZXR3b3JrIGluamVjdGlu ZyBhIHBvbGljeSwgaXQgYmVjb21lcyBwb3RlbnRpYWxseSBjb25jZXJuaW5nLg0KDQo+IEkgYWdy ZWUuIERvIHdlIHdhbnQgaW1wbGVtZW50YXRpb25zIHRvIHJlc3RyaWN0IHNvbWV0aGluZz8gRG8g d2Ugd2FudCB0byBnaXZlIHNvbWUgbmFtaW5nIGd1aWRlbGluZXMgb3IgcHJlY2F1dGlvbnMgdG8g dGhlIG9wZXJhdG9ycz8NCg0KSSBkb27igJl0IHRoaW5rIHRoZSBjb25jZXJuIGlzIGFkZHJlc3Nh YmxlIG9uIHRoZSBvcmlnaW5hdGlvbiBzaWRlLCBzaW5jZSBpdCBhc3N1bWVzIGEgYmFkIGFjdG9y IHRvIGJlZ2luIHdpdGgsIGFuZCB0aGV54oCZcmUgbm90IGdvaW5nIHRvIGJlIGJvdGhlcmVkIGJ5 IHdoYXQgd2Ugd3JpdGUgaW4gYW4gUkZDLiBUaGF0IHdhcyB3aHkgaW4gbXkgc3VnZ2VzdGlvbiBJ IHdhcyB0aGlua2luZyBpbiB0ZXJtcyBvZiBkaXNwbGF5IGNvbnZlbnRpb25zLiBJ4oCZbSBub3Qg c3VwZXIgZXhjaXRlZCBieSBteSBvd24gaWRlYSwgdGhvdWdoLCBiZWNhdXNlIGl0IHJlbWluZHMg bWUgdW5jb21mb3J0YWJseSBtdWNoIG9mIHRoZSBkaXNjbGFpbWVyIG15IElUIGRlcGFydG1lbnQg c2xhcHMgb24gZXZlcnkgaW5jb21pbmcgZW1haWwsIOKAnFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1 dGlvdXMgb2YgY29udGVudF3igJ0uIEl04oCZcyBub3QgcGFydGljdWxhcmx5IGFjdGlvbmFibGUs IGFuZCBpdOKAmXMgYW5ub3lpbmcuIDotKA0KDQo+IEluIGEgcHJldmlvdXMgcmVzcG9uc2UsIHlv dXIgc3VnZ2VzdGlvbnMgZm9yIHRoZSB0ZXh0IGZvciBvcGVyYXRvcnMgd2VyZSAoc29tZXdoYXQ/ KSBvZiB0aGUgbmF0dXJlIC0gImJld2FyZSB0aGUgbmFtZSBvZiB0aGUgU1IgUG9saWN5IG1heSBu b3QgYWN0dWFsbHkgYmUgY29ycmVjdCBvciBtYXkgYmUgbWlzbGVhZGluZyBiZWNhdXNlIHNvbWVv bmUgbWlnaHQgaGF2ZSBoYWNrZWQgaW50byB0aGUgbmV0d29yayIuIEkgYW0gbm90IHN1cmUgaWYg c29tZXRoaW5nIG9mIHRoYXQgbmF0dXJlIGhlbHBzLiBJZiB0aGUgbmFtZXMgc3RvcCBiZWluZyBt ZWFuaW5nZnVsIHRoZW4gdGhleSBhcmUgbm8gbW9yZSByZWxldmFudD8gSXNuJ3QgdGhlIHNlY3Vy aXR5IGFzcGVjdCB0byBiZSB0YWtlbiBjYXJlIG9mIGhlcmUgaXMgdG8gcHJldmVudCBoYWNraW5n PyBTb21ldGhpbmcgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0Pw0KDQrigJxTZWN1cml0 eSBpcyBldmVyeW9uZeKAmXMgcmVzcG9uc2libGl0eS7igJ0NCg0KPiBJJ2xsIGFkbWl0IHRoYXQg SSBhbSBydW5uaW5nIG91dCBvZiBpZGVhcyBvbiB3aGF0IHdvdWxkIGJlIGEgbWVhbmluZ2Z1bCB0 ZXh0IHRvIGFkZCB0byBhZGRyZXNzIHlvdXIgY29uY2VybnMuIFdvdWxkIGFwcHJlY2lhdGUgc29t ZSB0ZXh0IHN1Z2dlc3Rpb24gdGhhdCBpcyByZWxldmFudCB0byB0aGlzIHNwZWNpZmljIGNvbnRl eHQuDQoNCkluIHRoZSBlbmQsIG1heWJlIGl04oCZcyB0cnVlIHRoYXQgdGhlcmXigJlzIG5vdCBt dWNoIHRvIGJlIGRvbmUsIHdoaWNoIHN1Y2tzLCBidXQgdGhhdOKAmXMgbGlmZS4gQnV0IGV2ZW4g aWYgd2UgdGhyb3cgb3VyIGhhbmRzIGluIHRoZSBhaXIgYW5kIHNheSDigJxub3RoaW5nIHRvIGJl IGRvbmXigJ0sIHdoaWNoIGlzIEkgdGhpbmsgd2hlcmUgd2XigJlyZSBnZXR0aW5nIHRvLCBJIGRv buKAmXQgdGhpbmsgdGhlcmUgd291bGQgYmUgYW55IGhhcm0gaW4gcHV0dGluZyBhIHNlbnRlbmNl IG9yIHR3byBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc3VjaCBhcyB5b3UgbWVudGlv biBqdXN0IGFib3ZlLiBTb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mLA0KDQrigJxJbiBTZWN0 aW9uIDIuMSB3ZSBtZW50aW9uIHRoYXQgYSBzeW1ib2xpYyBuYW1lIE1BWSBiZSBzaWduYWxlZCBh bG9uZyB3aXRoIGEgY2FuZGlkYXRlIHBhdGguIFdoaWxlIHRoZSB2YWx1ZSBvZiBzeW1ib2xpYyBu YW1lcyBmb3IgZGlzcGxheSBjbGFyaXR5IGlzIGluZGlzcHV0YWJsZSwgYXMgd2l0aCBhbnkgdW5y ZXN0cmljdGVkIGZyZWVmb3JtIHRleHQgcmVjZWl2ZWQgZnJvbSBleHRlcm5hbCBwYXJ0aWVzLCB0 aGVyZSBjYW4gYmUgbm8gYWJzb2x1dGUgYXNzdXJhbmNlIHRoYXQgdGhlIGluZm9ybWF0aW9uIHRo ZSB0ZXh0IHB1cnBvcnRzIHRvIHNob3cgaXMgYWNjdXJhdGUgb3IgZXZlbiB0cnV0aGZ1bC4gRm9y IHRoaXMgcmVhc29uLCB1c2VycyBvZiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkaXNwbGF5IHN1Y2gg aW5mb3JtYXRpb24gd291bGQgYmUgd2VsbC1hZHZpc2VkIG5vdCB0byByZWx5IG9uIGl0IHdpdGhv dXQgcXVlc3Rpb24uIEZ1cnRoZXJtb3JlLCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkaXNwbGF5IHN1 Y2ggaW5mb3JtYXRpb24gbWlnaHQgd2lzaCB0byBkaXNwbGF5IGl0IGluIHN1Y2ggYSBmYXNoaW9u IGFzIHRvIGRpZmZlcmVudGlhdGUgaXQgZnJvbSBrbm93bi1nb29kIGluZm9ybWF0aW9uLiAoU3Vj aCBkaXNwbGF5IGNvbnZlbnRpb25zIGFyZSBpbmhlcmVudGx5IGltcGxlbWVudGF0aW9uLXNwZWNp ZmljOyBvbmUgZXhhbXBsZSBtaWdodCBiZSB1c2Ugb2YgYSBkaXN0aW5ndWlzaGVkIHRleHQgY29s b3Igb3Igc3R5bGUgZm9yIGluZm9ybWF0aW9uIHRoYXQgc2hvdWxkIGJlIHRyZWF0ZWQgd2l0aCBj YXV0aW9uLinigJ0NCg0KTGV04oCZcyBiZSBob25lc3QsIHRoZSDigJxvb29oIGJlIGNhcmVmdWzi gJ0gdGV4dCBwcm92aWRlcyBhYm91dCBhcyBtdWNoIHByb3RlY3Rpb24gYXMgd2V0IHRpc3N1ZSBw YXBlciwgYW5kIGRpc3BsYXlpbmcgdGhlIHN0cmluZyBpbiBtYWdlbnRhIG5vdCBhIHdob2xlIGxv dCBtb3JlIHRoYW4gdGhhdCDigJQgYnV0IGl04oCZcyBzdGlsbCBiZXR0ZXIgdG8gZGlzY2xvc2Ug dGhlIGNvY25lcm4gdGhhbiBub3QgdG8uDQoNClJlZ2FyZHMsDQoNCuKAlEpvaG4NCg0KPiBUaGFu a3MsDQo+IEtldGFuDQo+DQo+IE9uIFR1ZSwgTWFyIDIyLCAyMDIyIGF0IDI6NTQgQU0gSm9obiBT Y3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ8bWFpbHRvOmpnc0BqdW5pcGVyLm5ldD4+IHdyb3RlOg0K Pj4gSGkgS2V0YW4sDQo+Pg0KPj4gWW91IGFza2VkICJ3aGV0aGVyIHRoZSByZXNwb25zZXMgYW5k IGRyYWZ0IHVwZGF0ZXMgYWRkcmVzcyBbbXldIGNvbmNlcm5z4oCdLiBJ4oCZZCBzYXkgdGhhdCB3 aGlsZSBJ4oCZbSBub3QgY29tcGxldGVseSBoYXBweSBhYm91dCBjZXJ0YWluIHRoaW5ncyAoZS5n LiwgSSByZW1haW4gdW5jb252aW5jZWQgdGhhdCB0aGUgY29tcGFuaW9uIElEUiBkb2Mgc2hvdWxk buKAmXQgYmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlKSBJIGRvbuKAmXQgbmVlZCB0byBjb250aW51 ZSBob2xkaW5nIGEgRElTQ1VTUyBvbiB0aGVtOiB3ZeKAmXZlIGhhZCBhIGRpc2N1c3Npb24sIHdl IGRvbuKAmXQgY29tcGxldGVseSBhZ3JlZSwgdGhlc2UgdGhpbmdzIGhhcHBlbi4gT24gcG9pbnQg NCBob3dldmVyLCBJIGRvbuKAmXQgdGhpbmsgb3VyIGRpc2N1c3Npb24gaGFzIGNvbmNsdWRlZC4g QXQgbGVhc3QsIGlmIHlvdSByZXBsaWVkIHRvIHRoaXMsIEkgbWlzc2VkIGl0Og0KPj4NCj4+ID4g T24gRmViIDE2LCAyMDIyLCBhdCAyOjQyIFBNLCBKb2huIFNjdWRkZXIgPGpncz00MGp1bmlwZXIu bmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj4g d3JvdGU6DQo+PiA+DQo+PiA+PiA0LiBJbiDCpzIuMSB5b3UgdGFsayBhYm91dCB0aGUgc2lnbmFs aW5nIG9mIHN5bWJvbGljIG5hbWVzIGZvciBjYW5kaWRhdGUgcGF0aHMuDQo+PiA+PiBBbHRob3Vn aCB5b3UgYXJlIGNhcmVmdWwgdG8gc2F5IHRoYXQgc3VjaCBzeW1ib2xpYyBuYW1lcyBhcmUgb25s eSB1c2VkIGZvcg0KPj4gPj4gcHJlc2VudGF0aW9uIHB1cnBvc2VzLCBpdCBzZWVtcyB0byBtZSB0 aGV5IHN0aWxsIGNvdWxkIGJlIGNvbnNpZGVyZWQgYSBuZXcNCj4+ID4+IHBvdGVudGlhbCBzb3Vy Y2Ugb2YgdnVsbmVyYWJpbGl0eSwgc2luY2UgYSBzdHJpbmcgdGhhdCBoYXMgbm8gc2FuaXR5LWNo ZWNraW5nDQo+PiA+PiB3aGF0c29ldmVyIGFwcGxpZWQgYnkgdGhlIHByb3RvY29sIGNhbiBkaXNw bGF5IGxpdGVyYWxseSBhbnl0aGluZyB0byBhbg0KPj4gPj4gb3BlcmF0b3Igdmlld2luZyBpdC4g U2hvdWxkbuKAmXQgdGhpcyBiZSBhZGRyZXNzZWQgaW4geW91ciBTZWN1cml0eQ0KPj4gPj4gQ29u c2lkZXJhdGlvbnM/IChGb3IgYW4gZXhhbXBsZSBvZiBhIHJlbGF0ZWQgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMsIHNlZSBSRkMNCj4+ID4+IDkwMDMuIEl04oCZcyBwcm9iYWJseSBub3QgdGhlIGJl c3QgZXhhbXBsZSwgYnV0IGl04oCZcyB0aGUgb25lIEkgaGFkIGF0IG15DQo+PiA+PiBmaW5nZXJ0 aXBz4oCmKQ0KPj4gPj4NCj4+ID4+IEtUPiBSRkM5MDAzIHVzZXMgVVRGLTggd2hpbGUgdGhpcyBk b2N1bWVudCB1c2VzIHByaW50YWJsZSBBU0NJSS4gQXMgc3VjaCwgSSBhbSBub3QgYXdhcmUgb2Yg c2VjdXJpdHkgaXNzdWVzIGFyb3VuZCBwcmludGFibGUgQVNDSUkgLSBwbGVhc2UgZG8gcG9pbnQg bWUgdG8gYW55IHJlZmVyZW5jZXMuDQo+PiA+DQo+PiA+IFlvdeKAmXJlIHRoaW5raW5nIHRvbyBt dWNoIGxpa2UgYSBwcm90b2NvbCBkZXNpZ25lci4gVGhlIGtpbmQgb2YgY29uY2VybiBJ4oCZbSB0 aGlua2luZyBhYm91dCBoYXMgdG8gZG8gd2l0aCB1c2luZyB0aGUgc3RyaW5nIGFzIGEgdmVjdG9y IHRvIHB1dCBzb21lIHdvcmRzIGluIGZyb250IG9mIGFuIG9wZXJhdG9yLCBhcyBwYXJ0IG9mIGEg bGFyZ2VyIHNvY2lhbCBlbmdpbmVlcmluZyBhdHRlbXB0LiBJIGRvbuKAmXQgaGF2ZSBhIGRldGFp bGVkIGF0dGFjayBzY2VuYXJpbyB0byBwYWludCBmb3IgeW91LCBidXQgYSBxdWljayBza2V0Y2gg aXMgYWxvbmcgdGhlIGxpbmVzIG9mDQo+PiA+DQo+PiA+IC0gQXR0YWNrZXIgbWFuYWdlcyB0byBp bmplY3QgYSBjYW5kaWRhdGUgcGF0aCB3aXRoIHRoZSBuYW1lIOKAnEJpZ19CYW5rX0xvd19MYXRl bmN54oCdDQo+PiA+IC0gUHJvVGlwOiB0aGUgY2FuZGlkYXRlIHBhdGggZG9lcyBub3QgYWN0dWFs bHkgdGVybWluYXRlIGF0IEJpZ19CYW5rDQo+PiA+IC0gQXR0YWNrZXIgdGhlbiBwaG9uZXMgTk9D LCBmZWlnbnMgdXJnZW5jeSwgYXNrcyBOT0MgdG8gcmVkaXJlY3QgQmlnX0JhbmsgdHJhZmZpYyBv bnRvIHRoYXQgcGF0aA0KPj4gPg0KPj4gPiBZb3UgZ2V0IHRoZSBpZGVhLCBJIGhvcGUuDQo+Pg0K Pj4gTW9yZSBzbmlwcGVkLCBidXQgdGhpcyBpcyB0aGUgbWVhdCBvZiBpdC4gSW4gY2FzZSB5b3Ug aGF2ZW7igJl0IGxvb2tlZCBhdCBSRkMgOTAwM+KAmXMgc2VjdXJpdHkgc2VjdGlvbiwgaGVyZeKA mXMgYSBzbmlwIGZyb20gaXQ6DQo+Pg0KPj4gICAgQXMgQkdQIFNodXRkb3duIENvbW11bmljYXRp b25zIGFyZSBsaWtlbHkgdG8gYXBwZWFyIGluIHN5c2xvZyBvdXRwdXQsDQo+PiAgICB0aGVyZSBp cyBhIHJpc2sgdGhhdCBjYXJlZnVsbHkgY29uc3RydWN0ZWQgU2h1dGRvd24gQ29tbXVuaWNhdGlv bg0KPj4gICAgbWlnaHQgYmUgZm9ybWF0dGVkIGJ5IHJlY2VpdmluZyBzeXN0ZW1zIGluIGEgd2F5 IHRvIG1ha2UgdGhlbSBhcHBlYXINCj4+ICAgIGFzIGFkZGl0aW9uYWwgc3lzbG9nIG1lc3NhZ2Vz Lg0KPj4NCj4+IChGV0lXLCBJIGRpZG7igJl0IGNvbnRyaWJ1dGUgdGhhdCB0ZXh0LikNCj4+DQo+ PiBQbGVhc2UgZG9u4oCZdCBvYnNlc3MgYWJvdXQg4oCcc3lzbG9n4oCdIGluIHRoZSBleGFtcGxl IGFib3ZlLCBpdOKAmXMgbm90IGNlbnRyYWwgdG8gdGhlIHBvaW50LCBqdXN0IGxpa2UgVVRGLTgg dnMgQVNDSUkgaXNu4oCZdCBjZW50cmFsLiBUaGUgcG9pbnQsIGFnYWluLCBpcyB0aGF0IGJ5IGlu dHJvZHVjaW5nIGEgd2F5IGZvciBhbiBhdHRhY2tlciB0byBjYXVzZSBhIHRhcmdldCBzeXN0ZW0g dG8gZGlzcGxheSBhcmJpdHJhcnkgc3RyaW5ncywgaXQgd291bGQgc2VlbSByZWFzb25hYmxlIHRv IHdvbmRlciBpZiB0aGF0IGNyZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIG1pc2NoaWVmIHRoYXQg ZG9lc27igJl0IG9yZGluYXJpbHkgZXhpc3QgaW4gb3VyIHByb3RvY29scywgaW52b2x2aW5nIG1p c2xlYWRpbmcgcGVvcGxlIGxvb2tpbmcgYXQgdGhlIGRpc3BsYXllZCBzdHJpbmcgaW4gYSB1c2Vy IGludGVyZmFjZS4NCj4+DQo+PiBUaGVyZSBhcmUgdmFyaW91cyB3YXlzIHRoaXMgY29uY2VybiBj b3VsZCBiZSBtaXRpZ2F0ZWQgKGlmIHdlIHdlcmUgdG8gY29tZSB0byBhZ3JlZW1lbnQgdGhhdCBp dOKAmXMgZXZlbiBhIGNvbmNlcm4pLiBPbmUgd291bGQgYmUgdG8gcmVtb3ZlIHRoZSDigJxzaWdu YWwgYXJiaXRyYXJ5IHN0cmluZ3PigJ0gaWRlYTsgdGhpcyBpcyBjbGVhcmx5IHRoZSBzb2xpZGVz dCB3YXkgdG8gZG8gaXQuIEFub3RoZXIgd291bGQgYmUgdG8gbWFuZGF0ZSAob3Igc3Ryb25nbHkg c3VnZ2VzdCkgdGhhdCBzeW1ib2xpYyBuYW1lcyBnbGVhbmVkIGZyb20gc29tZXRoaW5nIG90aGVy IHRoYW4gY29uZmlndXJhdGlvbiBiZSBkaXNwbGF5ZWQgaW4gc3VjaCBhIHdheSBhcyB0byBtYWtl IHRoZSBvcGVyYXRvciBhd2FyZSBvZiB0aGVpciBzdGF0dXMuIEF0IGEgbWluaW11bSwgb25lIG1p Z2h0IGFkZCBhIHBhcmFncmFwaCBvciB0d28gaWRlbnRpZnlpbmcgdGhlIGNvbmNlcm4uIEnigJlt IHN1cmUgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0IGNvdWxkIGJlIGNvbnRlbXBsYXRlZC4N Cj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IOKAlEpvaG4NCj4NCg0K --_000_C2E55EE9BC364F41834B3604B8C98A70junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <711D6CE4C3FAB743B1DD8C083D578001@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkxvb2tzIGdvb2QsIHRoYW5rcy4gSeKAmXZlIGNs ZWFyZWQgbXkgZGlzY3VzcywgdGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcy4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlEpvaG48YnIgY2xh c3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIgMjIsIDIwMjIsIGF0IDI6MTEgUE0sIEtldGFuIFRh bGF1bGlrYXIgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnQuaWV0ZkBnbWFpbC5jb20iIGNsYXNz PSIiPmtldGFudC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xkZXIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgSm9obiwNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgeW91ciBndWlkYW5j ZSB3aXRoIHRoZSB0ZXh0LiBWZXJ5IG11Y2ggYXBwcmVjaWF0ZWQgLSBlc3BlY2lhbGx5IGluIHRo ZSBtaWRkbGUgb2YgdGhlIGJ1c3kgSUVURiB3ZWVrLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSd2ZSBqdXN0IHBvc3RlZCBhbiB1cGRh dGUgdG8gdGhlIGRyYWZ0IHdpdGggc2xpZ2h0IG1vZGlmaWNhdGlvbnMgdG8geW91ciB0ZXh0IChz byBhcyB0byBjb3ZlciBib3RoIHNlYyAyLjEgYW5kIDIuNiBhbmQgc3VnZ2VzdCB0aGUgdXNlIG9m IHRoZSB3ZWxsLWRlZmluZWQgaWRlbnRpZmllcnMgYXMgYSBtaXRpZ2F0aW9uIGFwcHJvYWNoIGlu c3RlYWQgb2YgcmVseWluZyBzb2xlbHkgb24gdGhlIHN5bWJvbGljIG5hbWVzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLXBvbGljeS0yMl9fOyEh TkV0NnlNYU8tZ2shVFBkdzdaZHFlQ1JTMmh0QjFKQ3RVOW9xemZVUzBha29QM2IyRkdvWmZyeWU2 TkJMLUFfQ3B4elJoVmx6MWckIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc3By aW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3ktMjI8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QbGVhc2Ug bGV0IHVzIGtub3cgaWYgdGhpcyBhZGRyZXNzZXMgeW91ciBjb25jZXJucy48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+S2V0YW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUdWUsIE1hciAyMiwgMjAy MiBhdCAxMToyMCBQTSBKb2huIFNjdWRkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqZ3NAanVuaXBl ci5uZXQiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qZ3NAanVuaXBlci5uZXQ8L2E+Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQg cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhpIEtldGFuLDxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyBhcyBhbHdheXMgZm9yIHlvdXIgcXVpY2sgcmVwbHku PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBPbiBNYXIgMjIsIDIwMjIsIGF0IDQ6 NTQgQU0sIEtldGFuIFRhbGF1bGlrYXIgJmx0OzxhIGhyZWY9Im1haWx0bzprZXRhbnQuaWV0ZkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5rZXRhbnQuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJy IGNsYXNzPSIiPg0KJmd0OyBIaSBKb2huLDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIi Pg0KJmd0OyBJIGR1ZyBpbnRvIG15IGVtYWlscyBhbmQgeW91IGFyZSByaWdodCB0aGF0IHdoaWxl IHdlIGhhZCBhIGRpc2N1c3Npb24gb24gcG9pbnQgNCAoaS5lLiBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlIHVzZSBvZiBzeW1ib2xpYyBuYW1lcyksIGl0IHdhcyBu b3QgY29uY2x1ZGVkLiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBzYW1lLjxiciBjbGFzcz0iIj4NCiZn dDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBJdCBtaWdodCBiZSBoZWxwZnVsIHRvIHBsYWNlIGEgY29u dGV4dCBvbiB3aHkgdGhlIGRyYWZ0IHVzZXMgc3ltYm9saWMgbmFtZXMgaW4gdGhlIGZpcnN0IHBs YWNlLiBUaGUgY2xvc2VzdCBhbmFsb2dpZXMgdGhhdCBjb21lIHRvIG15IG1pbmQgYXJlIHR1bm5l bHMgKGRpZmZlcmVudCB0eXBlcyAtIFRFLCBJUGluSVAsIElQc2VjKSBhbmQgTVBMUyBMU1BzIChv ciBwYXRocykuIFRoZXNlIGNvbnN0cnVjdHMgaGF2ZSBoYWQgc3ltYm9saWMgbmFtZXMNCiBhc3Nv Y2lhdGVkIHdpdGggdGhlbSBmb3IgYSBsb25nIHRpbWUgbm93IC0gYm90aCBmb3IgbG9jYWwgdXNl IG9uIHJvdXRlcnMgKHNvbWUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgLSBvdGhlcnMgc3BlY2lm aWVkIGJ5IElFVEYpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU3VyZS4gQW55dGhpbmcg bG9jYWwgdG8gdGhlIHJvdXRlciBpc27igJl0IHJlbGF0ZWQgdG8gbXkgY29uY2Vybiwgd2hpY2gg aXMgc3BlY2lmaWMgdG8gdGhlIG9wcG9ydHVuaXR5IGZvciBhIHJlbW90ZSBhdHRhY2tlciB0byBt aXNsZWFkIHNvbWVvbmUgb24gdGhlIGxvY2FsIHJvdXRlci4gSSBob3BlIGl04oCZcyBjbGVhciBi eSBub3cgdGhhdCBJIGhhdmUgbm8gaXNzdWUgd2l0aCBhc3NvY2lhdGluZyBhIHN5bWJvbGljIG5h bWUgd2l0aCBhIFNSIFBvbGljeQ0KIChvciBhbnkgb3RoZXIgdGhpbmcpLCBhcyBzdWNoLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgYW5kIGFsc28gc2lnbmFsZWQgdmlhIHJvdXRp bmcgcHJvdG9jb2xzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdyB0aGF0IHlvdSBw b2ludCBpdCBvdXQsIEkgZG8gc2VlIGEgZmV3IHN1Y2gsIGUuZy4gdGhlIFNZTUJPTElDLVBBVEgt TkFNRSBpbiBSRkMgODIzMS4gVGhhdCBwYXJ0aWN1bGFyIGV4YW1wbGUgaGFzIGFyZ3VhYmx5IGRp ZmZlcmVudCB0aHJlYXQgcHJvcGVydGllcyBzaW5jZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4g YSBQQ0UgYW5kIGl0cyBjbGllbnRzIGlzbuKAmXQgbWVkaWF0ZWQgdGhyb3VnaCBvdGhlciByb3V0 ZXJzOyB0aGUgdHJ1c3QgcmVsYXRpb25zaGlwDQogaXMgY2xlYXJlciBhbmQgdGhlIOKAnHJlbW90 ZSBhdHRhY2tlcuKAnSBpcyBub3Qgc28gdmVyeSByZW1vdGUuIEJ1dCBJIGltYWdpbmUgdGhlcmUg YXJlIG90aGVyIGV4YW1wbGVzIHRvIGJlIGZvdW5kLCBhbmQgSSBkb27igJl0IHdhbnQgdG8gc3Bs aXQgaGFpcnMgb24gdGhpcyBkZXRhaWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0 OyBPcGVyYXRvcnMgYXJlIHRoZXJlZm9yZSBxdWl0ZSBmYW1pbGlhciB3aXRoIHRoZWlyIHVzYWdl IGFuZCBoZW5jZSB0aGVpciBpbnRyb2R1Y3Rpb24gaW4gdGhlIFNSIFBvbGljeSBjb25zdHJ1Y3Qu IEkgZG9uJ3QgYmVsaWV2ZSB0aGUgV0cgd291bGQgd2FudCB0byB0YWtlIHRoZSBvcHRpb24gb2Yg dGhlaXIgcmVtb3ZhbCAoaXQgd2FzIGEgc3VnZ2VzdGVkIG9wdGlvbikuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSSBkaWRu4oCZdCByZWFsbHkgZXhwZWN0IHlvdSB0bzsgSSB3YXMganVz dCBsYXlpbmcgb3V0IHNvbWUgcG9pbnRzIGluIHRoZSBzb2x1dGlvbiBzcGFjZS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IFRoZW4gd2UgZ2V0IHRvIG9wdGlvbiBvZiBhZGRpbmcg c3BlY2lmaWMgdGV4dCB0byB0aGUgZHJhZnQgKGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cz8pIHRoYXQgd291bGQgZGlzY3VzcyB5b3VyIGNvbmNlcm5zLiBTdWNoIHRleHQgbWF5IGJlIGFk ZHJlc3NlZCB0byBpbXBsZW1lbnRhdG9ycyBhbmQvb3Igb3BlcmF0b3JzLiBBcyBtZW50aW9uZWQg YWJvdmUsIHRoZSB1c2Ugb2Ygc3ltYm9saWMgbmFtZXMgZm9yIGNvbnN0cnVjdHMgc2ltaWxhcg0K IHRvIFNSIFBvbGljeSBuYW1lIGFuZCBTUiBQb2xpY3kgQ2FuZGlkYXRlIFBhdGggbmFtZSBpcyBu b3QgJnF1b3Q7bmV3JnF1b3Q7IGZvciBib3RoIHNldHMgb2YgcmVhZGVycy4gVGhlcmVmb3JlLCBJ IGFtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdG8gY292ZXIgb3IgYWRkIGFueXRoaW5nIG5ldyBpbiB0 aGlzIGRvY3VtZW50IGFuZCBJIGNvdWxkIG5vdCBmaW5kIHRleHQgdGhhdCBJIGNvdWxkIGJvcnJv dyBmcm9tIG90aGVyIFJGQ3Mgb3IgcG9pbnQgdG8gb3RoZXIgUkZDcy4NCiBlLmcuLCA8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv cmZjL3JmYzgyMzEuaHRtbCpzZWN0aW9uLTcuMy4yX187SXchIU5FdDZ5TWFPLWdrIVRQZHc3WmRx ZUNSUzJodEIxSkN0VTlvcXpmVVMwYWtvUDNiMkZHb1pmcnllNk5CTC1BX0NweHp1X25KNHVnJCIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9yZmMvcmZjODIzMS5odG1sI3NlY3Rpb24tNy4zLjI8L2E+PGJyIGNsYXNz PSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEkgZGlkIGxvb2sgYXQgUkZDOTAwMyBidXQg aXRzIGNvbnRleHQgaXMgdmVyeSBkaWZmZXJlbnQuIEZyb20geW91ciBESVNDVVNTIGNvbW1lbnQs IEkgc2VlIHRoYXQgeW91ciBjb25jZXJuIGlzIHRoYXQgYSBzdHJpbmcgZG9lcyBub3QgaGF2ZSBh bnkgc2FuaXR5IGNoZWNraW5nIC0gdGhlIG9wZXJhdG9yIGlzIGZyZWUgdG8gdXNlIGFueSB0ZXh0 LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNvcnJlY3QuIEFzIGxvbmcgYXMgeW91IGFz c3VtZSBnb29kIHdpbGwgb24gdGhlIHBhcnQgb2Yg4oCcdGhlIG9wZXJhdG9y4oCdIGl04oCZcyBh bGwgZ29vZC4gSWYgeW91IHN0YXJ0IHRoaW5raW5nIGluIHRlcm1zIG9mIGFuIGF0dGFja2VyIGlu IHNvbWUgZGlzdGFudCBwYXJ0IG9mIHRoZSBuZXR3b3JrIGluamVjdGluZyBhIHBvbGljeSwgaXQg YmVjb21lcyBwb3RlbnRpYWxseSBjb25jZXJuaW5nLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJmd0OyBJIGFncmVlLiBEbyB3ZSB3YW50IGltcGxlbWVudGF0aW9ucyB0byByZXN0cmlj dCBzb21ldGhpbmc/IERvIHdlIHdhbnQgdG8gZ2l2ZSBzb21lIG5hbWluZyBndWlkZWxpbmVzIG9y IHByZWNhdXRpb25zIHRvIHRoZSBvcGVyYXRvcnM/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSSBkb27igJl0IHRoaW5rIHRoZSBjb25jZXJuIGlzIGFkZHJlc3NhYmxlIG9uIHRoZSBvcmln aW5hdGlvbiBzaWRlLCBzaW5jZSBpdCBhc3N1bWVzIGEgYmFkIGFjdG9yIHRvIGJlZ2luIHdpdGgs IGFuZCB0aGV54oCZcmUgbm90IGdvaW5nIHRvIGJlIGJvdGhlcmVkIGJ5IHdoYXQgd2Ugd3JpdGUg aW4gYW4gUkZDLiBUaGF0IHdhcyB3aHkgaW4gbXkgc3VnZ2VzdGlvbiBJIHdhcyB0aGlua2luZyBp biB0ZXJtcyBvZiBkaXNwbGF5IGNvbnZlbnRpb25zLiBJ4oCZbQ0KIG5vdCBzdXBlciBleGNpdGVk IGJ5IG15IG93biBpZGVhLCB0aG91Z2gsIGJlY2F1c2UgaXQgcmVtaW5kcyBtZSB1bmNvbWZvcnRh Ymx5IG11Y2ggb2YgdGhlIGRpc2NsYWltZXIgbXkgSVQgZGVwYXJ0bWVudCBzbGFwcyBvbiBldmVy eSBpbmNvbWluZyBlbWFpbCwg4oCcW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250 ZW50XeKAnS4gSXTigJlzIG5vdCBwYXJ0aWN1bGFybHkgYWN0aW9uYWJsZSwgYW5kIGl04oCZcyBh bm5veWluZy4gOi0oPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBJbiBhIHByZXZp b3VzIHJlc3BvbnNlLCB5b3VyIHN1Z2dlc3Rpb25zIGZvciB0aGUgdGV4dCBmb3Igb3BlcmF0b3Jz IHdlcmUgKHNvbWV3aGF0Pykgb2YgdGhlIG5hdHVyZSAtICZxdW90O2Jld2FyZSB0aGUgbmFtZSBv ZiB0aGUgU1IgUG9saWN5IG1heSBub3QgYWN0dWFsbHkgYmUgY29ycmVjdCBvciBtYXkgYmUgbWlz bGVhZGluZyBiZWNhdXNlIHNvbWVvbmUgbWlnaHQgaGF2ZSBoYWNrZWQgaW50byB0aGUgbmV0d29y ayZxdW90Oy4gSSBhbSBub3Qgc3VyZSBpZiBzb21ldGhpbmcNCiBvZiB0aGF0IG5hdHVyZSBoZWxw cy4gSWYgdGhlIG5hbWVzIHN0b3AgYmVpbmcgbWVhbmluZ2Z1bCB0aGVuIHRoZXkgYXJlIG5vIG1v cmUgcmVsZXZhbnQ/IElzbid0IHRoZSBzZWN1cml0eSBhc3BlY3QgdG8gYmUgdGFrZW4gY2FyZSBv ZiBoZXJlIGlzIHRvIHByZXZlbnQgaGFja2luZz8gU29tZXRoaW5nIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcyBkcmFmdD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrigJxTZWN1cml0eSBp cyBldmVyeW9uZeKAmXMgcmVzcG9uc2libGl0eS7igJ0gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJmd0OyBJJ2xsIGFkbWl0IHRoYXQgSSBhbSBydW5uaW5nIG91dCBvZiBpZGVhcyBvbiB3 aGF0IHdvdWxkIGJlIGEgbWVhbmluZ2Z1bCB0ZXh0IHRvIGFkZCB0byBhZGRyZXNzIHlvdXIgY29u Y2VybnMuIFdvdWxkIGFwcHJlY2lhdGUgc29tZSB0ZXh0IHN1Z2dlc3Rpb24gdGhhdCBpcyByZWxl dmFudCB0byB0aGlzIHNwZWNpZmljIGNvbnRleHQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSW4gdGhlIGVuZCwgbWF5YmUgaXTigJlzIHRydWUgdGhhdCB0aGVyZeKAmXMgbm90IG11Y2gg dG8gYmUgZG9uZSwgd2hpY2ggc3Vja3MsIGJ1dCB0aGF04oCZcyBsaWZlLiBCdXQgZXZlbiBpZiB3 ZSB0aHJvdyBvdXIgaGFuZHMgaW4gdGhlIGFpciBhbmQgc2F5IOKAnG5vdGhpbmcgdG8gYmUgZG9u ZeKAnSwgd2hpY2ggaXMgSSB0aGluayB3aGVyZSB3ZeKAmXJlIGdldHRpbmcgdG8sIEkgZG9u4oCZ dCB0aGluayB0aGVyZSB3b3VsZCBiZSBhbnkgaGFybSBpbiBwdXR0aW5nIGEgc2VudGVuY2UNCiBv ciB0d28gaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHN1Y2ggYXMgeW91IG1lbnRpb24g anVzdCBhYm92ZS4gU29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiw8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQrigJxJbiBTZWN0aW9uIDIuMSB3ZSBtZW50aW9uIHRoYXQgYSBzeW1ib2xp YyBuYW1lIE1BWSBiZSBzaWduYWxlZCBhbG9uZyB3aXRoIGEgY2FuZGlkYXRlIHBhdGguIFdoaWxl IHRoZSB2YWx1ZSBvZiBzeW1ib2xpYyBuYW1lcyBmb3IgZGlzcGxheSBjbGFyaXR5IGlzIGluZGlz cHV0YWJsZSwgYXMgd2l0aCBhbnkgdW5yZXN0cmljdGVkIGZyZWVmb3JtIHRleHQgcmVjZWl2ZWQg ZnJvbSBleHRlcm5hbCBwYXJ0aWVzLCB0aGVyZSBjYW4gYmUgbm8gYWJzb2x1dGUNCiBhc3N1cmFu Y2UgdGhhdCB0aGUgaW5mb3JtYXRpb24gdGhlIHRleHQgcHVycG9ydHMgdG8gc2hvdyBpcyBhY2N1 cmF0ZSBvciBldmVuIHRydXRoZnVsLiBGb3IgdGhpcyByZWFzb24sIHVzZXJzIG9mIGltcGxlbWVu dGF0aW9ucyB0aGF0IGRpc3BsYXkgc3VjaCBpbmZvcm1hdGlvbiB3b3VsZCBiZSB3ZWxsLWFkdmlz ZWQgbm90IHRvIHJlbHkgb24gaXQgd2l0aG91dCBxdWVzdGlvbi4gRnVydGhlcm1vcmUsIGltcGxl bWVudGF0aW9ucyB0aGF0IGRpc3BsYXkNCiBzdWNoIGluZm9ybWF0aW9uIG1pZ2h0IHdpc2ggdG8g ZGlzcGxheSBpdCBpbiBzdWNoIGEgZmFzaGlvbiBhcyB0byBkaWZmZXJlbnRpYXRlIGl0IGZyb20g a25vd24tZ29vZCBpbmZvcm1hdGlvbi4gKFN1Y2ggZGlzcGxheSBjb252ZW50aW9ucyBhcmUgaW5o ZXJlbnRseSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYzsgb25lIGV4YW1wbGUgbWlnaHQgYmUgdXNl IG9mIGEgZGlzdGluZ3Vpc2hlZCB0ZXh0IGNvbG9yIG9yIHN0eWxlIGZvciBpbmZvcm1hdGlvbg0K IHRoYXQgc2hvdWxkIGJlIHRyZWF0ZWQgd2l0aCBjYXV0aW9uLinigJ08YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpMZXTigJlzIGJlIGhvbmVzdCwgdGhlIOKAnG9vb2ggYmUgY2FyZWZ1bOKA nSB0ZXh0IHByb3ZpZGVzIGFib3V0IGFzIG11Y2ggcHJvdGVjdGlvbiBhcyB3ZXQgdGlzc3VlIHBh cGVyLCBhbmQgZGlzcGxheWluZyB0aGUgc3RyaW5nIGluIG1hZ2VudGEgbm90IGEgd2hvbGUgbG90 IG1vcmUgdGhhbiB0aGF0IOKAlCBidXQgaXTigJlzIHN0aWxsIGJldHRlciB0byBkaXNjbG9zZSB0 aGUgY29jbmVybiB0aGFuIG5vdCB0by48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWdh cmRzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCuKAlEpvaG48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQomZ3Q7IFRoYW5rcyw8YnIgY2xhc3M9IiI+DQomZ3Q7IEtldGFuPGJyIGNs YXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IE9uIFR1ZSwgTWFyIDIyLCAyMDIyIGF0 IDI6NTQgQU0gSm9obiBTY3VkZGVyICZsdDs8YSBocmVmPSJtYWlsdG86amdzQGp1bmlwZXIubmV0 IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+amdzQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSGkgS2V0YW4sPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgWW91IGFza2VkICZxdW90O3doZXRoZXIgdGhlIHJlc3Bv bnNlcyBhbmQgZHJhZnQgdXBkYXRlcyBhZGRyZXNzIFtteV0gY29uY2VybnPigJ0uIEnigJlkIHNh eSB0aGF0IHdoaWxlIEnigJltIG5vdCBjb21wbGV0ZWx5IGhhcHB5IGFib3V0IGNlcnRhaW4gdGhp bmdzIChlLmcuLCBJIHJlbWFpbiB1bmNvbnZpbmNlZCB0aGF0IHRoZSBjb21wYW5pb24gSURSIGRv YyBzaG91bGRu4oCZdCBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UpIEkgZG9u4oCZdCBuZWVkIHRv IGNvbnRpbnVlDQogaG9sZGluZyBhIERJU0NVU1Mgb24gdGhlbTogd2XigJl2ZSBoYWQgYSBkaXNj dXNzaW9uLCB3ZSBkb27igJl0IGNvbXBsZXRlbHkgYWdyZWUsIHRoZXNlIHRoaW5ncyBoYXBwZW4u IE9uIHBvaW50IDQgaG93ZXZlciwgSSBkb27igJl0IHRoaW5rIG91ciBkaXNjdXNzaW9uIGhhcyBj b25jbHVkZWQuIEF0IGxlYXN0LCBpZiB5b3UgcmVwbGllZCB0byB0aGlzLCBJIG1pc3NlZCBpdDo8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7IE9uIEZl YiAxNiwgMjAyMiwgYXQgMjo0MiBQTSwgSm9obiBTY3VkZGVyICZsdDtqZ3M9PGEgaHJlZj0ibWFp bHRvOjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij40MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyA0LiBJbiDC pzIuMSB5b3UgdGFsayBhYm91dCB0aGUgc2lnbmFsaW5nIG9mIHN5bWJvbGljIG5hbWVzIGZvciBj YW5kaWRhdGUgcGF0aHMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgQWx0aG91Z2gg eW91IGFyZSBjYXJlZnVsIHRvIHNheSB0aGF0IHN1Y2ggc3ltYm9saWMgbmFtZXMgYXJlIG9ubHkg dXNlZCBmb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwcmVzZW50YXRpb24gcHVy cG9zZXMsIGl0IHNlZW1zIHRvIG1lIHRoZXkgc3RpbGwgY291bGQgYmUgY29uc2lkZXJlZCBhIG5l dzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHBvdGVudGlhbCBzb3VyY2Ugb2YgdnVs bmVyYWJpbGl0eSwgc2luY2UgYSBzdHJpbmcgdGhhdCBoYXMgbm8gc2FuaXR5LWNoZWNraW5nPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgd2hhdHNvZXZlciBhcHBsaWVkIGJ5IHRoZSBw cm90b2NvbCBjYW4gZGlzcGxheSBsaXRlcmFsbHkgYW55dGhpbmcgdG8gYW48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBvcGVyYXRvciB2aWV3aW5nIGl0LiBTaG91bGRu4oCZdCB0aGlz IGJlIGFkZHJlc3NlZCBpbiB5b3VyIFNlY3VyaXR5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0 OyZndDsgQ29uc2lkZXJhdGlvbnM/IChGb3IgYW4gZXhhbXBsZSBvZiBhIHJlbGF0ZWQgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMsIHNlZSBSRkM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0 OyA5MDAzLiBJdOKAmXMgcHJvYmFibHkgbm90IHRoZSBiZXN0IGV4YW1wbGUsIGJ1dCBpdOKAmXMg dGhlIG9uZSBJIGhhZCBhdCBteTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IGZpbmdl cnRpcHPigKYpPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgJmd0OyZndDsgS1QmZ3Q7IFJGQzkwMDMgdXNlcyBVVEYtOCB3aGlsZSB0aGlzIGRv Y3VtZW50IHVzZXMgcHJpbnRhYmxlIEFTQ0lJLiBBcyBzdWNoLCBJIGFtIG5vdCBhd2FyZSBvZiBz ZWN1cml0eSBpc3N1ZXMgYXJvdW5kIHByaW50YWJsZSBBU0NJSSAtIHBsZWFzZSBkbyBwb2ludCBt ZSB0byBhbnkgcmVmZXJlbmNlcy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7IDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7ICZndDsgWW914oCZcmUgdGhpbmtpbmcgdG9vIG11Y2ggbGlrZSBhIHBy b3RvY29sIGRlc2lnbmVyLiBUaGUga2luZCBvZiBjb25jZXJuIEnigJltIHRoaW5raW5nIGFib3V0 IGhhcyB0byBkbyB3aXRoIHVzaW5nIHRoZSBzdHJpbmcgYXMgYSB2ZWN0b3IgdG8gcHV0IHNvbWUg d29yZHMgaW4gZnJvbnQgb2YgYW4gb3BlcmF0b3IsIGFzIHBhcnQgb2YgYSBsYXJnZXIgc29jaWFs IGVuZ2luZWVyaW5nIGF0dGVtcHQuIEkgZG9u4oCZdCBoYXZlIGEgZGV0YWlsZWQgYXR0YWNrDQog c2NlbmFyaW8gdG8gcGFpbnQgZm9yIHlvdSwgYnV0IGEgcXVpY2sgc2tldGNoIGlzIGFsb25nIHRo ZSBsaW5lcyBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZndDsgPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgJmd0OyAtIEF0dGFja2VyIG1hbmFnZXMgdG8gaW5qZWN0IGEgY2FuZGlkYXRlIHBhdGgg d2l0aCB0aGUgbmFtZSDigJxCaWdfQmFua19Mb3dfTGF0ZW5jeeKAnTxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7ICZndDsgLSBQcm9UaXA6IHRoZSBjYW5kaWRhdGUgcGF0aCBkb2VzIG5vdCBhY3R1YWxs eSB0ZXJtaW5hdGUgYXQgQmlnX0Jhbms8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmZ3Q7IC0gQXR0 YWNrZXIgdGhlbiBwaG9uZXMgTk9DLCBmZWlnbnMgdXJnZW5jeSwgYXNrcyBOT0MgdG8gcmVkaXJl Y3QgQmlnX0JhbmsgdHJhZmZpYyBvbnRvIHRoYXQgcGF0aDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 ICZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgJmd0OyBZb3UgZ2V0IHRoZSBpZGVhLCBJIGhv cGUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgTW9yZSBz bmlwcGVkLCBidXQgdGhpcyBpcyB0aGUgbWVhdCBvZiBpdC4gSW4gY2FzZSB5b3UgaGF2ZW7igJl0 IGxvb2tlZCBhdCBSRkMgOTAwM+KAmXMgc2VjdXJpdHkgc2VjdGlvbiwgaGVyZeKAmXMgYSBzbmlw IGZyb20gaXQ6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7IEFzIEJHUCBTaHV0ZG93biBDb21tdW5pY2F0aW9ucyBhcmUgbGlrZWx5IHRv IGFwcGVhciBpbiBzeXNsb2cgb3V0cHV0LDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyB0aGVyZSBpcyBhIHJpc2sgdGhhdCBjYXJlZnVsbHkgY29uc3RydWN0ZWQgU2h1dGRvd24g Q29tbXVuaWNhdGlvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBtaWdodCBi ZSBmb3JtYXR0ZWQgYnkgcmVjZWl2aW5nIHN5c3RlbXMgaW4gYSB3YXkgdG8gbWFrZSB0aGVtIGFw cGVhcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBhcyBhZGRpdGlvbmFsIHN5 c2xvZyBtZXNzYWdlcy4gPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgKEZXSVcsIEkgZGlkbuKAmXQgY29udHJpYnV0ZSB0aGF0IHRleHQuKTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFBsZWFzZSBkb27igJl0IG9ic2Vz cyBhYm91dCDigJxzeXNsb2figJ0gaW4gdGhlIGV4YW1wbGUgYWJvdmUsIGl04oCZcyBub3QgY2Vu dHJhbCB0byB0aGUgcG9pbnQsIGp1c3QgbGlrZSBVVEYtOCB2cyBBU0NJSSBpc27igJl0IGNlbnRy YWwuIFRoZSBwb2ludCwgYWdhaW4sIGlzIHRoYXQgYnkgaW50cm9kdWNpbmcgYSB3YXkgZm9yIGFu IGF0dGFja2VyIHRvIGNhdXNlIGEgdGFyZ2V0IHN5c3RlbSB0byBkaXNwbGF5IGFyYml0cmFyeSBz dHJpbmdzLCBpdCB3b3VsZA0KIHNlZW0gcmVhc29uYWJsZSB0byB3b25kZXIgaWYgdGhhdCBjcmVh dGVzIGFuIG9wcG9ydHVuaXR5IGZvciBtaXNjaGllZiB0aGF0IGRvZXNu4oCZdCBvcmRpbmFyaWx5 IGV4aXN0IGluIG91ciBwcm90b2NvbHMsIGludm9sdmluZyBtaXNsZWFkaW5nIHBlb3BsZSBsb29r aW5nIGF0IHRoZSBkaXNwbGF5ZWQgc3RyaW5nIGluIGEgdXNlciBpbnRlcmZhY2UuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVGhlcmUgYXJlIHZhcmlvdXMg d2F5cyB0aGlzIGNvbmNlcm4gY291bGQgYmUgbWl0aWdhdGVkIChpZiB3ZSB3ZXJlIHRvIGNvbWUg dG8gYWdyZWVtZW50IHRoYXQgaXTigJlzIGV2ZW4gYSBjb25jZXJuKS4gT25lIHdvdWxkIGJlIHRv IHJlbW92ZSB0aGUg4oCcc2lnbmFsIGFyYml0cmFyeSBzdHJpbmdz4oCdIGlkZWE7IHRoaXMgaXMg Y2xlYXJseSB0aGUgc29saWRlc3Qgd2F5IHRvIGRvIGl0LiBBbm90aGVyIHdvdWxkIGJlIHRvIG1h bmRhdGUgKG9yIHN0cm9uZ2x5DQogc3VnZ2VzdCkgdGhhdCBzeW1ib2xpYyBuYW1lcyBnbGVhbmVk IGZyb20gc29tZXRoaW5nIG90aGVyIHRoYW4gY29uZmlndXJhdGlvbiBiZSBkaXNwbGF5ZWQgaW4g c3VjaCBhIHdheSBhcyB0byBtYWtlIHRoZSBvcGVyYXRvciBhd2FyZSBvZiB0aGVpciBzdGF0dXMu IEF0IGEgbWluaW11bSwgb25lIG1pZ2h0IGFkZCBhIHBhcmFncmFwaCBvciB0d28gaWRlbnRpZnlp bmcgdGhlIGNvbmNlcm4uIEnigJltIHN1cmUgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0DQog Y291bGQgYmUgY29udGVtcGxhdGVkLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsg4oCUSm9objxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C2E55EE9BC364F41834B3604B8C98A70junipernet_-- From nobody Tue Mar 22 11:31:28 2022 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 226CE3A0F40; Tue, 22 Mar 2022 11:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 PAk3T-QICKJV; Tue, 22 Mar 2022 11:30:53 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 B8E9E3A0FD7; Tue, 22 Mar 2022 11:30:50 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id a127so11781183vsa.3; Tue, 22 Mar 2022 11:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=So5Jr8zg6Qr0NQvgCAj5GsHX9aDRAEzRPvfC8GuOSZE=; b=DHldJkzcH/1tl2ES0oF6LZ8qDcrDDuTrY08x8vbYjE7mArhAyLRnVCyFz0m+9f/HAy 5FCG6scFYP9sb3KYT6e1q2a0+u6s1w9G0AsC4WzNvbog8VFUyd45OMESDCrQb0IslXQ+ YvUVxYvr0oQk/Nszopo/wsD28/5XCAI1Kcxoex9a8ceOI6rac9O828wXefvDS1ZOoQv5 nuZksE/OriFoj7HG5JiMyke3/hYHYVZt1Rch4r6VH3UbWFDj7+1olgtQRY/e4TxHkhBs EGcqdxWtR17j0JWrlm8Uy7/8gc3Y2Kt2wvLzUdlsCB/N1RXTVrs7GpTeDGrQY5zV0vt4 IZpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=So5Jr8zg6Qr0NQvgCAj5GsHX9aDRAEzRPvfC8GuOSZE=; b=OeVSArdCDNyglVjKWMT+VuABB6CZ49j3YbAA7fbISjmB75HkOKU2P6vOFj2dEhgTMP qFkhpoV97VBnAnUMGjvW8JDqQIIfvLoPS0Cq8k855UzfkDKgqEoDbwYf88Smq2KF9eTp KsRwXS5aoYRtxbZts2yfy6l6/JLoXy/IVySj3Q9aJfZWBn4Y1e4dnwW/XgMss//pDyzB FfNgqv5QiMXyJB7tKOTSvqyFOvN8x335nbBurj2QGpSl8p63uhoZQDVeIKAXtAsJTIX2 VBxt4KDk0l2K9d1LTLvAYaqy1LbtLrBMalHux+lEHIZCV66JvOjVD674fxsEcIShg/O5 mJIg== X-Gm-Message-State: AOAM5320qbfBQlej7eUvODdJZjTCMv6JsDecXmU9cjrYAcjK84c6byEk 4gwgWzGo8EBYkX12a+13nWAwD+7PjPobQ3pI2pnAWzFX X-Google-Smtp-Source: ABdhPJwRMSkYweWYnxBVTggdglmpJsESN73RVLLhqnzbvYtWclm6ukaEd+wsV9PbDKCrHJagTplr5tRsP6GUT42gCJ0= X-Received: by 2002:a05:6102:510c:b0:322:b84a:4212 with SMTP id bm12-20020a056102510c00b00322b84a4212mr10776441vsb.64.1647973849513; Tue, 22 Mar 2022 11:30:49 -0700 (PDT) MIME-Version: 1.0 References: <164503079307.9996.17286143339105134181@ietfa.amsl.com> <6E8C015A-C0AE-4775-9B49-09F7DA40B9B2@juniper.net> In-Reply-To: From: Ketan Talaulikar Date: Wed, 23 Mar 2022 00:00:37 +0530 Message-ID: To: John Scudder Cc: james.n.guichard@futurewei.com, draft-ietf-spring-segment-routing-policy@ietf.org, SPRING WG , spring-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000e6408605dad2cf42" Archived-At: Subject: Re: [spring] John Scudder's Discuss on draft-ietf-spring-segment-routing-policy-17: (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, 22 Mar 2022 18:31:01 -0000 --000000000000e6408605dad2cf42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks John for your inputs and suggestions. Thanks, Ketan On Tue, 22 Mar, 2022, 11:51 pm John Scudder, wrote: > Looks good, thanks. I=E2=80=99ve cleared my discuss, thanks for your work= on this. > > =E2=80=94John > > On Mar 22, 2022, at 2:11 PM, Ketan Talaulikar > wrote: > > > > Hi John, > > Thanks for your guidance with the text. Very much appreciated - especiall= y > in the middle of the busy IETF week. > > I've just posted an update to the draft with slight modifications to your > text (so as to cover both sec 2.1 and 2.6 and suggest the use of the > well-defined identifiers as a mitigation approach instead of relying sole= ly > on the symbolic names. > > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-p= olicy-22 > > > Please let us know if this addresses your concerns. > > Thanks, > Ketan > > > On Tue, Mar 22, 2022 at 11:20 PM John Scudder wrote: > >> Hi Ketan, >> >> Thanks as always for your quick reply. >> >> > On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar >> wrote: >> > >> > >> > Hi John, >> > >> > I dug into my emails and you are right that while we had a discussion >> on point 4 (i.e. security considerations associated with the use of >> symbolic names), it was not concluded. My apologies for the same. >> > >> > It might be helpful to place a context on why the draft uses symbolic >> names in the first place. The closest analogies that come to my mind are >> tunnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). >> These constructs have had symbolic names associated with them for a long >> time now - both for local use on routers (some implementation-specific - >> others specified by IETF) >> >> Sure. Anything local to the router isn=E2=80=99t related to my concern, = which is >> specific to the opportunity for a remote attacker to mislead someone on = the >> local router. I hope it=E2=80=99s clear by now that I have no issue with >> associating a symbolic name with a SR Policy (or any other thing), as su= ch. >> >> > and also signaled via routing protocols. >> >> Now that you point it out, I do see a few such, e.g. the >> SYMBOLIC-PATH-NAME in RFC 8231. That particular example has arguably >> different threat properties since the relationship between a PCE and its >> clients isn=E2=80=99t mediated through other routers; the trust relation= ship is >> clearer and the =E2=80=9Cremote attacker=E2=80=9D is not so very remote.= But I imagine >> there are other examples to be found, and I don=E2=80=99t want to split = hairs on >> this detail. >> >> > Operators are therefore quite familiar with their usage and hence thei= r >> introduction in the SR Policy construct. I don't believe the WG would wa= nt >> to take the option of their removal (it was a suggested option). >> >> I didn=E2=80=99t really expect you to; I was just laying out some points= in the >> solution space. >> >> > Then we get to option of adding specific text to the draft (in the >> security considerations?) that would discuss your concerns. Such text ma= y >> be addressed to implementators and/or operators. As mentioned above, the >> use of symbolic names for constructs similar to SR Policy name and SR >> Policy Candidate Path name is not "new" for both sets of readers. >> Therefore, I am not sure if we need to cover or add anything new in this >> document and I could not find text that I could borrow from other RFCs o= r >> point to other RFCs. e.g., >> https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2 >> >> > >> > I did look at RFC9003 but its context is very different. From your >> DISCUSS comment, I see that your concern is that a string does not have = any >> sanity checking - the operator is free to use any text. >> >> Correct. As long as you assume good will on the part of =E2=80=9Cthe ope= rator=E2=80=9D >> it=E2=80=99s all good. If you start thinking in terms of an attacker in = some >> distant part of the network injecting a policy, it becomes potentially >> concerning. >> >> > I agree. Do we want implementations to restrict something? Do we want >> to give some naming guidelines or precautions to the operators? >> >> I don=E2=80=99t think the concern is addressable on the origination side= , since >> it assumes a bad actor to begin with, and they=E2=80=99re not going to b= e bothered >> by what we write in an RFC. That was why in my suggestion I was thinking= in >> terms of display conventions. I=E2=80=99m not super excited by my own id= ea, though, >> because it reminds me uncomfortably much of the disclaimer my IT departm= ent >> slaps on every incoming email, =E2=80=9C[External Email. Be cautious of = content]=E2=80=9D. >> It=E2=80=99s not particularly actionable, and it=E2=80=99s annoying. :-( >> >> > In a previous response, your suggestions for the text for operators >> were (somewhat?) of the nature - "beware the name of the SR Policy may n= ot >> actually be correct or may be misleading because someone might have hack= ed >> into the network". I am not sure if something of that nature helps. If t= he >> names stop being meaningful then they are no more relevant? Isn't the >> security aspect to be taken care of here is to prevent hacking? Somethin= g >> beyond the scope of this draft? >> >> =E2=80=9CSecurity is everyone=E2=80=99s responsiblity.=E2=80=9D >> >> > I'll admit that I am running out of ideas on what would be a meaningfu= l >> text to add to address your concerns. Would appreciate some text suggest= ion >> that is relevant to this specific context. >> >> In the end, maybe it=E2=80=99s true that there=E2=80=99s not much to be = done, which >> sucks, but that=E2=80=99s life. But even if we throw our hands in the ai= r and say >> =E2=80=9Cnothing to be done=E2=80=9D, which is I think where we=E2=80=99= re getting to, I don=E2=80=99t >> think there would be any harm in putting a sentence or two in the Securi= ty >> Considerations such as you mention just above. Something along the lines= of, >> >> =E2=80=9CIn Section 2.1 we mention that a symbolic name MAY be signaled = along >> with a candidate path. While the value of symbolic names for display >> clarity is indisputable, as with any unrestricted freeform text received >> from external parties, there can be no absolute assurance that the >> information the text purports to show is accurate or even truthful. For >> this reason, users of implementations that display such information woul= d >> be well-advised not to rely on it without question. Furthermore, >> implementations that display such information might wish to display it i= n >> such a fashion as to differentiate it from known-good information. (Such >> display conventions are inherently implementation-specific; one example >> might be use of a distinguished text color or style for information that >> should be treated with caution.)=E2=80=9D >> >> Let=E2=80=99s be honest, the =E2=80=9Coooh be careful=E2=80=9D text prov= ides about as much >> protection as wet tissue paper, and displaying the string in magenta not= a >> whole lot more than that =E2=80=94 but it=E2=80=99s still better to disc= lose the cocnern >> than not to. >> >> Regards, >> >> =E2=80=94John >> >> > Thanks, >> > Ketan >> > >> > On Tue, Mar 22, 2022 at 2:54 AM John Scudder wrote: >> >> Hi Ketan, >> >> >> >> You asked "whether the responses and draft updates address [my] >> concerns=E2=80=9D. I=E2=80=99d say that while I=E2=80=99m not completely= happy about certain things >> (e.g., I remain unconvinced that the companion IDR doc shouldn=E2=80=99t= be a >> normative reference) I don=E2=80=99t need to continue holding a DISCUSS = on them: >> we=E2=80=99ve had a discussion, we don=E2=80=99t completely agree, these= things happen. On >> point 4 however, I don=E2=80=99t think our discussion has concluded. At = least, if >> you replied to this, I missed it: >> >> >> >> > On Feb 16, 2022, at 2:42 PM, John Scudder > 40juniper.net@dmarc.ietf.org> wrote: >> >> > >> >> >> 4. In =C2=A72.1 you talk about the signaling of symbolic names for >> candidate paths. >> >> >> Although you are careful to say that such symbolic names are only >> used for >> >> >> presentation purposes, it seems to me they still could be >> considered a new >> >> >> potential source of vulnerability, since a string that has no >> sanity-checking >> >> >> whatsoever applied by the protocol can display literally anything >> to an >> >> >> operator viewing it. Shouldn=E2=80=99t this be addressed in your S= ecurity >> >> >> Considerations? (For an example of a related Security >> Considerations, see RFC >> >> >> 9003. It=E2=80=99s probably not the best example, but it=E2=80=99s= the one I had at >> my >> >> >> fingertips=E2=80=A6) >> >> >> >> >> >> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. A= s >> such, I am not aware of security issues around printable ASCII - please = do >> point me to any references. >> >> > >> >> > You=E2=80=99re thinking too much like a protocol designer. The kind= of >> concern I=E2=80=99m thinking about has to do with using the string as a = vector to >> put some words in front of an operator, as part of a larger social >> engineering attempt. I don=E2=80=99t have a detailed attack scenario to = paint for >> you, but a quick sketch is along the lines of >> >> > >> >> > - Attacker manages to inject a candidate path with the name >> =E2=80=9CBig_Bank_Low_Latency=E2=80=9D >> >> > - ProTip: the candidate path does not actually terminate at Big_Ban= k >> >> > - Attacker then phones NOC, feigns urgency, asks NOC to redirect >> Big_Bank traffic onto that path >> >> > >> >> > You get the idea, I hope. >> >> >> >> More snipped, but this is the meat of it. In case you haven=E2=80=99t= looked >> at RFC 9003=E2=80=99s security section, here=E2=80=99s a snip from it: >> >> >> >> As BGP Shutdown Communications are likely to appear in syslog >> output, >> >> there is a risk that carefully constructed Shutdown Communication >> >> might be formatted by receiving systems in a way to make them appe= ar >> >> as additional syslog messages. >> >> >> >> (FWIW, I didn=E2=80=99t contribute that text.) >> >> >> >> Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the exa= mple above, it=E2=80=99s not >> central to the point, just like UTF-8 vs ASCII isn=E2=80=99t central. Th= e point, >> again, is that by introducing a way for an attacker to cause a target >> system to display arbitrary strings, it would seem reasonable to wonder = if >> that creates an opportunity for mischief that doesn=E2=80=99t ordinarily= exist in >> our protocols, involving misleading people looking at the displayed stri= ng >> in a user interface. >> >> >> >> There are various ways this concern could be mitigated (if we were to >> come to agreement that it=E2=80=99s even a concern). One would be to rem= ove the >> =E2=80=9Csignal arbitrary strings=E2=80=9D idea; this is clearly the sol= idest way to do it. >> Another would be to mandate (or strongly suggest) that symbolic names >> gleaned from something other than configuration be displayed in such a w= ay >> as to make the operator aware of their status. At a minimum, one might a= dd >> a paragraph or two identifying the concern. I=E2=80=99m sure there are o= ther things >> that could be contemplated. >> >> >> >> Regards, >> >> >> >> =E2=80=94John >> > >> > > --000000000000e6408605dad2cf42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks John for your inputs and=C2=A0suggestions.

Thanks,
Ketan<= /div>


On Tue, 22 Mar, 2022, 11:51 pm John Scudde= r, <jgs@juniper.net> wrote:
Looks good, thanks. I=E2=80=99ve cleared my discuss, thanks for your work o= n this.

=E2=80=94John

On Mar 22, 2022, at 2:11 PM, Ketan Talaulikar <ketant.ietf@gmail= .com> wrote:



Hi John,

Thanks for your guidance with the text. Very much appreciated - especi= ally in the middle of the busy IETF week.

I've just posted an update to the draft with slight modifications = to your text (so as to cover both sec 2.1 and 2.6 and suggest the use of th= e well-defined identifiers as a mitigation approach instead of relying sole= ly on the symbolic names.


Please let us know if this addresses your concerns.

Thanks,
Ketan


On Tue, Mar 22, 2022 at 11:20 PM John= Scudder <jgs@juniper.net> wrote:
Hi Ketan,

Thanks as always for your quick reply.

> On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar <ketant.ietf@gmail= .com> wrote:
>
>
> Hi John,
>
> I dug into my emails and you are right that while we had a discussion = on point 4 (i.e. security considerations associated with the use of symboli= c names), it was not concluded. My apologies for the same.
>
> It might be helpful to place a context on why the draft uses symbolic = names in the first place. The closest analogies that come to my mind are tu= nnels (different types - TE, IPinIP, IPsec) and MPLS LSPs (or paths). These= constructs have had symbolic names associated with them for a long time now - both for local use on routers (= some implementation-specific - others specified by IETF)

Sure. Anything local to the router isn=E2=80=99t related to my concern, whi= ch is specific to the opportunity for a remote attacker to mislead someone = on the local router. I hope it=E2=80=99s clear by now that I have no issue = with associating a symbolic name with a SR Policy (or any other thing), as such.

> and also signaled via routing protocols.

Now that you point it out, I do see a few such, e.g. the SYMBOLIC-PATH-NAME= in RFC 8231. That particular example has arguably different threat propert= ies since the relationship between a PCE and its clients isn=E2=80=99t medi= ated through other routers; the trust relationship is clearer and the =E2=80=9Cremote attacker=E2=80=9D is not so very remote= . But I imagine there are other examples to be found, and I don=E2=80=99t w= ant to split hairs on this detail.

> Operators are therefore quite familiar with their usage and hence thei= r introduction in the SR Policy construct. I don't believe the WG would= want to take the option of their removal (it was a suggested option).

I didn=E2=80=99t really expect you to; I was just laying out some points in= the solution space.

> Then we get to option of adding specific text to the draft (in the sec= urity considerations?) that would discuss your concerns. Such text may be a= ddressed to implementators and/or operators. As mentioned above, the use of= symbolic names for constructs similar to SR Policy name and SR Policy Candidate Path name is not "new"= for both sets of readers. Therefore, I am not sure if we need to cover or = add anything new in this document and I could not find text that I could bo= rrow from other RFCs or point to other RFCs. e.g., https://www.rfc-editor.org/rfc/rfc8231.html#section-7.3.2
>
> I did look at RFC9003 but its context is very different. From your DIS= CUSS comment, I see that your concern is that a string does not have any sa= nity checking - the operator is free to use any text.

Correct. As long as you assume good will on the part of =E2=80=9Cthe operat= or=E2=80=9D it=E2=80=99s all good. If you start thinking in terms of an att= acker in some distant part of the network injecting a policy, it becomes po= tentially concerning.

> I agree. Do we want implementations to restrict something? Do we want = to give some naming guidelines or precautions to the operators?

I don=E2=80=99t think the concern is addressable on the origination side, s= ince it assumes a bad actor to begin with, and they=E2=80=99re not going to= be bothered by what we write in an RFC. That was why in my suggestion I wa= s thinking in terms of display conventions. I=E2=80=99m not super excited by my own idea, though, because it reminds me uncomforta= bly much of the disclaimer my IT department slaps on every incoming email, = =E2=80=9C[External Email. Be cautious of content]=E2=80=9D. It=E2=80=99s no= t particularly actionable, and it=E2=80=99s annoying. :-(

> In a previous response, your suggestions for the text for operators we= re (somewhat?) of the nature - "beware the name of the SR Policy may n= ot actually be correct or may be misleading because someone might have hack= ed into the network". I am not sure if something of that nature helps. If the names stop being meaningful then they are no = more relevant? Isn't the security aspect to be taken care of here is to= prevent hacking? Something beyond the scope of this draft?

=E2=80=9CSecurity is everyone=E2=80=99s responsiblity.=E2=80=9D

> I'll admit that I am running out of ideas on what would be a meani= ngful text to add to address your concerns. Would appreciate some text sugg= estion that is relevant to this specific context.

In the end, maybe it=E2=80=99s true that there=E2=80=99s not much to be don= e, which sucks, but that=E2=80=99s life. But even if we throw our hands in = the air and say =E2=80=9Cnothing to be done=E2=80=9D, which is I think wher= e we=E2=80=99re getting to, I don=E2=80=99t think there would be any harm i= n putting a sentence or two in the Security Considerations such as you mention just above. Some= thing along the lines of,

=E2=80=9CIn Section 2.1 we mention that a symbolic name MAY be signaled alo= ng with a candidate path. While the value of symbolic names for display cla= rity is indisputable, as with any unrestricted freeform text received from = external parties, there can be no absolute assurance that the information the text purports to show is accurate or ev= en truthful. For this reason, users of implementations that display such in= formation would be well-advised not to rely on it without question. Further= more, implementations that display such information might wish to display it in such a fashion as to differen= tiate it from known-good information. (Such display conventions are inheren= tly implementation-specific; one example might be use of a distinguished te= xt color or style for information that should be treated with caution.)=E2=80=9D

Let=E2=80=99s be honest, the =E2=80=9Coooh be careful=E2=80=9D text provide= s about as much protection as wet tissue paper, and displaying the string i= n magenta not a whole lot more than that =E2=80=94 but it=E2=80=99s still b= etter to disclose the cocnern than not to.

Regards,

=E2=80=94John

> Thanks,
> Ketan
>
> On Tue, Mar 22, 2022 at 2:54 AM John Scudder <jgs@juniper.net> = wrote:
>> Hi Ketan,
>>
>> You asked "whether the responses and draft updates address [m= y] concerns=E2=80=9D. I=E2=80=99d say that while I=E2=80=99m not completely= happy about certain things (e.g., I remain unconvinced that the companion = IDR doc shouldn=E2=80=99t be a normative reference) I don=E2=80=99t need to= continue holding a DISCUSS on them: we=E2=80=99ve had a discussion, we don=E2=80=99= t completely agree, these things happen. On point 4 however, I don=E2=80=99= t think our discussion has concluded. At least, if you replied to this, I m= issed it:
>>
>> > On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.org> wrote:
>> >
>> >> 4. In =C2=A72.1 you talk about the signaling of symbolic = names for candidate paths.
>> >> Although you are careful to say that such symbolic names = are only used for
>> >> presentation purposes, it seems to me they still could be= considered a new
>> >> potential source of vulnerability, since a string that ha= s no sanity-checking
>> >> whatsoever applied by the protocol can display literally = anything to an
>> >> operator viewing it. Shouldn=E2=80=99t this be addressed = in your Security
>> >> Considerations? (For an example of a related Security Con= siderations, see RFC
>> >> 9003. It=E2=80=99s probably not the best example, but it= =E2=80=99s the one I had at my
>> >> fingertips=E2=80=A6)
>> >>
>> >> KT> RFC9003 uses UTF-8 while this document uses printa= ble ASCII. As such, I am not aware of security issues around printable ASCI= I - please do point me to any references.
>> >
>> > You=E2=80=99re thinking too much like a protocol designer. Th= e kind of concern I=E2=80=99m thinking about has to do with using the strin= g as a vector to put some words in front of an operator, as part of a large= r social engineering attempt. I don=E2=80=99t have a detailed attack scenario to paint for you, but a quick sketch is along the lines of
>> >
>> > - Attacker manages to inject a candidate path with the name = =E2=80=9CBig_Bank_Low_Latency=E2=80=9D
>> > - ProTip: the candidate path does not actually terminate at B= ig_Bank
>> > - Attacker then phones NOC, feigns urgency, asks NOC to redir= ect Big_Bank traffic onto that path
>> >
>> > You get the idea, I hope.
>>
>> More snipped, but this is the meat of it. In case you haven=E2=80= =99t looked at RFC 9003=E2=80=99s security section, here=E2=80=99s a snip f= rom it:
>>
>>=C2=A0 =C2=A0 As BGP Shutdown Communications are likely to appear i= n syslog output,
>>=C2=A0 =C2=A0 there is a risk that carefully constructed Shutdown C= ommunication
>>=C2=A0 =C2=A0 might be formatted by receiving systems in a way to m= ake them appear
>>=C2=A0 =C2=A0 as additional syslog messages.
>>
>> (FWIW, I didn=E2=80=99t contribute that text.)
>>
>> Please don=E2=80=99t obsess about =E2=80=9Csyslog=E2=80=9D in the = example above, it=E2=80=99s not central to the point, just like UTF-8 vs AS= CII isn=E2=80=99t central. The point, again, is that by introducing a way f= or an attacker to cause a target system to display arbitrary strings, it wo= uld seem reasonable to wonder if that creates an opportunity for mischief that= doesn=E2=80=99t ordinarily exist in our protocols, involving misleading pe= ople looking at the displayed string in a user interface.
>>
>> There are various ways this concern could be mitigated (if we were= to come to agreement that it=E2=80=99s even a concern). One would be to re= move the =E2=80=9Csignal arbitrary strings=E2=80=9D idea; this is clearly t= he solidest way to do it. Another would be to mandate (or strongly suggest) that symbolic names gleaned from something other than configurati= on be displayed in such a way as to make the operator aware of their status= . At a minimum, one might add a paragraph or two identifying the concern. I= =E2=80=99m sure there are other things that could be contemplated.
>>
>> Regards,
>>
>> =E2=80=94John
>

--000000000000e6408605dad2cf42-- From nobody Wed Mar 23 04:49:10 2022 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 793FD3A0B1C; Wed, 23 Mar 2022 04:48:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-spring-segment-routing-policy@ietf.org, james.n.guichard@futurewei.com, martin.vigoureux@nokia.com, rfc-editor@rfc-editor.org, spring-chairs@ietf.org, spring@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <164803610845.30337.497694653724072712@ietfa.amsl.com> Date: Wed, 23 Mar 2022 04:48:28 -0700 Archived-At: Subject: [spring] Protocol Action: 'Segment Routing Policy Architecture' to Proposed Standard (draft-ietf-spring-segment-routing-policy-22.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: Wed, 23 Mar 2022 11:48:29 -0000 The IESG has approved the following document: - 'Segment Routing Policy Architecture' (draft-ietf-spring-segment-routing-policy-22.txt) as Proposed Standard This document is the product of the Source Packet Routing in Networking Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ Technical Summary Segment Routing [RFC8402] allows a headend node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. Working Group Summary This document is a foundation for segment routing policy concepts and steering techniques into an SR policy. It has been largely reviewed, commented on and supported by the working group. Document Quality The document is well written with many examples of policy concepts and steering techniques. There are known implementations / implementation plans. Personnel The Document Shepherd is James N Guichard. The Responsible Area Director is Martin Vigoureux. From nobody Thu Mar 24 18:36:21 2022 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 D237D3A1275; Thu, 24 Mar 2022 18:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 AqlRjXIJHIgM; Thu, 24 Mar 2022 18:36:12 -0700 (PDT) Received: from h3cspam02-ex.h3c.com (smtp.h3c.com [60.191.123.50]) (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 0CBE73A126D; Thu, 24 Mar 2022 18:36:11 -0700 (PDT) Received: from mail.maildlp.com ([172.25.15.154]) by h3cspam02-ex.h3c.com with ESMTP id 22P1XiNu011165; Fri, 25 Mar 2022 09:33:44 +0800 (GMT-8) (envelope-from lihao@h3c.com) Received: from DAG2EX09-IDC.srv.huawei-3com.com (unknown [10.8.0.72]) by mail.maildlp.com (Postfix) with ESMTP id 3D89B231CD1F; Fri, 25 Mar 2022 09:35:00 +0800 (CST) Received: from DAG2EX05-BASE.srv.huawei-3com.com (10.8.0.68) by DAG2EX09-IDC.srv.huawei-3com.com (10.8.0.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Fri, 25 Mar 2022 09:33:45 +0800 Received: from DAG2EX05-BASE.srv.huawei-3com.com ([fe80::f963:2fad:283e:6b1c]) by DAG2EX05-BASE.srv.huawei-3com.com ([fe80::f963:2fad:283e:6b1c%2]) with mapi id 15.01.2375.017; Fri, 25 Mar 2022 09:33:45 +0800 From: Lihao To: Reshad Rahman , "rtg-bfd@ietf.org" , "jhaas@pfrc.org" , linchangwang CC: "jiangwenying@chinamobile.com" , "spring@ietf.org" Thread-Topic: Discuss on draft-lin-sbfd-path-consistency-over-srv6-00 Thread-Index: Adg9lItZSTV7l6NCQVmogVCNMcV8IgCDTBsAABGHn2A= Date: Fri, 25 Mar 2022 01:33:45 +0000 Message-ID: <2899330e688a44e3975a0174f7d5f6f0@h3c.com> References: <84d962b16db840d7a11caeb64dbc7b9c@h3c.com> <1023702339.65398.1648170488347@mail.yahoo.com> In-Reply-To: <1023702339.65398.1648170488347@mail.yahoo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.76.35] x-sender-location: DAG2 Content-Type: multipart/alternative; boundary="_000_2899330e688a44e3975a0174f7d5f6f0h3ccom_" MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam02-ex.h3c.com 22P1XiNu011165 Archived-At: Subject: Re: [spring] Discuss on draft-lin-sbfd-path-consistency-over-srv6-00 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, 25 Mar 2022 01:36:18 -0000 --_000_2899330e688a44e3975a0174f7d5f6f0h3ccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmVzaGFkDQoNCiAgIHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KICBZZXMsICBmb3Ig dGhlIGRlY3JpcHRpb24gb2YgUy1CRkQgZWNobywgaXQncyBhIHdyaXRpbmcgbWlzdGFrZQ0KDQog ICAgICBXZSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgdG8gY29udHJvbCBwYWNrZXQuDQoNCg0KQmVz dCBXaXNoZXMNCg0KTGloYW8NCg0KRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJlc2hhZCBSYWhtYW4NClNlbnQ6IEZyaWRheSwgTWFy Y2ggMjUsIDIwMjIgOTowOCBBTQ0KVG86IHJ0Zy1iZmRAaWV0Zi5vcmc7IGpoYWFzQHBmcmMub3Jn OyBsaW5jaGFuZ3dhbmcgKFJEKSA8bGluY2hhbmd3YW5nLjA0NDE0QGgzYy5jb20+DQpDYzogamlh bmd3ZW55aW5nQGNoaW5hbW9iaWxlLmNvbTsgc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTog RGlzY3VzcyBvbiBkcmFmdC1saW4tc2JmZC1wYXRoLWNvbnNpc3RlbmN5LW92ZXItc3J2Ni0wMA0K DQpIaSwNCg0KVGhhbmsgeW91IGZvciBrZWVwaW5nIHRoZSBCRkQgV0cgaW4gdGhlIGxvb3AuIEkg ZG9uJ3QgaGF2ZSBhbnkgY29tbWVudHMgb24gdGhlIGNvcnJlbGF0aW9uLCB3aWxsIGxlYXZlIHRo YXQgdG8gU1BSSU5HLg0KDQpNeSBvbmx5IHF1ZXN0aW9uIGZvciBub3cgaXMgcmVnYXJkaW5nIHRo ZSB1c2Ugb2YgUy1CRkQgZWNobyBwYWNrZXRzLiBSRkM3ODgwIHJlY29tbWVuZHMgdG8gYWxzbyB1 c2UgUy1CRkQgY29udHJvbCBwYWNrZXRzIHdoZW4gdXNpbmcgUy1CRkQgZWNobyBiZWNhdXNlIGEg dHJhbnNpdCBub2RlIGNvdWxkIHUtdHVybiB0aGUgcGFja2V0LiBBbmQgaWYgdGhlIHBhY2tldCBp cyBiZWluZyBkZWxpdmVyZWQgYW55d2F5IHRvIHRoZSBjb250cm9sIHBsYW5lIChhcyBwZXIgNC4y KSwgY29udHJvbCBwYWNrZXRzIHNob3VsZCBiZSB1c2VkIGluc3RlYWQuDQoNClJlZ2FyZHMsDQpS ZXNoYWQuDQoNCk9uIE1vbmRheSwgTWFyY2ggMjEsIDIwMjIsIDEwOjMyOjAwIFBNIEVEVCwgbGlu Y2hhbmd3YW5nIDxsaW5jaGFuZ3dhbmcuMDQ0MTRAaDNjLmNvbTxtYWlsdG86bGluY2hhbmd3YW5n LjA0NDE0QGgzYy5jb20+PiB3cm90ZToNCg0KDQoNCkhpIFdHICxDaGFpcnM6DQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0 ZW5jeS1vdmVyLXNydjYtMDANCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8g a2VlcCB0aGUgZm9yd2FyZCBwYXRoIGFuZA0KcmV2ZXJzZSBwYXRoIG9mIFMtQkZEIGNvbnNpc3Rl bnQgd2hlbiBkZXRlY3RpbmcgU1J2NiBQb2xpY3kuDQoNClRoZXJlIGlzIG5vIG1lZXRpbmcgZm9y IGJmZCBpbiBJRVRGLTExMywgIHdlIHdpbGwgcHJlc2VudCB0aGlzIGRyYWZ0IGluIHNwcmluZyBX RzoNCiAgTWFyY2ggMjUsIDIwMjIgIDEyOjMwLTE0OjMwIEZyaWRheSBBZnRlcm5vb24gc2Vzc2lv biBJIChVVEMrMSkNCiAgbyBTLUJGRCBQYXRoIENvbnNpc3RlbmN5IG92ZXIgU1J2NlsgNSBtaW51 dGVzIF0NCg0KUy1CRkQgY291bGQgYmUgdXNlZCB0byBtb25pdG9yIFNSdjYgUG9saWN5LCAgYSBz ZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCBhIHNlZ21lbnQgbGlzdC4NClBhdGggaW5jb25zaXN0ZW5j eSBtYXkgY2F1c2UgZmFsc2UgcG9zaXRpdmUgaXNzdWUuDQpUbyB0aGUgaXNzdWUsIFRoZSBjb25z aXN0ZW5jeSBvZiBmb3J3YXJkIGFuZCByZXZlcnNlIHBhdGggb2YgdGhlIHNhbWUgc2Vzc2lvbiBz aG91bGQgYmUgZ3VhcmFudGVlZC4NClRoaXMgZHJhZnQgZGVzY3JpYmVzIGhvdyB0byByZWFsaXpl IHRoZSBiaWRpcmVjdGlvbmFsIHBhdGggY29uc2lzdGVuY3kgb2YgcGFja2V0IHdoZW4gbW9uaXRv cmluZyBTUnY2IHBvbGljeSBieSBTLUJGRC4NCg0KSG93IHRvIGNvcnJlbGF0ZSBiaWRpcmVjdGlv bmFsIHBhdGg/DQoxLiAgQ29ycmVsYXRpbmcgYmlkaXJlY3Rpb25hbCBwYXRoIHVzaW5nIFBhdGgg U2VnbWVudA0KICAgIDIuICBQYXRoIFNlZ21lbnQgaXMgZGVmaW5lZCB0byBpZGVudGlmeSBhbiBT UiBwYXRoIGluIFtkcmFmdC1pZXRmLXNwcmluZy1zcnY2LXBhdGgtc2VnbWVudF0NCiAgICAzLiAg W2RyYWZ0LWlldGYtaWRyLXNyLXBvbGljeS1wYXRoLXNlZ21lbnRdIGV4dGVuZHMgQkdQIFNSIFBv bGljeQ0KICAgIDQuICBVc2luZyBwYXRoIHNlZ21lbnQgYW5kIHJldmVyc2UgcGF0aCBzZWdtZW50 IHRvIGVzdGFibGlzaCBhIG1hcHBpbmcgdGFibGUNCiAgICAgIFVzaW5nIHRoZSBtYXBwaW5nIHRh YmxlIHRvIGdldCBzZWdtZW50IGxpc3QgYnkgcmV2ZXJzZSBQYXRoIHNlZ21lbnQNCg0KUy1CRkQg SW5pdGlhdG9yIHByb2NlZHVyZToNCiAgICAxLiBFbmNhcHN1bGF0aW5nIHRoZSBzZWdtZW50IGxp c3QgYXNzb2NpYXRlZCB3aXRoIFNCRkQtc2Vzc2lvbiBzZXNzaW9uIHRvIFNSSA0KICAgIDIuIEVu Y2Fwc3VsYXRpbmcgdGhlIHBhdGggc2VnbWVudCBvZiBzZWdtZW50IGxpc3QgaW4gU1JILCBhbmQg c2V0IFNSSC5QLUZsYWcNCg0KUy1CRkQgcmVmbGVjdG9yIHByb2NlZHVyZToNCiAgICAxLiBJZiBT UkguUC1mbGFnIGlzIHNldCwgZXh0cmFjdHMgdGhlIHBhdGggc2VnbWVudCAoaS5lLiBTSUQtUGF0 aC1BMSlvZiB0aGUgZm9yd2FyZCBwYXRoIGZyb20gU1JIDQogICAgMi5HZXQgc2VnbWVudCBsaXN0 IG9mIHJldmVyc2UgcGF0aCBieSB0aGUgcGF0aCBzZWdtZW50IGFzIGEgcmV2ZXJzZSBwYXRoIHNl Z21lbnQgZnJvbSBtYXBwaW5nIHRhYmxlDQogICAgMy4gRW5jYXBzdWxhdGluZyByZXNwb25zZSBw YWNrZXQgd2l0aCB0aGUgcmV2ZXJzZSBzZWdtZW50IGxpc3QNCg0KQW55IGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgZ3JlYXRseSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQpDaGFuZ3dh bmcgTGluDQoNCg0KDQrlj5Hku7bkuro6IGxpbmNoYW5nd2FuZyAoUkQpDQrlj5HpgIHml7bpl7Q6 IDIwMjLlubQz5pyIMuaXpSAyMzoxNw0K5pS25Lu25Lq6OiBqaWFuZ3dlbnlpbmdAY2hpbmFtb2Jp bGUuY29tPG1haWx0bzpqaWFuZ3dlbnlpbmdAY2hpbmFtb2JpbGUuY29tPjsgY2hlbmd3ZWlxaWFu ZyAoY2hlbmd3ZWlxaWFuZ0BjaGluYW1vYmlsZS5jb208bWFpbHRvOmNoZW5nd2VpcWlhbmdAY2hp bmFtb2JpbGUuY29tPik7IGxpaGFvICgwMjU2NiwgUkQpOyAncnRnLWJmZEBpZXRmLm9yZzxtYWls dG86cnRnLWJmZEBpZXRmLm9yZz4nDQrkuLvpopg6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1saW4t c2JmZC1wYXRoLWNvbnNpc3RlbmN5LW92ZXItc3J2Ni0wMC50eHQNCg0KSGkgV0csDQoNCldlIGhh dmUganVzdCBwb3N0ZWQgYSBuZXcgZHJhZnQgYWJvdXQgc2JmZCBwYXRoIGNvbnNpc3RlbmN5IG92 ZXIgU1J2NiBpbiBCRkRXRy4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNydjYtMDANCg0KVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8ga2VlcCB0aGUgZm9yd2FyZCBwYXRoIGFuZA0KcmV2 ZXJzZSBwYXRoIG9mIFMtQkZEIGNvbnNpc3RlbnQgd2hlbiBkZXRlY3RpbmcgU1J2NiBQb2xpY3ku DQoNCkFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkgd2VsY29tZS4NCg0K QmVzdCByZWdhcmRzLA0KQ2hhbmd3YW5nIExpbg0KDQoNCg0KDQoNCuWPkeS7tuS6ujogSS1ELUFu bm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmktZC1h bm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPl0g5Luj6KGoIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K5Y+R6YCB5pe26Ze0OiAyMDIy5bm0 M+aciDLml6UgMTk6MzMNCuaUtuS7tuS6ujogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzpp LWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQrkuLvpopg6IEktRCBBY3Rpb246IGRyYWZ0LWxpbi1zYmZk LXBhdGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwLnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgIDogUy1CRkQgUGF0aCBDb25zaXN0ZW5j eSBvdmVyIFNSdjYNCiAgICAgICAgQXV0aG9ycyAgICAgICAgOiBDaGFuZ3dhbmcgTGluDQogICAg ICAgICAgICAgICAgICAgICAgICAgIFdlaXFpYW5nIENoZW5nDQogICAgICAgICAgICAgICAgICAg ICAgICAgIFdlbnlpbmcgSmlhbmcNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWxpbi1zYmZkLXBh dGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwLnR4dA0KUGFnZXMgICAgICAgICAgOiAxMg0KRGF0 ZSAgICAgICAgICAgIDogMjAyMi0wMy0wMg0KDQpBYnN0cmFjdDoNCiAgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBjYW4gYmUgdXNlZCB0byBtb25pdG9yDQogIHBhdGhz IGJldHdlZW4gbm9kZXMuIFNlYW1sZXNzIEJGRCAoUy1CRkQpIHByb3ZpZGVzIGEgc2ltcGxpZmll ZA0KICBtZWNoYW5pc20gd2hpY2ggaXMgc3VpdGFibGUgZm9yIG1vbml0b3Jpbmcgb2YgcGF0aHMg dGhhdCBhcmUgc2V0dXANCiAgZHluYW1pY2FsbHkgYW5kIG9uIGEgbGFyZ2Ugc2NhbGUgbmV0d29y ay4gSW4gU1J2Niwgd2hlbiBhIGhlYWRlbmQNCiAgdXNlIFMtQkZEIHRvIG1vbml0b3IgdGhlIHNl Z21lbnQgbGlzdC9DUGF0aCBvZiBTUnY2IFBvbGljeSwgdGhlDQogIGZvcndhcmQgcGF0aCBvZiBT LUJGRCBwYWNrZXQgaXMgaW5kaWNhdGVkIGJ5IHNlZ21lbnQgbGlzdCwgdGhlDQogIHJldmVyc2Ug cGF0aCBvZiBCRkQgcGFja2V0IGlzIHZpYSB0aGUgc2hvcnRlc3QgcGF0aCBmcm9tIHRoZQ0KICBy ZWZsZWN0b3IgYmFjayB0byB0aGUgaW5pdGlhdG9yIChoZWFkZW5kKSBhcyBkZXRlcm1pbmVkIGJ5 IHJvdXRpbmcuDQogIFRoZSBmb3J3YXJkIHBhdGggYW5kIHJldmVyc2UgcGF0aCBvZiBTLUJGRCBw YWNrZXQgYXJlIGxpa2VseQ0KICBpbmNvbnNpc3RlbnQgZ29pbmcgdGhyb3VnaCBkaWZmZXJlbnQg aW50ZXJtZWRpYXRlIG5vZGVzIG9yIGxpbmtzLg0KICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IG1ldGhvZCB0byBrZWVwIHRoZSBmb3J3YXJkIHBhdGggYW5kDQogIHJldmVyc2UgcGF0aCBvZiBT LUJGRCBjb25zaXN0ZW50IHdoZW4gZGV0ZWN0aW5nIFNSdjYgUG9saWN5Lg0KDQoNClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVy LXNydjYvDQoNClRoZXJlIGlzIGFsc28gYW4gaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpbi1zYmZkLXBh dGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwDQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSByc3luYyBhdCByc3luYy5pZXRmLm9yZzo6aW50ZXJuZXQtZHJhZnRzDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1B bm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86SS1ELUFu bm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p LWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVz LnR4dA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5paw 5Y2O5LiJ6ZuG5Zui55qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw 5Z2A5Lit5YiX5Ye6DQrnmoTkuKrkurrmiJbnvqTnu4TjgILnpoHmraLku7vkvZXlhbbku5bkurrk u6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIbl nLDms4TpnLLjgIHlpI3liLbjgIENCuaIluaVo+WPke+8ieacrOmCruS7tuS4reeahOS/oeaBr+OA guWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7 tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrA0K6YKu5Lu277yBDQpUaGlzIGUtbWFpbCBhbmQg aXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gTmV3 IEgzQywgd2hpY2ggaXMNCmludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdo b3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0 bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1p bmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykg aXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlcg0KYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSBpdCENCg== --_000_2899330e688a44e3975a0174f7d5f6f0h3ccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlc2hhZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyB0aGFua3MgZm9y IHlvdXIgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7IFllcywmbmJzcDsgZm9yIHRoZSBkZWNyaXB0aW9uIG9mIFMtQkZEIGVjaG8sIGl0J3Mg YSB3cml0aW5nIG1pc3Rha2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2Ugd2lsbCB1cGRhdGUgdGhlIGRyYWZ0 IHRvIGNvbnRyb2wgcGFja2V0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJlc3QgV2lzaGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxpaGFvDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlJlc2hhZCBSYWhtYW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJj aCAyNSwgMjAyMiA5OjA4IEFNPGJyPg0KPGI+VG86PC9iPiBydGctYmZkQGlldGYub3JnOyBqaGFh c0BwZnJjLm9yZzsgbGluY2hhbmd3YW5nIChSRCkgJmx0O2xpbmNoYW5nd2FuZy4wNDQxNEBoM2Mu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gamlhbmd3ZW55aW5nQGNoaW5hbW9iaWxlLmNvbTsgc3By aW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBEaXNjdXNzIG9uIGRyYWZ0LWxp bi1zYmZkLXBhdGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoYW5rIHlvdSBmb3Iga2VlcGlu ZyB0aGUgQkZEIFdHIGluIHRoZSBsb29wLiBJIGRvbid0IGhhdmUgYW55IGNvbW1lbnRzIG9uIHRo ZSBjb3JyZWxhdGlvbiwgd2lsbCBsZWF2ZSB0aGF0IHRvIFNQUklORy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TXkgb25seSBxdWVzdGlv biBmb3Igbm93IGlzIHJlZ2FyZGluZyB0aGUgdXNlIG9mIFMtQkZEIGVjaG8gcGFja2V0cy4gUkZD Nzg4MCByZWNvbW1lbmRzIHRvIGFsc28gdXNlIFMtQkZEIGNvbnRyb2wgcGFja2V0cyB3aGVuIHVz aW5nIFMtQkZEIGVjaG8gYmVjYXVzZSBhIHRyYW5zaXQgbm9kZQ0KIGNvdWxkIHUtdHVybiB0aGUg cGFja2V0LiBBbmQgaWYgdGhlIHBhY2tldCBpcyBiZWluZyBkZWxpdmVyZWQgYW55d2F5IHRvIHRo ZSBjb250cm9sIHBsYW5lIChhcyBwZXIgNC4yKSwgY29udHJvbCBwYWNrZXRzIHNob3VsZCBiZSB1 c2VkIGluc3RlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZXNoYWQuICZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9InlkcDE5OTE5OTBheWFob29fcXVvdGVk Xzg3MzQ4NDIyMDYiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+T24gTW9uZGF5LCBNYXJjaCAy MSwgMjAyMiwgMTA6MzI6MDAgUE0gRURULCBsaW5jaGFuZ3dhbmcgJmx0OzxhIGhyZWY9Im1haWx0 bzpsaW5jaGFuZ3dhbmcuMDQ0MTRAaDNjLmNvbSI+bGluY2hhbmd3YW5nLjA0NDE0QGgzYy5jb208 L2E+Jmd0OyB3cm90ZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2 MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzI2MjgyQSI+SGkgV0cgLENoYWlyczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyNjI4MkEiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNydjYtMDAiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpbi1z YmZkLXBhdGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRo b2QgdG8ga2VlcCB0aGUgZm9yd2FyZCBwYXRoIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjYyODJBIj5yZXZlcnNlIHBhdGggb2YgUy1CRkQgY29uc2lzdGVudCB3 aGVuIGRldGVjdGluZyBTUnY2IFBvbGljeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyNjI4MkEiPlRoZXJlIGlzIG5vIG1lZXRpbmcgZm9yIGJmZCBpbiBJRVRGLTExMywm bmJzcDsgd2Ugd2lsbCBwcmVzZW50IHRoaXMgZHJhZnQgaW4gc3ByaW5nIFdHOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJzcDsgTWFyY2ggMjUsIDIw MjImbmJzcDsgMTI6MzAtMTQ6MzAgRnJpZGF5IEFmdGVybm9vbiBzZXNzaW9uIEkgKFVUQyYjNDM7 MSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jm5ic3A7 IG8gUy1CRkQgUGF0aCBDb25zaXN0ZW5jeSBvdmVyIFNSdjZbIDUgbWludXRlcyBdPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5TLUJGRCBjb3VsZCBiZSB1c2Vk IHRvIG1vbml0b3IgU1J2NiBQb2xpY3ksJm5ic3A7IGEgc2Vzc2lvbiBhc3NvY2lhdGVkIHdpdGgg YSBzZWdtZW50IGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy NjI4MkEiPlBhdGggaW5jb25zaXN0ZW5jeSBtYXkgY2F1c2UgZmFsc2UgcG9zaXRpdmUgaXNzdWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPlRvIHRoZSBp c3N1ZSwgVGhlIGNvbnNpc3RlbmN5IG9mIGZvcndhcmQgYW5kIHJldmVyc2UgcGF0aCBvZiB0aGUg c2FtZSBzZXNzaW9uIHNob3VsZCBiZSBndWFyYW50ZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5UaGlzIGRyYWZ0IGRlc2NyaWJlcyBob3cgdG8gcmVh bGl6ZSB0aGUgYmlkaXJlY3Rpb25hbCBwYXRoIGNvbnNpc3RlbmN5IG9mIHBhY2tldCB3aGVuIG1v bml0b3JpbmcgU1J2NiBwb2xpY3kgYnkgUy1CRkQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMjYyODJBIj5Ib3cgdG8gY29ycmVsYXRlIGJpZGlyZWN0aW9uYWwgcGF0aD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+MS4mbmJzcDsg Q29ycmVsYXRpbmcgYmlkaXJlY3Rpb25hbCBwYXRoIHVzaW5nIFBhdGggU2VnbWVudDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJzcDsgJm5ic3A7IDIu Jm5ic3A7IFBhdGggU2VnbWVudCBpcyBkZWZpbmVkIHRvIGlkZW50aWZ5IGFuIFNSIHBhdGggaW4g W2RyYWZ0LWlldGYtc3ByaW5nLXNydjYtcGF0aC1zZWdtZW50XTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJzcDsgJm5ic3A7IDMuJm5ic3A7IFtkcmFm dC1pZXRmLWlkci1zci1wb2xpY3ktcGF0aC1zZWdtZW50XSBleHRlbmRzIEJHUCBTUiBQb2xpY3k8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jm5ic3A7ICZu YnNwOyA0LiZuYnNwOyBVc2luZyBwYXRoIHNlZ21lbnQgYW5kIHJldmVyc2UgcGF0aCBzZWdtZW50 IHRvIGVzdGFibGlzaCBhIG1hcHBpbmcgdGFibGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzI2MjgyQSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVXNpbmcgdGhlIG1hcHBp bmcgdGFibGUgdG8gZ2V0IHNlZ21lbnQgbGlzdCBieSByZXZlcnNlIFBhdGggc2VnbWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Uy1CRkQgSW5pdGlhdG9y IHByb2NlZHVyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2Mjgy QSI+Jm5ic3A7ICZuYnNwOyAxLiBFbmNhcHN1bGF0aW5nIHRoZSBzZWdtZW50IGxpc3QgYXNzb2Np YXRlZCB3aXRoIFNCRkQtc2Vzc2lvbiBzZXNzaW9uIHRvIFNSSDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJzcDsgJm5ic3A7IDIuIEVuY2Fwc3VsYXRp bmcgdGhlIHBhdGggc2VnbWVudCBvZiBzZWdtZW50IGxpc3QgaW4gU1JILCBhbmQgc2V0IFNSSC5Q LUZsYWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPlMtQkZE IHJlZmxlY3RvciBwcm9jZWR1cmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyNjI4MkEiPiZuYnNwOyAmbmJzcDsgMS4gSWYgU1JILlAtZmxhZyBpcyBzZXQsIGV4dHJh Y3RzIHRoZSBwYXRoIHNlZ21lbnQgKGkuZS4gU0lELVBhdGgtQTEpb2YgdGhlIGZvcndhcmQgcGF0 aCBmcm9tIFNSSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJB Ij4mbmJzcDsgJm5ic3A7IDIuR2V0IHNlZ21lbnQgbGlzdCBvZiByZXZlcnNlIHBhdGggYnkgdGhl IHBhdGggc2VnbWVudCBhcyBhIHJldmVyc2UgcGF0aCBzZWdtZW50IGZyb20gbWFwcGluZyB0YWJs ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJzcDsg Jm5ic3A7IDMuIEVuY2Fwc3VsYXRpbmcgcmVzcG9uc2UgcGFja2V0IHdpdGggdGhlIHJldmVyc2Ug c2VnbWVudCBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4 MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJB Ij5BbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBncmVhdGx5IHdlbGNvbWUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5CZXN0IHJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPkNoYW5nd2FuZyBM aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMjYyODJBIj7lj5Hku7bkuro8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjogbGluY2hh bmd3YW5nIChSRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMjYyODJB Ij7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPjogMjAyMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjojMjYyODJBIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPjM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzI2 MjgyQSI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYy ODJBIj4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMyNjI4MkEi PuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+ DQogMjM6MTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMjYyODJBIj7m lLbku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4 MkEiPjoNCjxhIGhyZWY9Im1haWx0bzpqaWFuZ3dlbnlpbmdAY2hpbmFtb2JpbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+amlhbmd3ZW55aW5nQGNoaW5hbW9iaWxlLmNvbTwvYT47IGNoZW5nd2VpcWlh bmcgKDxhIGhyZWY9Im1haWx0bzpjaGVuZ3dlaXFpYW5nQGNoaW5hbW9iaWxlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmNoZW5nd2VpcWlhbmdAY2hpbmFtb2JpbGUuY29tPC9hPik7IGxpaGFvICgwMjU2 NiwgUkQpOyAnPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5ydGctYmZkQGlldGYub3JnPC9hPic8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjojMjYyODJBIj7kuLvpopg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyNjI4MkEiPjogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWxpbi1zYmZkLXBhdGgtY29u c2lzdGVuY3ktb3Zlci1zcnY2LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzI2MjgyQSI+SGkgV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjYyODJBIj5XZSBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IGRyYWZ0IGFib3V0IHNiZmQgcGF0 aCBjb25zaXN0ZW5jeSBvdmVyIFNSdjYgaW4gQkZEV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNydjYt MDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWxpbi1zYmZkLXBhdGgtY29uc2lzdGVuY3ktb3Zlci1zcnY2LTAwPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+VGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYSBtZXRob2QgdG8ga2VlcCB0aGUgZm9yd2FyZCBwYXRoIGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5yZXZlcnNlIHBhdGggb2YgUy1CRkQg Y29uc2lzdGVudCB3aGVuIGRldGVjdGluZyBTUnY2IFBvbGljeS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPkFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMg YXJlIGdyZWF0bHkgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzI2MjgyQSI+Q2hhbmd3YW5nIExpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 IzI2MjgyQSI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj46IEktRC1Bbm5vdW5jZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppLWQt YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjojMjYyODJBIj7ku6Pooag8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2 MjgyQSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzI2MjgyQSI+5Y+R 6YCB5pe26Ze0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYy ODJBIj46IDIwMjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzI2 MjgyQSI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYy ODJBIj4zPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMyNjI4MkEi PuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+ Mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMjYyODJBIj7ml6U8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPg0KIDE5 OjMzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzI2MjgyQSI+5pS25Lu2 5Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj46 DQo8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOiMyNjI4MkEiPuS4u+mimDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+OiBJLUQgQWN0aW9uOiBkcmFmdC1saW4tc2JmZC1wYXRoLWNvbnNp c3RlbmN5LW92ZXItc3J2Ni0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjYyODJBIj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzI2MjgyQSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFMtQkZEIFBhdGggQ29uc2lzdGVuY3kg b3ZlciBTUnY2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDogQ2hhbmd3YW5nIExpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV2VpcWlhbmcg Q2hlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlbnlpbmcgSmlhbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+RmlsZW5hbWUmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1saW4tc2JmZC1wYXRoLWNvbnNpc3RlbmN5LW92ZXItc3J2 Ni0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+ UGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMTI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+RGF0ZSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMi0wMy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+QWJzdHJhY3Q6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPiZuYnNwOyBCaWRpcmVjdGlvbmFsIEZvcndhcmRp bmcgRGV0ZWN0aW9uIChCRkQpIGNhbiBiZSB1c2VkIHRvIG1vbml0b3I8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+Jm5ic3A7IHBhdGhzIGJldHdlZW4gbm9k ZXMuIFNlYW1sZXNzIEJGRCAoUy1CRkQpIHByb3ZpZGVzIGEgc2ltcGxpZmllZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJzcDsgbWVjaGFuaXNtIHdo aWNoIGlzIHN1aXRhYmxlIGZvciBtb25pdG9yaW5nIG9mIHBhdGhzIHRoYXQgYXJlIHNldHVwPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPiZuYnNwOyBkeW5h bWljYWxseSBhbmQgb24gYSBsYXJnZSBzY2FsZSBuZXR3b3JrLiBJbiBTUnY2LCB3aGVuIGEgaGVh ZGVuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj4mbmJz cDsgdXNlIFMtQkZEIHRvIG1vbml0b3IgdGhlIHNlZ21lbnQgbGlzdC9DUGF0aCBvZiBTUnY2IFBv bGljeSwgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEi PiZuYnNwOyBmb3J3YXJkIHBhdGggb2YgUy1CRkQgcGFja2V0IGlzIGluZGljYXRlZCBieSBzZWdt ZW50IGxpc3QsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYy ODJBIj4mbmJzcDsgcmV2ZXJzZSBwYXRoIG9mIEJGRCBwYWNrZXQgaXMgdmlhIHRoZSBzaG9ydGVz dCBwYXRoIGZyb20gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMy NjI4MkEiPiZuYnNwOyByZWZsZWN0b3IgYmFjayB0byB0aGUgaW5pdGlhdG9yIChoZWFkZW5kKSBh cyBkZXRlcm1pbmVkIGJ5IHJvdXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyNjI4MkEiPiZuYnNwOyBUaGUgZm9yd2FyZCBwYXRoIGFuZCByZXZlcnNlIHBhdGgg b2YgUy1CRkQgcGFja2V0IGFyZSBsaWtlbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+Jm5ic3A7IGluY29uc2lzdGVudCBnb2luZyB0aHJvdWdoIGRpZmZl cmVudCBpbnRlcm1lZGlhdGUgbm9kZXMgb3IgbGlua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPiZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IG1ldGhvZCB0byBrZWVwIHRoZSBmb3J3YXJkIHBhdGggYW5kPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPiZuYnNwOyByZXZlcnNlIHBhdGggb2YgUy1CRkQg Y29uc2lzdGVudCB3aGVuIGRldGVjdGluZyBTUnY2IFBvbGljeS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzI2MjgyQSI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5jeS1vdmVyLXNydjYvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25z aXN0ZW5jeS1vdmVyLXNydjYvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzI2MjgyQSI+VGhlcmUgaXMgYWxzbyBhbiBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1saW4tc2JmZC1w YXRoLWNvbnNpc3RlbmN5LW92ZXItc3J2Ni0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGluLXNiZmQtcGF0aC1jb25zaXN0ZW5j eS1vdmVyLXNydjYtMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2 MjgyQSI+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSByc3luYyBhdCByc3lu Yy5pZXRmLm9yZzo6aW50ZXJuZXQtZHJhZnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyNjI4MkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjYyODJBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzI2MjgyQSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+SS1E LUFubm91bmNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjYyODJBIj48YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5JbnRlcm5ldC1EcmFmdCBkaXJl Y3RvcmllczoNCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYyODJBIj5vcg0KPGEgaHJlZj0iZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj5mdHA6 Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMyNjI4MkEiPuacrOmCruS7tuWPiuWF tumZhOS7tuWQq+acieaWsOWNjuS4iembhuWboueahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWP kemAgee7meS4iumdouWcsOWdgOS4reWIl+WHujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6IzI2MjgyQSI+55qE5Liq5Lq65oiW576k57uE44CC56aB5q2i5Lu75L2V5YW25LuW5Lq6 5Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG 5Zyw5rOE6Zyy44CB5aSN5Yi244CBPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjYyODJBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjoj MjYyODJBIj7miJbmlaPlj5HvvInmnKzpgq7ku7bkuK3nmoTkv6Hmga/jgILlpoLmnpzmgqjplJnm lLbkuobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bk urrlubbliKDpmaTmnKw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyNjI4MkEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMyNjI4MkEi PumCruS7tu+8gTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2 MjgyQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyNjI4MkEiPlRo aXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24gZnJvbSBOZXcgSDNDLCB3aGljaCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMjYyODJBIj5pbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0 eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+aW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90 YWwgb3IgcGFydGlhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjYy ODJBIj5kaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNv bnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzI2MjgyQSI+cmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNl aXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzI2MjgyQSI+YnkgcGhvbmUgb3IgZW1h aWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2899330e688a44e3975a0174f7d5f6f0h3ccom_-- From nobody Fri Mar 25 01:19:48 2022 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 4619E3A11DC for ; Thu, 24 Mar 2022 18:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=yahoo.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 wDigz-SVWVsF for ; Thu, 24 Mar 2022 18:09:20 -0700 (PDT) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (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 DD0713A11CF for ; Thu, 24 Mar 2022 18:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648170555; bh=hHfvgi0KSiR/TznLvw8VF0YEv9DWLcJ2dmibVUcv5Xo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=b+BkxvTEms/NmtdrV9ZFC83gSLppk/l8Debstr7gX8rHRDQ465i9R7KtSs+o2BBr2Hl2Ke//6EvzwFL/riYry7Yywa/580/zfyNAmc9wzWRE+IbVZRpT2z15l2medOvA7Q6iikogO/piRi4E2ZnoxLsjQnkyV8+GaTDAq8SukpcByYMjQEEOIN1I8wepwNN0m7opfX+LbHHnwteHoNzZPVXDSHoHmopdruTjFY+NNVKK3SMsrRM5dMLaAPOGu+qGUhFS8wUpMuubBIu12dhCXfyMxLtrxSlw26V3lFoUBKCRfudnGMvdU7J/A68UMZ4JJn8L/zYO3Sb6DslmTE3siQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648170555; bh=V3Ce4ax322FJzQ/v019uG2/MECz6sWHZQCMN1PnQxOF=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=TSWi6/ddTOg4e2OYjPbN5RWYCkJMQQ1mih8BcgfC6RJSZAIDYc4J1zpPUXZb+lKSju90w8mWIt+1bL3vYKyUn3qisylWCqnjvOG3Zcb2ecz5xQ/OCIks2E0YoMjZXLMZ8ITrI6hWbhsO4lThAg0W8WozbN0Gb51nT3j6twYYazGSsxeCO9Oz1Nxhdht4RnpIusFdJUjaU/LPIQe2l9z0fsyCCLf2G6GtYJXYjvqpe4mlgvYZFDkITNFAcB/ZwPZCiNkc23sX2PcnRnVD2ecKf8rBLRadImDXutzTFNQZuXfTw7w1h4R9Yl+YrbQssmKuKZzEQCfQ+oywke5agZ2hZQ== X-YMail-OSG: k6mFzqsVM1m0lIl_.rBKgozc64SUHfBvbCYQ_SlRPCjPAkymY7._h3B9jz7TcX6 68uxSuI8GLLuLR0sjYVwrcA.WmYi2lsPEFWrQFTchM20eu7aN1.2jWOh23Yz.2q.OWspC2MJOK1m CVl0_DJw.JKJZ5sxuYeYNnDdnoOGDEvqVCuNpR.jlwgbxVBAfXDKA9FGQrS8uvPpASE3tvlK0PKv 5h7Ae9WW46LAJeE71g1nlRzCh1qTDDTUzMzY.O1KEqblfo6BsEuxo7yvnPOaRWotvk3sv11gWcnk aFJlfNWm_03h1okKNLS1hvnEhOODDfN71GJZdLPJT.P426N7Ous1Js4V.SYBlZo68ZZwPmgFu_6x OgsIg_aTkPF3HUtEXYE8rATedchFizd448Tw_Y4Z_e9.gmXXzvp1TBMtbki4sBnLozHkEEH6chtT lFvEDfVRY4ILl3N_ZsccGAT_1UG3SLdSPSKY.Dz5H3cK1NrySSSueoH2KFciyVy2WWo4dX6d4mx6 5P_9BhiMavdpm8Rs63ryRXLVvk4e.JprCj.MrA5rd0pjD6P2bwdOman0WB3Euuhuw0SHhfUILhRF nC5M5iiKz1PzmZg8dDQUvnfJAik5i58BIjBoTfSaPJ4V_Q5oRJIX5RhHMkR1AyaqOrBKl.G02c5t AtQQCloig0QR7Hpt0e_klC6wyHTUMyzM.7a7siLY3RK726tY5VXlMcWn6zLZVekG_TAnxKkyEvS8 HDBio890gEEng8K6d2mmmR2BySUgdXsRuYcNIsZMnaEcfVh9la.hQiZMSQ4ppg2MtYM1xAoEtey1 junk0TJ8t726hYMm52wbayne9zKxnqb4OUWkz_yA_OY_1a1iuKd5GoQEf3PUtHjWM7s2Z7Ne8QRq _xlnDn4WWRTia0lDcMPlbj_UNfLKgG1Ahp5nsxF6Gssp1pnxaUtDXN4PmDHfyJVwf7T5bhx8XjQH 3PLeCUoVyt7znTW4O3xfZTkbQt7_JhOQkFGN47urSPIvLNqFzWVepVfCVI2H11g24WfA0GshFmqF 7mwvNrImCjA4fGtx7g0yZO9sB3r29EaNnkTbjq32R3_QgKpE45o1DIOJp1M11FfpqAB9cjPFJy4G OzH0aGfvT6PG042cj2brmeOLFe_oRi3qMMBaAU7fDnfxtVVAQwYAzj2PGkeN7JKr_sB0OR3uP4g8 ufmPYh4STcQR26pc1umoVLpCp_hX3oipc.NVj2wVa4XZiHh7OZHYMGVZ2ajZEtYX.9W5WuscZFv7 wpNoHvlx_VF.r6Wt_8lsNn4XHuN.vcuncAmfTK9YtRCkJjug2tfkmDYA0YjMT2gw6vO339952o5B hJGUQbEmiwAnLn9folyaeLKBNU70cNZNoL.XIQJVIWynHKWY.BePgi7g4.qslxmbvKFebgt_ovBi xpVRvvGZNYsClG7wamhQnVsjCrwDg1CNJ2PwKph15alLXA6FOHmmGVR2A8prvo.y7tT4GVSyS87n MY1bYcZ6kE7ElpbOfJdcNYue6JZ6GRgv.Ms0ML3cfSBCJ3LO4euZCcUD8ykG4btSDxpU2vbe3_a_ aQWKerCqeOUAsDgd5jiDE1wQB99mFDNiZZOpyrxmUFcNzYkPado2NR51pR6AMPhYuq0CnqTUtGOI l81cnhrzoVQMu7DgjMTOdgTgpgxhfpZtv7pDgUJqW1KxRFaSSRylmELdogCawfwghwLRhS_GJTVU qljaTvOtfqFJHI7jmgqs73lF.EqfZ9UHNmDaXrdq9p9tYsfpuVEYnTfpyDpiEbRCa.TGBiFY0nZJ K96wNXtmq2lgGYQuP.98Q_BoixekxyWyiKW5lnHiqZhSqZ6PhiYf8eBOeg4fXKpTx8uwI_gOoKeJ aVxBwPXCLc1b0zsI1u6FIT8Gt_zWxmVW4_Bx1EZq1IebQCM0B50U4spXl8rpxiWdl4TZRZsdnGtb tIn7qnvoMWRz0XYt4mX5osuYeG.4gXTojUZLtsD0qU22lkc5nwBMq4gzf.4Lm6a4CF5d90KJY7cr rFbve9NsdtFyUpG46q4.5JTTX4ThQ9qQDy1JxWpo30ablvDobJT9HEwfMKOoV5BuCGNjwAAIATie 9tlXFg0NGQKSFKViVNGpwMHrDN1HhQ7LtJisvSQv6Uf8Kl_Ewy_sesvty6s3VfBwicrBbwwXBd.N XiINZrrvOmX1H_obBcxjwIIV9PsySociCtRrmerJnLo_um7zd2aYV34tStKnQvYwNmIL_cKjxt_t vAnrIqfBleXhVQw3jXNnA3IkltYW6FBfz4uOLMW.IVVabQguyQmsvTAHcRre1Hxox9nF1gK5A4C_ BsCFTmKM6nU6a0AHkhY4IFULxsQM0eWPZ6r5sKiCrdRoIw7Fh6kqA1iv4Lg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Fri, 25 Mar 2022 01:09:15 +0000 Date: Fri, 25 Mar 2022 01:08:08 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: "rtg-bfd@ietf.org" , "jhaas@pfrc.org" , linchangwang Cc: "jiangwenying@chinamobile.com" , "spring@ietf.org" Message-ID: <1023702339.65398.1648170488347@mail.yahoo.com> In-Reply-To: <84d962b16db840d7a11caeb64dbc7b9c@h3c.com> References: <84d962b16db840d7a11caeb64dbc7b9c@h3c.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_65397_624625370.1648170488344" X-Mailer: WebService/1.1.19987 YMailNorrin Archived-At: X-Mailman-Approved-At: Fri, 25 Mar 2022 01:19:46 -0700 Subject: Re: [spring] Discuss on draft-lin-sbfd-path-consistency-over-srv6-00 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, 25 Mar 2022 01:09:26 -0000 ------=_Part_65397_624625370.1648170488344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thank you for keeping the BFD WG in the loop. I don't have any comments on = the correlation, will leave that to SPRING. My only question for now is regarding the use of S-BFD echo packets. RFC788= 0 recommends to also use S-BFD control packets when using S-BFD echo becaus= e a transit node could u-turn the packet. And if the packet is being delive= red anyway to the control plane (as per 4.2), control packets should be use= d instead. Regards,Reshad. =C2=A0=C2=A0 On Monday, March 21, 2022, 10:32:00 PM EDT, linchangwang wrote: =20 =20 =20 Hi WG ,Chairs: https://datatracker.ietf.org/doc/html/draft-lin-sbfd-path-consistency-over-= srv6-00 This document describes a method to keep the forward path and reverse path of S-BFD consistent when detecting SRv6 Policy. There is no meeting for bfd in IETF-113,=C2=A0 we will present this draft i= n spring WG: =C2=A0 March 25, 2022=C2=A0 12:30-14:30 Friday Afternoon session I (UTC+1) =C2=A0 o S-BFD Path Consistency over SRv6[ 5 minutes ] S-BFD could be used to monitor SRv6 Policy,=C2=A0 a session associated with= a segment list. Path inconsistency may cause false positive issue. To the issue, The consistency of forward and reverse path of the same sessi= on should be guaranteed. This draft describes how to realize the bidirectional path consistency of p= acket when monitoring SRv6 policy by S-BFD. How to correlate bidirectional path? 1.=C2=A0 Correlating bidirectional path using Path Segment =C2=A0 =C2=A0 2.=C2=A0 Path Segment is defined to identify an SR path in [d= raft-ietf-spring-srv6-path-segment] =C2=A0 =C2=A0 3.=C2=A0 [draft-ietf-idr-sr-policy-path-segment] extends BGP = SR Policy =C2=A0 =C2=A0 4.=C2=A0 Using path segment and reverse path segment to estab= lish a mapping table =C2=A0 =C2=A0 =C2=A0 Using the mapping table to get segment list by reverse= Path segment S-BFD Initiator procedure: =C2=A0 =C2=A0 1. Encapsulating the segment list associated with SBFD-sessio= n session to SRH =C2=A0 =C2=A0 2. Encapsulating the path segment of segment list in SRH, and= set SRH.P-Flag S-BFD reflector procedure: =C2=A0 =C2=A0 1. If SRH.P-flag is set, extracts the path segment (i.e. SID-= Path-A1)of the forward path from SRH =C2=A0 =C2=A0 2.Get segment list of reverse path by the path segment as a r= everse path segment from mapping table =C2=A0 =C2=A0 3. Encapsulating response packet with the reverse segment lis= t Any comments and suggestions are greatly welcome. Best regards, Changwang Lin =E5=8F=91=E4=BB=B6=E4=BA=BA: linchangwang (RD) =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B43=E6=9C=882=E6=97=A5 23:= 17 =E6=94=B6=E4=BB=B6=E4=BA=BA: jiangwenying@chinamobile.com; chengweiqiang (c= hengweiqiang@chinamobile.com); lihao (02566, RD); 'rtg-bfd@ietf.org' =E4=B8=BB=E9=A2=98: Re: I-D Action: draft-lin-sbfd-path-consistency-over-sr= v6-00.txt Hi WG, We have just posted a new draft about sbfd path consistency over SRv6 in BF= DWG. https://datatracker.ietf.org/doc/html/draft-lin-sbfd-path-consistency-over-= srv6-00 This document describes a method to keep the forward path and reverse path of S-BFD consistent when detecting SRv6 Policy. Any comments and suggestions are greatly welcome. Best regards, Changwang Lin =E5=8F=91=E4=BB=B6=E4=BA=BA: I-D-Announce [mailto:i-d-announce-bounces@ietf= .org] =E4=BB=A3=E8=A1=A8 internet-drafts@ietf.org =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2022=E5=B9=B43=E6=9C=882=E6=97=A5 19:= 33 =E6=94=B6=E4=BB=B6=E4=BA=BA: i-d-announce@ietf.org =E4=B8=BB=E9=A2=98: I-D Action: draft-lin-sbfd-path-consistency-over-srv6-0= 0.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S-BFD= Path Consistency over SRv6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Changwang = Lin =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Weiqiang Cheng =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Wenying Jiang Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-lin-sbfd-path-consistency-over-= srv6-00.txt Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 12 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2022-03-02 Abstract: =C2=A0 Bidirectional Forwarding Detection (BFD) can be used to monitor =C2=A0 paths between nodes. Seamless BFD (S-BFD) provides a simplified =C2=A0 mechanism which is suitable for monitoring of paths that are setup =C2=A0 dynamically and on a large scale network. In SRv6, when a headend =C2=A0 use S-BFD to monitor the segment list/CPath of SRv6 Policy, the =C2=A0 forward path of S-BFD packet is indicated by segment list, the =C2=A0 reverse path of BFD packet is via the shortest path from the =C2=A0 reflector back to the initiator (headend) as determined by routing. =C2=A0 The forward path and reverse path of S-BFD packet are likely =C2=A0 inconsistent going through different intermediate nodes or links. =C2=A0 This document describes a method to keep the forward path and =C2=A0 reverse path of S-BFD consistent when detecting SRv6 Policy. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lin-sbfd-path-consistency-over-srv6/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-lin-sbfd-path-consistency-over-= srv6-00 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------------------------------------------------------------------------= ---------------------------------------------------------- =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6= =9C=89=E6=96=B0=E5=8D=8E=E4=B8=89=E9=9B=86=E5=9B=A2=E7=9A=84=E4=BF=9D=E5=AF= =86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81= =E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA =E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81=E6= =AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4=BD= =95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD=86= =E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86=E5= =9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81 =E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD=E7= =9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6=94= =B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B= =E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=E5= =8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC =E9=82=AE=E4=BB=B6=EF=BC=81 This e-mail and its attachments contain confidential information from New H= 3C, which is intended only for the person or entity whose address is listed above. Any u= se of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! =20 ------=_Part_65397_624625370.1648170488344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank = you for keeping the BFD WG in the loop. I don't have any comments on the co= rrelation, will leave that to SPRING.

My only question fo= r now is regarding the use of S-BFD echo packets. RFC7880 recommends to als= o use S-BFD control packets when using S-BFD echo because a transit node co= uld u-turn the packet. And if the packet is being delivered anyway to the c= ontrol plane (as per 4.2), control packets should be used instead.

Regards,
Reshad. &nb= sp; 

=20
=20
On Monday, March 21, 2022, 10:32:00 PM EDT, linchangwan= g <linchangwang.04414@h3c.com> wrote:



Hi WG ,Cha= irs:


This document describes a method to keep the fo= rward path and
reverse path of S-BFD consistent w= hen detecting SRv6 Policy.

There is no meeting for bfd in IETF-113,  we will present this dr= aft in spring WG:
  March 25, 2022  12:= 30-14:30 Friday Afternoon session I (UTC+1)
 = ; o S-BFD Path Consistency over SRv6[ 5 minutes ]

S-BFD could be used to monitor SRv6 Policy,&nbs= p; a session associated with a segment list.
Path= inconsistency may cause false positive issue.
To= the issue, The consistency of forward and reverse path of the same session= should be guaranteed.
This draft describes how t= o realize the bidirectional path consistency of packet when monitoring SRv6= policy by S-BFD.

How = to correlate bidirectional path?
1.  Correla= ting bidirectional path using Path Segment
 =   2.  Path Segment is defined to identify an SR path in [draft-i= etf-spring-srv6-path-segment]
    3.&nb= sp; [draft-ietf-idr-sr-policy-path-segment] extends BGP SR Policy
=
    4.  Using path segment and reverse path= segment to establish a mapping table
  &nbs= p;   Using the mapping table to get segment list by reverse Path segm= ent

S-BFD Initiator pr= ocedure:
    1. Encapsulating the segme= nt list associated with SBFD-session session to SRH
    2. Encapsulating the path segment of segment list in SRH, = and set SRH.P-Flag

S-B= FD reflector procedure:
    1. If SRH.P= -flag is set, extracts the path segment (i.e. SID-Path-A1)of the forward pa= th from SRH
    2.Get segment list of r= everse path by the path segment as a reverse path segment from mapping tabl= e
    3. Encapsulating response packet = with the reverse segment list

Any comments and suggestions are greatly welcome.

Best regards,
Changwang Lin



=E5=8F=91=E4=BB=B6=E4=BA=BA= : linchangwang (RD)
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2022=E5=B9=B43=E6=9C=882=E6=97=A5 23:17
=E6=94=B6=E4=BB=B6=E4=BA=BA: jiangwenying@chinamobile.com; ch= engweiqiang (chengweiqiang@chinamobile.com); lihao (02566, RD)= ; 'r= tg-bfd@ietf.org'
=E4=B8=BB=E9=A2=98: Re: I-D = Action: draft-lin-sbfd-path-consistency-over-srv6-00.txt

Hi WG,

We have just posted a new draft about sbfd path consis= tency over SRv6 in BFDWG.

<= /div>
This document describes a method to keep the forward = path and
reverse path of S-BFD consistent when de= tecting SRv6 Policy.

A= ny comments and suggestions are greatly welcome.
=
Best regards,
Changwan= g Lin





=
=E5=8F=91=E4=BB=B6=E4=BA=BA: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 internet-drafts= @ietf.org
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2022=E5=B9=B43=E6=9C=882=E6=97=A5 19:33
=E6= =94=B6=E4=BB=B6=E4=BA=BA: i-d-announce@ietf.org
=E4=B8=BB=E9=A2=98: I-D Action: draft-lin-sbfd-path-consistency-over-sr= v6-00.txt


A New Internet-Draft is available from the on-line Internet-= Drafts directories.

        Title    &nb= sp;     : S-BFD Path Consistency over SRv6
        Authors        : Chan= gwang Lin
          &nbs= p;               Weiqiang Cheng
                &= nbsp;         Wenying Jiang
F= ilename        : draft-lin-sbfd-path-consistency-over-s= rv6-00.txt
Pages         = ; : 12
Date          &n= bsp; : 2022-03-02

Abst= ract:
  Bidirectional Forwarding Detection = (BFD) can be used to monitor
  paths betwee= n nodes. Seamless BFD (S-BFD) provides a simplified
  mechanism which is suitable for monitoring of paths that are set= up
  dynamically and on a large scale netwo= rk. In SRv6, when a headend
  use S-BFD to = monitor the segment list/CPath of SRv6 Policy, the
  forward path of S-BFD packet is indicated by segment list, the
  reverse path of BFD packet is via the short= est path from the
  reflector back to the i= nitiator (headend) as determined by routing.
&nbs= p; The forward path and reverse path of S-BFD packet are likely
<= div dir=3D"ltr">  inconsistent going through different intermediate n= odes or links.
  This document describes a = method to keep the forward path and
  rever= se path of S-BFD consistent when detecting SRv6 Policy.


The IETF dat= atracker status page for this draft is:
There is also an htmlized version available at:
=


Internet-Drafts are also available by rsync at rsync.ie= tf.org::internet-drafts


______________________________________________= _
I-D-Announce mailing list
Internet-Draft directories: http://www.ietf.org/shadow.html=
------------------------------= ---------------------------------------------------------------------------= ----------------------------
=E6=9C=AC=E9=82=AE= =E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=9C=89=E6=96=B0=E5= =8D=8E=E4=B8=89=E9=9B=86=E5=9B=A2=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6=81= =AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=E4=B8=8A= =E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA
=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6= =81=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81
=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4= =BB=B6=E4=B8=AD=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82= =A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7= =E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9= =80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C= =AC
=E9=82=AE=E4=BB=B6=EF=BC=81
This e-mail and its attachments contain confidential information f= rom New H3C, which is
intended only for the perso= n or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limite= d to, total or partial
disclosure, reproduction, = or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please= notify the sender
by phone or email immediately = and delete it!
------=_Part_65397_624625370.1648170488344-- From nobody Fri Mar 25 05:18:49 2022 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 68E7E3A0FCA; Fri, 25 Mar 2022 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 5bPwMQQOaedd; Fri, 25 Mar 2022 05:18:34 -0700 (PDT) Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (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 2535B3A1064; Fri, 25 Mar 2022 05:18:33 -0700 (PDT) Received: by mail.swisscom.com; Fri, 25 Mar 2022 13:18:31 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_353688_1587292926.1648210710970" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V9oMcdQQNnatmRd469paurhuMCJ/J8ypy9vnmw1sTcwnlY4hLBrZMGl6RgN12mag+ZwNw2I7230zhx5zdeeNCl/cie7SIwJS6LIJQVjaVC2anuath8KbPPjfaIgah6obGW/2+yJwH+hjteF46EfDUQQS51EqWeW34xXkGZ8y/nflNFA+9oWbMNRs2GIdVxBk00+O+Fee+3OqiOo+EnnkbHBZHgnbBjjGVlL07q0YLOnFSndtK8cvB8FE5AaIrjvU0KEB7pgX7oIhgNF+iAqNrK/3kUKWJWuDF+aPgN21g9o3u+zoP8ywgX/IMcprfSWE1vLILN1uAaZ6e7wZoF9Xlw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IMAHZrd1sdM8UC1+2B8a/Rsjb98CC6GzTZEErpbpArE=; b=hYngkUKmaC4cXUpVxvaRD5ZVxdBkFs8OoSgIj7Q6hPWp5jn661LXe2/EhpxNAvUA+YZpN+OircxkiM2UMS9b4aIwKb7fM8n8kiOyHuRGv4C2KK0z/UV9TqBWEmKg8nnYY0D7Q0SC1w8QznjU5OGlGuqVtkUsg+iqRlGs0Y1Sr5eFlEsYgwUCM/eooF15JQWWK+Ps6Yt0MOZYeqOmNc1vro8T+bAKUD+n98EqpOFQhB0WdQ6rJAvqoH801qxh5CZnOhN58mhvLkOTbxOh/wmdeINSz9k6kzm/q4dQrdaVffrz1keeB+ZGBmzVOhPmNoRmvBHjHX1yyWJns9Xs5FNkNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , Thread-Topic: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-02.txt Thread-Index: AQHYMSy364GMZj6QJU2LfxMuF870Iqyx9z2QgB4mddA= Date: Fri, 25 Mar 2022 12:18:27 +0000 Message-ID: References: <164655210645.9671.6215224488696350140@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=true; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2022-03-25T12:18:25Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=ca45ac0e-d5ae-4e4c-bb6c-6618b3aad25f; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ca86a2d-b3c6-436f-1fc9-08da0e599133 x-ms-traffictypediagnostic: ZR0P278MB0107:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Owbvi6qZuWTJvtSQJyXWJdGtRHFSouebXa2q/fbVpU3ltErZGtblPPvERSEJorIApITD1LXYB7rzMeVHoS+2HzctrZbeveKg5WZlw+/FYc/tsxTpQNQRAYoN2F8T1YoqJX9+IZ2jHEloabbc2+yFhkXU0txjYxk5DVTYHyPxG9y2iOC153bb+hoaTMN/T0CtfQXrajUrhvbQdI6SoxbhDV8q26V7ifD8eWmrOm1lr+1FF7sX0psawo8/KBy5GK0Eysed2HzgzFqIn6HXLCUi+pDqimqETIlF+FxQHlXsdvXezLo2MBkaTjlD4H1nDvY6tyy+DcJC+UaaWXWbbLALN5mtbgSnSNtRJxoN3wyENGX+Mz4hod9wyq8eEcSUb8lJRMO8EZ6+uYh2Vjfyt7Z78tDTeaaCkjY+mxmns+jx1FDBXfHWKrCBaTNU1Rjt8KaJZhG7DFonWINxmFO0XiEsCVTALFc8HCTi+tcfatjDm3MrrUpfKIiTY26LYVQz9UGNDPViiWs5oit5w0Jd+6ksr2y++Hk7LmAxCivmWGtn0gHKbPgIvcmdsF1G2+UKvQiIg+ng+Uo+U4MUzm3NYedDLr2l2e80/hVDLGkqkI/GSSsj80Fmd5XH2hYIuKPNy16nUges/7n8cPbk9HmKsueag9pzv2A7Pp57DXgDKQlLlYRKrNAVrKmC16N7ywSIAKEBRoXQwdJm2QD5yXorDHnki6xaI6gSdc6rALdXYqELcCzQNYqgCY0+zoo5Ng7feOCxR+9py0+Fv1UhhzQjBiLTzPbgCzk7e4SldnTYT//caMc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(2906002)(9686003)(26005)(82960400001)(316002)(15650500001)(38100700002)(19627235002)(110136005)(71200400001)(10300500001)(5660300002)(76116006)(64756008)(33656002)(38070700005)(66946007)(186003)(55016003)(508600001)(83380400001)(8676002)(10290500003)(66476007)(86362001)(450100002)(66556008)(66446008)(122000001)(52536014)(8936002)(66574015)(53546011)(7696005)(6506007)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?vFKIIkZYGiEpKmWM431Fs7kauFOYBgJ4/Lzmfo32D2ESSnCkrLjv8QU20hH0?= =?us-ascii?Q?+w2HrTpxVYH0+I8yE3ZfKYgfs+cuUpCU90j5JoJmitIIQSkCsr6HCdpmYBdV?= =?us-ascii?Q?Of/MddH+oVQ7asqELTGv9/NQVmg/HX24Vkk+nUbWoOtOet9UgQe96GR5tYtX?= =?us-ascii?Q?GV+2VxIjkUfVKCZ4HbFjWvY1o0dAcE8OMehY0etL840OoRzFg4kisC5iu+Lj?= =?us-ascii?Q?EJ7GQnjRB9jk3DyY+qMIngwLH7f3PF0PKXWYjYaMZv/GeGUm4jNmX4eYi+7Y?= =?us-ascii?Q?3o2DKL5gzerw3tUXUqyrXOi6VRQx7Ee+WTMYJVZ8D6sKICeoOOLt1SU6E1ZD?= =?us-ascii?Q?pAN41k2WvMmr7/nw2DRg2k3hZTOtnKlJV3BNjEfuh2WmXFDycijRS6zZ0V8m?= =?us-ascii?Q?Y/DDA1gOlRsHen4HAeXS6pWzN2BxW0Fn+ODg3KmRLskxIuCiRjLgOTtHhHCQ?= =?us-ascii?Q?zdV/4I1ysKgoGMUpgJtIJI60dmk0PGee0kDls8z4clxXToj3UrSb8PDv28Xe?= =?us-ascii?Q?8Jh9rmBUK5ZIZ4B1gKqw+cJcNOOfDhm4f9Eiop1LXy3E9h6+1PyRtYvVzAt/?= =?us-ascii?Q?pVsYPAUGdjh01di5aILQ5lzxXhRhS4bQK34fWclXkwp7QpgSbQCS/fqyrHJo?= =?us-ascii?Q?rkQRqee/It+x6rjfZNRfMkvFAdSVK7Ii8i1g0WU0EEEq5P5AAeNg5nEIo4ed?= =?us-ascii?Q?j7gmbIS66OtYHA6qqsjFx5wCeSlkPI4S4KCI3t0vRssuKpaXjo1m2rArWzYj?= =?us-ascii?Q?TstuR83wOaQ4cG22w6bm0HQKa6odV4hewE81Sv+B0jjEqZFraUU96ojOOXok?= =?us-ascii?Q?hEX2AczLwz7lm8E9e9oht0kMU1OP+xWaoV4mWjQCrfbOkgiJnpTuuPBt3qH4?= =?us-ascii?Q?krrnljQDze6Z1utv0GrNthabCCsMuO/fvyKqQW7isGjsKB4eLBHgOEjmCMZp?= =?us-ascii?Q?6M4alHhY3u4n3HXaZRQI6aKYRoIcm0BxREEwHp9FKVnPStPqG5X7uEBw09mW?= =?us-ascii?Q?ZiSxY3ucXFwdzsS1ecov1P3sDXeZgHmjq9FXJMi/YZ8vPB7dns6vF4up2BFr?= =?us-ascii?Q?3A6+Ypcf9wPvdeHhuoLLhPI8zllkzTniRW2y3htRB13b2anh10zD0gkUf/x1?= =?us-ascii?Q?unvvroVZxwJuVPrIkpz76j/v9FN/CB8gHJMEGwycmCW6QZtnaAkIY+TF0CBt?= =?us-ascii?Q?k2tXw+wIgI9ELic1lgAFamKxaJ/tk9XrLFGuF1hL+vPu/+Wu7uUxOomOF/md?= =?us-ascii?Q?/nRHmT3pWy+zTED8IDGrboY9HnGsQ1MdFXOlFRGMebcv6Y26zeNEYeH4DIyf?= =?us-ascii?Q?rN08n8EU7/j4cdxe4XFxtcapjuMtKLOPMFf9RdGF+4I4eTK1DseVawyIIxIM?= =?us-ascii?Q?MtWz68xpTQHLaqzhooWtLycCuy5nQdJnfvcdKrgLX6T4RL32I6n8xygUVQxU?= =?us-ascii?Q?5E/Z1mWy09KA0d3iYxQ8nAzL/9L17BKcXDgnXPy0kHug500Jog+s1w=3D=3D?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1ca86a2d-b3c6-436f-1fc9-08da0e599133 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2022 12:18:27.6802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jFRDVCZWX+8AoW7BJhCfqAl1F0UEhVtUjYSDCvz9XOyaeawmH0Whpg559U7RQVW5XWBv/mGDMVXjmdvOPttFN2S5AHu4TT+AbQ1fC5tp73M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0107 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Mailer: Totemo_TrustMail_(Notification) X-Trustmail: processed Archived-At: Subject: Re: [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-02.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: Fri, 25 Mar 2022 12:18:40 -0000 ------=_Part_353688_1587292926.1648210710970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear OPSAWG and SPRING working group, Thanks for the feedback on slide 7. https://datatracker.ietf.org/meeting/113/materials/slides-113-opsawg-export= -of-segment-routing-ipv6-information-in-ipfix-01 https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-03 We understood it does not bring much added value to decompose the C-SID con= tainer into Compressed-SID (C-SID) in IPFIX and it does makes sense to add = an operational consideration section to describe how an IPFIX data-collecti= on could distinct between a list of IPv6 SID's and a list of C-SID containe= rs. Regarding the question wherever slide 7 also applies to G-SID defined in ht= tps://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cm= pr-04#section-3.1. Yes, in essencence the same alsop applies to G-SID and G= -SID Container. We will update the input in the upcoming -04 version. Further comments and = input welcomed. Regarding implementation status. We intend to release open-source VPP runni= ng code by IETF 115 hacktathon. One major network vendor commited on implem= entation and others showed interest. Best wishes Thomas -----Original Message----- From: Graf Thomas, INI-NET-TCZ-ZH1=20 Sent: Sunday, March 6, 2022 8:46 AM To: spring ; opsawg Subject: FW: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh= -02.txt Dear OPSAWG and SPRING working group, Based on the feedbacks I received, I updated the document.=20 Apart from the small editorial changes, the following points have been addr= essed - updated IANA sections according to RFC 8126 - added ipv6SRHSegmentListSection to facilitate immediate export without da= ta flow manipulation - added Operational Considerations section to described differences between= ipv6SRHSegmentBasicList and ipv6SRHSegmentListSection Looking forward for further reviews and comments. Based wishes Thomas -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Sunday, March 6, 2022 8:35 AM To: Benoit Claise ; Graf Thomas, INI-NET-TCZ-ZH1 = Subject: New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-02.= txt A new version of I-D, draft-tgraf-opsawg-ipfix-srv6-srh-02.txt has been successfully submitted by Thomas Graf and posted to the IETF repos= itory. Name:=09=09draft-tgraf-opsawg-ipfix-srv6-srh Revision:=0902 Title:=09=09Export of Segment Routing IPv6 Information in IP Flow Informati= on Export (IPFIX) Document date:=092022-03-06 Group:=09=09Individual Submission Pages:=09=0912 URL: https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-sr= v6-srh-02.txt Status: https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-s= rv6-srh/ Htmlized: https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ip= fix-srv6-srh Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tgraf-opsawg-ipfi= x-srv6-srh-02 Abstract: This document introduces new IP Flow Information Export (IPFIX) information elements to identify the SRv6 Segment Routing Header dimensions and SRv6 Control Plane Protocol that traffic is being forwarded with. = =20 The IETF Secretariat ------=_Part_353688_1587292926.1648210710970 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMzI1MTIxODMwWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBh8Nx1 TayzFp6y8s+x6XXGDhYlA/VYniUhpD4k//liqTB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQA3P44/1BzyOP+Gwp6Gjr1qHP+t XHvL7/PDWP/NXYXbX9qH+xb8wq5GDN5VcGCp6w5bskgmRW6KXaQc3kULby3+pbrO/X6M6CDOlYCT R0mRLBNdu065juv4xPdW2OEC7JmqJybLbjYwYAHWZYuAfy7S07xBcYCsBErN5a/d0IZIo0oiSmCT Hq6b2OtYK/4YEvU1jJog7ps+x4cap4GdcufdGlestu6Zgr+sdiE3qIBRoUiMo6pHlSRLzU1NUpZ8 5gCWagTGkdjAKllEJ1Mu/YwiInXivX5yY1AX/z7PA+DfpSzSK9C7Z7Xr04RYJugW//cecDPKDnvZ LFrPLeC4BKZuAAAAAAAA ------=_Part_353688_1587292926.1648210710970-- From nobody Fri Mar 25 05:52:09 2022 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 789A33A1218; Fri, 25 Mar 2022 05:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=ciena.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 0HBiIawMM9WZ; Fri, 25 Mar 2022 05:52:01 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 EF23B3A0CAB; Fri, 25 Mar 2022 05:51:58 -0700 (PDT) Received: from pps.filterd (m0222747.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22PB7Ucf003389; Fri, 25 Mar 2022 08:51:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=06252019; bh=wStu7G583+w/WjLD8FXgsob+5rVjwHK7sVoUm/GFcro=; b=YyWzwgD45u4QRgBIIpNYoz2ip2Yq8/kxta5nhy/v6prBjiYF9Utrtok3Iy5m1M80Nuld mGkLC6yJ+gnw5S2vmT+Z2STtsi+OGxeKLOU1KqkygJIWgZSvRzj6eKQVt5fUhTvRE3f+ 33R0gWdHsJ9qfEFgJn+F92MY/DnyKnOn2xcfG9CUrIlclVSWH5zOu4b+4EpzD3TnhDpE j5CSwoHVukpsLrx+kxapJAa4VTfYak4ocir8WX9a3LFpsE+rQV1XxJyLfbhwSd7Wo6I+ GVUBBFiArn7/h8yE8kgwIUmC6Lr0KzIQDraBwtcjhcwnX/MGti6B+kctHYrGRg+COofS nw== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by mx0a-00103a01.pphosted.com (PPS) with ESMTPS id 3f1ck687ht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Mar 2022 08:51:54 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TbsaqM4Q2RNmVOpAQjzdcjBjrX+pbKMeW1ZlN0mblB96Xb5mabC2H76QAM0rqJ87RMLWKQ15DT7ab+dawkrjWamj4Z/nzMr7YLWV+Ye5kwtRPjs+hyGcBIAu8RsaHiyq4GZSKP1KrBt+gmq9MM/WR/CLJPlxRd2TXSJ7EV8egDQw7M5CE6W4EnHiZZPV2ZWd8wwqyu3JtYExG6bzb9VLetx+LX2MBeK/G7yBCBIGSEHPJdymeCDObvjZME9H1DmKsUpuQorRbWPxwLWvfWW5zW8GQqfqZ9/uY5KXE3Lz7m70Clv+cVuZ6AcuqMh0DQ+1Pd61uiY8xbWHWU9MreSOlw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wStu7G583+w/WjLD8FXgsob+5rVjwHK7sVoUm/GFcro=; b=jNsDu8mNwGwgmULkyk7L3aI21ZtLGpDEeL5F4rij/HtKZ6X9bShaQfBRA6kRonvhPHyAK3H8FNHgday4DmVrUrzinK1ELfLzvj5E6qTPVBXf7C07sfD+UQOyvf8IJcU/6G/7qEkPJqza4hRiRsoKpRPtLsf0/h9pho3SaN7H1a8FpgIM0n6XrMYTyGc+de2Z23zQTHyfCnYULB6N6dfcITkAXVbLlWAMA/1o3lGVfdPclUNmw/8AWoC7Tp//yCPwiNfX/4w57o2SIlmbjV0o9/BtjOuYqvDLTIymDCjoRXRlP8FS8JH0bH/8h9xitVhUCTeJEsdoQSqQi3rvDl0OMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none Received: from BYAPR04MB4581.namprd04.prod.outlook.com (2603:10b6:a03:15::20) by CH2PR04MB6679.namprd04.prod.outlook.com (2603:10b6:610:a2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.18; Fri, 25 Mar 2022 12:51:52 +0000 Received: from BYAPR04MB4581.namprd04.prod.outlook.com ([fe80::1c24:1ccc:d71:2f66]) by BYAPR04MB4581.namprd04.prod.outlook.com ([fe80::1c24:1ccc:d71:2f66%5]) with mapi id 15.20.5081.025; Fri, 25 Mar 2022 12:51:51 +0000 From: "Boutros, Sami" To: "bruno.decraene@orange.com" CC: "spring@ietf.org" , "bess-chairs@ietf.org" , James Guichard , Joel Halpern Direct Thread-Topic: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Thread-Index: AQHYN8d9qsvIv4XmqkeeKayn8L1mKazCB0CAgA4Tcs4= Date: Fri, 25 Mar 2022 12:51:51 +0000 Message-ID: References: <5986_1647438032_6231E8D0_5986_381_4_a7932aa651064602ad086333cf5c607a@orange.com> In-Reply-To: <5986_1647438032_6231E8D0_5986_381_4_a7932aa651064602ad086333cf5c607a@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=True; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-03-16T13:40:29.0000000Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 586c40e3-1930-4921-52d7-08da0e5e3bd4 x-ms-traffictypediagnostic: CH2PR04MB6679:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jYf4DILtrkRG0bj0XdHt+gxZMuu3Aq/1oUgXgZYXCfb9Jj98WDjL8LWOrzkM0/c0iG/og52r42fWr542nlQcRNGfr8Qb+KKzWDBg46kXQ4w/2RkhUA3nqLMe8xGM7JzZlPp5B1z3/jdpk6pqRHxAfDGFdB01gw8zf1h4Anb5JvAvfgRnAdm8iL9fNknTejMlFTKZp30zlb/Xufa/Rjoc2tugYaIZlnduOIu/ZMleTtf4rHe9QFHbsvLK+pdkD/IFmUyM1Kcsjb7X4baAmdhL7cJwQBJvQKJvqUKAkRS1us8dePWY8J9uGgxyr+ENYx9kJdP/3+g880w6+ACRLiNcGznSXEws09h50f3hlMOXIMrDbhn1zPX+AHyeB2m5MY2qWxzwJi5RjCQ1jGL95mO17lXuPUMvKPDYjEO2clBWDc/UoGd4fznmq9pVcq6hkUirfR2GwZysoQDfQ92XqFj/78NGGx/B6zfbL+MS0plGenNOCkOjZPRsAXOYLgmQATe7+j4VnR5lDuYUuzw++ujiCE6D9LvBYRBsTfYIELO8XHwTGYWxOLK7DW1GwvB5rQhMJyMMJZBCnUyz0kLzhmkj/iNETcVX58rY70SoYfk0F3LT9mOlN3ITPoBvFg1MG9vj6hztlPp7LMgy2aKAlcMIJFoVVWfIdLXokYoU2P39fPevOCXuAg8z+635IGL4IBUirqb1uylpg1vXVGAgGJ3Lcg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4581.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(8936002)(9326002)(33656002)(508600001)(26005)(7696005)(6506007)(53546011)(55236004)(9686003)(5660300002)(52536014)(6916009)(83380400001)(2906002)(8676002)(186003)(86362001)(71200400001)(316002)(55016003)(54906003)(66476007)(4326008)(66556008)(64756008)(91956017)(66946007)(66446008)(76116006)(38100700002)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?nd8gUjMTfuKuc4gvPaCGfdKX9CsxDqi4Ime7Tn/xpqHY7Wuj8OV3fR9q?= =?Windows-1252?Q?t/wd2tIfZGnzKt5dycxCcUoXJ3En0T/hv6DmZN/ZZz4iBtZkYaZYMnwA?= =?Windows-1252?Q?QPZ77vAfW6x/wlRTqTsZ+fDsF7JuebRIuaNX3j0gZo1UHW+IKfOKnRjJ?= =?Windows-1252?Q?akR7p+trEM0oWTYAPm4PHRJvD4810vD3kMdNoYz8yNSbRiMMZ15cwK7p?= =?Windows-1252?Q?aQk6E8yXcEeH4bCoGRa3+6Bve6lmti3Dg3MQJkBFJo385zs2gL2Es0S+?= =?Windows-1252?Q?TE677M6xvONpGt7Mf8UxdQTrdmViN9upB67PaQnfuLWrMZbwsIOyiPwA?= =?Windows-1252?Q?g9wUsbOH8J4rP3WQaQ847Hd8HCkVa6OE9TVU4gUHBFwFHuV0+bQgiuHT?= =?Windows-1252?Q?5Eq/vPxmwAs27jMrqj5t0WrD6VgIHfZ63sGqw9qf6Pg1gLsBAVdgtCcB?= =?Windows-1252?Q?kxI1NOxoqQ9Gdr0NB60/+v6cMg5aUx9MSmdlkm922v/YNHZLARLhzz1c?= =?Windows-1252?Q?VFDclx3WmEeBUk9rCOV/bVJiKJ37oTaRg1Kdhj7kZ+knc8eupRkzdjv4?= =?Windows-1252?Q?/RwwP/kUIddTKE3/h9xBiYgg8r2H+u3YwEO+FmbQPfrQaokrTJ7jSU2w?= =?Windows-1252?Q?s2weEF5CMkwPle6ginX/hLZm8dGjQLD9SbJhsMnREdLbGa2iZidzowTe?= =?Windows-1252?Q?kGNzSPtqYMYw8945Lua0b9NQKsHc78mmpDkJVoMSL//M9+8AQOrbThSQ?= =?Windows-1252?Q?vatNlE+OJX2VZRVMpVfuSoBOtaVr+T1MCPKAK3sGW9Hyqqu6a8D/yrmJ?= =?Windows-1252?Q?PzlyGtfO4m1Zpon2Rw5L5QGuFKcBXtP0jIT6EfCoWLX5JiV2crBytrCr?= =?Windows-1252?Q?ALXZ0AX6isOnvoV6be4mLSS1fXjIG6TxXVH7qsudJDO59sVGEfWJTmJ0?= =?Windows-1252?Q?ooVsorTH7aJQm/O5+5+M6xJzxpXmTYYhhsyobK6R+0KpLXukal/9EWhg?= =?Windows-1252?Q?Wf10evVPKoRDyNneGSHYRCinFth6TPmYDzWRyBtSUjylkJVo/skRIWm9?= =?Windows-1252?Q?20/dlnP5LBwZZidwTPE0eNixiT+LsJ16Qz2diEc65UihzgH+KBS4+c8R?= =?Windows-1252?Q?LK8fej5+0VPHyegtBnk+vXqbwpr/zJtixFMmPWulX0p9y1Udz3hvEGT9?= =?Windows-1252?Q?aC/AeHqm06AAhvPDGvXbgncEKSSxdhTpfAjOud/LXxbGpOwBDG+rWsqv?= =?Windows-1252?Q?2vR36Bg/3xHwa7+bgFuLPdx3PiMFMdGsTGjnTe5zrGjgf4Q9KM2OTrAi?= =?Windows-1252?Q?F+jLlQoM0P0dJN/ZRcqhDy1e8CgDtci2d0X0ErbmpZsdt/cwVVA5TocZ?= =?Windows-1252?Q?U5vHaDbxK+7kbZmTFtdPN67yLP41zvvdprcKFxoNc6aCJuGKzEbLd5Oe?= =?Windows-1252?Q?38+gWzrOJPGZ0oRLwicutUWQYWFjBQs6CX8p4/1dGN7XiV3BVCsG4xtE?= =?Windows-1252?Q?sRJB4BVL9oZYeqffDzMH9MD8Zw6U4HCqDpFJyE/2mwrRQjXWnmj/UFCL?= =?Windows-1252?Q?Xd0je0gbpLa4tQ0Tu5PZxXNYlGE6Q0LiCLejoWArZ/1V4JRAzTOz+s3z?= =?Windows-1252?Q?tAqUR2sL/ztjUT7tSVoVmmZiWTeBcsyzYDogIJOSY3y/pKhU59GAxkfC?= =?Windows-1252?Q?rJw5MA6cnvKf2jzOP4M90p7VFXifUiiApw0TLgImvBWu5Q2umPkGPqCW?= =?Windows-1252?Q?t16z7G5GrrmGSTmLgqZVTqHTpOItmM59gnBtkkD+oy989TSYuHpkKcZ+?= =?Windows-1252?Q?usw2Ol0ssKNcYvju7gHj/UsEZPHDuE8+K3gNnVql5/lWHkdPV1Q8wWC8?= =?Windows-1252?Q?geWVzCoiQhpTO8Yo3wxOPw6z8gJCqnbPj3k=3D?= Content-Type: multipart/alternative; boundary="_000_BYAPR04MB458184F2BC99FFFD2BE88CD8C41A9BYAPR04MB4581namp_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4581.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 586c40e3-1930-4921-52d7-08da0e5e3bd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2022 12:51:51.8894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y0SjxJ23cmaF0SfvJZ/3S1Hh8Egws+ESkx371EEFQZ213dg5HToMQhUOize9EIxovOKofwTMg0sggGy8RxiMyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR04MB6679 X-Proofpoint-GUID: rGiPs8QbQOic1QFpXonpOmPo8u4CjSUK X-Proofpoint-ORIG-GUID: rGiPs8QbQOic1QFpXonpOmPo8u4CjSUK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-25_02,2022-03-24_01,2022-02-23_01 Archived-At: Subject: Re: [spring] WG adoption for draft-boutros-spring-elan-services-over-sr-00 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, 25 Mar 2022 12:52:08 -0000 --_000_BYAPR04MB458184F2BC99FFFD2BE88CD8C41A9BYAPR04MB4581namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bruno, The main salient points in this draft are about: * Defining a service SRGB for services. * Getting rid of overlay convergence and using underlay anycast SID con= vergence to converge all services riding on this anycast SID. * Use of an underlay node/anycast SID to learn mac against in Dataplane= . (Keep in mind we are not proposing any change to data plane MAC learning = mechanisms like aging, move, security, etc=85) But rather how with the SR e= ncap we will learn the MAC against the source SID under the service SID in = the SR encap. NVO3 defining VxLAN, Geneve, etc.. where MAC is learned again= st Source IP address in the encap didn=92t go to discuss this in BESS. Are you saying we should discuss the above in the BESS working group? We are not making any relevant changes to the ELAN service, it is true we w= ould need to define a new BGP message to auto-discover the services that wi= ll apply to BESS and we will have a draft on that to discuss in BESS. Thanks, Sami From: bruno.decraene@orange.com Date: Wednesday, March 16, 2022 at 2:40 PM To: Boutros, Sami Cc: spring@ietf.org , bess-chairs@ietf.org , James Guichard , Joel Halpern Dire= ct Subject: [**EXTERNAL**] RE: WG adoption for draft-boutros-spring-elan-servi= ces-over-sr-00 [+bess chairs] Dear Sami, authors, SPRING and BESS chairs believe this work would be better addressed in the B= ESS WG. Thanks, Regards, --Bruno, Jim, Joel Orange Restricted From: Boutros, Sami Sent: Monday, March 14, 2022 6:23 PM To: DECRAENE Bruno INNOV/NET ; James Guichard ; Joel Halpern Direct Cc: spring@ietf.org Subject: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Dear WG Chairs, The authors would like to request a WG adoption for this draft, the draft w= as presented at last IETF. We could present the draft at this IETF too, if you folks like. Thanks, Sami ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BYAPR04MB458184F2BC99FFFD2BE88CD8C41A9BYAPR04MB4581namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

The main salient po= ints in this draft are about:

 

  • Defining a service SRGB for services= .
  • Getting rid = of overlay convergence and using underlay anycast SID convergence to conver= ge all services riding on this anycast SID.
  • Use of an underlay node/anycast SID to learn = mac against in Dataplane. (Keep in mind we are not proposing any change to = data plane MAC learning mechanisms like aging, move, security, etc=85) But rather how with the SR encap we wi= ll learn the MAC against the source SID under the service SID in the SR enc= ap. NVO3 defining VxLAN, Geneve, etc.. where MAC is learned against Source = IP address in the encap didn=92t go to discuss this in BESS.

 

Are you saying we s= hould discuss the above in the BESS working group?

 

We are not making a= ny relevant changes to the ELAN service, it is true we would need to define= a new BGP message to auto-discover the services that will apply to BESS an= d we will have a draft on that to discuss in BESS.

 

Thanks,<= /span>

 

Sami

From: bruno.d= ecraene@orange.com <bruno.decraene@orange.com>
Date: Wednesday, March 16, 2022 at 2:40 PM
To: Boutros, Sami <sboutros@ciena.com>
Cc: spring@ietf.org <spring@ietf.org>, bess-chairs@ietf.org &l= t;bess-chairs@ietf.org>, James Guichard <james.n.guichard@futurewei.c= om>, Joel Halpern Direct <jmh.direct@joelhalpern.com>
Subject: [**EXTERNAL**] RE: WG adoption for draft-boutros-spring-ela= n-services-over-sr-00

[+bess chairs]

 =

Dear Sami, authors,

 <= /span>

SPRING and BESS chairs believe this work would be better addressed in = the BESS WG.=

 <= /span>

Thanks,=

Regards,

--Bruno, Jim, Joel=

 <= /span>

 <= /span>

Orange Restricted

From:= Boutros, Sami <sboutros@ciena.com>
Sent: Monday, March 14, 2022 6:23 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; Jame= s Guichard <james.n.guichard@futurewei.com>; Joel Halpern Direct <= jmh.direct@joelhalpern.com>
Cc: spring@ietf.org
Subject: WG adoption for draft-boutros-spring-elan-services-over-sr-= 00

 

Dear WG Chairs,

 

The authors would l= ike to request a WG adoption for this draft, the draft was presented at las= t IETF.

 

We could present th= e draft at this IETF too, if you folks like.

 

Thanks,

 

Sami

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_BYAPR04MB458184F2BC99FFFD2BE88CD8C41A9BYAPR04MB4581namp_-- From nobody Fri Mar 25 06:48:57 2022 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 64D273A128E; Fri, 25 Mar 2022 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-0.01] 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 e6lOClErLaai; Fri, 25 Mar 2022 06:48:51 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 C9B303A1279; Fri, 25 Mar 2022 06:48:48 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id d3so5231310ilr.10; Fri, 25 Mar 2022 06:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=coNgV6MpAwmMpObnmfGQ0fRJqRVQ3JnpkXccZ4t4088=; b=H1s4YWTckyPsqu501TKXqsvjjNXasSCG2QTC9VmAcUD/q+1nzs2YzRsNdW4ITCswE4 4oEGfp7WAKrOedKu72Ayp/DELeTzBWtpw4+wbZ3u0DnggPQqKJ494pxSRaA6UMhNMrVt 3Ldr1wIjFWKE0jyEiz7plRdBXNdgc/Ts6vVdLNZdwQhaVFcSSQ2I1Cy8kTcIfN7THS3C e/lRu21+5zkc5V+G5O/byxe+oJpZhCVQz849DWqeMKkVXS90aBv7zcU1d3CIOcXlQfpt zZh+1fWgUOnclawbVULANaP7ZZcFeDoIh1sUHjbq7TPOahRUEkGHwEfqQVlB3smr0ak6 2bSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=coNgV6MpAwmMpObnmfGQ0fRJqRVQ3JnpkXccZ4t4088=; b=3jFbcPiAJa83Ri5HEnIgjaWnYdXB4pzZp9ZGKqLtU5j18eMw1Av9i5LZRwgaMdP/uC y6BnrCzybiIdKutCeQ+VivIEU2infTCQPkEX1KBveN4TnvzJ0spWlxXdkAqb+mlBd2Rb 6djxqSLxFJivffioyhIvMsXewhjRQeoimmctza3RYsUPqk48zIe5QwxBz2rnYdHlUVLf eBRGL+MifPjeaW3zxkKZiNFuHF4VbiMCQrYhTO9CamcgeAGmgQ3VJMXXid7xiMcvp/Wj aP9tpL17In4Gq3uh/S3JVj84IYY5YIzggjIoI0hbnz1rg83Wz+5hilqTi2x8SCN1wO6k Ns+Q== X-Gm-Message-State: AOAM530Ub3ewcrwlDSQjwaZJHv5lHpOPQ6H8aPaC38SqgOZoQrUCPzle hV2YaJaaSnjzvpGDPAHk++hrlL3HkYWmu9fjsFqH4GSgu8k= X-Google-Smtp-Source: ABdhPJxymaHq8gbkgatYT2WgDa3Yo/XTrvyETwo4aHi2Lw8BGaxnVttrzSXsFuhvn+QGa/6Kf10wucSpjcGZrEMYTuc= X-Received: by 2002:a92:ae02:0:b0:2c6:798d:2be with SMTP id s2-20020a92ae02000000b002c6798d02bemr5016521ilh.18.1648216127033; Fri, 25 Mar 2022 06:48:47 -0700 (PDT) MIME-Version: 1.0 From: Vishnu Pavan Beeram Date: Fri, 25 Mar 2022 08:48:35 -0500 Message-ID: To: draft-schmutzer-pce-cs-sr-policy@ietf.org Cc: spring@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3d69905db0b3830" Archived-At: Subject: [spring] Regarding Circuit Style Segment Routing Policies [draft-schmutzer-pce-cs-sr-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, 25 Mar 2022 13:48:54 -0000 --000000000000c3d69905db0b3830 Content-Type: text/plain; charset="UTF-8" Authors, This draft is introducing a specific type of transport profile for SR policy paths. To be more precise, it is introducing "Bandwidth Constrained Bidirectional Corouted Pinned Path SR policies" with restoration and/or reversion features enabled. I'm not sure if "Circuit-Styled" is an apt name for this specific profile, but I don't have a better alternative to offer . It is interesting how all of these TE features are being reinvented for SR policy paths. Is "Bandwidth Constraint" the only reason for the dependency on a PCE/Controller (because of the need for a centralized Resource Reservation Manager)? Would a Bidirectional Corouted Pinned Path SR policy not be classified as "Circuit Style" if it wasn't bandwidth constrained (in other words, do you envision any "Circuit Style" SR policy without a controller in place)? If this work were to progress, I would suggest having one document in SPRING WG that discusses just the profile without getting into any PCEP/BGP specific details (TEAS WG participants would be interested given that you are modeling/defining a specific type of TE path profile; would be useful to keep them notified) and a document in PCE WG that discusses the PCEP specific procedures for this type of SR policies. The "new" PCEP protocol-extensions being proposed (in draft-sidor-pce-circuit-style-pcep-extensions) are path-control technology agnostic (don't quite agree with the proposed encodings -- but that would be a mail on the PCE list) and can potentially be discussed separately. Regards, -Pavan --000000000000c3d69905db0b3830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

This d= raft is=C2=A0introducing a specific type of transport profile for SR= policy paths. To be more precise, it is=C2=A0introducing "Bandwidth C= onstrained Bidirectional Corouted Pinned Path SR policies" with restor= ation and/or reversion features enabled. I'm not sure if "Circuit-= Styled" is an apt name for this specific profile, but I don't have= a better alternative to offer . It is interesting how all of these TE feat= ures are being=C2=A0reinvented for SR policy paths.

Is "Bandwidth Constraint" the only reason for the dependency on= a PCE/Controller (because of the need for a centralized Resource Reservati= on Manager)? Would=C2=A0a Bidirectional Corouted Pinned Path SR policy not = be classified as "Circuit Style" if it wasn't bandwidth const= rained (in other words, do you envision any "Circuit Style" SR po= licy without a controller in place)?

If this work = were to progress, I would suggest having one document in SPRING WG that dis= cusses just the profile without getting into any PCEP/BGP specific details = (TEAS WG participants would be interested given that you are modeling/defin= ing a specific type of TE path profile; would be useful to keep them notifi= ed) and a document in PCE WG that discusses the PCEP specific procedures fo= r this type of SR policies. The "new" PCEP protocol-extensions be= ing proposed (in draft-sidor-pce-circuit-style-pcep-extensions) are path-co= ntrol technology agnostic (don't quite agree with the proposed encoding= s -- but that would be a mail on the PCE list) and can potentially be discu= ssed separately.

Regards,
-Pavan
--000000000000c3d69905db0b3830-- From nobody Sun Mar 27 10:04:49 2022 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 8548E3A07EC; Sun, 27 Mar 2022 10:04:27 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164840066737.28196.10277968366816860952@ietfa.amsl.com> Date: Sun, 27 Mar 2022 10:04:27 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-bfd-03.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: Sun, 27 Mar 2022 17:04:28 -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 : Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane Authors : Greg Mirsky Jeff Tantsura Ilya Varlashkin Mach(Guoyi) Chen Jiang Wenying Filename : draft-ietf-spring-bfd-03.txt Pages : 15 Date : 2022-03-27 Abstract: Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any existing path between systems. This document defines how to use Label Switched Path Ping to bootstrap a BFD session, control an SR Policy in the reverse direction of the SR-MPLS tunnel, and applicability of BFD Demand mode in the SR-MPLS domain. Also, the document describes the use of BFD Echo with BFD Control packet payload. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-spring-bfd-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-bfd-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 28 00:17:57 2022 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 8645C3A1771 for ; Fri, 25 Mar 2022 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=arista.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 4JtL8ce1W8YF for ; Fri, 25 Mar 2022 11:20:14 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 0D3AA3A1770 for ; Fri, 25 Mar 2022 11:20:13 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id mp6-20020a17090b190600b001c6841b8a52so12945505pjb.5 for ; Fri, 25 Mar 2022 11:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=JvoOFUMigCYdnLaQiQXorCrh7xF5aHuJULyfiF0Kb08=; b=J9KE3utwnwXcH9CJbm35AghF1f1V+dut2GMqzJlN3yjj3zTIPGZskIMyyjMq0teyU2 Hc/+D8xyABnj5+SWcfqa7FzKzSyMiTTNTp+QFrERBbvFdF2103fXUeGSaOEkvndiO6xF 04Hp7QCUaWpNAk4SEcpmwXYiLSbageiL2xdMYkQ1jHo0mDs97+z/jTQUJfOcrOjA8KEA VAahN0+eOKgvcFrBJewUrXXPqKVTF3b6tq0bM8UJhNMIwBazS3LNrJfKZVJnoOGJ7MIf xO/vUXXJdL/bHbOmnYEdrbJoU+pV+swqtERWfqZrqG2oB5GI0/p0DLB/vy26lbu1B3FY q0PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JvoOFUMigCYdnLaQiQXorCrh7xF5aHuJULyfiF0Kb08=; b=LwgFneIgu6UqMBGTN6HWJmhs+1TlJ08JP3S0A0VO2oGYREf1drkNcs6QDpKWhXmorF /M9D1E6gH2LePVQlzT4Azy7DaswH3q3R2/vNElSmwJeAfjdlcte8IDI6JeLobsdJ7eYW 0nu8xs0EwmQlSZqEJLPgpdiCckYNZ3VzHdW1wDthM+LdyU9byGspSpEzdyrX5AkaCe4G sohgy775N10kuw4jcX2niNtz8+7AU89sniKBr2yUtBRGcKQE3SQGEppKIHoXEo4CsCvk uclwVAGtAWkD3G4dFXWVx9PIhA/CyholdF+OVobewpKgHEXnX4MbJckyMRczP8bCU73A Biaw== X-Gm-Message-State: AOAM530gkAdm9SKmEN0AajYE2fZlgjawEhW8n9VrrNfUVF7/yu9gmMAJ htPUuXppM/sa9OSy3s0MavGgzZboNAoufEaf39pk03cLyth9NrxP X-Google-Smtp-Source: ABdhPJy43zUb4lrs0idwpdkamvBPjZQdupiUDph80rcrr8lacBcsw3hY5f9CamZb5N/MIA7jpnV+9TqEt2kFpw6B3QY= X-Received: by 2002:a17:903:244d:b0:154:3bb0:7b8c with SMTP id l13-20020a170903244d00b001543bb07b8cmr13248399pls.115.1648232400993; Fri, 25 Mar 2022 11:20:00 -0700 (PDT) MIME-Version: 1.0 From: Trevor Mendez Date: Fri, 25 Mar 2022 14:19:50 -0400 Message-ID: To: spring@ietf.org Content-Type: multipart/alternative; boundary="000000000000c5354c05db0f021b" Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2022 00:17:55 -0700 Subject: [spring] NEXT-ONLY-CSID in draft-filsfils-spring-net-pgm-extension-srv6-usid-12 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, 25 Mar 2022 18:20:19 -0000 --000000000000c5354c05db0f021b Content-Type: text/plain; charset="UTF-8" Hi all, What is the meaning of NEXT-ONLY-CSID? It isn't clear to me what the difference is between 42 and 43 below? +=======+========+======================================+===========+ | Value | Hex | Endpoint behavior | Reference | +=======+========+======================================+===========+ | 42 | 0x002A | End with NEXT-ONLY-CSID | [This.ID] | +-------+--------+--------------------------------------+-----------+ | 43 | 0x002B | End with NEXT-CSID | [This.ID] | +-------+--------+--------------------------------------+-----------+ (Looks like a similar question was asked before here , but I didn't see an answer.) Thanks, Trevor --000000000000c5354c05db0f021b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

What is the meaning of NEXT-ONL= Y-CSID?=C2=A0 It isn't clear to me what the difference is between 42 an= d 43 below?

   +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D+
   | Value |  Hex   |          Endpoint behavior           | Reference |
   +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
   | 42    | 0x002A |       End with NEXT-ONLY-CSID        | [This.ID] |
   +-------+--------+--------------------------------------+-----------+
   | 43    | 0x002B |          End with NEXT-CSID          | [This.ID] |
   +-------+--------+--------------------------------------+-----------+

(Looks like a similar question was asked befor= e here, but I didn't see an=C2=A0answer.)

Thanks,
Trevor
<= /div> --000000000000c5354c05db0f021b-- From nobody Mon Mar 28 03:07:59 2022 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 0F1DD3A113F; Mon, 28 Mar 2022 03:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=orange.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 1C3Mw_HdX2bd; Mon, 28 Mar 2022 03:07:51 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 8D7D13A07FB; Mon, 28 Mar 2022 03:07:50 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar22.francetelecom.fr (ESMTP service) with ESMTPS id 4KRpKc4lXZz2xXx; Mon, 28 Mar 2022 12:07:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1648462068; bh=mV4zZxrBM9zFYKUep0VN2IZ3ImSZEw0xXLKs8Y/euEA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=aFaueUp4/qsfW6HKPlj4YCA0WQBJ07kECx2P1uTinVyQfFnf5z+nhJpQSxeAoIfg7 J0fNrgFgSJQqpkSrs3hCuvJOVkwMykwZXVmIpqI/nvIeka7gUGIJAHbLTEkrAOTbTd 20A7oyicGUldVLS8WdLh89h5qax5802vPK7a5TEQJyG0qk2XEfbX3HT/OQz/uSjcDo LJvNOb9Bb/l6Haq+X4wAQtRn47ccAAvsk2vWCSaQMg+ckaUCa4jsr4cQRfI4l/qdOY Q3tzluO/FRaP+opaJgsOjdp7tdVP0fbhGTTSex78TFChEyWWXb/ht4GNHNb5GqEXGY 35RSXT5MOSdBg== From: To: "Boutros, Sami" CC: "spring@ietf.org" , "bess-chairs@ietf.org" , James Guichard , "Joel Halpern Direct" Thread-Topic: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Thread-Index: AQHYN8d97Vj2myKfRUyVlMJBHJByT6zCB0CAgA4Tcs6ABIlFMA== Date: Mon, 28 Mar 2022 10:07:47 +0000 Message-ID: <11545_1648462068_624188F4_11545_401_1_b594a898f2674328ad5ac72f2b38b987@orange.com> References: <5986_1647438032_6231E8D0_5986_381_4_a7932aa651064602ad086333cf5c607a@orange.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-03-28T10:07:45Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-03-28T10:07:45Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 5215b0de-ab05-4c45-b245-b05650afd916 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.53] Content-Type: multipart/alternative; boundary="_000_b594a898f2674328ad5ac72f2b38b987orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption for draft-boutros-spring-elan-services-over-sr-00 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 Mar 2022 10:07:57 -0000 --_000_b594a898f2674328ad5ac72f2b38b987orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sami, < Abstract This document proposes a new approach for realizing Ethernet LAN (ELAN) services > BESS : BGP Enabled Services https://datatracker.ietf.org/doc/charter-ietf-= bess/ SPRING : Source Packet Routing in Networking https://datatracker.ietf.org/d= oc/charter-ietf-spring/ We could also dig a bit more, just looking at the ToC: 4. Control Plane Behavior . . . . . . . . . . . .= . . . . . . . 5 4.1. Service discovery . . . . . . . . . . = . . . . . . . . . . 5 4.2. All-Active Service Redundancy . . . . = . . . . . . . . . . 6 4.3. Mass service withdrawal . . . . . . . = . . . . . . . . . . 6 4.4. E-Tree Support . . . . . . . . . . . = . . . . . . . . . . 6 5. Data Plane Behavior . . . . . . . . . . . . = . . . . . . . . . 6 5.1. Unicast Traffic . . . . . . . . . . . = . . . . . . . . . . 7 5.2. BUM Traffic . . . . . . . . . . . . . = . . . . . . . . . . 8 5.3. Data Plane MAC learning . . . . . . . = . . . . . . . . . . 8 5.3.1. Single Home CE . . . . . . . . = . . . . . . . . . . . 9 5.3.2. Multi-Home CE . . . . . . . . . = . . . . . . . . . . . 9 5.4. ARP suppression . . . . . . . . . . . = . . . . . . . . . . 10 5.5. Distributed Anycast Gateway . . . . . = . . . . . . . . . . 10 5.6. Multi-pathing . . . . . . . . . . . . = . . . . . . . . . . 10 5.7. E-Tree Support . . . . . . . . . . . = . . . . . . . . . . 11 It looks to me that the above is primarily about VPN overlay service, rathe= r than source routing in the underlay. So yes, to re-iterate, at this point, SPRING and BESS chairs believe this w= ork would be better addressed in the BESS WG. Thanks, --Bruno Orange Restricted From: Boutros, Sami Sent: Friday, March 25, 2022 1:52 PM To: DECRAENE Bruno INNOV/NET Cc: spring@ietf.org; bess-chairs@ietf.org; James Guichard ; Joel Halpern Direct Subject: Re: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Hi Bruno, The main salient points in this draft are about: * Defining a service SRGB for services. * Getting rid of overlay convergence and using underlay anycast SID con= vergence to converge all services riding on this anycast SID. * Use of an underlay node/anycast SID to learn mac against in Dataplane= . (Keep in mind we are not proposing any change to data plane MAC learning = mechanisms like aging, move, security, etc...) But rather how with the SR e= ncap we will learn the MAC against the source SID under the service SID in = the SR encap. NVO3 defining VxLAN, Geneve, etc.. where MAC is learned again= st Source IP address in the encap didn't go to discuss this in BESS. Are you saying we should discuss the above in the BESS working group? We are not making any relevant changes to the ELAN service, it is true we w= ould need to define a new BGP message to auto-discover the services that wi= ll apply to BESS and we will have a draft on that to discuss in BESS. Thanks, Sami From: bruno.decraene@orange.com > Date: Wednesday, March 16, 2022 at 2:40 PM To: Boutros, Sami > Cc: spring@ietf.org >, bess-chairs@ietf.org >, James Guichard >, Joel Halpern Direct > Subject: [**EXTERNAL**] RE: WG adoption for draft-boutros-spring-elan-servi= ces-over-sr-00 [+bess chairs] Dear Sami, authors, SPRING and BESS chairs believe this work would be better addressed in the B= ESS WG. Thanks, Regards, --Bruno, Jim, Joel Orange Restricted From: Boutros, Sami > Sent: Monday, March 14, 2022 6:23 PM To: DECRAENE Bruno INNOV/NET >; James Guichard >; Joel Halpern Direct > Cc: spring@ietf.org Subject: WG adoption for draft-boutros-spring-elan-services-over-sr-00 Dear WG Chairs, The authors would like to request a WG adoption for this draft, the draft w= as presented at last IETF. We could present the draft at this IETF too, if you folks like. Thanks, Sami ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_b594a898f2674328ad5ac72f2b38b987orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sami,

 

« Abstract

&n= bsp;

   This document proposes a new approach for realizing Ethernet LAN

   (ELAN) services »

 

BESS=  : BGP Enabled Services  https://= datatracker.ietf.org/doc/charter-ietf-bess/

SPRI= NG : Source Packet Routing in Networking https://d= atatracker.ietf.org/doc/charter-ietf-spring/

 

 

We c= ould also dig a bit more, just looking at the ToC:

4.  Control Plane B=
ehavior  . . . . . . . . . . .=
 . . . . . . . .   5
     4=
.1.  Service discovery . . . . . . . . =
. . . . . . . . . . . .   5
     4=
.2.  All-Active Service Redundancy . . =
. . . . . . . . . . . .   6
     4=
.3.  Mass service withdrawal . . . . . =
. . . . . . . . . . . .   6
     4=
.4.  E-Tree Support  . . . . . . . . . . . . . . . . . . . . .   6=

   5.  Data Plane Behavior . . . . . . . . . . . . . . . =
. . . . . .   6=

     5=
.1.  Unicast Traffic . . . . . . . . . =
. . . . . . . . . . . .   7
     5=
.2.  BUM Traffic . . . . . . . . . . . =
. . . . . . . . . . . .   8
     5=
.3.  Data Plane MAC learning . . . . . =
. . . . . . . . . . . .   8
       5.3.1.  Single Home CE  . . . . . . . . . . . . . . . . =
. . .   9<=
/o:p>
       5.3.2.  Multi-Home CE . . =
. . . . . . . . . . . . . . . . . .  =
 9=

     5=
.4.  ARP suppression . . . . . . . . . =
. . . . . . . . . . . .  10
     5=
.5.  Distributed Anycast Gateway . . . =
. . . . . . . . . . . .  10
     5.6.&n=
bsp; Multi-pathing . . . . . . . . . . . . . . . . . . . . . .  1=
0
     5.7.&n=
bsp; E-Tree Support  . =
. . . . . . . . . . . . . . . . . . . .&nb=
sp; 11

 

 

It l= ooks to me that the above is primarily about VPN overlay service, rather th= an source routing in the underlay.

 

So y= es, to re-iterate, at this point, SPRING and BESS chairs believe this work would = be better addressed in the BESS WG.

 

Than= ks,

--Br= uno

 

 

Orange Restricted

From: Boutros, Sam= i <sboutros@ciena.com>
Sent: Friday, March 25, 2022 1:52 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>
Cc: spring@ietf.org; bess-chairs@ietf.org; James Guichard <james.= n.guichard@futurewei.com>; Joel Halpern Direct <jmh.direct@joelhalper= n.com>
Subject: Re: WG adoption for draft-boutros-spring-elan-services-over= -sr-00

 

Hi Bruno,

 

The main salient points in this draft are about:

 

  • Defining a service S= RGB for services.
  • Getting rid of overlay convergence and using underlay a= nycast SID convergence to converge all services riding on this anycast SID.
  • Use of an underlay = node/anycast SID to learn mac against in Dataplane. (Keep in mind we are not proposing any change to data plane MAC learning m= echanisms like aging, move, security, etc…) But rather how with the S= R encap we will learn the MAC against the source SID under the service SID = in the SR encap. NVO3 defining VxLAN, Geneve, etc.. where MAC is learned against Source IP address in the encap = didn’t go to discuss this in BESS.

 

Are you saying we should discuss the above in the BESS = working group?

 

We are not making any relevant changes to the ELAN serv= ice, it is true we would need to define a new BGP message to auto-discover = the services that will apply to BESS and we will have a draft on that to discuss in BESS.

 

Thanks,

 

Sami

<= b>From: bruno.decraene@orange.com <bruno.decraene@orange.com>
Date: Wednesday, March 16, 2022 at 2:40 PM
To: Boutros, Sami <sboutros= @ciena.com>
Cc: spring@ietf.org <spring@ietf.org>, bess-chairs@ietf.org <bess-chairs@ietf.org>, James Guich= ard <james.n.guichard@= futurewei.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>
Subject: [**EXTERNAL**] RE: WG adoption for draft-boutros-spring-ela= n-services-over-sr-00

[+bess chairs]<= /span>

 

Dear Sami, authors,

 

SPRING and BESS chairs believe = this work would be better addressed in the BESS WG.

 

Thanks,

Regards,

--Bruno, Jim, Joel

 

 

Orange Restricted

From: Boutros,= Sami <sboutros@ciena.com>
Sent: Monday, March 14, 2022 6:23 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; James Guichard <james.n.guichard@futurewei.com&g= t;; Joel Halpern Direct <j= mh.direct@joelhalpern.com>
Cc: spring@ietf.org
Subject: WG adoption for draft-boutros-spring-elan-services-over-sr-= 00

 

Dear WG Chairs,=

 

The authors would like to request a WG adoption for thi= s draft, the draft was presented at last IETF.

 

We could present the draft at this IETF too, if you fol= ks like.

 

Thanks,

 

Sami= 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_b594a898f2674328ad5ac72f2b38b987orangecom_-- From nobody Mon Mar 28 23:39:20 2022 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 3C45E3A11B6; Mon, 28 Mar 2022 23:39:18 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164853595813.31655.9515795143111136229@ietfa.amsl.com> Date: Mon, 28 Mar 2022 23:39:18 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-compression-requirement-01.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 Mar 2022 06:39:19 -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 : Compressed SRv6 SID List Requirements Authors : Weiqiang Cheng Chongfeng Xie Ron Bonica Darren Dukes Cheng Li Peng Shaofu Wim Henderickx Filename : draft-ietf-spring-compression-requirement-01.txt Pages : 16 Date : 2022-03-28 Abstract: This document specifies requirements for solutions to compress SRv6 SID lists. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-compression-requirement/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-compression-requirement-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-compression-requirement-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 28 23:40:10 2022 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 352D03A1387; Mon, 28 Mar 2022 23:39:55 -0700 (PDT) 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.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <164853599518.29024.11898011843337007908@ietfa.amsl.com> Date: Mon, 28 Mar 2022 23:39:55 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-compression-analysis-01.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 Mar 2022 06:40:01 -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 : Compressed SRv6 SID List Analysis Authors : Ron Bonica Weiqiang Cheng Darren Dukes Wim Henderickx Cheng Li Peng Shaofu Chongfeng Xie Filename : draft-ietf-spring-compression-analysis-01.txt Pages : 28 Date : 2022-03-28 Abstract: Several mechanisms have been proposed to compress the SRv6 SID list. This document analyzes each mechanism with regard to the requirements stated in the companion requirements document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-compression-analysis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-spring-compression-analysis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-compression-analysis-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Mar 30 02:04:30 2022 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 A81863A17C3; Wed, 30 Mar 2022 02:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 qkq-IzsIlYEC; Wed, 30 Mar 2022 02:04:17 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694243A17A3; Wed, 30 Mar 2022 02:04:17 -0700 (PDT) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4KT0qM3qvZzBvnwv; Wed, 30 Mar 2022 17:04:15 +0800 (CST) Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 22U93oDH077063; Wed, 30 Mar 2022 17:03:50 +0800 (GMT-8) (envelope-from liu.yao71@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 30 Mar 2022 17:03:50 +0800 (CST) Date: Wed, 30 Mar 2022 17:03:50 +0800 (CST) X-Zmail-TransId: 2afb62441cf6fffffffff91-b3731 X-Mailer: Zmail v1.0 Message-ID: <202203301703500769671@zte.com.cn> Mime-Version: 1.0 From: To: Cc: , Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl1.zte.com.cn 22U93oDH077063 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 62441D0F.001 by FangMail milter! X-FangMail-Envelope: 1648631055/4KT0qM3qvZzBvnwv/62441D0F.001/10.30.14.238/[10.30.14.238]/mse-fl1.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 62441D0F.001/4KT0qM3qvZzBvnwv Archived-At: Subject: [spring] =?utf-8?q?SID_Related_Algorithm_in_draft-peng-idr-segme?= =?utf-8?q?nt-routing-te-policy-attr?= 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, 30 Mar 2022 09:04:29 -0000 Hi all, We presented https://datatracker.ietf.org/doc/draft-peng-idr-segment-routing-te-policy-attr on IDR's session last week. This document defines two kinds of new Segment Sub-TLVs to carry SID related algorithm when delivering SR Policy via BGP. One is for SR-MPLS adjacency with algorithm, another kind is defined for carrying the algo along with the SR-MPLS or SRv6 SID value. While we believe that the former kind is necessary, considering draft-ietf-lsr-algorithm-related-adjacency-sid complements that in scenarios where multiple algorithm share the same link resource, the algorithm can be also included as part of an Adj-SID advertisement for SR-MPLS. We'd like to request the WG's opinion especially about the delivering SR-MPLS or SRv6 SID value with optional algorithm. (Thanks for Ketan's suggestion about this.) Segment Sub-TLVs carrying SID value with optional algorithm are defined in this draft because we think it may benefit the scenarios below: Scenario 1: For verification purposes. The headend can check if the SID value and the related algorithm received can be found in its SR-DB if requested to do so. Scenario 2: The headend may not know about the SID-related algorithm especially in the inter-domain scenario. Providing the algorithm info benefits troubleshooting and network management. Any comments and suggestions are welcome. Thanks, Yao From nobody Wed Mar 30 18:57:58 2022 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 C6B5C3A0CA9; Wed, 30 Mar 2022 18:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.906 X-Spam-Level: X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 DwzSZZ6nShUU; Wed, 30 Mar 2022 18:57:53 -0700 (PDT) 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 64A793A0C94; Wed, 30 Mar 2022 18:57:53 -0700 (PDT) Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KTRGh343yz67P81; Thu, 31 Mar 2022 09:55:56 +0800 (CST) Received: from canpemm100006.china.huawei.com (7.192.104.17) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 31 Mar 2022 03:57:49 +0200 Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm100006.china.huawei.com (7.192.104.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 31 Mar 2022 09:57:48 +0800 Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.021; Thu, 31 Mar 2022 09:57:48 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: SPRING Meeting Minutes to be reviewed Thread-Index: AdhEorC1WvehoI8PQ++/ZCwM0OIyUg== Date: Thu, 31 Mar 2022 01:57:48 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.177.25] Content-Type: multipart/alternative; boundary="_000_d99bba42b8814be89354d9f1cc01e74bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] SPRING Meeting Minutes to be reviewed 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, 31 Mar 2022 01:57:56 -0000 --_000_d99bba42b8814be89354d9f1cc01e74bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The Meeting Minutes has been uploaded. Please let us know if you want to ma= ke any changes. https://datatracker.ietf.org/doc/minutes-113-spring/ Thank you! Best Regards, Shuping --_000_d99bba42b8814be89354d9f1cc01e74bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The Meeting Minutes has been up= loaded. Please let us know if you want to make any changes.

 

https://datatracker.ietf.org/doc/minutes-= 113-spring/

 

Thank you!

 

Best Regards,

Shuping

--_000_d99bba42b8814be89354d9f1cc01e74bhuaweicom_-- From nobody Thu Mar 31 08:21:30 2022 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 7D3AB3A1B1D for ; Thu, 31 Mar 2022 08:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=joelhalpern.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 cl1EYNguBMUM for ; Thu, 31 Mar 2022 08:21:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 7F9223A1AD2 for ; Thu, 31 Mar 2022 08:21:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4KTn7t09xNz6GR99 for ; Thu, 31 Mar 2022 08:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1648740074; bh=R0DHqYjxTn79TTCVE1x2prU8Jx6AVXxYk+tzbiegnH0=; h=Date:References:Subject:To:From:In-Reply-To:From; b=qBPSngai8qdnoLODh9uSijI1eZpqXVMGbv0mDbAwFVuOAiS+1Mgd5OgSXnJqzzAMC mHXtBFlTYL1nEsOwUqppp927G2fMOMkMEVNkKP/99RFafbriIs4l5JMPR+y0j9ZkzI 4gS0M7gDmwWr83lEdvTIVzX9JTpE8AZ7dZ8fjD3U= X-Quarantine-ID: <3-v5nG4vHJvR> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.21.218] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4KTn7s3hrcz6GBZb for ; Thu, 31 Mar 2022 08:21:13 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------HKDO0JIwEuVAQQlD5HF5aDc3" Message-ID: <4e8b4ea9-a74e-1446-f4b5-73febf0489b9@joelhalpern.com> Date: Thu, 31 Mar 2022 11:21:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 References: <92790B16-19F8-40AD-BF8B-F9CBB619EE37@gmail.com> Content-Language: en-US To: "spring@ietf.org" From: "Joel M. Halpern" In-Reply-To: <92790B16-19F8-40AD-BF8B-F9CBB619EE37@gmail.com> X-Forwarded-Message-Id: <92790B16-19F8-40AD-BF8B-F9CBB619EE37@gmail.com> Archived-At: Subject: [spring] Fwd: Call for adoption: 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, 31 Mar 2022 15:21:29 -0000 This is a multi-part message in MIME format. --------------HKDO0JIwEuVAQQlD5HF5aDc3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Attached and copied below for spring participants information is the adoption call in 6man for draft-krishnan-6man-sids. Please have any conversation about that on the 6man list. Thank you, Joel This message starts a two week 6MAN call on adopting: Title: Segment Identifiers in SRv6 Authors: S. Krishnan File Name: draft-krishnan-6man-sids-00 Document date: February 10, 2022 https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids-00 as a 6MAN working group document. For background this draft was the result a query to the 6MAN working group from the SPRING w.g. chairs regarding regarding draft-filsfilscheng-spring-srv6-srh-compression. The query was: https://mailarchive.ietf.org/arch/msg/ipv6/5IpkHf5tVa-G4sKca-EWGEziYSo/ After an active discussion, the reply from the 6MAN chairs and ADs was: https://mailarchive.ietf.org/arch/msg/ipv6/rGgpWZyPaKonLaeuT37D7qZ1Vcw/ This topic was also presented at IETF 112, slides here: https://datatracker.ietf.org/meeting/112/materials/slides-112-6man-srv6-sids-00 Substantive comments and statements of support for adopting this document should be sent to the mailing list. Editorial suggestions can be sent to the author. This adoption call will end on 13 April 2022. Further, if you are willing to work on this document, either as contributor, author, or reviewer please notify the list. This will provide the chairs with an indication of the energy level in the working group to work on this document. Bob, Jen, Ole --------------HKDO0JIwEuVAQQlD5HF5aDc3 Content-Type: message/rfc822; name="Call for adoption: .eml" Content-Disposition: attachment; filename="Call for adoption: .eml" Content-Transfer-Encoding: 7bit >From - Wed Mar 30 16:32:48 2022 X-Account-Key: account3 X-UIDL: UID888827-1313906940 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: X-Original-To: jmh@joelhalpern.com Delivered-To: jmh@joelhalpern.com Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.164]) by web12.tigertech.net (Postfix) with ESMTP id 4KTJ4M67GmzNy5qm for ; Wed, 30 Mar 2022 13:31:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxb2.tigertech.net (Postfix) with ESMTP id 4KTJ4M5sFsz1rxr8 for ; Wed, 30 Mar 2022 13:31:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Authentication-Results: b2.tigertech.net (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b=eOY/qgSo; dkim=pass (1024-bit key) header.d=ietf.org header.b=qG038Xag; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=gmail.com header.b=jBuUpqn7 X-TigerTech-Content-Filter: SpamAssassin score -225.605 (DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TT_LIST_UNSUBSCRIBE,TT_WHITELISTED_MANUALLY,TT_WHITELISTED_POLICY_DAEMON,T_SCC_BODY_TEXT_LINE,USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST,USER_IN_SPF_WHITELIST) X-Spam-Flag: NO X-Spam-Score: -225.6 X-Spam-Level: X-Spam-Status: No, score=-225.6 required=7.0 tests=[DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TT_LIST_UNSUBSCRIBE=1, TT_WHITELISTED_MANUALLY=-25, TT_WHITELISTED_POLICY_DAEMON=-1, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DKIM_WELCOMELIST=0.001, USER_IN_DKIM_WHITELIST=-100, USER_IN_SPF_WHITELIST=-100] autolearn=disabled X-Spam-Report: * -1.0 TT_WHITELISTED_POLICY_DAEMON Manually whitelisted * 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) * [4.31.198.44 listed in wl.mailspike.net] * -100 USER_IN_SPF_WHITELIST From: address is in the user's SPF * whitelist * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override * is CUSTOM_MED * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level * mail domains are different * 0.0 USER_IN_DKIM_WELCOMELIST From: address is in the user's DKIM * welcomelist * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail * provider * -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from * envelope-from domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 1.0 TT_LIST_UNSUBSCRIBE Has a "List-Unsubscribe" header * 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and * EnvelopeFrom freemail headers are different * -0.0 T_SCC_BODY_TEXT_LINE No description available. * 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders * -100 USER_IN_DKIM_WHITELIST DEPRECATED: See USER_IN_DKIM_WELCOMELIST * -25 TT_WHITELISTED_MANUALLY Manually whitelisted * -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list * manager X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted (sender ietf.org whitelisted manually) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxb2.tigertech.net (Postfix) with ESMTPS for ; Wed, 30 Mar 2022 13:31:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E91593A0FB6 for ; Wed, 30 Mar 2022 13:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1648672289; bh=DdS5F7MSLQIomm4bowX3o9r8c8yAdR+xcuVfoKValf0=; h=From:Subject:Date:To:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=eOY/qgSoxNwZYljNIkb7WffFyNhUFIubcwsvkYEwOhvMYuBf7iYoR5IEFjVRk9SnW k0DH+qU3g7Yp+LJH9wbigR6YdZiidoHX7A15Uwosh4VT2QikGhCx8uxvb59VTYfNYf 0Ej76Zp7WMBKAeRiJKJLqbb4WUFRHGlvs4HwA0A8= X-Mailbox-Line: From ipv6-bounces@ietf.org Wed Mar 30 13:31:20 2022 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACA93A0FCE; Wed, 30 Mar 2022 13:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1648672268; bh=DdS5F7MSLQIomm4bowX3o9r8c8yAdR+xcuVfoKValf0=; h=From:Subject:Date:To:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=qG038Xag2mG+ok0kR5OCo7n074z+AIpqRKf9JPheMY43f9gJrGuBcBAI++/fNWMDe gRxRHVcf8GP+v+Q+6lorzVgrEsrWzw3Y7AjQRv2B8krdQd3SEjjw9u8DKnoMjABoVy Fh3mJsKAZG4exi9HPm4kwi2DzC8s+3M4TSe8LUIw= X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC5A3A0F46 for ; Wed, 30 Mar 2022 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 N5ol6pOTQos3 for ; Wed, 30 Mar 2022 13:31:02 -0700 (PDT) Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) (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 DF4863A0F64 for ; Wed, 30 Mar 2022 13:31:02 -0700 (PDT) Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-df02f7e2c9so10803151fac.10 for ; Wed, 30 Mar 2022 13:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:mime-version:subject:message-id:date:cc:to; bh=Zw1fg/6klb2Tbs2DAnFvL8kMSIHBbgAepishOgLQVeY=; b=jBuUpqn7he80WblWAdxQJ/F0U4eF1BnUB938113eTtXR6Fvtr6KmJ58JrXg4HQMEAo l/SBFWpBZDTB8O8qn5+HJRiAMlY6G0yFcPFjXQzAjoIQn6rzpxJHZQVWCyB2TgqYQcLw 0d1IbZOgPDcyOtYq6TW+wHM5WJFyr1MXEh93sLztjl76EheSdlW5svMs4L0cs984gZ2l yDLAA8D5CcD02YQODVmoj/u5VY8AP36d1xMB7VszQlwp6gMqoDCg0g2po4eO9usX147a jeFo7TcDbba+/gOYbuvXzCjTj/vRLC0lSs5lzHZ4A3qiQesfz5PUbgQTwWu/EQtO9EPv FRDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=Zw1fg/6klb2Tbs2DAnFvL8kMSIHBbgAepishOgLQVeY=; b=fwEklViJt5DanqRzq41aU7J5XYPqyotCrQmxRslNOgmyVTZ3CFlUWrhPjVcsOpA2Zd XXZAnBhFrNeYbB9ytbpKyA2Q6O6FhhzL5Hwd5duowxeqYHS0/PSd4A3EZuZ3fPxHgpVk TGUZunGHujxHxJ60F62hPKlBnVXlH26dl+8s7hWXup7ZYmUfFrngV+0DhT14OgeK8ydJ ORG8Ouy9lwySiGCKFnPjZMV3JJV6I//n89SVC0TDpHPXodPT0IyuoAKhZm+4ZWO5z77M JErdOZSX6EAXGSZYBCBxaTwp+bV+RU4Z3/fxDpvUp6j+v6f4LzlfWL6Zben9nNpjvWj5 vaog== X-Gm-Message-State: AOAM531MGYbrx1Zh8OjuzVup94z9wGODiWoulQPGDPDLpsebXVXb061F V706ys3FshKy3PZ1xsM91gkbU/K+R5w= X-Google-Smtp-Source: ABdhPJz9QPYPdKYb7TfisXel8l1gNziyCC8h8Tyl5WLb2ZtE4oMX83GhPJoUCGjvnMjfnLJBLX0i7w== X-Received: by 2002:a05:6870:5390:b0:de:f680:db03 with SMTP id h16-20020a056870539000b000def680db03mr816361oan.237.1648672261118; Wed, 30 Mar 2022 13:31:01 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:4383:c05f:fce8:fb84:36aa:9ad0]) by smtp.gmail.com with ESMTPSA id s125-20020acaa983000000b002ecdbaf98fesm10716994oie.34.2022.03.30.13.30.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Mar 2022 13:31:00 -0700 (PDT) From: Bob Hinden Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Call for adoption: Message-Id: <92790B16-19F8-40AD-BF8B-F9CBB619EE37@gmail.com> Date: Wed, 30 Mar 2022 13:30:58 -0700 To: IPv6 List X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bob Hinden Content-Type: multipart/mixed; boundary="===============3713033530068543361==" Errors-To: ipv6-bounces@ietf.org Sender: "ipv6" --===============3713033530068543361== Content-Type: multipart/signed; boundary="Apple-Mail=_AE7A8BE0-70F9-4FA6-924B-463805E5E711"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Apple-Mail=_AE7A8BE0-70F9-4FA6-924B-463805E5E711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This message starts a two week 6MAN call on adopting: Title: Segment Identifiers in SRv6 Authors: S. Krishnan File Name: draft-krishnan-6man-sids-00 Document date: February 10, 2022 https://datatracker.ietf.org/doc/html/draft-krishnan-6man-sids-00 as a 6MAN working group document. For background this draft was the result a query to the 6MAN working = group from the SPRING w.g. chairs regarding regarding = draft-filsfilscheng-spring-srv6-srh-compression. The query was: = https://mailarchive.ietf.org/arch/msg/ipv6/5IpkHf5tVa-G4sKca-EWGEziYSo/ After an active discussion, the reply from the 6MAN chairs and ADs was: = https://mailarchive.ietf.org/arch/msg/ipv6/rGgpWZyPaKonLaeuT37D7qZ1Vcw/ This topic was also presented at IETF 112, slides here: = https://datatracker.ietf.org/meeting/112/materials/slides-112-6man-srv6-si= ds-00 Substantive comments and statements of support for adopting this = document should be sent to the mailing list. Editorial suggestions can = be sent to the author. This adoption call will end on 13 April 2022. Further, if you are willing to work on this document, either as = contributor, author, or reviewer please notify the list. This will = provide the chairs with an indication of the energy level in the working = group to work on this document. Bob, Jen, Ole --Apple-Mail=_AE7A8BE0-70F9-4FA6-924B-463805E5E711 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmJEvgIACgkQrut0EXfn u6gYmgf+K0RhoLK3tDRvV7xgVI1wC1nzaQ136xTxwznOPH8jBkrVb8c8r11lKj4b yNWA0PO8BdRupGQBZ0oZtqkPK18FI73uenIdLTocRrTvXMQmUwjYNpXa9gyubkcg au4gbXBpJgt/NTqH5mQ40PauX6jqqu1YkVKLNoLJAn+vvzWCLQnuMka+0BYM7KBX tIt5hctQcnktXHg83OIsthw75t1nNDfP91tBPmYCNeAfBL3EVIsND9v+tVC2Aki0 jEgMq4ffHtBIigLiZmDjGG2vrqtnSrEpRd5AA7xC6j4nzT0qH9YoNgGFivA1iidV R4hO2QXq1sKQl/yvsvPrmOU5iWqiow== =ZWO4 -----END PGP SIGNATURE----- --Apple-Mail=_AE7A8BE0-70F9-4FA6-924B-463805E5E711-- --===============3713033530068543361== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============3713033530068543361==-- --------------HKDO0JIwEuVAQQlD5HF5aDc3--